dbcc dmvs 2005 2008

DBCC dropcleanbuffers

DBCC freeproccacheDBCC freesessioncache

DBCC perfmon

Execution phaseDescriptionProgress reporting granularityDBCC TABLE CHECKThe logical and physical consistency of the objects in the database is checked during this phase.Progress reported at the database page level.The progress reporting value is updated for each 1000 database pages that are checked.DBCC TABLE REPAIR

DBCC checkalloc [('dbname'dbid[, NOINDEX REPAIR])] [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, ESTIMATEONLY]]DBCC checkcatalog [('dbname'dbid)] [WITH NO_INFOMSGS]DBCC checkconstraints [( 'tab_name' tab_id 'constraint_name' constraint_id )] [WITH ALL_CONSTRAINTS ALL_ERRORMSGS]DBCC checkdb [('dbname dbid'[, NOINDEX REPAIR])] [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY][, ESTIMATEONLY][, TABLOCK]]DBCC checkfilegroup [( [ {'filegroup_name' filegroup_id} ] [, NOINDEX] )] [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY][, ESTIMATEONLY][, TABLOCK]]DBCC checkident ('table_name'[, { NORESEED {RESEED [, new_reseed_value] } } ] )DBCC checktable ('table_name'[, {NOINDEX index_id REPAIR}]) [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY][, ESTIMATEONLY][, TABLOCK]]DBCC cleantable ('dbname'dbid, 'table_name'table_id [, batch_size])DBCC concurrencyviolation (reset display startlog stoplog)DBCC dbreindex ('table_name' [, index_name [, fillfactor]]) [WITH NO_INFOMSGS]DBCC dbrepair ('dbname', markdirty {dropdevice, int} {repairindex, int, int})

DBCC free dll_name (FREE) e.g. DBCC xp_sample (FREE)

DBCC help ('dbcc_command' '?')DBCC indexdefrag ({dbname dbid 0}, {tableid tablename} [, {indid indname} [, partition_number]])DBCC inputbuffer (spid, [batchid])DBCC opentran [({'dbname' dbid})] [WITH TABLERESULTS[,NO_INFOMSGS]]DBCC outputbuffer (spid, [batchid])

