System Base Tables

Comments: No Comments
Published on: January 30, 2012

On January 19th, I published a post about the Dedicated Administrator Connection.  I spoke very briefly of the system base tables in that article.  Today, I want to dive into these tables a little bit more.

First, let’s get the Microsoft definition for these tables.  “System base tables are the underlying tables that actually store the metadata for a specific database.”

Have you ever queried sys.objects from the master database and wondered about some of the results?  You can see all of the System base tables when querying the sys.objects view.  These tables are denoted in sys.objects by type of ‘S’ and a type_desc of ‘SYSTEM_TABLE’.

Here is a simple query to take a quick peek at these tables.

[codesyntax lang=”tsql”]


There is no need for a Dedicated Administrator connection in order for this query to work.  You can view these results with a non-DAC connection to the instance so long as you have adequate permissions to query sys.objects.  That said, not all objects returned by that query are System Base Tables.  Furthermore, it appears that the list from MSDN is not comprehensive.  One such example is the reference to sys.sysserrefs that does not appear to exist in SQL 2008 R2 and the missing System Base table called sys.sysbrickfiles (which is used by sysaltfiles as shown in this execution plan).

If I try to query the sysbrickfiles table (as an example) without connecting via DAC, I will get an error message like this:

This is normal behavior.  You cannot query the system base tables without first connecting via DAC.  Having said that, the obligatory warning is required.  As explained on MSDN, these tables are intended for use by Microsoft.  Proceed at your own risk and please make sure you have backups.

In addition to these System Base tables, you will find tables not mentioned in the article nor in the master database.  These System Base tables are found within the Resource database.  The resource database does contain most of the tables mentioned in that article, but there are some differences.  I will leave that discovery exercise to the reader.

There is plenty about SQL Server that many of us take for granted.  Under the hood, there is much more to learn.  Taking a peek at the System Base tables is one of those areas that will help you to learn more about SQL Server.  My question is this: How far are you willing to explore to learn more about SQL Server?

No Comments - Leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

January 2012
« Dec   Feb »


  • @SQLSoldier: @zlthomps You don't get a pass on current policies by installing an old version. 2/2 #sqlhelp
  • @SQLSoldier: @zlthomps You can no longer buy SQL Server 2008 licenses. If you put up a new server, then the current licensing rules apply. 1/2 #sqlhelp
  • @zlthomps: Can't find it documented anywhere that SA is required in MSSQL 08 for unlicensed passive replica in Azure VMs #sqlhelp
  • @Ammar_P: RT @Ammar_P: Is there a easy way to restore(attach) all DB after reinstalling SQL?Any steps dat i can perform right now till server is avai…
  • @mikekrausdpw: #sqlhelp @AMtwo @zlthomps Opened a ticket with Microsoft. Thanks for everyone help!
  • @AndreasWolter: @mikekrausdpw instead of that try a repair install with latest cu. Even xcopy from a clean Version/Backup would work. #SQLHelp
  • @AMtwo: @mikekrausdpw #sqlhelp I would never blindly run repair_allow_data_loss...If you do that, you want to know what data will be lost.
  • @AMtwo: @mikekrausdpw #sqlhelp If CHECKDB is reporting problems with the mssqlsystemresource db, you should probably call MS Support.
  • @mikekrausdpw: #sqlhelp the dbcc check is recommends runng the follg cmd DBCC CHECKDB (mssqlsystemresource)repair_allow_data_loss anyone every try this?
  • @zlthomps: #SQLServer 2008 Enterprise physical with #Azure VM Passive (logshipping), is SA required? I know it would be after SQL2012. #sqlhelp

Welcome , today is Wednesday, July 27, 2016