Sind Sie Datenbank-Administrator oder Software-Entwickler? Interessiert Sie SQL-Server Technik? Wenn ja, dann kennen Sie wahrscheinlich Anforderungen wie diese:
Hatten Sie schon einmal das Problem zwei Datenbanken vergleichen zu müssen? Oder eine Datenbank zu erweitern? Und das Ganze möglichst automatisiert? Ich habe diese Anforderung ... sehr oft. Es gibt eine Applikation, einmal HOT (Echtdaten) und einmal COLD (Demodaten) - die Benutzer verwenden HOT zum Arbeiten und COLD zum Testen.
Es beginnt dann besonders interessant zu werden, wenn in der Demodatenbank neue Funktionen und Erweiterungen eingebaut werden. Diese werden getestet, Anwender geben Daten ein - und wollen dann auf einmal, dass die eingegebenen Daten in das Echtsystem übernommen werden.
Leider war der Split der Datenbank-Version schon vor einem Monat und die Scripts zum Erweitern der HOT-Datenbank haben ihren Weg zum Administrator nicht gefunden. Und der steht nun da und weiß nicht, welche Schema-Änderungen durchzuführen sind, damit beide Systeme die gleichen Struktur haben, damit dann die Daten übernommen werden können.
Klingt zu übertrieben? Glauben Sie mir, so etwas (und ähnliche Anforderungen) passiert in der Praxis öfters - vor allem bei rasch wachsenden Systemen. Da wäre es natürlich gut, sich helfen zu können.
Zunächst einmal gibt es im SQL Management Studio im Kontextmenü immer den SCRIPT-Befehl:
Diese Funktion schreibt dann beispielsweise ein ALTER des Objekts in ein File zum Ausführen auf dem Zielsystem. Das ist sehr brauchbar aber eben manuell. Wie kann Scripten und Vergleichen automatisiert werden?
Hier hilft T-SQL weiter. Im SQL Server 2005 wurden die (kryptischen) Abfrage-Mechanismen des Vorgängers SQL Server 2000 durch neue Views im Schema sys ersetzt. Damit ist es nun bequem möglich, Datenbank-Objekte abzufragen.
Hier nun ein paar praktische Beispiele:
-- Anzeige aller Objekte
select * from sys.sysobjects order by xtype, name
Liefert alle Objekte aus dem Systemkatalog. xtype gibt dabei an, um welchen Objekt-Typ es sich handelt (siehe unten).
-- Anzeige aller Tables in einer DB:
sp_tables
-- Anzeige aller Views (0..Default Microsoft Views, 1..eigene Views):
SELECT * FROM sys.all_views WHERE is_ms_shipped = 1
-- Detaillierte Anzeige aller Spalten-Informationen einer Tabelle:
SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'produkte'
-- SQL einer Stored Procedure anzeigen:
sp_helptext 'spMeinProgramm'
Durch ein JOIN mit Syscomments können auch die dahinterliegenden SQLs angezeigt werden! Somit funktioniert die Anzeige beispielsweise aller Views und der verwendeten SQL-Befehle so:
select o.id, o.name, c.text from sysobjects o join syscomments c on o.id=c.id where xtype='V' order by id, colid
/* -- xtype Werte:
C = CHECK constraint
D = Default or DEFAULT constraint
F = FOREIGN KEY constraint
L = Log
FN = Scalar function
IF = Inlined table-function
P = Stored procedure
PK = PRIMARY KEY constraint (type is K)
RF = Replication filter stored procedure
S = System table
TF = Table function
TR = Trigger
U = User table
UQ = UNIQUE constraint (type is K)
V = View
X = Extended stored procedure
*/
Mit diesen Werkzeugen können zum Beispiel alle Schemas oder SQLs (von Views, SPs od. Funcs) in eine Tabelle geschrieben werden. Diese könnte dann in einer Stored Procedure mit einer ebenso erzeugten Tabelle in einer anderen Datenbank vergleichen werden und die Unterschiede auswerfen. Oder die Tabelle als Textdatei exportiert werden und dann die beiden Files (z.B. mit Windows-Bordmitteln: fc.exe oder mit WinDiff - ja, das gibt es noch immer) verglichen werden.
Die Vorgangsweise hängt natürlich vom erwünschten Ziel ab: Eine Automatisierung als Stored Procedure um alle unterschiedlichen Views, Stored Procedures und Functions auszuwerfen, oder per SSI, oder.... Also recht individuell. ;-)
Der Knackpunkt für mich war, herauszufinden, wie man zu den SQL-Befehlen in den gespeicherten SQL-Objekten gelangt. Und das liefert eben das JOIN mit Syscomments zur weiteren Verarbeitung oder zum Parsen für komplexere Anwendungen (Ja, ich weiß: Die Schemata's können natürlich auch mit ADO.NET ausgelesen und verarbeitet werden - für einfache Anforderungen ist T-SQL jedoch gut geeignet).
Achja, noch ein SQL zur Performance-Messung: Dynamic Management Views (DMV) liefern Informationen über den aktuellen Auslastungszustand des SQL Servers. Zum Beispiel ein Snapshot der aktuellen Aktivität eines SQL Servers:
SELECT object_name, counter_name, instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name IN ('Buffer cache hit ratio',
'User Connections', 'Transactions' , 'Average Wait Time (ms)', 'Transactions/sec',
'Errors/sec', 'Target Server Memory (KB)', 'Total Server Memory (KB)' )
ORDER BY object_name, counter_name
Diesen Output wieder periodisch in eine Tabelle schreiben, somit Daten über längere Zeiträume sammeln und mit Reporting Services auswerten. Und so weiter...
SQL Server ist eine große Spielwiese ein DBMS mit vielfältigen Möglichkeiten!
Beitrag von Toni Pohl
Categories: Developer, Microsoft, Tools
Source: https://blog.atwork.at/post/Brauchbares-SQL-fuuml3br-HOT-und-COLD