DBCC pintable (database_id, table_id)DBCC proccache ([compplan_ticks_threshold])DBCC requeststats ({clear} {setfastdecayrate, rate} {setslowdecayrate, rate})DBCC show_statistics ('table_name'[, 'target_name'])DBCC showcontig ([table_id table_name [, index_id index_name]] [WITH FAST, ALL_INDEXES, TABLERESULTS [,ALL_LEVELS]])DBCC shrinkdatabase ({'dbname'dbid}, [freespace_percentage [, {NOTRUNCATE TRUNCATEONLY}]])DBCC shrinkfile ({fileid 'filename'} {[, EMPTYFILE] [[, compress_size] [, {NOTRUNCATE TRUNCATEONLY}]]})DBCC sqlperf (LOGSPACE)DBCC traceoff [( tracenum [, tracenum ... ] )]DBCC traceon [( tracenum [, tracenum ... ] )]DBCC tracestatus (trace# [, ...trace#])DBCC unpintable (dbid, table_id)DBCC updateusage ({'dbname' dbid 0} [, {'table_name' table_id} [, {index_id 'index_name'}]]) [WITH [NO_INFOMSGS] [,] COUNT_ROWS]useroptions

Database repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are object errors that must be repaired.Progress reported at the individual repair level.The counter is updated for each repair that is completed.DBCC ALLOC CHECKAllocation structures in the database are checked during this phase.Note:

Progress is not reportedDBCC ALLOC REPAIRDatabase repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are allocation errors that must be repaired.Progress is not reported.DBCC SYS CHECKDatabase system tables are checked during this phase.Progress reported at the database page level.The progress reporting value is updated for every 1000 database pages that are checked.DBCC SYS REPAIRDatabase repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are system table errors that must be repaired.Progress reported at the individual repair level.The counter is updated for each repair that is completed.DBCC SSB CHECKSQL Server Service Broker objects are checked during this phase.Note:This phase is not executed when DBCC CHECKTABLE is executed.Progress is not reported.DBCC CHECKCATALOGThe consistency of database catalogs are checked during this phase.Note:This phase is not executed when DBCC CHECKTABLE is executed.Progress is not reported.DBCC IVIEW CHECKThe logical consistency of any indexed views present in the database is checked during this phase.Progress reported at the level of the individual database view that is being checked.

The command above checks the TestDB database but not its indexes. This won’t take long at all. The output returned will tell you if there are problems with the database. If so, check to make sure your backup is handy and then you can run the next level of this command:DBCC CHECKDB (’TestDB’, REPAIR_FAST)This command will attempt to fix many errors, but won’t allow any data to be lost. If that doesn’t work, the next level of the command is:DBCC CHECKDB (’TestDB’, REPAIR_REBUILD)This command takes longer, but will also correct the indexes (if it can). It will also not allow data loss. Should this command not correct your errors, you’ll definitely want to have that backup handy, because you’re going to need it. The next level of this command will potentially lose data. It looks like this:DBCC CHECKDB (’TestDB’, REPAIR_ALLOW_DATA_LOSS)As you can probably guess, this command could potentially lose data or make your applications unusable, depending on what data is lost (if any). I only use this command to repair the database on another server and then pull data selectively where I need it.DBCC DBREINDEX

The format for the command is:DBCC DBREINDEX (TableName, IndexName, Fill Factor)The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.DBCC INDEXDEFRAG

DBCC CHECKALLOC performs the same checks.

DBCC CHECKDB (’TestDB’, NOINDEX)

The DBCC DBREINDEX command rebuilds the indexes on a database. You can specify a particular index or all of them. This is the most popular and time consuming command you’ll normally run, and the one you’ll use most often for making your database access fast.

The DBCC INDEXDEFRAG command defragments the index rather than rebuilding it. This command is normally used when time is an issue, such as in cases of very large databases. What’s normally done here is that this command is run during the week, and the DBCC DBREINDEX is run once a week.

Miscellaneous commandsThese commands perform such tasks as enabling row-level locking or removing a dynamic-link library (DLL) from memory.

DBCC HELP

DBCC PINTABLEThis command "pins" a table into memory. Once the table is accessed, it stays in the buffer cache of memory and performance (for that table, anyway) is improved. Unless you’ve got a real driving need for this command, you probably shouldn’t use it. Its sister is DBCC UNPINTABLE which of course, releases the table from memory.DBCC TRACEON

DBCC dllname (FREE)I’ve actually had to use the DBCC dllname(free) command — it’s primarily a programming convention. It frees up memory used by a DLL that’s often been called by an extended stored procedure.

DBCC HELP is one of the best commands to remember — it simply shows you the syntax of the other commands:DBCC HELP (’CHECKDB’)

This command, and its sister command DBCC TRACEOFF Turn trace flags off and on, which can control the way SQL Server implements some of its behavior. These flags are normally used for debugging purposes, and I haven’t seen them in use on a production system

The logical and physical consistency of the objects in the database is checked during this phase.

The progress reporting value is updated for each 1000 database pages that are checked.

[('dbname'dbid[, NOINDEX REPAIR])] [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, ESTIMATEONLY]]

[( 'tab_name' tab_id 'constraint_name' constraint_id )] [WITH ALL_CONSTRAINTS ALL_ERRORMSGS] [('dbname dbid'[, NOINDEX REPAIR])] [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY][, ESTIMATEONLY][, TABLOCK]]

[( [ {'filegroup_name' filegroup_id} ] [, NOINDEX] )] [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY][, ESTIMATEONLY][, TABLOCK]] ('table_name'[, { NORESEED {RESEED [, new_reseed_value] } } ] ) ('table_name'[, {NOINDEX index_id REPAIR}]) [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY][, ESTIMATEONLY][, TABLOCK]]

({dbname dbid 0}, {tableid tablename} [, {indid indname} [, partition_number]])

([table_id table_name [, index_id index_name]] [WITH FAST, ALL_INDEXES, TABLERESULTS [,ALL_LEVELS]]) ({'dbname'dbid}, [freespace_percentage [, {NOTRUNCATE TRUNCATEONLY}]])

