ADSM-L

Re: MS SQL Server Connect Agent - HELP!

1998-06-15 10:02:56
Subject: Re: MS SQL Server Connect Agent - HELP!
From: Christo Heuer <christoh AT ABSA.CO DOT ZA>
Date: Mon, 15 Jun 1998 16:02:56 +0200
Hi Del,

Thanks for the response - muchly apreciated.

Now I'm more impressed - I'm eagerly awaiting
the PTF!

Regards
Christo Heuer



>Debbie,  Christo,
>
>Please see my responses below marked with "***".
>Thanks.
>
>Del Hoobler
>ADSM Agent Development
>
>>I must be blind, or ignorant, possibly both, but I cannot find explicit
>>documentation that answers my questions on the SQL Server Connect Agent.
>>I could probably plunder my way through, but I would rather hear from
>>some experienced users of this connect agent.  Can someone please answer
>>a few questions for me, or point me to better documentation than the
>>Install and Using Guide?
>
>Don't blame yourself for this - it is rather "In not much detail"
>documented.
>
>***
>*** We are updating the documentation and will make it better
>*** for the first SQL Agent PTF (due out later this year).
>***
>
>>
>>1) With the Exchange connect agent, retention is controlled manually on
>>the client.  Is this also true for the SQL agent, or do I set the copy
>>control in the policy set to reflect what I really want the retention
>>periods to be?
>
>I have not found any other way of doing it. So yes,  it is also controlled
>manually - although you can write a script to delete the versions you
>do not want any more.
>Maybe version2 will have this included as part of the package?
>
>***
>*** The SQL Agent works exactly like the Exchange Agent in regards to
>*** this issue, i.e. each backup creates a new ADSM object.
>*** Therfore, you must manually delete prior backups.
>*** For release 2, we are working on making this better to
>*** utilize the power of the ADSM server policies for versioning
>*** and expiration.
>***
>
>>
>>2) When automating the operations or using the command line interface is
>>there a way to specify all databases or do you have to explicitly backup
>>each one?   (no wild card or mask?)
>
>Big pain in the ... !!! - I can not believe that you can not use masking in
>the command line. You can do a /adsmquerydb:*  but not /backupfull:*
>What the reasoning behind this I would not know - but we have one
>SQL server that has about 68 different databases - not the user's fault,
>the application creates all these databases by itself. Now it is a manual
>operation from my side every once in a while to go and compare what
>is currently in the batch file and what new databases has been created.
>Grrrrr...... Is all I have to say IBM!
>
>***
>*** We understand the frustration here.
>*** We are enhancing this to allow wildcards for the database name.
>*** The good news is you won't have to wait for Release 2.
>*** Stayed tuned for the SQL Agent PTF 1 due out later this year.
>***
>
>>
>>The Exchange connect agent is actually controlled by a command file that
>>is executed by the Central Scheduler.  Is this not the case with the SQL
>>Server Agent?  In the Getting Started doc for the SQL Server Agent there
>>are examples of centralized scheduling through the ADSM Central
>>Scheduler under Tasks, but there is not a lot of background info there.
>>Several questions come to mind on setting up the schedule.
>
>That is how I'm using it, but if there are other ways I'll look into it.
>
>I'll have to check into this but currently I have it set up as a .bat file
>that
>contains the 68 databases to be backed up and this is kicked off by the
>Adsm Central Schedular Service.
>
>***
>*** Again, the SQL Agent documentation didn't have the dedicated
>*** appendix for setting up scheduling.  This will be updated
>*** in the SQL Agent PTF 1.  In the mean time, you can use the
>*** the Exchange Agent documentation and sample batch files
>*** as templates for setting up the SQL Agent scheduled backups.
>***
>
>>
>>1) This server is already being backed up by ADSM using the
>>Backup/Archive client, with an NT service running for centralized
>>scheduling from ADSM Admin.  I gave the SQL Server Agent a different
>>node name (the node name for ADSM regular backups is NEMESIS, for SQL
>>Server it's SQL_NEMESIS) to allow me to more easily manage the backups
>>differently.  Do I need a seperate service for the SQL Server backups?
>>If not, how does it know to use the SQL Agent to backup those databases?
>
>You will have to define another service to run the second SQL backup.
>
>***
>*** Yes, set up a second service to "schedule" a batch file that
>*** issues the correct sqldsmc commands for backing up your databases.
>*** Again, use your Exchange Agent documentation for examples of
>*** setting up this procedure.  If you don't have the Exchange Agent,
>*** a procedure with examples was posted to this list
>*** on 3/12/1998 by zaremba AT US.IBM DOT COM.
>*** Review the list archives for this append.
>***
>
>>
>>2) The example says to specify the name of the database in the OBJECTS
>>field.  Is it really just the name of the database that goes in that
>>field, no other qualifiers?
>>
>
>Have not played around with this so will let you know when I have.
>
>***
>*** No, you don't want to do it this way.  Again, follow the
>*** Exchange Agent "cookbook" directions for setting this up.
>*** The key is that you will have a separate defined schedule
>*** that is a "command" type schedule that calls a batch file
>*** to do your backups.
>***
>
>>3) The operation specified in the example is incremental.  Does this
>>mean that it will only backup the transaction logs?  How do I specify
>>that I want a full backup and truncate the logs?
>
>Again, I have not tried it this way. In the adsm connect agent command line
>you can specify
>incr or full which would react like you think (Incr. just doing logs), but
I
>don't think the action you specify on the Schedule knows anything
>about SQL and more to the point the transaction logs.
>
>***
>*** Again, define a "command" schedule that calls a batch file that
>*** does this for you.  I would say that you should have to schedules
>*** defined, one to call a batch file that does your full backups and
>*** one to call a batch file that does your incrementals.
>***
>
>>
>>Again, please excuse my ignorance, and thanks in advance for your help.
>
>No need to excuse yourself - we are all here to learn from each other's
>experience.
>
>One more thing about the SQL connect agent - I think IBM can enhance
>the product a bit more to be able to restore a database directly from the
>connect agent after it has been dropped from the SQL server side. Currently
>you have two options - back up the database file with your normal ADSM
>client
>(Your database has to be stopped to enable this), and in the event that you
>want
>to restore the database restore the file first from your normal backup and
>then restore
>your database via the connect agent to get a more recent copy or you define
>a dummy DB
>with the same name that existed, and restore your data from the connect
>agent.
>I can not see why the data is not available for restore when the SQL DB has
>been dropped.
>
>If you don't know what I'm talking about do a test - Create a test DB -
back
>it up using the
>connect agent and then drop the DB from the SQL server side. Try to do a
>restore from
>the connect agent now - you are not able to do the restore because ADSM
does
>not see
>the DB? Maybe there is a reason for this but I can't think of it...
>
>***
>*** Use the "Direct Query" function (right mouse button on the restore
panel)
>*** to allow a query off all previously backed up databases.  It will
>*** query the ADSM server for all previously backed up databases regardless
>*** of whether or not they currently exist.
>***
>
>Other than these few pain in the .... the agent works great.
>
>Regards
>Christo Heuer
>ABSA Group
>Johannesburg
>SOUTH AFRICA
>
>>
>>Debbie Weeks
>>University of South Florida
>>Information Technologies/Technical Support
>>*********
>>*Debbie AT admin.usf DOT edu
>>*(813) 974-6926   *  S/C 574-6926
>>Fax(813) 974-6926
<Prev in Thread] Current Thread [Next in Thread>