SQLServer数据库和应用元数据有何特点?
如何把驻留在物理服务器/SQL 实例上的数据库转变为它们相应的应用程序名称。在准备计划好的服务器停机通知时,这种需要就产生了。如果你不是数据库管理员或特定数据库的应用分析师,你通常会无视数据库的命名规则,而这些数据库支持着你每日依赖的应用程序。
这就是为什么当需要产生时在适当的位置上由元数据库来提供转化很重要。
考试大提示: 大部分数据库管理员拥有某种形式的数据库元数据库,他们依赖其来跟踪范围很广的Microsoft SQL Server环境。
利用连接的服务器和分布式数据库访问来建立一个已经在的环境中使用了七年的元数据库。它不是漂亮的,但它是功能性很强的。
跟很多IT开发者和数据库管理员一样,它很慢,不像它可以的那样最新型,也不像它应该的那样安全。
增加到数据库中的应用元数据包括创建两张表:dbo。Applications,专为存储所有程序的应用名称,而这些程序在环境中依赖于SQL Server数据库,还有dbo。
Database_Applications,它保存SQL 实例、数据库和应用程序之间的关系。
Applications Table
CREATE TABLE [dbo]。
[Applications]
(
[AppID] [int] IDENTITY(154,1) NOT NULL,
[ApplicationName] [varchar](100) NOT NULL,
)
Database_Applications Table
CREATE TABLE [dbo]。
[Database_Applications]
(
[DB_AppID] [int] IDENTITY(1,1) NOT NULL,
[ServerName] [varchar](50) NOT NULL,
[DatabaseName] [varchar](100) NOT NULL,
[ApplicationName] [varchar](100) NULL
)
你可能注意到,没有规范化dbo。
Database_Applications表。如果规范化,会只存储两个区域:一个与存储的应用元数据的表有关的外键,和一个元数据库相对应的外键。原因:没有处理大量的数据:有大概800个数据库,这些数据库在环境里发布80个实例。
虽然这对于一个数据库管理员来说是个很大的环境,但是它既不转变成在我的元数据表里的大量纪录,也不转变成数据库的巨大字节。
不是通过dbo。Applications表的主键,而是包含表中的应用程序名,可以通过只访问dbo。
Database_Applications表产生我的主要应用程序元数据报告(key Application Metadata report)。
环境中的SQL元数据库使用“焦土政策”人口处理方法,除了SQL Agent Job History和Backup History,其他的表都被每天删除和重新载入。
发现在
dbo。Database_Applications表中保存信息可以使我的生活变得很容易。
[展开]