Tag Info

Hot answers tagged

5

DBCC CHECKDB is vital for SQL Server databases to be 100% sure that there is no corruption. However, due to databases growing massive in size, its very hard to find a maintenance window when you claim to be 24x7 up. Over the years, SQL Server team has implemented various mechanisms that will detect most common forms of corruptions especially related to ...


4

Are these additional checks necessary/important? (Indexed views are probably a bit more concerning to me, I don't think we are using Service Broker or FILESTREAM yet.) You can run DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS directly on the indexed views. Checking indexed views can be problematic in certain circumstances, so be prepared to investigate ...


4

5000 inserts per minute are about 83 inserts per second. With 5 indexes that's 400 physical rows inserted per second. If the workload was in-memory this would not pose a problem even to the smallest of servers. Even if this was a row-by-row insert using the most inefficient way I can think of. 83 trivial queries per second are just not interesting from a CPU ...


2

this is a very loaded question. You're using advanced features of MS SQL Server but are leaving out a lot of information regarding HA. The senior DBA that set all this up should have a upgrade plan for you which has all the requirements listed such as acceptable replication delays, massive testing to ensure the replication won't break, testing service ...


2

Hopefully with that size you are on Enterprise edition? If not, good luck :) (just kidding see bottom of answer) If you are on Enterprise, I would suggest looking into partitioning. This has saved my butt a time or two when dealing with this same kind of scenario. Create your partitions on the date field and you will have to best determine how big you want ...


1

A colleague of mine had a similar-ish problem with long-running shrinks. He took some time to investigate it and found that he had lots of indexes at the 'end' of the file. A little index maintenance, and then the shrink operation ran fine. You can read his blog about it here: http://sqltrees.wordpress.com/2013/08/11/shrinking-databases/


1

First you need to run upgrade advisor to be able to confirm that there won't be any errors during the upgrade from 2008 to 2012. If you want to minimize downtime, then setup mirroring from SQL 2008 to 2012 (yes mirroring is still supported but declared deprecated). Then during the day of cutover (migration), change the mode of mirroring to SYNCHRONOUS and ...



Only top voted, non community-wiki answers of a minimum length are eligible