({fileid 'filename'} {[, EMPTYFILE] [[, compress_size] [, {NOTRUNCATE TRUNCATEONLY}]]})

({'dbname' dbid 0} [, {'table_name' table_id} [, {index_id 'index_name'}]]) [WITH [NO_INFOMSGS] [,] COUNT_ROWS]useroptions

Database repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are object errors that must be repaired.

Database repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are allocation errors that must be repaired.

The progress reporting value is updated for every 1000 database pages that are checked.

Database repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are system table errors that must be repaired.

The logical consistency of any indexed views present in the database is checked during this phase.Progress reported at the level of the individual database view that is being checked.

The command above checks the TestDB database but not its indexes. This won’t take long at all. The output returned will tell you if there are problems with the database. If so, check to make sure your backup is handy and then you can run the next level of this command:DBCC CHECKDB (’TestDB’, REPAIR_FAST)This command will attempt to fix many errors, but won’t allow any data to be lost. If that doesn’t work, the next level of the command is:DBCC CHECKDB (’TestDB’, REPAIR_REBUILD)This command takes longer, but will also correct the indexes (if it can). It will also not allow data loss. Should this command not correct your errors, you’ll definitely want to have that backup handy, because you’re going to need it. The next level of this command will potentially lose data. It looks like this:DBCC CHECKDB (’TestDB’, REPAIR_ALLOW_DATA_LOSS)As you can probably guess, this command could potentially lose data or make your applications unusable, depending on what data is lost (if any). I only use this command to repair the database on another server and then pull data selectively where I need it.

The format for the command is:DBCC DBREINDEX (TableName, IndexName, Fill Factor)The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.

command rebuilds the indexes on a database. You can specify a particular index or all of them. This is the most popular and time consuming command you’ll normally run, and the one you’ll use most often for making your database access fast.

command defragments the index rather than rebuilding it. This command is normally used when time is an issue, such as in cases of very large databases. What’s normally done here is that this command is run during the week, and the DBCC DBREINDEX is run once a week.

These commands perform such tasks as enabling row-level locking or removing a dynamic-link library (DLL) from memory.

This command "pins" a table into memory. Once the table is accessed, it stays in the buffer cache of memory and performance (for that table, anyway) is improved. Unless you’ve got a real driving need for this command, you probably shouldn’t use it. Its sister is DBCC UNPINTABLE which of course, releases the table from memory.

command — it’s primarily a programming convention. It frees up memory used by a DLL that’s often been called by an extended stored procedure.

is one of the best commands to remember — it simply shows you the syntax of the other commands:DBCC HELP (’CHECKDB’)

Turn trace flags off and on, which can control the way SQL Server implements some of its behavior. These flags are normally used for debugging purposes, and I haven’t seen them in use on a production system

[( [ {'filegroup_name' filegroup_id} ] [, NOINDEX] )] [WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY][, ESTIMATEONLY][, TABLOCK]]

Database repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are object errors that must be repaired.

Database repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are allocation errors that must be repaired.

Database repairs are performed during this phase if REPAIR_FAST, REPAIR_REBUILD, or REPAIR_ALLOW_DATA_LOSS is specified, and there are system table errors that must be repaired.

The command above checks the TestDB database but not its indexes. This won’t take long at all. The output returned will tell you if there are problems with the database. If so, check to make sure your backup is handy and then you can run the next level of this command:DBCC CHECKDB (’TestDB’, REPAIR_FAST)This command will attempt to fix many errors, but won’t allow any data to be lost. If that doesn’t work, the next level of the command is:DBCC CHECKDB (’TestDB’, REPAIR_REBUILD)This command takes longer, but will also correct the indexes (if it can). It will also not allow data loss. Should this command not correct your errors, you’ll definitely want to have that backup handy, because you’re going to need it. The next level of this command will potentially lose data. It looks like this:DBCC CHECKDB (’TestDB’, REPAIR_ALLOW_DATA_LOSS)As you can probably guess, this command could potentially lose data or make your applications unusable, depending on what data is lost (if any). I only use this command to repair the database on another server and then pull data selectively where I need it.

The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.

