In general it is not a best practice to perform SHRINK database operation on a production server, atleast regularly! Sometimes it may be compulsory to keep them sized in order to ensure the disk storage is not compromised for any sudden changes to databases ETL processes, coming to the point by design...
Memory - an important aspect of system performance within a RDBMS platform, not specific to a database product or application. Coming to Microsoft related products such as Windows Server and SQL Server so on, various resources available on web such as MSDN blogs, Books Online and articles, frequently...
Posted to
SQLServer-QA.net - Knowledge Sharing Network (SSQA.net)
(Weblog)
by
Anonymous
on
04-01-2008
Filed under: sql server, performance, memory, cache, disk space, troubleshoot, system, best practice, raid, hardware, monitoring, configuration, baseline
As a programmer interacting with SQL Server's cache is not often needed, but when you do need to determine what is going on with the cache, or you simply need to flush the execution plans or data pages to tune a query, you now have the means to do so. Below is the TSQL I have used to obtain buffers...
We already know that using DBCC FREEPROCCACHE will have the affect of flushing all the cache with immediate affect and also DBCC FREESYSTEMCACHE (new in SQL 2005) has similar affect but will flush the plans asynchronously that are marked as unused anymore. Also you would know that when a database is...
I don't believe you would need to reset the cache on a production server, it is not a best practice to perform in this case. Most of the times in development or test environments for the purpose of benchmarking you would need to reset the cache for optimum results. You may know that in this case...