"Sam" <S**@discussions.microsoft.com> wrote in message
news:F686876C-7681-45C1-A02F-4566BF6E456F@microsoft.com...
> Hi,
>
> We're running SQL Server 2005 Std. We have two mission critical databases
> on
> this server. Because of our backup policies -- Full Recovery, the
> transaction
> files on these databases ate up all the available space on the server.
> Here's
> the actual space usage data on these databases:
>
> DB1:
> MDF: 420 MB
> LDF: 21.8 GB
>
> DB2:
> MDF: 250 MB
> LDF: 10.2 GB
>
> Even though we do a transaction log backup, the LDF file sizes don't
> change
> even after a Shrink process.
>
> I did some reading on backup policies. Looks like the answer we're looking
> for is to change our Recovery Model.
>
> My question is will I be able to shrink the transaction log file size by
> switching to Simple Recovery model.
>
> I'm quickly running out of space. Based on the answers I will get for my
> question, here's what I intend to do:
>
> 1. Perform FULL back up on both databases and their transaction log files
> 2. Switch to Simple Recovery Model.
> 3. Once I get some space and normalcy back, I will wait till the weekend
> to
> add 3 more hard disks to the server box and set up a RAID 5 configuration
> 4. Once I restore the databases, I will wait for a few more days to
> monitor
> these databases
> 5. Switch back to Full Recovery model but this time set up timely
> transaction log file backups to control the growth of these files.
>
> Please let me know:
> 1. Will switching to Simple Recovery Model help me shrink LDF file sizes?
> 2. Does my 5-step execution plan make sense. If not, I'd appreciate your
> suggestions.
>
> --
> Thanks,
>
> Sam

"Sam" <S**@discussions.microsoft.com> wrote in message
news:F686876C-7681-45C1-A02F-4566BF6E456F@microsoft.com...
> Hi,
>
> We're running SQL Server 2005 Std. We have two mission critical databases
> on
> this server. Because of our backup policies -- Full Recovery, the
> transaction
> files on these databases ate up all the available space on the server.
> Here's
> the actual space usage data on these databases:
>
> DB1:
> MDF: 420 MB
> LDF: 21.8 GB
>
> DB2:
> MDF: 250 MB
> LDF: 10.2 GB
>
> Even though we do a transaction log backup, the LDF file sizes don't
> change
> even after a Shrink process.
>
> I did some reading on backup policies. Looks like the answer we're looking
> for is to change our Recovery Model.
>
> My question is will I be able to shrink the transaction log file size by
> switching to Simple Recovery model.
>
> I'm quickly running out of space. Based on the answers I will get for my
> question, here's what I intend to do:
>
> 1. Perform FULL back up on both databases and their transaction log files
> 2. Switch to Simple Recovery Model.
> 3. Once I get some space and normalcy back, I will wait till the weekend
> to
> add 3 more hard disks to the server box and set up a RAID 5 configuration
> 4. Once I restore the databases, I will wait for a few more days to
> monitor
> these databases
> 5. Switch back to Full Recovery model but this time set up timely
> transaction log file backups to control the growth of these files.
>
> Please let me know:
> 1. Will switching to Simple Recovery Model help me shrink LDF file sizes?
> 2. Does my 5-step execution plan make sense. If not, I'd appreciate your
> suggestions.
>
> --
> Thanks,
>
> Sam

> Hi,
>
> We're running SQL Server 2005 Std. We have two mission critical databases
> on this server. Because of our backup policies -- Full Recovery, the
> transaction files on these databases ate up all the available space on the
> server. Here's the actual space usage data on these databases:
>
> DB1:
> MDF: 420 MB
> LDF: 21.8 GB
>
> DB2:
> MDF: 250 MB
> LDF: 10.2 GB
>
> Even though we do a transaction log backup, the LDF file sizes don't
> change even after a Shrink process.
>
> I did some reading on backup policies. Looks like the answer we're looking
> for is to change our Recovery Model.
>
> My question is will I be able to shrink the transaction log file size by
> switching to Simple Recovery model.
>
> I'm quickly running out of space. Based on the answers I will get for my
> question, here's what I intend to do:
>
> 1. Perform FULL back up on both databases and their transaction log files
> 2. Switch to Simple Recovery Model.
> 3. Once I get some space and normalcy back, I will wait till the weekend
> to add 3 more hard disks to the server box and set up a RAID 5
> configuration 4. Once I restore the databases, I will wait for a few more
> days to monitor these databases
> 5. Switch back to Full Recovery model but this time set up timely
> transaction log file backups to control the growth of these files.
>
> Please let me know:
> 1. Will switching to Simple Recovery Model help me shrink LDF file sizes?
> 2. Does my 5-step execution plan make sense. If not, I'd appreciate your
> suggestions.
>

"Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
news:%23q1%23g6UyGHA.3632@TK2MSFTNGP03.phx.gbl...
> I've had this situation - disk full due to log.
>
> I do this
> 1. Change DB to simple recovery
> 2. Do complete backup (I use the Backup in all tasks). Of course you need
> a
> place to put it<G>.
> 3. After the backup is done I can use shrinkfile to shrink the log.
> 4. Set DB back to desired recovery model.  I use bulk-logged and on my
> critical systems I do Tlog backups every 30 minutes or so - I keep them
> for
> a day and do a complete backup of the DB in the early morning which is
> then
> picked up by our Tivoli system.
>
> Why are you using full recovery model?  I will admit I'm new at SQL Server
> DBA (I was given the job along with my other responsibilities <G>) but
> from
> the reading I did (Kalen's SQL 2000 Sever book) Bulk logged was a good
> compromise.  You have better performance but the TLOG backup is bigger.
>
> Sam wrote:
>
>> Hi,
>>
>> We're running SQL Server 2005 Std. We have two mission critical databases
>> on this server. Because of our backup policies -- Full Recovery, the
>> transaction files on these databases ate up all the available space on
>> the
>> server. Here's the actual space usage data on these databases:
>>
>> DB1:
>> MDF: 420 MB
>> LDF: 21.8 GB
>>
>> DB2:
>> MDF: 250 MB
>> LDF: 10.2 GB
>>
>> Even though we do a transaction log backup, the LDF file sizes don't
>> change even after a Shrink process.
>>
>> I did some reading on backup policies. Looks like the answer we're
>> looking
>> for is to change our Recovery Model.
>>
>> My question is will I be able to shrink the transaction log file size by
>> switching to Simple Recovery model.
>>
>> I'm quickly running out of space. Based on the answers I will get for my
>> question, here's what I intend to do:
>>
>> 1. Perform FULL back up on both databases and their transaction log files
>> 2. Switch to Simple Recovery Model.
>> 3. Once I get some space and normalcy back, I will wait till the weekend
>> to add 3 more hard disks to the server box and set up a RAID 5
>> configuration 4. Once I restore the databases, I will wait for a few more
>> days to monitor these databases
>> 5. Switch back to Full Recovery model but this time set up timely
>> transaction log file backups to control the growth of these files.
>>
>> Please let me know:
>> 1. Will switching to Simple Recovery Model help me shrink LDF file sizes?
>> 2. Does my 5-step execution plan make sense. If not, I'd appreciate your
>> suggestions.
>>
>

> Hi Brett,
>
> I just wanted to point out you want to be careful about switching your
> database from Full to Bulk Logged recovery.  As you said, it's a
> compromise, and it can be a good compromise, but you are limiting your
> choices if you
> are in a recovery situation.  If something happens to the disk media that
> the data is on to make it unreadable, but the log is still readable, with
> Full recovery you can back up the current log and recover up to the point
> of the failure, with Bulk Logged recovery, you will only be able to
> recover up
> to the end of the last completed log backup before the failure.  Also,
> with the Full recovery model, you can do point in time recoveries, with
> Bulk Logged, you can only recover to the end of a log backup.
>
> I'm not saying don't use bulk logged (or even Simple) recovery.  Just make
> sure that you have examined the recovery requirements of your database and
> that the Bulk Logged restrictions are acceptable for your database before
> you do and that what you have gained is worth the additional risk.
> Nothing will make your life more miserable as a DBA than needing to do a
> recovry and not having the backups you need to do it.
>
> Tom
>
> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
> news:%23q1%23g6UyGHA.3632@TK2MSFTNGP03.phx.gbl...
>> I've had this situation - disk full due to log.
>>
>> I do this
>> 1. Change DB to simple recovery
>> 2. Do complete backup (I use the Backup in all tasks). Of course you need
>> a
>> place to put it<G>.
>> 3. After the backup is done I can use shrinkfile to shrink the log.
>> 4. Set DB back to desired recovery model.  I use bulk-logged and on my
>> critical systems I do Tlog backups every 30 minutes or so - I keep them
>> for
>> a day and do a complete backup of the DB in the early morning which is
>> then
>> picked up by our Tivoli system.
>>
>> Why are you using full recovery model?  I will admit I'm new at SQL
>> Server DBA (I was given the job along with my other responsibilities <G>)
>> but from
>> the reading I did (Kalen's SQL 2000 Sever book) Bulk logged was a good
>> compromise.  You have better performance but the TLOG backup is bigger.
>>
>> Sam wrote:
>>
>>> Hi,
>>>
>>> We're running SQL Server 2005 Std. We have two mission critical
>>> databases on this server. Because of our backup policies -- Full
>>> Recovery, the transaction files on these databases ate up all the
>>> available space on the
>>> server. Here's the actual space usage data on these databases:
>>>
>>> DB1:
>>> MDF: 420 MB
>>> LDF: 21.8 GB
>>>
>>> DB2:
>>> MDF: 250 MB
>>> LDF: 10.2 GB
>>>
>>> Even though we do a transaction log backup, the LDF file sizes don't
>>> change even after a Shrink process.
>>>
>>> I did some reading on backup policies. Looks like the answer we're
>>> looking
>>> for is to change our Recovery Model.
>>>
>>> My question is will I be able to shrink the transaction log file size by
>>> switching to Simple Recovery model.
>>>
>>> I'm quickly running out of space. Based on the answers I will get for my
>>> question, here's what I intend to do:
>>>
>>> 1. Perform FULL back up on both databases and their transaction log
>>> files 2. Switch to Simple Recovery Model.
>>> 3. Once I get some space and normalcy back, I will wait till the weekend
>>> to add 3 more hard disks to the server box and set up a RAID 5
>>> configuration 4. Once I restore the databases, I will wait for a few
>>> more days to monitor these databases
>>> 5. Switch back to Full Recovery model but this time set up timely
>>> transaction log file backups to control the growth of these files.
>>>
>>> Please let me know:
>>> 1. Will switching to Simple Recovery Model help me shrink LDF file
>>> sizes? 2. Does my 5-step execution plan make sense. If not, I'd
>>> appreciate your suggestions.
>>>
>>

"Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
news:eiKoVOWyGHA.4392@TK2MSFTNGP04.phx.gbl...
> Thanks for the input.  As I mentioned - I'm learning and this was
> confusing<G>.  Back to Kalen's book.
>
> Let me see if I understand what happens if I have a problem. My purpose is
> to have a full backup done once/day by our Tivoli system and then on
> selected databases be able to recover up to a point in time.  For one
> system we picked 30 minutes between log backups and for another 60
> minutes.
> That can be changed as we'd like to NOT lose any data but there are
> tradeoffs.  Any suggestions on what I should be doing will be appreciated.
>
>
> Scenerio: I am doing bulk-logged during the night which is then backed up
> to
> Tivoli.  Then around 0600 when the day starts I begin doing Log backups at
> an interval - 30 minutes on one system.  These log backups are not only
> stored on a backup directory but are moved to another server.  We're
> running RAID 1 so if we lose the disk RAID 1 should give us our data BUT
> since I'm paranoid I'll move the log backups off to another server. They
> are kept for a day.
>
> 1. Hmm, I'm no sure I understand it all but I'll do some more reading.
>
> #1. Assume I can recover my log file:
>
> Full Model:
> A. Backup the log file.
> B. Restore the full backup from Tivoli.
> C. Restore the log file I just backed up
>
> I am now up and running - correct?
>
> Bulk-logged
>
> A. Restore last full backup from Tivoli
> B. Then restore each log in turn until I get to the most current log - As
> I
> understand it that reconstructs everything so at the end of the last log
> restore I am back where I was with say 30 minutes of data lost at the
> most.
>
> I am now up and running minus the time between my last log backup and the
> crash - correct?
>
> #2 if I can't recover the log file:
>
> With Full recovery:
>
> A. Restore last full backup from Tivoli
> B. Restore last log backup
>
> I will now be running but will have lost data between the time of the last
> log backukp and crash  - correct.
>
> With Bulk-logged - same as Full recovery where I can't get the log back.
>
>
>
>
> Tom Cooper wrote:
>
>> Hi Brett,
>>
>> I just wanted to point out you want to be careful about switching your
>> database from Full to Bulk Logged recovery.  As you said, it's a
>> compromise, and it can be a good compromise, but you are limiting your
>> choices if you
>> are in a recovery situation.  If something happens to the disk media that
>> the data is on to make it unreadable, but the log is still readable, with
>> Full recovery you can back up the current log and recover up to the point
>> of the failure, with Bulk Logged recovery, you will only be able to
>> recover up
>> to the end of the last completed log backup before the failure.  Also,
>> with the Full recovery model, you can do point in time recoveries, with
>> Bulk Logged, you can only recover to the end of a log backup.
>>
>> I'm not saying don't use bulk logged (or even Simple) recovery.  Just
>> make
>> sure that you have examined the recovery requirements of your database
>> and
>> that the Bulk Logged restrictions are acceptable for your database before
>> you do and that what you have gained is worth the additional risk.
>> Nothing will make your life more miserable as a DBA than needing to do a
>> recovry and not having the backups you need to do it.
>>
>> Tom
>>
>> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
>> news:%23q1%23g6UyGHA.3632@TK2MSFTNGP03.phx.gbl...
>>> I've had this situation - disk full due to log.
>>>
>>> I do this
>>> 1. Change DB to simple recovery
>>> 2. Do complete backup (I use the Backup in all tasks). Of course you
>>> need
>>> a
>>> place to put it<G>.
>>> 3. After the backup is done I can use shrinkfile to shrink the log.
>>> 4. Set DB back to desired recovery model.  I use bulk-logged and on my
>>> critical systems I do Tlog backups every 30 minutes or so - I keep them
>>> for
>>> a day and do a complete backup of the DB in the early morning which is
>>> then
>>> picked up by our Tivoli system.
>>>
>>> Why are you using full recovery model?  I will admit I'm new at SQL
>>> Server DBA (I was given the job along with my other responsibilities
>>> <G>)
>>> but from
>>> the reading I did (Kalen's SQL 2000 Sever book) Bulk logged was a good
>>> compromise.  You have better performance but the TLOG backup is bigger.
>>>
>>> Sam wrote:
>>>
>>>> Hi,
>>>>
>>>> We're running SQL Server 2005 Std. We have two mission critical
>>>> databases on this server. Because of our backup policies -- Full
>>>> Recovery, the transaction files on these databases ate up all the
>>>> available space on the
>>>> server. Here's the actual space usage data on these databases:
>>>>
>>>> DB1:
>>>> MDF: 420 MB
>>>> LDF: 21.8 GB
>>>>
>>>> DB2:
>>>> MDF: 250 MB
>>>> LDF: 10.2 GB
>>>>
>>>> Even though we do a transaction log backup, the LDF file sizes don't
>>>> change even after a Shrink process.
>>>>
>>>> I did some reading on backup policies. Looks like the answer we're
>>>> looking
>>>> for is to change our Recovery Model.
>>>>
>>>> My question is will I be able to shrink the transaction log file size
>>>> by
>>>> switching to Simple Recovery model.
>>>>
>>>> I'm quickly running out of space. Based on the answers I will get for
>>>> my
>>>> question, here's what I intend to do:
>>>>
>>>> 1. Perform FULL back up on both databases and their transaction log
>>>> files 2. Switch to Simple Recovery Model.
>>>> 3. Once I get some space and normalcy back, I will wait till the
>>>> weekend
>>>> to add 3 more hard disks to the server box and set up a RAID 5
>>>> configuration 4. Once I restore the databases, I will wait for a few
>>>> more days to monitor these databases
>>>> 5. Switch back to Full Recovery model but this time set up timely
>>>> transaction log file backups to control the growth of these files.
>>>>
>>>> Please let me know:
>>>> 1. Will switching to Simple Recovery Model help me shrink LDF file
>>>> sizes? 2. Does my 5-step execution plan make sense. If not, I'd
>>>> appreciate your suggestions.
>>>>
>>>
>

> Close, but not quite.
>
> You need to restore all the log backups (in order) since the last full
> backup not just the last log backup.  So where you have:
>
>> #1. Assume I can recover my log file:
>>
>> Full Model:
>> A. Backup the log file.
>> B. Restore the full backup from Tivoli.
>> C. Restore the log file I just backed up
>>
> It should be
>
> A. Backup the log file.
> B. Restore the full backup from Tivoli (with the NORECOVERY or STANDBY
> option)
> C. Restore each log backup (except the last one you just did in step A)
> since the full backup in order (with the NORECOVERY or STANDBY option)
> D. Restore the log file you just backed up (with the RECOVERY option)
>
> But it sounds like you have a good handle on it and are paranoid which is
> good for a DBA when talking dealing with backup/recovery issues.  I do,
> however, have a couple of suggestions.
>
> First, practice doing various kinds of recoveries on a test server.  For
> example, take yesterday's full backup and yesterday's logs through 11 AM
> and
> apply them in on a test server.  Then run tests of your applications
> against
> this test server to make sure everything works.  You don't want the first
> time you actually do a recovery to be when you've had a disaster.  Too
> many sites have a tested backup plan when what they need is a tested
> RECOVERY plan (of which, of course, the backup plan is an important part).
>
> Second, you may want to consider keeping your log backups longer.  You say
> you keep them for day.  I'm not sure from that exactly how long you are
> keeping them, but you probably want to keep them until you have at least
> two
> subsequent full backups.  For example, you take a full backup Monday
> morning, then you want to keep the log backups you take during the day
> Monday at least until you have successfully backed up the database on
> Wednesday morning.  The reason for this is that if the database crashes
> Tuesday night, you will try restoring from Tuesday's full backup and then
> Tuesday's log backup.  If for some reason, Tuesday's backup is unreadable,
> you will want to be able to go back to Monday's full backup and then apply
> all the log backups from Monday and then Tuesday.  It's cheap insurance.
>
> Tom
>
> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
> news:eiKoVOWyGHA.4392@TK2MSFTNGP04.phx.gbl...
>> Thanks for the input.  As I mentioned - I'm learning and this was
>> confusing<G>.  Back to Kalen's book.
>>
>> Let me see if I understand what happens if I have a problem. My purpose
>> is to have a full backup done once/day by our Tivoli system and then on
>> selected databases be able to recover up to a point in time.  For one
>> system we picked 30 minutes between log backups and for another 60
>> minutes.
>> That can be changed as we'd like to NOT lose any data but there are
>> tradeoffs.  Any suggestions on what I should be doing will be
>> appreciated.
>>
>>
>> Scenerio: I am doing bulk-logged during the night which is then backed up
>> to
>> Tivoli.  Then around 0600 when the day starts I begin doing Log backups
>> at
>> an interval - 30 minutes on one system.  These log backups are not only
>> stored on a backup directory but are moved to another server.  We're
>> running RAID 1 so if we lose the disk RAID 1 should give us our data BUT
>> since I'm paranoid I'll move the log backups off to another server. They
>> are kept for a day.
>>
>> 1. Hmm, I'm no sure I understand it all but I'll do some more reading.
>>
>> #1. Assume I can recover my log file:
>>
>> Full Model:
>> A. Backup the log file.
>> B. Restore the full backup from Tivoli.
>> C. Restore the log file I just backed up
>>
>> I am now up and running - correct?
>>
>> Bulk-logged
>>
>> A. Restore last full backup from Tivoli
>> B. Then restore each log in turn until I get to the most current log - As
>> I
>> understand it that reconstructs everything so at the end of the last log
>> restore I am back where I was with say 30 minutes of data lost at the
>> most.
>>
>> I am now up and running minus the time between my last log backup and the
>> crash - correct?
>>
>> #2 if I can't recover the log file:
>>
>> With Full recovery:
>>
>> A. Restore last full backup from Tivoli
>> B. Restore last log backup
>>
>> I will now be running but will have lost data between the time of the
>> last
>> log backukp and crash  - correct.
>>
>> With Bulk-logged - same as Full recovery where I can't get the log back.
>>
>>
>>
>>
>> Tom Cooper wrote:
>>
>>> Hi Brett,
>>>
>>> I just wanted to point out you want to be careful about switching your
>>> database from Full to Bulk Logged recovery.  As you said, it's a
>>> compromise, and it can be a good compromise, but you are limiting your
>>> choices if you
>>> are in a recovery situation.  If something happens to the disk media
>>> that the data is on to make it unreadable, but the log is still
>>> readable, with Full recovery you can back up the current log and recover
>>> up to the point of the failure, with Bulk Logged recovery, you will only
>>> be able to recover up
>>> to the end of the last completed log backup before the failure.  Also,
>>> with the Full recovery model, you can do point in time recoveries, with
>>> Bulk Logged, you can only recover to the end of a log backup.
>>>
>>> I'm not saying don't use bulk logged (or even Simple) recovery.  Just
>>> make
>>> sure that you have examined the recovery requirements of your database
>>> and
>>> that the Bulk Logged restrictions are acceptable for your database
>>> before you do and that what you have gained is worth the additional
>>> risk. Nothing will make your life more miserable as a DBA than needing
>>> to do a recovry and not having the backups you need to do it.
>>>
>>> Tom
>>>
>>> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
>>> news:%23q1%23g6UyGHA.3632@TK2MSFTNGP03.phx.gbl...
>>>> I've had this situation - disk full due to log.
>>>>
>>>> I do this
>>>> 1. Change DB to simple recovery
>>>> 2. Do complete backup (I use the Backup in all tasks). Of course you
>>>> need
>>>> a
>>>> place to put it<G>.
>>>> 3. After the backup is done I can use shrinkfile to shrink the log.
>>>> 4. Set DB back to desired recovery model.  I use bulk-logged and on my
>>>> critical systems I do Tlog backups every 30 minutes or so - I keep them
>>>> for
>>>> a day and do a complete backup of the DB in the early morning which is
>>>> then
>>>> picked up by our Tivoli system.
>>>>
>>>> Why are you using full recovery model?  I will admit I'm new at SQL
>>>> Server DBA (I was given the job along with my other responsibilities
>>>> <G>)
>>>> but from
>>>> the reading I did (Kalen's SQL 2000 Sever book) Bulk logged was a good
>>>> compromise.  You have better performance but the TLOG backup is bigger.
>>>>
>>>> Sam wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We're running SQL Server 2005 Std. We have two mission critical
>>>>> databases on this server. Because of our backup policies -- Full
>>>>> Recovery, the transaction files on these databases ate up all the
>>>>> available space on the
>>>>> server. Here's the actual space usage data on these databases:
>>>>>
>>>>> DB1:
>>>>> MDF: 420 MB
>>>>> LDF: 21.8 GB
>>>>>
>>>>> DB2:
>>>>> MDF: 250 MB
>>>>> LDF: 10.2 GB
>>>>>
>>>>> Even though we do a transaction log backup, the LDF file sizes don't
>>>>> change even after a Shrink process.
>>>>>
>>>>> I did some reading on backup policies. Looks like the answer we're
>>>>> looking
>>>>> for is to change our Recovery Model.
>>>>>
>>>>> My question is will I be able to shrink the transaction log file size
>>>>> by
>>>>> switching to Simple Recovery model.
>>>>>
>>>>> I'm quickly running out of space. Based on the answers I will get for
>>>>> my
>>>>> question, here's what I intend to do:
>>>>>
>>>>> 1. Perform FULL back up on both databases and their transaction log
>>>>> files 2. Switch to Simple Recovery Model.
>>>>> 3. Once I get some space and normalcy back, I will wait till the
>>>>> weekend
>>>>> to add 3 more hard disks to the server box and set up a RAID 5
>>>>> configuration 4. Once I restore the databases, I will wait for a few
>>>>> more days to monitor these databases
>>>>> 5. Switch back to Full Recovery model but this time set up timely
>>>>> transaction log file backups to control the growth of these files.
>>>>>
>>>>> Please let me know:
>>>>> 1. Will switching to Simple Recovery Model help me shrink LDF file
>>>>> sizes? 2. Does my 5-step execution plan make sense. If not, I'd
>>>>> appreciate your suggestions.
>>>>>
>>>>
>>

"Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
news:%23G7kzXXyGHA.4232@TK2MSFTNGP05.phx.gbl...
> Paranoia is a good trait for a DBA I guess <G>.
>
> I see on the logs - you need to do each in order to get the DB back to
> it's
> final state before the crash.
>
> Funny you should mention practice as I am working on setting up a practice
> restore on a test DB that we have.  I want to make sure it works (parnoia
> again <G>) and also to go through it and experience it.  I'm sensitive to
> the need for a recovery plan due to some of the environments I've worked
> in - and I 've had to use the recovery plan!
>
> I do a full backup once in the early morning.  That backup goes to our
> Tivoli system which keeps the DB backups for anywhere from 14 to 90 days.
>
> Let me make sure I have this:
>
> I have a backup in the morning - usually 0100-0200.  Our databases they
> are
> not used overnight so I do the log backups every x minutes from 0600 to
> 1800 or 2300 depending on which one it is.  These log backups are kept
> until the next day - I use a maint plan and tell it to keep only 1 day.
>
> Monday at 0600 I have a full backup (maint plan again) of the DB.   Then I
> do log bacups every x minutes until the end time.  From the end time till
> the DB full backup I have no activity.  The DB is backed up at say 0200.
>
> Tuesday: I have a full backup at 0200 Tuesday.  At 0600 the first Tlog
> backup is done replacing Monday's 0600 and so on.
>
> Do I need to go to full mode or will bulk-logged be sufficient.  We have
> plenty of space on all the servers.  Am I correct in believing that when I
> do the full backup the log is cleared?
>
> Thank you for you help and time.  This is helping me make sure I provide
> the
> best database setup for our people.
>
>
> Tom Cooper wrote:
>
>> Close, but not quite.
>>
>> You need to restore all the log backups (in order) since the last full
>> backup not just the last log backup.  So where you have:
>>
>>> #1. Assume I can recover my log file:
>>>
>>> Full Model:
>>> A. Backup the log file.
>>> B. Restore the full backup from Tivoli.
>>> C. Restore the log file I just backed up
>>>
>> It should be
>>
>> A. Backup the log file.
>> B. Restore the full backup from Tivoli (with the NORECOVERY or STANDBY
>> option)
>> C. Restore each log backup (except the last one you just did in step A)
>> since the full backup in order (with the NORECOVERY or STANDBY option)
>> D. Restore the log file you just backed up (with the RECOVERY option)
>>
>> But it sounds like you have a good handle on it and are paranoid which is
>> good for a DBA when talking dealing with backup/recovery issues.  I do,
>> however, have a couple of suggestions.
>>
>> First, practice doing various kinds of recoveries on a test server.  For
>> example, take yesterday's full backup and yesterday's logs through 11 AM
>> and
>> apply them in on a test server.  Then run tests of your applications
>> against
>> this test server to make sure everything works.  You don't want the first
>> time you actually do a recovery to be when you've had a disaster.  Too
>> many sites have a tested backup plan when what they need is a tested
>> RECOVERY plan (of which, of course, the backup plan is an important
>> part).
>>
>> Second, you may want to consider keeping your log backups longer.  You
>> say
>> you keep them for day.  I'm not sure from that exactly how long you are
>> keeping them, but you probably want to keep them until you have at least
>> two
>> subsequent full backups.  For example, you take a full backup Monday
>> morning, then you want to keep the log backups you take during the day
>> Monday at least until you have successfully backed up the database on
>> Wednesday morning.  The reason for this is that if the database crashes
>> Tuesday night, you will try restoring from Tuesday's full backup and then
>> Tuesday's log backup.  If for some reason, Tuesday's backup is
>> unreadable,
>> you will want to be able to go back to Monday's full backup and then
>> apply
>> all the log backups from Monday and then Tuesday.  It's cheap insurance.
>>
>> Tom
>>
>> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
>> news:eiKoVOWyGHA.4392@TK2MSFTNGP04.phx.gbl...
>>> Thanks for the input.  As I mentioned - I'm learning and this was
>>> confusing<G>.  Back to Kalen's book.
>>>
>>> Let me see if I understand what happens if I have a problem. My purpose
>>> is to have a full backup done once/day by our Tivoli system and then on
>>> selected databases be able to recover up to a point in time.  For one
>>> system we picked 30 minutes between log backups and for another 60
>>> minutes.
>>> That can be changed as we'd like to NOT lose any data but there are
>>> tradeoffs.  Any suggestions on what I should be doing will be
>>> appreciated.
>>>
>>>
>>> Scenerio: I am doing bulk-logged during the night which is then backed
>>> up
>>> to
>>> Tivoli.  Then around 0600 when the day starts I begin doing Log backups
>>> at
>>> an interval - 30 minutes on one system.  These log backups are not only
>>> stored on a backup directory but are moved to another server.  We're
>>> running RAID 1 so if we lose the disk RAID 1 should give us our data BUT
>>> since I'm paranoid I'll move the log backups off to another server. They
>>> are kept for a day.
>>>
>>> 1. Hmm, I'm no sure I understand it all but I'll do some more reading.
>>>
>>> #1. Assume I can recover my log file:
>>>
>>> Full Model:
>>> A. Backup the log file.
>>> B. Restore the full backup from Tivoli.
>>> C. Restore the log file I just backed up
>>>
>>> I am now up and running - correct?
>>>
>>> Bulk-logged
>>>
>>> A. Restore last full backup from Tivoli
>>> B. Then restore each log in turn until I get to the most current log -
>>> As
>>> I
>>> understand it that reconstructs everything so at the end of the last log
>>> restore I am back where I was with say 30 minutes of data lost at the
>>> most.
>>>
>>> I am now up and running minus the time between my last log backup and
>>> the
>>> crash - correct?
>>>
>>> #2 if I can't recover the log file:
>>>
>>> With Full recovery:
>>>
>>> A. Restore last full backup from Tivoli
>>> B. Restore last log backup
>>>
>>> I will now be running but will have lost data between the time of the
>>> last
>>> log backukp and crash  - correct.
>>>
>>> With Bulk-logged - same as Full recovery where I can't get the log back.
>>>
>>>
>>>
>>>
>>> Tom Cooper wrote:
>>>
>>>> Hi Brett,
>>>>
>>>> I just wanted to point out you want to be careful about switching your
>>>> database from Full to Bulk Logged recovery.  As you said, it's a
>>>> compromise, and it can be a good compromise, but you are limiting your
>>>> choices if you
>>>> are in a recovery situation.  If something happens to the disk media
>>>> that the data is on to make it unreadable, but the log is still
>>>> readable, with Full recovery you can back up the current log and
>>>> recover
>>>> up to the point of the failure, with Bulk Logged recovery, you will
>>>> only
>>>> be able to recover up
>>>> to the end of the last completed log backup before the failure.  Also,
>>>> with the Full recovery model, you can do point in time recoveries, with
>>>> Bulk Logged, you can only recover to the end of a log backup.
>>>>
>>>> I'm not saying don't use bulk logged (or even Simple) recovery.  Just
>>>> make
>>>> sure that you have examined the recovery requirements of your database
>>>> and
>>>> that the Bulk Logged restrictions are acceptable for your database
>>>> before you do and that what you have gained is worth the additional
>>>> risk. Nothing will make your life more miserable as a DBA than needing
>>>> to do a recovry and not having the backups you need to do it.
>>>>
>>>> Tom
>>>>
>>>> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
>>>> news:%23q1%23g6UyGHA.3632@TK2MSFTNGP03.phx.gbl...
>>>>> I've had this situation - disk full due to log.
>>>>>
>>>>> I do this
>>>>> 1. Change DB to simple recovery
>>>>> 2. Do complete backup (I use the Backup in all tasks). Of course you
>>>>> need
>>>>> a
>>>>> place to put it<G>.
>>>>> 3. After the backup is done I can use shrinkfile to shrink the log.
>>>>> 4. Set DB back to desired recovery model.  I use bulk-logged and on my
>>>>> critical systems I do Tlog backups every 30 minutes or so - I keep
>>>>> them
>>>>> for
>>>>> a day and do a complete backup of the DB in the early morning which is
>>>>> then
>>>>> picked up by our Tivoli system.
>>>>>
>>>>> Why are you using full recovery model?  I will admit I'm new at SQL
>>>>> Server DBA (I was given the job along with my other responsibilities
>>>>> <G>)
>>>>> but from
>>>>> the reading I did (Kalen's SQL 2000 Sever book) Bulk logged was a good
>>>>> compromise.  You have better performance but the TLOG backup is
>>>>> bigger.
>>>>>
>>>>> Sam wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We're running SQL Server 2005 Std. We have two mission critical
>>>>>> databases on this server. Because of our backup policies -- Full
>>>>>> Recovery, the transaction files on these databases ate up all the
>>>>>> available space on the
>>>>>> server. Here's the actual space usage data on these databases:
>>>>>>
>>>>>> DB1:
>>>>>> MDF: 420 MB
>>>>>> LDF: 21.8 GB
>>>>>>
>>>>>> DB2:
>>>>>> MDF: 250 MB
>>>>>> LDF: 10.2 GB
>>>>>>
>>>>>> Even though we do a transaction log backup, the LDF file sizes don't
>>>>>> change even after a Shrink process.
>>>>>>
>>>>>> I did some reading on backup policies. Looks like the answer we're
>>>>>> looking
>>>>>> for is to change our Recovery Model.
>>>>>>
>>>>>> My question is will I be able to shrink the transaction log file size
>>>>>> by
>>>>>> switching to Simple Recovery model.
>>>>>>
>>>>>> I'm quickly running out of space. Based on the answers I will get for
>>>>>> my
>>>>>> question, here's what I intend to do:
>>>>>>
>>>>>> 1. Perform FULL back up on both databases and their transaction log
>>>>>> files 2. Switch to Simple Recovery Model.
>>>>>> 3. Once I get some space and normalcy back, I will wait till the
>>>>>> weekend
>>>>>> to add 3 more hard disks to the server box and set up a RAID 5
>>>>>> configuration 4. Once I restore the databases, I will wait for a few
>>>>>> more days to monitor these databases
>>>>>> 5. Switch back to Full Recovery model but this time set up timely
>>>>>> transaction log file backups to control the growth of these files.
>>>>>>
>>>>>> Please let me know:
>>>>>> 1. Will switching to Simple Recovery Model help me shrink LDF file
>>>>>> sizes? 2. Does my 5-step execution plan make sense. If not, I'd
>>>>>> appreciate your suggestions.
>>>>>>
>>>>>
>>>
>

> Hi Brett,
>
> A couple of things, .
>
> First, you asked, "Am I correct in believing that when I do the full
> backup
> the log is cleared?"  No.  Full backups do not have any effect on the
> contents of the log.  If you have your database set to Full or Bulk Logged
> recovery and you only do full backups, you log file will grow indefinitely
> and none of the space in it will ever be reused.  Only log backups mark
> space within the log file as no longer in use and available for reuse.
> Under certain circumstances, even log backups may leave substantial
> portions
> of the log marked as in use.  For example, SQL Server can't claer the log
> past the oldest open transaction (because if a connection does a begin
> tran makes some changes, waits 6 hours, and then does a rollback, SQL
> Server will need those log entries to do the rollback).
>
> Second, you asked, "Do I need to go to full mode or will bulk-logged be
> sufficient.  We have plenty of space on all the servers."
> Only you can answer this since you know your system, its daily workload,
> and
> its recovery requirements.  But my inclination would be to go to full
> recovery unless you have a good reason not to.  If you have the disk
> space,
> the other major consideration is performance.  But, in my experience,
> there
> is often no noticible difference in performance.  So, I would probably try
> full recovery mode and see if you have acceptable performance.  If you do,
> why not use it?
>
> Third, if it were my site, I would want to keep the log backups longer.
> Maybe as long as you are keeping the full backups.  (It would make no
> sense to keep them longer since they are essentially useless without a
> previous
> full backup).  This may depend on how much storage you have available and
> how expensive it would be to keep the additional log backups, but I would
> certainly want to.
>
>  Fourth, you don't mention offsite storage of your backups.  But you
> certainly want to do that, like maybe keep this morning's  full backup and
> today's log backups on site, but ship yesterday's off to an offsite
> storage location.
>
> Fifth, make sure you have met any requirements that legally apply to your
> business for both backup and security (SOX, HIPPA, etc).
>
> Tom
>
> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
> news:%23G7kzXXyGHA.4232@TK2MSFTNGP05.phx.gbl...
>> Paranoia is a good trait for a DBA I guess <G>.
>>
>> I see on the logs - you need to do each in order to get the DB back to
>> it's
>> final state before the crash.
>>
>> Funny you should mention practice as I am working on setting up a
>> practice
>> restore on a test DB that we have.  I want to make sure it works (parnoia
>> again <G>) and also to go through it and experience it.  I'm sensitive to
>> the need for a recovery plan due to some of the environments I've worked
>> in - and I 've had to use the recovery plan!
>>
>> I do a full backup once in the early morning.  That backup goes to our
>> Tivoli system which keeps the DB backups for anywhere from 14 to 90 days.
>>
>> Let me make sure I have this:
>>
>> I have a backup in the morning - usually 0100-0200.  Our databases they
>> are
>> not used overnight so I do the log backups every x minutes from 0600 to
>> 1800 or 2300 depending on which one it is.  These log backups are kept
>> until the next day - I use a maint plan and tell it to keep only 1 day.
>>
>> Monday at 0600 I have a full backup (maint plan again) of the DB.   Then
>> I
>> do log bacups every x minutes until the end time.  From the end time till
>> the DB full backup I have no activity.  The DB is backed up at say 0200.
>>
>> Tuesday: I have a full backup at 0200 Tuesday.  At 0600 the first Tlog
>> backup is done replacing Monday's 0600 and so on.
>>
>> Do I need to go to full mode or will bulk-logged be sufficient.  We have
>> plenty of space on all the servers.  Am I correct in believing that when
>> I do the full backup the log is cleared?
>>
>> Thank you for you help and time.  This is helping me make sure I provide
>> the
>> best database setup for our people.
>>
>>
>> Tom Cooper wrote:
>>
>>> Close, but not quite.
>>>
>>> You need to restore all the log backups (in order) since the last full
>>> backup not just the last log backup.  So where you have:
>>>
>>>> #1. Assume I can recover my log file:
>>>>
>>>> Full Model:
>>>> A. Backup the log file.
>>>> B. Restore the full backup from Tivoli.
>>>> C. Restore the log file I just backed up
>>>>
>>> It should be
>>>
>>> A. Backup the log file.
>>> B. Restore the full backup from Tivoli (with the NORECOVERY or STANDBY
>>> option)
>>> C. Restore each log backup (except the last one you just did in step A)
>>> since the full backup in order (with the NORECOVERY or STANDBY option)
>>> D. Restore the log file you just backed up (with the RECOVERY option)
>>>
>>> But it sounds like you have a good handle on it and are paranoid which
>>> is
>>> good for a DBA when talking dealing with backup/recovery issues.  I do,
>>> however, have a couple of suggestions.
>>>
>>> First, practice doing various kinds of recoveries on a test server.  For
>>> example, take yesterday's full backup and yesterday's logs through 11 AM
>>> and
>>> apply them in on a test server.  Then run tests of your applications
>>> against
>>> this test server to make sure everything works.  You don't want the
>>> first
>>> time you actually do a recovery to be when you've had a disaster.  Too
>>> many sites have a tested backup plan when what they need is a tested
>>> RECOVERY plan (of which, of course, the backup plan is an important
>>> part).
>>>
>>> Second, you may want to consider keeping your log backups longer.  You
>>> say
>>> you keep them for day.  I'm not sure from that exactly how long you are
>>> keeping them, but you probably want to keep them until you have at least
>>> two
>>> subsequent full backups.  For example, you take a full backup Monday
>>> morning, then you want to keep the log backups you take during the day
>>> Monday at least until you have successfully backed up the database on
>>> Wednesday morning.  The reason for this is that if the database crashes
>>> Tuesday night, you will try restoring from Tuesday's full backup and
>>> then
>>> Tuesday's log backup.  If for some reason, Tuesday's backup is
>>> unreadable,
>>> you will want to be able to go back to Monday's full backup and then
>>> apply
>>> all the log backups from Monday and then Tuesday.  It's cheap insurance.
>>>
>>> Tom
>>>
>>> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
>>> news:eiKoVOWyGHA.4392@TK2MSFTNGP04.phx.gbl...
>>>> Thanks for the input.  As I mentioned - I'm learning and this was
>>>> confusing<G>.  Back to Kalen's book.
>>>>
>>>> Let me see if I understand what happens if I have a problem. My purpose
>>>> is to have a full backup done once/day by our Tivoli system and then on
>>>> selected databases be able to recover up to a point in time.  For one
>>>> system we picked 30 minutes between log backups and for another 60
>>>> minutes.
>>>> That can be changed as we'd like to NOT lose any data but there are
>>>> tradeoffs.  Any suggestions on what I should be doing will be
>>>> appreciated.
>>>>
>>>>
>>>> Scenerio: I am doing bulk-logged during the night which is then backed
>>>> up
>>>> to
>>>> Tivoli.  Then around 0600 when the day starts I begin doing Log backups
>>>> at
>>>> an interval - 30 minutes on one system.  These log backups are not only
>>>> stored on a backup directory but are moved to another server.  We're
>>>> running RAID 1 so if we lose the disk RAID 1 should give us our data
>>>> BUT since I'm paranoid I'll move the log backups off to another server.
>>>> They are kept for a day.
>>>>
>>>> 1. Hmm, I'm no sure I understand it all but I'll do some more reading.
>>>>
>>>> #1. Assume I can recover my log file:
>>>>
>>>> Full Model:
>>>> A. Backup the log file.
>>>> B. Restore the full backup from Tivoli.
>>>> C. Restore the log file I just backed up
>>>>
>>>> I am now up and running - correct?
>>>>
>>>> Bulk-logged
>>>>
>>>> A. Restore last full backup from Tivoli
>>>> B. Then restore each log in turn until I get to the most current log -
>>>> As
>>>> I
>>>> understand it that reconstructs everything so at the end of the last
>>>> log restore I am back where I was with say 30 minutes of data lost at
>>>> the most.
>>>>
>>>> I am now up and running minus the time between my last log backup and
>>>> the
>>>> crash - correct?
>>>>
>>>> #2 if I can't recover the log file:
>>>>
>>>> With Full recovery:
>>>>
>>>> A. Restore last full backup from Tivoli
>>>> B. Restore last log backup
>>>>
>>>> I will now be running but will have lost data between the time of the
>>>> last
>>>> log backukp and crash  - correct.
>>>>
>>>> With Bulk-logged - same as Full recovery where I can't get the log
>>>> back.
>>>>
>>>>
>>>>
>>>>
>>>> Tom Cooper wrote:
>>>>
>>>>> Hi Brett,
>>>>>
>>>>> I just wanted to point out you want to be careful about switching your
>>>>> database from Full to Bulk Logged recovery.  As you said, it's a
>>>>> compromise, and it can be a good compromise, but you are limiting your
>>>>> choices if you
>>>>> are in a recovery situation.  If something happens to the disk media
>>>>> that the data is on to make it unreadable, but the log is still
>>>>> readable, with Full recovery you can back up the current log and
>>>>> recover
>>>>> up to the point of the failure, with Bulk Logged recovery, you will
>>>>> only
>>>>> be able to recover up
>>>>> to the end of the last completed log backup before the failure.  Also,
>>>>> with the Full recovery model, you can do point in time recoveries,
>>>>> with Bulk Logged, you can only recover to the end of a log backup.
>>>>>
>>>>> I'm not saying don't use bulk logged (or even Simple) recovery.  Just
>>>>> make
>>>>> sure that you have examined the recovery requirements of your database
>>>>> and
>>>>> that the Bulk Logged restrictions are acceptable for your database
>>>>> before you do and that what you have gained is worth the additional
>>>>> risk. Nothing will make your life more miserable as a DBA than needing
>>>>> to do a recovry and not having the backups you need to do it.
>>>>>
>>>>> Tom
>>>>>
>>>>> "Brett I. Holcomb" <Brett@newsgroups.nospam> wrote in message
>>>>> news:%23q1%23g6UyGHA.3632@TK2MSFTNGP03.phx.gbl...
>>>>>> I've had this situation - disk full due to log.
>>>>>>
>>>>>> I do this
>>>>>> 1. Change DB to simple recovery
>>>>>> 2. Do complete backup (I use the Backup in all tasks). Of course you
>>>>>> need
>>>>>> a
>>>>>> place to put it<G>.
>>>>>> 3. After the backup is done I can use shrinkfile to shrink the log.
>>>>>> 4. Set DB back to desired recovery model.  I use bulk-logged and on
>>>>>> my critical systems I do Tlog backups every 30 minutes or so - I keep
>>>>>> them
>>>>>> for
>>>>>> a day and do a complete backup of the DB in the early morning which
>>>>>> is then
>>>>>> picked up by our Tivoli system.
>>>>>>
>>>>>> Why are you using full recovery model?  I will admit I'm new at SQL
>>>>>> Server DBA (I was given the job along with my other responsibilities
>>>>>> <G>)
>>>>>> but from
>>>>>> the reading I did (Kalen's SQL 2000 Sever book) Bulk logged was a
>>>>>> good
>>>>>> compromise.  You have better performance but the TLOG backup is
>>>>>> bigger.
>>>>>>
>>>>>> Sam wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We're running SQL Server 2005 Std. We have two mission critical
>>>>>>> databases on this server. Because of our backup policies -- Full
>>>>>>> Recovery, the transaction files on these databases ate up all the
>>>>>>> available space on the
>>>>>>> server. Here's the actual space usage data on these databases:
>>>>>>>
>>>>>>> DB1:
>>>>>>> MDF: 420 MB
>>>>>>> LDF: 21.8 GB
>>>>>>>
>>>>>>> DB2:
>>>>>>> MDF: 250 MB
>>>>>>> LDF: 10.2 GB
>>>>>>>
>>>>>>> Even though we do a transaction log backup, the LDF file sizes don't
>>>>>>> change even after a Shrink process.
>>>>>>>
>>>>>>> I did some reading on backup policies. Looks like the answer we're
>>>>>>> looking
>>>>>>> for is to change our Recovery Model.
>>>>>>>
>>>>>>> My question is will I be able to shrink the transaction log file
>>>>>>> size by
>>>>>>> switching to Simple Recovery model.
>>>>>>>
>>>>>>> I'm quickly running out of space. Based on the answers I will get
>>>>>>> for my
>>>>>>> question, here's what I intend to do:
>>>>>>>
>>>>>>> 1. Perform FULL back up on both databases and their transaction log
>>>>>>> files 2. Switch to Simple Recovery Model.
>>>>>>> 3. Once I get some space and normalcy back, I will wait till the
>>>>>>> weekend
>>>>>>> to add 3 more hard disks to the server box and set up a RAID 5
>>>>>>> configuration 4. Once I restore the databases, I will wait for a few
>>>>>>> more days to monitor these databases
>>>>>>> 5. Switch back to Full Recovery model but this time set up timely
>>>>>>> transaction log file backups to control the growth of these files.
>>>>>>>
>>>>>>> Please let me know:
>>>>>>> 1. Will switching to Simple Recovery Model help me shrink LDF file
>>>>>>> sizes? 2. Does my 5-step execution plan make sense. If not, I'd
>>>>>>> appreciate your suggestions.
>>>>>>>
>>>>>>
>>>>
>>

"Sam" wrote:

> Hi,
>
> We're running SQL Server 2005 Std. We have two mission critical databases on
> this server. Because of our backup policies -- Full Recovery, the transaction
> files on these databases ate up all the available space on the server. Here's
> the actual space usage data on these databases:
>
> DB1:
> MDF: 420 MB
> LDF: 21.8 GB
>
> DB2:
> MDF: 250 MB
> LDF: 10.2 GB
>
> Even though we do a transaction log backup, the LDF file sizes don't change
> even after a Shrink process.
>
> I did some reading on backup policies. Looks like the answer we're looking
> for is to change our Recovery Model.
>
> My question is will I be able to shrink the transaction log file size by
> switching to Simple Recovery model.
>
> I'm quickly running out of space. Based on the answers I will get for my
> question, here's what I intend to do:
>
> 1. Perform FULL back up on both databases and their transaction log files
> 2. Switch to Simple Recovery Model.
> 3. Once I get some space and normalcy back, I will wait till the weekend to
> add 3 more hard disks to the server box and set up a RAID 5 configuration
> 4. Once I restore the databases, I will wait for a few more days to monitor
> these databases
> 5. Switch back to Full Recovery model but this time set up timely
> transaction log file backups to control the growth of these files.
>
> Please let me know:
> 1. Will switching to Simple Recovery Model help me shrink LDF file sizes?
> 2. Does my 5-step execution plan make sense. If not, I'd appreciate your
> suggestions.
>
> --
> Thanks,
>
> Sam

> Thank you all for your responses. I'm currently on a RAID but it's not
> RAID 5, it's currently a RAID 1.
>
> Looks like what I suggested -- the 5 step process -- should work. I will
> though run those tests you suggested.
>