command rebuilds the indexes on a database. You can specify a particular index or all of them. This is the most popular and time consuming command you’ll normally run, and the one you’ll use most often for making your database access fast.

command defragments the index rather than rebuilding it. This command is normally used when time is an issue, such as in cases of very large databases. What’s normally done here is that this command is run during the week, and the DBCC DBREINDEX is run once a week.

This command "pins" a table into memory. Once the table is accessed, it stays in the buffer cache of memory and performance (for that table, anyway) is improved. Unless you’ve got a real driving need for this command, you probably shouldn’t use it. Its sister is DBCC UNPINTABLE which of course, releases the table from memory.

command — it’s primarily a programming convention. It frees up memory used by a DLL that’s often been called by an extended stored procedure.

Turn trace flags off and on, which can control the way SQL Server implements some of its behavior. These flags are normally used for debugging purposes, and I haven’t seen them in use on a production system

The command above checks the TestDB database but not its indexes. This won’t take long at all. The output returned will tell you if there are problems with the database. If so, check to make sure your backup is handy and then you can run the next level of this command:DBCC CHECKDB (’TestDB’, REPAIR_FAST)

This command takes longer, but will also correct the indexes (if it can). It will also not allow data loss. Should this command not correct your errors, you’ll definitely want to have that backup handy, because you’re going to need it. The next level of this command will potentially lose data. It looks like this:DBCC CHECKDB (’TestDB’, REPAIR_ALLOW_DATA_LOSS)As you can probably guess, this command could potentially lose data or make your applications unusable, depending on what data is lost (if any). I only use this command to repair the database on another server and then pull data selectively where I need it.

The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.

command rebuilds the indexes on a database. You can specify a particular index or all of them. This is the most popular and time consuming command you’ll normally run, and the one you’ll use most often for making your database access fast.

command defragments the index rather than rebuilding it. This command is normally used when time is an issue, such as in cases of very large databases. What’s normally done here is that this command is run during the week, and the DBCC DBREINDEX is run once a week.

This command "pins" a table into memory. Once the table is accessed, it stays in the buffer cache of memory and performance (for that table, anyway) is improved. Unless you’ve got a real driving need for this command, you probably shouldn’t use it. Its sister is DBCC UNPINTABLE which of course, releases the table from memory.

Turn trace flags off and on, which can control the way SQL Server implements some of its behavior. These flags are normally used for debugging purposes, and I haven’t seen them in use on a production system

This command takes longer, but will also correct the indexes (if it can). It will also not allow data loss. Should this command not correct your errors, you’ll definitely want to have that backup handy, because you’re going to need it. The next level of this command will potentially lose data. It looks like this:DBCC CHECKDB (’TestDB’, REPAIR_ALLOW_DATA_LOSS)

The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.

This command "pins" a table into memory. Once the table is accessed, it stays in the buffer cache of memory and performance (for that table, anyway) is improved. Unless you’ve got a real driving need for this command, you probably shouldn’t use it. Its sister is DBCC UNPINTABLE which of course, releases the table from memory.

The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.

The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.

The part that’s the most difficult to figure out is the fill factor. A fill factor is how much room to fill up the index before SQL allocates more space to the index. Here’s the idea: If you use a factor of 100, all the space in an index is filled. That packs the indexes nice and tight, making their space use very efficient. If new data has to be entered into the index, you pay a penalty for each update. If you specify a low fill factor, say 50 or so, you have a lot more room free and don’t pay as much of a penalty when the index is added to, but the indexes become larger and can also affect performance.

List of DMV in SQL Server 2005

