SQL Server 2005：向系统表说再见
类别: MSSQL教程 
微软的SQL Server 数据库管理员 ，快快想一下!在不使用任何的文档的情况下，编写一个查询，从SQL Server 2000系统表中抽取索引的列表，然后列举每个索引中的字段，并判断这个字段是否按照升序或者降序进行排序。你有两分钟的时间。快!
如果你现在真的停下阅读，开始用必不可少的两分钟时间思考这项不讨好的任务，那么现在你就陷入了一个大麻烦中，这里面涉及了系统索引、系统索引关键字，系统字段，以及一些元数据函数，其中包括类似OBJECT_NAME 和INDEXKEY_PROPERTY这样的备用信息。到现在为止，要编写这样的一个查询很明显要花费远远超过2分钟的时间了。
不幸的SQL Server 2000数据库管理员们，需要浏览深奥的系统表，这是这项使用数据库管理系统的工作中最糟糕的一部分。系统表，通常是有效率的，但是在我的印象里，它可从来不是为了用户友好设计的。
幸运的是，眼前就有了救星。在SQL Server 2005中，系统表不见了。是的。不见了。再也不需要对陌生的位进行操作，也不需要找出神秘的编码方案――这在过去都是必需的。对于你们中间需要对遗留下来的参考这些表的人来说，我知道你在想什么:无休止的机械的升级以保障与SQL Server 2005的兼容。但是还不要心生厌恶。系统中仍然存在类似系统表的对象，就是为了向下兼容的目的。但是表的自身是――或者是实际上应该是――被遗忘，像8-tracks 和 Tab一样被投入了历史的垃圾桶中。
那么这些表去了哪里呢?SQL Server 2005中的系统数据现在存储在隐藏的“资源”表中，这个表只能被服务器自身直接访问。低级用户(和数据库管理员)必须使用新的一系列的分类视图，这些视图显示了从各种我们看不到也不能调用的隐藏表和各种隐藏函数中获得的数据。以前版本的SQL Server 中的系统表现在作为一系列所谓的(也相当正确的)“兼容视图”的形式实现。
分类视图和它们的伙伴，动态管理视图(下面进行解释)，代表了一种处理元数据的方式，这些元数据是完全重新设计和重新思考出来的。没有了那些只会给数据库管理员一些底层数据的微小感觉的神秘的表，现在的SQL Server提供了丰富的资源:SQL Server 2005中有超过200个分类和管理视图，取代了以前版本中大约50个的系统表。
所有这些视图都可以在系统计划中找到。(计划是在SQL Server 2005中大大扩展了的安全特性。但是这是另一篇贴士的话题。)要看到可用视图的完全列表，SQL Server Management Studio扩展了所有数据库的系统视图树。或者通过T-SQL 从视图自身选择一个列表，并找出友好的易于理解的名字:
SELECT name
FROM sys.all_views
WHERE is_ms_shipped = 1
你还会发现再也不需要通过浏览文档来查找有关做某件关系系统数据的事情的线索。这些视图都有很明确的自我解释。
有关视图名字的一些线索如下:那些前缀是dm_的是动态管理视图，通过类似当前会话、锁，以及系统资源的信息表示服务器的正在改变的状态。其他的视图都可以认为是分类视图。那些前缀是all_的包含了有关系统对象(例如视图)和用户定义的对象的信息。那些没有all_前缀的只包含了用户定义的对象的信息。在那些包括了系统对象的视图中，is_ms_shipping字段可用于区分用户定义对象和系统对象。如果is_ms_shipped字段的值为1，则这一行代表了一个系统对象，否则，就是用户定义的对象。
最后，让我们检查一些你可以从分类视图中获得数据类型。对于初学者，所有常见的内容都可以获得。例如:查看索引中的数据，使用sys.indexes，而不是原先的sysindexes――奇怪的是，现在称之为sys.sysindexes。对于约束，试试sys.check_constraints, sys.default_constraints, 或者 sys.key_constraints。看出这个趋势了吗?
这篇贴士哪怕是没有简单的提到一句有关新的动态管理视图的话，都是不完整的。这些视图是SQL Server存储新的元数据的强有力的工具，它们可以帮助数据库管理员快速解决问题并分析服务器的性能。其中的一些明星选手，包括sys.dm_exec_query_stats，用来报告查询要求了多少个处理器时间;以及sys.dm_db_index_usage_stats，用来帮助数据库管理员决定哪一个索引是最有用的，哪些是没有用的。
对于这个巨大的元数据视图集合，还有更多的话需要说。但是现在，可以看看最近由微软发布在网上的beta版的SQL Server 2005在线书籍。系统视图主题提供了对这个强大的新的数据仓库的能力的整体描述。
另外，以下是那个2分钟问题的解决方案。首先使用SQL Server 2000系统表。其次，可以尽早地阅读有关SQL Server 2005 分类视图的译本。
如果你现在真的停下阅读，开始用必不可少的两分钟时间思考这项不讨好的任务，那么现在你就陷入了一个大麻烦中，这里面涉及了系统索引、系统索引关键字，系统字段，以及一些元数据函数，其中包括类似OBJECT_NAME 和INDEXKEY_PROPERTY这样的备用信息。到现在为止，要编写这样的一个查询很明显要花费远远超过2分钟的时间了。
不幸的SQL Server 2000数据库管理员们，需要浏览深奥的系统表，这是这项使用数据库管理系统的工作中最糟糕的一部分。系统表，通常是有效率的，但是在我的印象里，它可从来不是为了用户友好设计的。
幸运的是，眼前就有了救星。在SQL Server 2005中，系统表不见了。是的。不见了。再也不需要对陌生的位进行操作，也不需要找出神秘的编码方案――这在过去都是必需的。对于你们中间需要对遗留下来的参考这些表的人来说，我知道你在想什么:无休止的机械的升级以保障与SQL Server 2005的兼容。但是还不要心生厌恶。系统中仍然存在类似系统表的对象，就是为了向下兼容的目的。但是表的自身是――或者是实际上应该是――被遗忘，像8-tracks 和 Tab一样被投入了历史的垃圾桶中。
那么这些表去了哪里呢?SQL Server 2005中的系统数据现在存储在隐藏的“资源”表中，这个表只能被服务器自身直接访问。低级用户(和数据库管理员)必须使用新的一系列的分类视图，这些视图显示了从各种我们看不到也不能调用的隐藏表和各种隐藏函数中获得的数据。以前版本的SQL Server 中的系统表现在作为一系列所谓的(也相当正确的)“兼容视图”的形式实现。
分类视图和它们的伙伴，动态管理视图(下面进行解释)，代表了一种处理元数据的方式，这些元数据是完全重新设计和重新思考出来的。没有了那些只会给数据库管理员一些底层数据的微小感觉的神秘的表，现在的SQL Server提供了丰富的资源:SQL Server 2005中有超过200个分类和管理视图，取代了以前版本中大约50个的系统表。
所有这些视图都可以在系统计划中找到。(计划是在SQL Server 2005中大大扩展了的安全特性。但是这是另一篇贴士的话题。)要看到可用视图的完全列表，SQL Server Management Studio扩展了所有数据库的系统视图树。或者通过T-SQL 从视图自身选择一个列表，并找出友好的易于理解的名字:
SELECT name
FROM sys.all_views
WHERE is_ms_shipped = 1
你还会发现再也不需要通过浏览文档来查找有关做某件关系系统数据的事情的线索。这些视图都有很明确的自我解释。
有关视图名字的一些线索如下:那些前缀是dm_的是动态管理视图，通过类似当前会话、锁，以及系统资源的信息表示服务器的正在改变的状态。其他的视图都可以认为是分类视图。那些前缀是all_的包含了有关系统对象(例如视图)和用户定义的对象的信息。那些没有all_前缀的只包含了用户定义的对象的信息。在那些包括了系统对象的视图中，is_ms_shipping字段可用于区分用户定义对象和系统对象。如果is_ms_shipped字段的值为1，则这一行代表了一个系统对象，否则，就是用户定义的对象。
最后，让我们检查一些你可以从分类视图中获得数据类型。对于初学者，所有常见的内容都可以获得。例如:查看索引中的数据，使用sys.indexes，而不是原先的sysindexes――奇怪的是，现在称之为sys.sysindexes。对于约束，试试sys.check_constraints, sys.default_constraints, 或者 sys.key_constraints。看出这个趋势了吗?
这篇贴士哪怕是没有简单的提到一句有关新的动态管理视图的话，都是不完整的。这些视图是SQL Server存储新的元数据的强有力的工具，它们可以帮助数据库管理员快速解决问题并分析服务器的性能。其中的一些明星选手，包括sys.dm_exec_query_stats，用来报告查询要求了多少个处理器时间;以及sys.dm_db_index_usage_stats，用来帮助数据库管理员决定哪一个索引是最有用的，哪些是没有用的。
对于这个巨大的元数据视图集合，还有更多的话需要说。但是现在，可以看看最近由微软发布在网上的beta版的SQL Server 2005在线书籍。系统视图主题提供了对这个强大的新的数据仓库的能力的整体描述。
另外，以下是那个2分钟问题的解决方案。首先使用SQL Server 2000系统表。其次，可以尽早地阅读有关SQL Server 2005 分类视图的译本。
![\"\"](\"http://www.jiao-cheng.com/Files/BeyondPic/200601/2006-1/24/0612409495031615.JPG\")
