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
|
