Since I plan to do a lot of testing, create a table to store some test definitions and results.
OK. Let's create a very basic heap to submit to checktable operations.
Its really, really easy for me to skip a detail like coalescing NULL values in wait tables to zero in order to get valid deltas... so lets encapsulate the test and results capture in a stored procedure.
Here's my simple stored procedure:
- take parameters for a checktable operation
- record the parameters and tare OLEDB wait values from system and session levels
- execute dynamic SQL for checktable operation
- record system and session level OLEDB wait values after checktable completion
All right. Let's run 8 tests - from MAXDOP 8 in decreasing order to MAXDOP 1.
And what was captured for OLEDB wait stats during each checktable?
They say a picture is worth a thousand words...
OLEDB wait count at the system level ranged from 6428 at maxdop 1 and maxdop 2 up to 6435 at maxdop 8. Interesting. The table OLEDB_TEST_HEAP was constructed with 80 * 80 = 6400 rows, each of which are expected to consume an 8k block (because of the 4000 character NVARCHAR and the lack of compression on the table). Since these results are from physical_only tests, could the number of waits be related to the number of blocks in the heap?
That seems plausible.
Let's resize OLEDB_TEST_HEAP to 10000 rows and see what happens.
Now run the same tests as above, with maxdop decreasing from 8 to 1, and display the results captured. Interesting. Very interesting.
So... yeah. Definitely a relationship between the number of pages in the heap and the number of OLEDB waits. Something(s) increase the number of OLEDB waits beyond the number of data pages, the number of used pages and the number of reserved pages in a way that I haven't deciphered yet, though.
One thing is clear - above maxdop 2, one OLEDB wait is added for each incremental increase in maxdop. That's interesting. Another interesting point: at maxdop 2 and maxdop 1 the number of OLEDB system waits are equal rather than decreasing again by 1. Hmmm.
And the most interesting thing: at maxdop 2 and maxdop 1, the session OLEDB waits seem not to update.
I created a connect item for the OLEDB wait disappearing act in the session wait DMV sys.dm_exec_session_wait_stats. The repro in this blog post is better than the one I put in the details of that connect item :-) I'll update the connect item later.
OLEDB waits not always updating in sys.dm_exec_session_waits
There's more to come as I continue to look at OLEDB wait behavior in checktable operations...
carry on with this epic saga here...
OLEDB waits in #SQLServer Checktable Part II - the song remains very nearly the samehttp://sql-sasquatch.blogspot.com/2017/06/oledb-waits-in-sqlserver-checktable_5.html