|
|
Posted by Erland Sommarskog on 10/02/21 11:48
DataPro (datapro01@yahoo.com) writes:
> Here is what the vendor is recommending:
>
> 1. Back up db and log via Windows Explorer or normal db backups
> 2. Stop services (application...EAS)
> 3. Disconnect/detach database
> 4. Delete log via Windows Explorer
> 5. Reconnect/reattach database.....log will dynamically be allocated
>
> Does this make sense?
No! Never delete a log file, unless you are told so by a Microsoft
support professional. There are so many people who have lost their
database, because they deleted the log. I guess it's safe if you
detach first, but I would like to take a gamble with a production
database.
> They also want autoshrink turned on but its my understanding some SQL
> DBA's don't want that. Your thoughts?
Shrinking a database file only make sense if there has been some
exceptional activity. Running a schema upgrade certainly counts as one.
But doing it as a matter of routine, or with autoshrink, only serves
to degrade the performance of the application in three different
ways:
1) The shrinking takes resources.
2) The autogrow takes resources.
3) The log file becomes fragmented on disk.
Autogrow is a mixed blessing. Up to SQL Server 6.5 there was no autogrow,
which meant that if the data or log segment was filled up, it was a
hard stop. Autogrow that was added in SQL 7 avoids these situations,
as long as the disk has space. However, for the DBA there is not
really any difference: he should should still monitor database size
amd increase the size in due time. A 10% autogrow in a 200 GB database
is very painfully noticeable fot the users.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|