SQL Server元数据的管理与应用

2009-05-12 21:04:46来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

大部分数据库管理员拥有某种形式的数据库元数据库,他们依赖其来跟踪范围很广的Microsoft SQL Server环境。我利用连接的服务器和分布式数据库访问来建立一个已经在我的环境中使用了七年的元数据库。它不是漂亮的,但它是功能性很强的。跟很多IT开发者和数据库管理员一样,即使它有自身的不足我还是为自己的创造感到骄傲。它很慢,不像它可以的那样最新型,也不像它应该的那样安全。

自从读了2007年5月和6月Rodney Landrum在SQL Server杂志上发表的关于SQL Server集成服务(SSIS)和数据库管理员知识库(DBA Repositories)的文章,我知道是时候采取别人的解决方法了。这对于我的环境来说是完美的,而一些改动也是容易采纳的。2008年2月,一篇后续文章在SQL Server杂志上发表,在这篇文章里,Rodney更新了他的解决方法。我下载了代码,在我的测试环境里审核,并迅速把它纳入产品中。当大家普遍地为这个解决方法所提供的而感到高兴时,在它包中缺少的一方面是把数据库关联到应用程序的能力。通过在他的解决方法中增加两张额外的表,我可以在我的“土生土长”元数据库中增加应用程序元数据到我现在使用的SQL Server杂志的方法中。

增加到我数据库中的应用元数据包括创建两张表: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表中保存信息可以使我的生活变得很容易。每日从我的环境中载入数据后,我可以通过以下脚本得到在我的环境中产生的任何新的数据库的良好的陈述。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:SQL Server数据库优化经验总结

下一篇:最新的关键SQL Server漏洞已被微软证实