Azure SQL DB Managed Instances: New Wait Stats

Incidental

This is a long list that I haven’t had a change to dig through yet — all I did was compare them to which waits were occurring on my 2017 CU4 instance.

There are about 174 of them that I found, though some may just be generated by Hekaton that I don’t have set up on my home servers.

Feel free to make notes on that Google Sheet — I’ve opened that up to the public.

Some kind of interesting ones:

  • BOOST_CPU_TASK
  • CLOUD_FABRIC_ENQUEUE
  • CLOUD_FABRIC_PAIRUP
  • CLOUD_FABRIC_RELEASE_ALL
  • CLOUD_FABRIC_WAIT
  • CPU_ALLOCATION_VERIFIER
  • FABRIC_PAIRING
  • SOS_WORK_DISPATCHER
  • TIERED_STORAGE_MIGRATION_TASK
  • TIERED_STORAGE_PERSIST_LRU_INFO_TASK
  • TIERED_STORAGE_REENCRYPTION_TASK
  • TIERED_STORAGE_SCANNER
  • WAIT_VLDB_DUMP_LOG_LOCK

I wonder what Microsoft considers a VLDB to be. Could this be the standard that we all abide by when talking about our VERY LARGE BIG HUGE TABLE problems?

Stay tuned!

 

Menu
{"cart_token":"","hash":"","cart_data":""}