First, Unlimited is excessive for everything.  However, we have
Unlimited set for # of versions, but we only keep the backups for 30
days for our regular node, 5 years for our monthly node, and 10 years
for our quarterly nodes when it comes to SQL server.

The key settings for SQL Server are unlimited versions then limit the #
of Days, this way you can run regular log backups and actually recover.

See Ya'
Howard

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Laughlin, Lisa
> Sent: Friday, September 05, 2008 9:38 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] inactivate TDP SQL transaction logs?
> 
> I have Del- and to me they were silent on the inactivation (it's quite
> different than Oracle/RMAN).  The question on the management class
> parameters was because the TSM Admins determined that they didn't need
> to follow the Redbook's recommendations on unlimited/unlimited and I
am
> unable to provide hard cold reasons why they should follow the
Redbook.
> 
> 
> What they gave me:
> 
> Created Policy Domain XXXXXXXX, Set up management class "Standard".
For
> now (until business side gets back to us with retention) set up the MC
> with 0 days between backups, 7 versions of each file kept, 30 days to
> keep inactive versions, 1 deleted version, keep last file f! or 60
> days.
> Set up separate collocation group for XXXXX.
> 
> 
> My comments regarding:
> 
> How does this MC affect backup of the SQL transaction logs (since it
is
> backup and not archive)?  I am concerned that the 7 versions existing
&
> 1 deleted may cause issues doing a point-in-time restore (i.e.- the
log
> that needs to be restored rolled off TSM & now the point in time
> recovery fails).
> 
> Regarding metadata being retained on disk vs. on tape.  We may not be
> able to query database objects for restore if the metadata is on tape.
> This is another concern I have regarding only one STANDARD management
> class.
> 
> 
> What I asked for:
> 
> 
> I have relied heavily on the IBM Redbook Backing up Microsoft SQL
> Server
> with IBM Tivoli Storage Manager (SG-24-6148-01) and its recommended
> setup
> 1.     I suggest you collocate by node or filesystem, depending on
size
> of filesystems & maxsize of the tapes--but if you can meet the
> business-side's RTO ! without collocation, then whatever works.
> 2.     Separate storage pools (stgp) be set up to backup the SQL
server
> environment. (Redbook pg 81)
> 2.a     Dedicated disk storage pools for the primary stgps for the SQL
> DB servers & the TDPs
>      DRSQLDBDISK- primary pool for DB Data
>      DRSQLLOGDISK- primary pool for DB logs
>      DRSQLDISKCOPY-copypool for DRSQLLOGDISK & DRSQLMETADISK)
>      DRSQLTAPECOPY- copy pool for DRSQLDBDISK in tape library
> REUSEDELAY=2
>      DR_DRIMVDL- DR offsite tapes     REUSEDELAY=2
>      DRSQLMETADISK-this is for metadata when using VSS. However, a
> system utilizing transaction log backup without using VSS staging was
> not illustrated in the Redbook, so it's unclear we'd need this for the
> legacy backup solution.
>      The documentation discusses ! when working with VSS backups
> another
> separate disk stgp be set up for the metadata. The problem with this
is
> that in the Redbook team's test environment, they assume all clustered
> servers would be utilizing VSS-either staging, offloaded or hardware.
I
> think that this is something we should look into-given the projected
> data volume and the RTOs-perhaps even the backup window. We could do
> the
> staging or off-loaded now-we just need to install the IBM TSM for Copy
> Services. And some more configuration.
> 3.     Separate Policy Domain (PD) (Redbook ppg 83 & 84)
> 3.a     Management Class (MC)
> *DRSQLDAILY- for the daily & weekly backups with retention policy
based
> on date- VEREXISTS=nolimit VERDELETED=nolimit RETEXTRA=35 RETONLY=90
> **Default MC
> *DRSQL_LONG- monthly backups & archives (shouldn't need to include
meta
> & logs if the archive/(full) backup is done correctly-right? I would
> also suggest that the scheduled job! s use dates in the name of the
> backup & for the archives, so we don't run into issues with version
> retention & for clarity) VEREXISTS=2 VERDELETED=1 RETEXTRA=400
> RETONLY=400
>      *DRSQL_LOGS- for the transaction logs VEREXISTS=nolimit
> VERDELETED=nolimit RETEXTRA=35 RETONLY=90
> *DRSQL_VSSLOCAL- for local (on the SQL server or the proxy) VSS
> backups-
> retention policy enforced by version & not time- VEREXISTS=3
> VERDELETED=3 RETEXTA=nolimit RETONLY=nolimit
> *DRSQL_VSSFULLTSM -daily VSS backups sent to TSM-retention policy
based
> on time= VEREXISTS=nolimit & RETEXTRA=35 RETONLY=35
> 
> 
> 
> 
> I am concerned about PIT recovery since I don't know what their
> "tweaking" will do to our ability to recover.  The business side is
> willing to pay for what we need, but the "service provider" is
> unwilling
> to provide what we ask for......
> 
> 
> If I could bother with one more stupid question... I am vague on
> how/if
> the transaction log "space" empties--  For example, I have a difffull
> running every night, then backup the logs and every 2 hours a backup
of
> the logs occurs-- If I get a notification (SNMP) that the drive
> designated for the SQL logs is 95% full -- Do I have to worry about
it?
> 
> 
> thanks!
> lisa
> 
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Del Hoobler
> Sent: Thursday, September 04, 2008 6:50 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] inactivate TDP SQL transaction logs?
> 
> Lisa,
> 
> For Data Protection for SQL, you do not need to schedule
> an inactivate logs. "log" backups are stored as backups,
> and are inactivated automatically on the next "full"
> backup of the associated database. I encourage you to read the
> "Backup overview", "Backup strategies", and
> "Recommended Tivoli Storage Manager policy settings" sections
> of the Data Protection for SQL Installation and User's Guide
> for more details.
> 
> 
>
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=
> /
> com.ibm.itsmfd.doc/dpsql.htm
> 
> Thanks,
> 
> Del
> 
> ----------------------------------------------------
> 
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/28/2008
> 04:27:24 PM:
> 
> > [image removed]
> >
> > inactivate TDP SQL transaction logs?
> >
> > Laughlin, Lisa
> >
> > to:
> >
> > ADSM-L
> >
> > 08/28/2008 04:28 PM
> >
> > Sent by:
> >
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> > Please respond to "ADSM: Dist Stor Manager"
> >
> > When I setup TDP for Oracle and used RMAN jobs , the transaction
logs
> > were archives ( & archive deletes) and you needed to also schedule
an
> > RMAN job to inactivate the logs and synchronize between RMAN and
> > TDP/TSM.  It's been a while and my details may be fuzzy; but it
> doesn't
> > seem that there is an equivalent in MSSQL. And the logs are backed
> up,
> > not archived.  Should I be scheduling inactivate jogs and do I have
> to
> > worry about duplicate transaction log names and a limit on the
number
> of
> > versions kept for the backups of the transaction logs?  Sorry if I
am
> > slightly incoherent-we go live on a project over the weekend, and
(as
> > usual) the backups were an afterthought, so I am kind of short on
> sleep
> > right now.  I know you guys have been there & done that.
> >
> > thanks!
> > lisa