New answers tagged

3

...once they are no longer in cache, both selecting and deleting the same 12 thousand rows takes ~40 seconds. This seems to indicate that the storage subsystem is inadequate. If this is the cause, SQL Server will probably be waiting with one of the PAGEIOLATCH_XX wait types. It definitely appears that the LOB data must be loaded into memory on the ...


0

Few Quick Possibilities: Bad Statistics. Seems unlikely on a table under millions of rows, but technically possible. Try running UPDATE STATISTICS . If this does work look into why your statistics are getting out of whack and what you can do to mitigate the problem. Lack of a good Clustered Index. This can be related to #1, if your CI is bad it can slow ...


0

What you are asking for can lead to unpredictable results in certain situations. What kind of situations? Running this on a Master and the Slave receives the same SQL. The problem I see is that rows of data in a Master may not be physically written in the same order on the Slave. Triggers will encounter issue (or really create issues) with this type of ...


2

I have never used SharePoint or worked with its databases specifically, but both links in your question indicate that you should be able to see, and work with, SharePoint databases in SQL Server Management Studio. The fact that you cannot see them in your particular case most likely means that they are hosted by a different server instance – not the ...


1

(This does not address your question directly; rather it addresses your goal of deleting old records.) Plan A You are talking about DELETEing "old" records. Assuming you are removing "all" the old records, then PARTITIONing is an excellent way to do that. PARTITION BY RANGE(TO_DAYS) by weeks. Use DROP PARTITION (instantaneous and non-invasive) to get ...



Top 50 recent answers are included