1. sys.dm_broker_activated_tasks2. sys.dm_broker_connections3. sys.dm_broker_forwarded_messages4. sys.dm_broker_queue_monitors5. sys.dm_clr_appdomains6. sys.dm_clr_loaded_assemblies7. sys.dm_clr_properties8. sys.dm_clr_tasks9. sys.dm_db_file_space_usage10. sys.dm_db_index_usage_stats11. sys.dm_db_mirroring_connections12. sys.dm_db_missing_index_details13. sys.dm_db_missing_index_group_stats14. sys.dm_db_missing_index_groups15. sys.dm_db_partition_stats16. sys.dm_db_session_space_usage17. sys.dm_db_task_space_usage18. sys.dm_exec_background_job_queue19. sys.dm_exec_background_job_queue_stats20. sys.dm_exec_cached_plans21. sys.dm_exec_connections22. sys.dm_exec_query_memory_grants23. sys.dm_exec_query_optimizer_info24. sys.dm_exec_query_resource_semaphores25. sys.dm_exec_query_stats26. sys.dm_exec_query_transformation_stats27. sys.dm_exec_requests28. sys.dm_exec_sessions29. sys.dm_fts_active_catalogs30. sys.dm_fts_index_population31. sys.dm_fts_memory_buffers32. sys.dm_fts_memory_pools33. sys.dm_fts_population_ranges34. sys.dm_io_backup_tapes35. sys.dm_io_cluster_shared_drives36. sys.dm_io_pending_io_requests37. sys.dm_os_buffer_descriptors38. sys.dm_os_child_instances39. sys.dm_os_cluster_nodes40. sys.dm_os_hosts41. sys.dm_os_latch_stats42. sys.dm_os_loaded_modules43. sys.dm_os_memory_allocations44. sys.dm_os_memory_cache_clock_hands45. sys.dm_os_memory_cache_counters46. sys.dm_os_memory_cache_entries

47. sys.dm_os_memory_cache_hash_tables48. sys.dm_os_memory_clerks49. sys.dm_os_memory_objects50. sys.dm_os_memory_pools51. sys.dm_os_performance_counters52. sys.dm_os_ring_buffers53. sys.dm_os_schedulers54. sys.dm_os_stacks55. sys.dm_os_sublatches56. sys.dm_os_sys_info57. sys.dm_os_tasks58. sys.dm_os_threads59. sys.dm_os_virtual_address_dump60. sys.dm_os_wait_stats61. sys.dm_os_waiting_tasks62. sys.dm_os_worker_local_storage63. sys.dm_os_workers64. sys.dm_qn_subscriptions65. sys.dm_repl_articles66. sys.dm_repl_schemas67. sys.dm_repl_tranhash68. sys.dm_repl_traninfo69. sys.dm_tran_active_snapshot_database_transactions70. sys.dm_tran_active_transactions71. sys.dm_tran_current_snapshot72. sys.dm_tran_current_transaction73. sys.dm_tran_database_transactions74. sys.dm_tran_tran_locks75. sys.dm_tran_session_transactions76. sys.dm_tran_top_version_generators77. sys.dm_tran_transactions_snapshot78. sys.dm_tran_version_store

New DMV in SQL Server 2008

1. sys.dm_audit_actions2. sys.dm_audit_class_type_map3. sys.dm_cdc_errors4. sys.dm_cdc_log_scan_sessions5. sys.dm_cryptographic_provider_properties6. sys.dm_database_encryption_keys7. sys.dm_db_mirroring_auto_page_repair8. sys.dm_db_mirroring_past_actions9. sys.dm_db_persisted_sku_features10. sys.dm_db_script_level11. sys.dm_exec_procedure_stats12. sys.dm_exec_trigger_stats13. sys.dm_filestream_file_io_handles14. sys.dm_filestream_file_io_requests15. sys.dm_fts_fdhosts16. sys.dm_fts_outstanding_batches17. sys.dm_os_dispatcher_pools18. sys.dm_os_dispatchers19. sys.dm_os_memory_brokers20. sys.dm_os_memory_node_access_stats21. sys.dm_os_memory_nodes22. sys.dm_os_nodes23. sys.dm_os_process_memory24. sys.dm_os_spinlock_stacks25. sys.dm_os_sys_memory26. sys.dm_resource_governor_configuration27. sys.dm_resource_governor_resource_pools28. sys.dm_resource_governor_workload_groups29. sys.dm_server_audit_status30. sys.dm_tran_commit_table31. sys.dm_xe_map_values32. sys.dm_xe_object_columns33. sys.dm_xe_objects34. sys.dm_xe_packages35. sys.dm_xe_session_event_actions36. sys.dm_xe_session_events37. sys.dm_xe_session_object_columns38. sys.dm_xe_session_targets39. sys.dm_xe_sessions