InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 22 May 2013 16:23:08 GMT20http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxIn that case consider switching to SIMPLE recovery before your maintenance then back to FULL after. Take a FULL backup immediately after switching back to FULL recovery to re-establish a log chain and continue taking log backups per the usual schedule.Thu, 06 Sep 2012 13:17:09 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxWe don't use the snaps as a backup method. It is strictly for rollback purposes if an update messes up.I have yet to ever have to roll a snapshot back.Thu, 06 Sep 2012 12:55:26 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxIf your talking about small DBs where it only takes 20 minutes for CHECKDB and you want as close to turnkey as possible, then go for it.I still would not overwrite your backup files though. If that's what you're going to do you might as well take a FULL backup, switch your DB into SIMPLE recovery before all the maintenance tasks, then switch back to FULL recovery and take another FULL backup and resume log backups.edit:PS VM snaps are no substitute for valid (i.e. can be restored) full + tran log backups taken from SQL Server to achieve point-in-time recovery. VMs can always serve as a recovery option in a pinch but should not be used as a first line of defense IMO. You are right about it being a whole other ball.Thu, 06 Sep 2012 12:05:04 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote] If there is corruption you want to stop right there and figure out what's going on.[/quote]So do you suggest I only move on to the backup and everything else if the checkdb is successful?This happens at 2AM in the morning no production is running during this process and it takes about 20 minutes to do the check and another 20 to do the index.I will also be honest as I have stated before not sure if in this topic or not. My real job is a net and sys admin. DB administration is only because I'm the only one I'm lucky if I can devote 10 minutes a week to db administration. So I do not check these logs weekly nor stay up on it. I need more of a run and have faith nothing wrong is happening.Which so far in my 10 years that is how sql has been treating me very well in those regards.I will say one concern you do raise which has been on my radar is Snapshots since we are 100% virtualized. I have set my drives that hold my sql db's to persistent so they will not snapshot but I still have concerns. My staff performs snaps once a month for update installations. This of course is another whole ball of wax.Thu, 06 Sep 2012 11:59:53 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxI do append to the same file for ease of file cleanup later when I do the overwrite.as this might not be the most perfect way it works. I do understand the logic of the other method.We backup on multiple levels though so I'm not so concerned about this specific file. We do nightly file system backups and nightly SQL backups from Backupexec. This actual sql backup I'm performing is more to control log growth and to just have another level of protection.Thu, 06 Sep 2012 11:51:08 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (9/6/2012)[/b][hr]ok here is where I'm settling.1. run db integrity check system db2. run db integrity check users db3. backup db full4. backup db log file (overwrite)5. set db bulk mode6. indexOptimize with stat update7. run db integrity check users db8. set db full recovery9. backup db log file (append)I do nightly log backups append and then during 8-5 during high transactions I'm doing log backups append every 15 minutes since we are doing some work currently that is really causing major transaction accumulation archive and purging inside the db. Once this is done I will probably remove the every 15 min run.What do you think about his weekly recommendation of running these cleanup task?Cleanup:•sp_delete_backuphistory one day a week•sp_purge_jobhistory one day a week•CommandLog Cleanup one day a week•Output File Cleanup one day a weekI have never ran any cleanup task before.[/quote]Why run checkdb again? If there is corruption you want to stop right there and figure out what's going on. If after analysis you determine a targeted index rebuild might correct it, run that, and then run checkdb again. checkdb might be the most intense operation you'll put your database through, so if your DB is large running it twice for no benefit in the vast majority of cases, and only a small benefit in the rest of the cases, is not worth it in my opinion.What do you mean by 'overwrite' ? Are you in the habit of appending backups to existing files? If so, I would recommend switching to one-backup-per-file.Thu, 06 Sep 2012 11:47:00 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxAre you appending each backup to the same file? If so, I would change that. Each backup should go to its own file. Currently you will lose all backup files if that file were to be accidently deleted or were to become corrupt.Thu, 06 Sep 2012 11:44:36 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxok here is where I'm settling.1. run db integrity check system db2. run db integrity check users db3. backup db full4. backup db log file (overwrite)5. set db bulk mode6. indexOptimize with stat update7. run db integrity check users db8. set db full recovery9. backup db log file (append)I do nightly log backups append and then during 8-5 during high transactions I'm doing log backups append every 15 minutes since we are doing some work currently that is really causing major transaction accumulation archive and purging inside the db. Once this is done I will probably remove the every 15 min run.What do you think about his weekly recommendation of running these cleanup task?Cleanup:•sp_delete_backuphistory one day a week•sp_purge_jobhistory one day a week•CommandLog Cleanup one day a week•Output File Cleanup one day a weekI have never ran any cleanup task before.Thu, 06 Sep 2012 11:36:36 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (9/6/2012)[/b][hr]the reason I was doing the integrity check twice is because I taught to run it first. Then ran it again because of this comment:http://ola.hallengren.com/frequently-asked-questions.htmlScheduling:"I recommend that you perform the integrity check after the index maintenance because index rebuilds sometimes fix database corruption."[/quote]He makes good points but I do not see it that way. If there is corruption in the database then I want it to surface during the integrity check, not masked by the index maintenance job. SQL Server will not create corruption on its own. Problems usually step from something gone awry in the I/O subsystem. The earlier problems like this are detected the better.Taking a full backup (or differential) after the index maintenance job will not free the active portion of the log. Only a tran log backup will do that so I'll stick with my log backup after the index job instead of a full.Thu, 06 Sep 2012 11:07:45 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxthe reason I was doing the integrity check twice is because I taught to run it first. Then ran it again because of this comment:http://ola.hallengren.com/frequently-asked-questions.htmlScheduling:"I recommend that you perform the integrity check after the index maintenance because index rebuilds sometimes fix database corruption."Thu, 06 Sep 2012 10:59:50 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (9/6/2012)[/b][hr]So let me throw my weekly maintenance plan order to you and please provide any feedback.1. run db integrity check system db2. set db bulk mode [b]< why?[/b]3. run db integrity check users db4. set db full recovery5. backup db full6. backup db log file7. set db bulk mode8. indexOptimize with stat update9. run db integrity check users db[b]< why again?[/b]10. set db full recoveryI know the article says to do a db backup after the index optimize but I was always taught to backup before those major operations incase of an issue.[/quote]In general the approach is a good one to keep. Index operations are not going to change the data in your database. Take a backup before if you're comfortable, but I do not think it is necessary and do not do that myself. If you're running in FULL or BULK LOGGED you can always get back to the point in time before you began the index and stats maintenance if ever needed.How often are you running log backups? You should take a log backup after you do your index maintenance to free the active portion of the log. Index maintenance will bloat your tran log [i]backups[/i] (even in BULK LOGGED).See how this sits with you:1. run db integrity check system and users db+ run full backup7. set db bulk mode8. indexOptimize with stat update10. set db full recovery+ run log backupThu, 06 Sep 2012 10:47:02 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxSo let me throw my weekly maintenance plan order to you and please provide any feedback.1. run db integrity check system db2. set db bulk mode3. run db integrity check users db4. set db full recovery5. backup db full6. backup db log file7. set db bulk mode8. indexOptimize with stat update9. run db integrity check users db10. set db full recoveryI know the article says to do a db backup after the index optimize but I was always taught to backup before those major operations incase of an issue.Thu, 06 Sep 2012 09:18:20 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote]A more advisable way to do this would be to leave the proc as-is and just provide the specialized parameters when you call it:[/quote]Perfect! I like this solution and when I did click to modify the SP it did create an ALTER PROCEDURE [dbo].[IndexOptimize]This is why I figured I could just execute the modified code but I do like what you have provided much better.Thanks again for all the help and valuable information!Thu, 06 Sep 2012 06:28:47 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxIf you right-clicked the script in SSMS Object Explorer and clicked Modify then it would have scripted the proc to a new Query Window as an ALTER PROC script. After modifying that you can simply execute the entire thing to save your changes to the server. Note that you should save that script off to another location since it is now non-standard in terms of what Ola has produced. A more advisable way to do this would be to leave the proc as-is and just provide the specialized parameters when you call it:[code="sql"]EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @LogToTable = 'Y', @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @StatisticsSample = 100;[/code]This way when Ola releases updated versions of his procs, which he periodically does, you will not need to remember to make your changes to his proc again.Wed, 05 Sep 2012 14:58:38 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxok I modified the top of the SP found under master dbo.indexoptimize[code="sql"]-- @UpdateStatistics nvarchar(max) = NULL,@UpdateStatistics nvarchar(max) = ALL,-- @OnlyModifiedStatistics nvarchar(max) = 'N',@OnlyModifiedStatistics nvarchar(max) = 'Y',-- @StatisticsSample int = NULL,@StatisticsSample int = 100,@StatisticsResample nvarchar(max) = 'N',[/code]ok scratch this I don't know how to save the changes. Do I just execute the opened SP after the changes are made?Wed, 05 Sep 2012 14:36:57 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxYou're welcome. I would let Ola's script handle the updating of stats using @UpdateStatistics = ALL, @OnlyModifiedStatistics = Y and @StatisticsSample = 100. Note these settings will do a full scan of all modified stats so could take a long time on a VLDB but you'll give the optimizer the best possible info it can get for estimating execution plans.Wed, 05 Sep 2012 14:26:32 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxI'm thinking of just running the standard ALL FULL update statistics I found in the Maintenance Plan where I would modify this to ALL but do you think there is benefit to running this from the MaintenanceSolution?If so what is your statistics settings recommendation?Wed, 05 Sep 2012 14:09:17 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxI see thanks!Wed, 05 Sep 2012 13:55:21 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxThis can go into your Execute T-SQL Statement Task:[code="sql"]EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @LogToTable = 'Y'[/code]Wed, 05 Sep 2012 13:51:34 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxyou lost me here.I think you meant I could run the command I pasted. Not sure though.Wed, 05 Sep 2012 13:47:46 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxYou can just call the SQL directly, no need to use sqlcmd there.If you pull that EXEC into a T-SQL Statement Task in your MP that will get it to wait.Wed, 05 Sep 2012 13:45:47 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxwould I use the code in the job that runs the stored procedure?example:[code="sql"]sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @LogToTable = 'Y'" -b[/code]or do I need to pull from the stored procedure?Wed, 05 Sep 2012 13:43:24 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (9/5/2012)[/b][hr]I do not see an execute package task in sql 2005 options for maintenance plans.How can I execute these jobs so that the plan waits?Is there a way to maybe take the sql that is in the job and put in the maintenance plan as a execute sql task?[/quote]Sorry, when I mentioned the Execute Package Task I was thinking of the full version of SSIS. I do not use Maintenance Plans (MPs) unless it is for a client with a small or nonexistent IT department and tend to forget they are limited versions of SSIS. You can use the Execute T-SQL Statement Task to execute the code you want and that will have the rest of your MP waiting until it completes before moving on.Wed, 05 Sep 2012 13:41:27 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxI do not see an execute package task in sql 2005 options for maintenance plans.How can I execute these jobs so that the plan waits?Is there a way to maybe take the sql that is in the job and put in the maintenance plan as a execute sql task?Wed, 05 Sep 2012 13:28:24 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (9/5/2012)[/b][hr]Ok I think I almost have everything up to snuff finally but a few last questions. I want to use these provided index and integrity check operations from my maintenance plan.I'm using the Execute SQL Server Agent Job Task to do this but..Later I get an error and what I think is going on is the task is executed but it is not waiting for completion of the agent job before moving on.Any suggestions?[/quote]The SSIS Task is simply a pass-through to the proc [u][url=http://msdn.microsoft.com/en-us/library/ms186757(v=sql.90).aspx]sp_start_job[/url][/u] which starts a job but does not wait for it to complete before returning control.You can try using an Execute Package task to execute the Maintenance Plan which will wait for completion before returning control.[quote]The other question I had was regarding a statistics update. It says the default is: Do not perform statistics maintenance. This is the default.Is this true then it is not performing stat updates? Is there a way to modify this after running the maintenacesolution.sql?[/quote]You can edit the proc dbo.IndexOptimize and change this line replacing NULL with the constant you want:[quote]@UpdateStatistics nvarchar(max) = NULL,[/quote]Wed, 05 Sep 2012 12:29:08 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (9/5/2012)[/b][hr]Ok I think I almost have everything up to snuff finally but a few last questions. I want to use these provided index and integrity check operations from my maintenance plan.I'm using the Execute SQL Server Agent Job Task to do this but..Later I get an error and what I think is going on is the task is executed but it is not waiting for completion of the agent job before moving on.Any suggestions?I'm running a integrity check twice once at start then again at end and it fails the second run:[quote]Executing the query "EXEC msdb.dbo.sp_start_job @job_id=N'b79066e6-9d0a-4989-b475-0cb9bb45c7eb'" failed with the following error: "SQLServerAgent Error: Request to run job DatabaseIntegrityCheck - USER_DATABASES (from User NT AUTHORITY\\SYSTEM) refused because the job is already running from a request by User NT AUTHORITY\\SYSTEM.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly[/quote]The other question I had was regarding a statistics update. It says the default is: Do not perform statistics maintenance. This is the default.Is this true then it is not performing stat updates? Is there a way to modify this after running the maintenacesolution.sql?[/quote]This, EXEC msdb.dbo.sp_start_job @job_id=N'b79066e6-9d0a-4989-b475-0cb9bb45c7eb', is an asyncronous call to start the job. It does not wait until it is finished to return.When you try to run it a second time, it is still running, hence the error you received.Wed, 05 Sep 2012 12:24:15 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxOk I think I almost have everything up to snuff finally but a few last questions. I want to use these provided index and integrity check operations from my maintenance plan.I'm using the Execute SQL Server Agent Job Task to do this but..Later I get an error and what I think is going on is the task is executed but it is not waiting for completion of the agent job before moving on.Any suggestions?I'm running a integrity check twice once at start then again at end and it fails the second run:[quote]Executing the query "EXEC msdb.dbo.sp_start_job @job_id=N'b79066e6-9d0a-4989-b475-0cb9bb45c7eb'" failed with the following error: "SQLServerAgent Error: Request to run job DatabaseIntegrityCheck - USER_DATABASES (from User NT AUTHORITY\\SYSTEM) refused because the job is already running from a request by User NT AUTHORITY\\SYSTEM.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly[/quote]The other question I had was regarding a statistics update. It says the default is: Do not perform statistics maintenance. This is the default.Is this true then it is not performing stat updates? Is there a way to modify this after running the maintenacesolution.sql?Wed, 05 Sep 2012 12:11:13 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (7/16/2012)[/b][hr]Is there a command to change the recovery model on the fly.[/quote][u][url=http://msdn.microsoft.com/en-us/library/ms190203(v=sql.90).aspx]Considerations for Switching from the Full or Bulk-Logged Recovery Model[/url][/u]In the article they show the ALTER DATABASE commands to switch back and forth.Mon, 16 Jul 2012 15:10:39 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxYou need to rebuild indexes regularly, not every 6 months. Ola's script will only rebuild what needs rebuilding so avoids the wasted effort of rebuilding indexes that don't need a rebuild.ALTER DATABASE to change recovery models, read this on bulk-logged before you use it.[url]http://www.sqlservercentral.com/articles/Recovery+models/89664/[/url]Mon, 16 Jul 2012 15:10:33 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxI will set it to 3000 for 3GB I believe it is only using about 1GB during the week at the most so 3GB should give it some room.Is there a command to change the recovery model on the fly. I was thinking of just pulling the rebuild index and maybe doing this like once every 6 months.Mon, 16 Jul 2012 15:05:01 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx1) Don't shrink on a regular basis2) Don't shrink your log to 0, regrowing a log from 0 is an expensive operation. If you absolutely have to shrink, shrink to its usual size.3) truncateOnly is not a valid option when shrinking a log, it's ignored. That command will shrink the log to 0If you don't want to log growing during index rebuilds, firstly don't rebuild everything (Ola's script), second switch to bulk-logged recovery for the duration of the rebuild if the risks to point-in-time recovery are acceptable.Mon, 16 Jul 2012 15:00:38 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxI do appreciate the information everyone has provided.Mon, 16 Jul 2012 14:59:44 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (7/16/2012)[/b][hr]I changed the daily code to run:[quote]USE [ActivplantDB]GODBCC SHRINKFILE (N'ActivplantDB_Log' , 0, TRUNCATEONLY)GO[/quote][/quote]Shrinking to 0 is not a good approach no matter what your situation. Growing a log file is expensive, very expensive as a matter of fact, so shrink it to a size that is as [i]large[/i] as you can tolerate. You know it will continue to grow again so shrinking it to 0 is asking for more activity on your server. If you can tolerate 50GB, shrink to 50GB. If only 3GB, then shrink to 3GB.[size="1"]edit: punctuation[/size]Mon, 16 Jul 2012 14:58:43 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxI changed the daily code to run:[quote]USE [ActivplantDB]GODBCC SHRINKFILE (N'ActivplantDB_Log' , 0, TRUNCATEONLY)GO[/quote]Mon, 16 Jul 2012 14:52:26 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (7/16/2012)[/b][hr]it is the standard shrink command it does not give me the option to define what I shrink from what I can tell. This is the code it runs.USE [ActivplantDB]GODBCC SHRINKDATABASE(N'ActivplantDB', 10, TRUNCATEONLY)GOUSE [InfinityQS]GODBCC SHRINKDATABASE(N'InfinityQS', 10, TRUNCATEONLY)[/quote]At the very least, until you decide what to do long term, stop shrinking your data files. Use DBCC SHRINKFILE on your log file only:[u][url=http://msdn.microsoft.com/en-us/library/ms189493(v=sql.90).aspx]DBCC SHRINKFILE (SQL Server 2005)[/url][/u]Mon, 16 Jul 2012 14:51:22 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (7/16/2012)[/b][hr]this maintenance.sql what does it do?[/quote]You do not have to install the Maintenance package he provides but it is turnkey so if you're having trouble with backups and checkdb consider it. The Index Maintenance portion (the direct link in my earlier post) examines the fragmentation level of indexes and rebuilds or reorganizes it only if it is above some threshold. The built in MP task rebuilds everything regardless of the level of fragmentation. The chances are extremely good that implementing Ola's Index Maintenance solution will significantly reduce the amount of rebuilds you do, likely resolving a lot of your log bloat and log backup size issues.[quote]I'm a DB admin that only looks when required. My main job is everything else in the company from net admin, server admin, exchange and so on...[/quote]Understood. I am showing you a common solution to a common problem. It only requires a bit of your time to dedicate to it, otherwise you'll be chasing this issue indefinitely.[quote]So I don't completely understand what this sql script does. We are in the process of having the application archive the data in the db to reduce the overall size.I have skrinks put in because we don't have all the space in the world. I don't want a file growing to 20GB because of something done but then after a backup the file really is sitting around 1GB all the time but because of that special time the file grew out of this world.[/quote]If you want to get beyond this issue read the article in my last post and consider spending a couple hours implementing Ola's solution, that's all it should take if you dedicate some time to it.Mon, 16 Jul 2012 14:49:53 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxit is the standard shrink command it does not give me the option to define what I shrink from what I can tell. This is the code it runs.USE [ActivplantDB]GODBCC SHRINKDATABASE(N'ActivplantDB', 10, TRUNCATEONLY)GOUSE [InfinityQS]GODBCC SHRINKDATABASE(N'InfinityQS', 10, TRUNCATEONLY)Mon, 16 Jul 2012 14:43:14 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxthis maintenance.sql what does it do?I'm a DB admin that only looks when required. My main job is everything else in the company from net admin, server admin, exchange and so on...So I don't completely understand what this sql script does. We are in the process of having the application archive the data in the db to reduce the overall size.I have skrinks put in because we don't have all the space in the world. I don't want a file growing to 20GB because of something done but then after a backup the file really is sitting around 1GB all the time but because of that special time the file grew out of this world.Mon, 16 Jul 2012 14:40:34 GMTlawson2305http://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspx[quote][b]lawson2305 (7/16/2012)[/b][hr]I do have a full maintenance plan run every Sunday. So I retract my statement before I run a log backup appended everyday but Sunday 2AM.in the plan I:Check DB integrityBackup DBBackup LogRebuild Index - reorganize pages with default amount of free space and sort results in a tempdbupdate statistics[b]shrink DB[/b][/quote]Are you shrinking the data files too, or only the log file?At any rate, as mentioned before, shrinking log or data files is futile unless you know what's making them grow.Please read this and all linked articles. It's a great information portal on this topic. Just take the rant-like tone with a grain of salt, he knows what he is talking about:[u][url=http://www.brentozar.com/archive/2009/08/stop-shrinking-your-database-files-seriously-now/]Stop Shrinking Your Database Files. Seriously. Now.[/url][/u]Mon, 16 Jul 2012 14:37:58 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1313513-357-1.aspxIn fact, you should not be shrinking your database on a regular basis. Should you determine how much space your databse requires over the next 3 to 6 months and size it appropriately. Then, as you approach the 3 to 6 month window, you should evaluate again and add enough space to allow your database to grow over the next 3 to 6 months.Mon, 16 Jul 2012 14:25:47 GMTLynn Pettis