SQL Server數據庫與其實際應用元數據介紹

以下的文章主要是介紹SQL Server數據庫與其實際應用元數據，我前兩天在相關網站看見SQL Server數據庫與其實際應用元數據的資料，覺得挺好，就拿出來供大家分享，希望會給大家帶來一些幫助在此方面。

以下的文章主要是介紹SQL Server數據庫與其實際應用元數據，我前兩天在相關網站看見SQL Server數據庫與其實際應用元數據的資料，覺得挺好，就拿出來供大家分享，希望會給大家帶來一些幫助在此方面。

我常被問到如何把駐留在物理服務器/SQL 實例上的SQL Server數據庫轉變為它們相應的應用程序名稱。在准備計劃好的服務器停機通知時，這種需要就產生了，但在我的組織內與IT經理或非技術人員溝通時，這也是有價值的。如果你不是數據

我常被問到如何把駐留在物理服務器/SQL 實例上的數據庫轉變為它們相應的應用程序名稱。在准備計劃好的服務器停機通知時，這種需要就產生了，但在我的組織內與IT經理或非技術人員溝通時，這也是有價值的。

如果你不是數據庫管理員或特定數據庫的應用分析師，你通常會無視數據庫的命名規則，而這些數據庫支持著你每日依賴的應用程序。這就是為什麼當需要產生時在適當的位置上由元數據庫來提供轉化很重要。

專家解答

大部分數據庫管理員擁有某種形式的數據庫元SQL Server數據庫，他們依賴其來跟蹤范圍很廣的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 實例、SQL Server數據庫和應用程序之間的關系。

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個數據庫，這些SQL Server數據庫在我的環境裡發布80個實例。雖然這對於一個數據庫管理員來說是個很大的環境，但是它既不轉變成在我的元數據表裡的大量紀錄，也不轉變成數據庫的巨大字節。

不是通過dbo.Applications表的主鍵，而是包含表中的應用程序名，我可以通過只訪問dbo.Database_Applications表產生我的主要應用程序元數據報告(key Application Metadata report)。

我的環境中的SQL元數據庫使用“焦土政策”人口處理方法，除了SQL Agent Job History和Backup History，其他的表都被每天刪除和重新載入。我發現在

dbo.Database_Applications表中保存信息可以使我的生活變得很容易。

每日從我的環境中載入數據後，我可以通過以下腳本得到在我的環境中產生的任何新的數據庫的良好的陳述。

SELECT D.[Server], D.DatabaseName FROM dbo.Databases D LEFT JOIN dbo.Database_Applications DA ON D.DatabaseName = DA.DatabaseName AND D.[Server] = DA.[ServerName] WHERE DA.DB_AppID IS NULL ORDER BY D.[Server], D.DatabaseName

這個查詢的結果提供任何數據庫的清單，這些SQL Server數據庫產生於上次我更新應用元數據和服務器時，它不僅是跨域的數據庫創建活動的通知，也是致力於更新兩個數據庫來符合應用程序信息的數據清單。這個查詢也適合SQL Server Reporting Services報告的數據表，而當我不在辦公室時，SQL Server Reporting Services報告也為我提供了一個新的數據庫到我的黑莓(BlackBerry)的日常通知。

最後，我創建了以下存儲程序，由此用任何新的數據庫信息來合並dbo.Applications表和dbo.Database_Applications 表。它接受三個參數：服務器，數據庫和應用程序。如果應用程序已經不存在於dbo.Applications表中，它就會被補充。然後一個記錄被插入到服務器/數據庫/應用程序關系中的dbo.Applications表。

CREATE PROCEDURE [dbo].[pAdd_Application]
@ServerName varchar(50),
@DatabaseName varchar(100),
@ApplicationName varchar(100)
AS --Add any new databases created,
but not recorded in the repository, to the repository
UPDATE dbo.Database_Applications
SET ApplicationName = @ApplicationName
WHERE ServerName = @ServerName
AND DatabaseName = @DatabaseName
AND ApplicationName IS NULL
--Determine if there is already an application
for this database in the repository, if not, then add it
IF (SELECT COUNT(*) FROM dbo.Applications
WHERE ApplicationName = @ApplicationName) = 0
BEGIN INSERT INTO dbo.Applications (ApplicationName)
VALUES (@ApplicationName)
PRINT 'Added new Application: '
+ @ApplicationName + ' to Applications table'
SELECT * FROM dbo.Applications
WHERE ApplicationName = @ApplicationName
END --List the new record in the repository
SELECT ServerName, DatabaseName, ApplicationName
FROM dbo.Database_Applications
WHERE ServerName = @ServerName
AND DatabaseName = @DatabaseName
AND ApplicationName = @ApplicationName

雖然我可以很容易地把這個存儲程序的執行整合為SQL Server集成服務(SSIS)程序包中的最後一步，而這個程序包能夠組裝我的存儲數據庫，但我選擇不這樣做，這是為了在我的環境裡，我能密切關注圍繞新的SQL Server數據庫創造而展開的活動