Tag Info

Hot answers tagged

8

No. This hard-coded restriction exists for good reasons related to possible excessive query plan compilation time. You can workaround it by listing the VALUES clauses in a CTE, then INSERTing from the CTE, but I do not recommend it. Break the INSERT statement up into VALUES clauses of <= 1,000 lines each as a workaround, or use an alternative data ...


4

SQL Server does not maintain when an Index was last rebuild, instead it keeps information when stats were last updated. That can be found using the STATS_DATE function. You can use Ola's Index maintenance solution or Michelle Ufford's - Index Defrag Script. These scripts are widely tested in the community and are much flexible so that you can adapt as per ...


2

From the SQL Server query optimizer's point of view, there is not much to choose between the parallel and serial execution plans in this case. In general, the optimizer's cost model reduces the CPU cost (not the I/O cost) of operators in a parallel plan in proportion to the estimated degree of parallelism available. This CPU adjustment explains why the ...


1

Dirty pages are written directly to the data files. There is no need to write them to the log because their modifications have been logged already. A dirty page never hits disk until all log records that record its modification have been written already. After the log has been hardened SQL Server is at leisure to write dirty data pages whenever it wants (or ...


1

As Kin noted above, it is not possible to get this information since it is not stored by SQL Server. Please refer to this article on technet. Since you are using Ola's scripts, unless you changed the defaults, the output of the IndexOptimize job should go to the same location as your error log.



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