/fdata%2F2470622%2Favatar-blog-1074652166-tmpphpjYbJuw.jpg){kind=avatar}
mssql
Migration MS SQL Server 2000 => 2005
Vor kurzem haben wir eine der MS SQL Server 2000 Instanz auf 2005 migriert. Wenn man vorher alles mit dem „Upgrade Advisor“ geprüft und die Probleme behoben hat, läuft es ganz easy (und je nach Datenmenge auch lange) ab.
Wir haben uns für die „In-Place“ Migration entschieden, da dann der Instanzname bleibt und keine weiteren Anpassungen nötig sind.
Also bei der Installation die vorhandene Instanz ausgewählt, installieren lassen, fertig … nach ja fast. Zum einen verbleiben die DBs in Kompatibilitätsmodus 80 = MS SQL Server 2000; wenn, dann wollen wir auch die neuen Features nutzen können, also muss das umgestellt werden (nur die „master“ wird automatisch umgestellt!).
Microsoft empfiehlt nach der Migration auf jeden Fall
- die Statistiken
- die Datenplatzverwendung
aktualisieren zu lassen. Ein CheckDB vorher & nachher schadet ebenfalls nicht.
Für das alles zusammen habe ich mir ein kleines Script erstellt, das man auf der jeweiligen DB ausführt:
-- Kompatibilitätsmodus auf 90 = SQL Server 2005 umsetzten DECLARE @DB sysname
SET @DB = (SELECT DB_NAME(DB_ID()))
EXEC dbo.sp_dbcmptlevel @dbname=@DB, @new_cmptlevel=90
-- Neue Option: Seitenüberwachung von "TORN_PAGE_DETECTION" -- auf "Checksum" ändern; verbessert die Fehlererkennung DECLARE @SQL nvarchar(500)
SET @SQL = N'ALTER DATABASE ' + @DB + ' SET PAGE_VERIFY CHECKSUM WITH NO_WAIT'
EXEC sp_executesql @stmt = @SQL
SET @SQL = N'ALTER DATABASE ' + @DB + ' SET PAGE_VERIFY CHECKSUM'
EXEC sp_executesql @stmt = @SQL
GO ---------------------------------------------------------------- -- Index- und Größenstatistiken aktualisieren EXEC master..sp_updatestats @resample ='RESAMPLE'
DBCC UPDATEUSAGE(0) WITH COUNT_ROWS
GO -- Zum Schluß die DB überprüfen lassen; läuft am längsten DBCC CheckDB(0) WITH ALL_ERRORMSGS
GO -- Abschließende Überprüfung: Alle DBs umgestellt? SELECT [name], compatibility_level, page_verify_option_desc
FROM sys.databases
ORDER BY [name]
Genauso wird dann voraussichtlich die Migration MS SQL Server 2005 => 2008 ablaufen.
Microsoft SQL Server 2008 Certification Paths
Microsoft hat zum MS SQL Server 2008 die Zertifizierungsmöglichkeiten zum MCTS und MCIP als PDF Datei veröffentlicht; der MCDBA fehlt aber.
Alles im allen ist es wie beim SQL Server 2005 geblieben:
Siehe auch
Executionplan mit Missing Index
Seit MS SQL Server 2005 gibt es die DMV sys.dm_db_missing_index_... , wo mitprotokolliert wird, „ja wenn ich den Index gehabt hätte, dann wäre ich soundso schneller gewesen“.
Lässt man im SSMS 2008 den „Tatsächlichen Ausführungsplan einschließen“, dann wird man nun dort ebenfalls ganz dezent drauf hingewiesen, das man einen Index zur Performance-Verbesserung anlegen könnte … ein Vorlage-Script wird sogar gleich mitgeliefert.
Gute Verbesserung, wie ich finde.
Workaround zur MS SQL Server Sicherheitslücke KB961040
Um schnell Hilfe zu bieten und die Sicherheitslücke (siehe Blog-Eintrag) zu Schließen hat Microsoft einen Workaround in KB961040 veröffentlicht:
MS SQL Server 2008 und BACKUP LOG with TRUNCATE_ONLY / NO_LOG
Sind die Datenbank mit Wiederherstellungsmodel = “Vollständig” konfiguriert, wächst die Transaktionsprotokoll Datei kontinuierlich an, bis zur nächsten LOG-Sicherung. Danach kann man das LOG mit SHRINKFILE verkleinern lassen.
Die "unsanftere" Methode dazu war bis zu MS SQL Server 2005 das „BACKUP LOG databasename WITH NO_LOG“, wobei NO_LOG ein Synonym zu TRUNCATE_ONLY ist.
Es bewirkte, dass zu dem Zeitpunkt das Transaktionsprotokoll abgeschnitten wird. Das hat wiederum zur Folge, dass an der Stelle auch die LOG Sicherungskette unterbrochen wurde. Im Falle des Falles hätte man nur die Sicherung bis vor dem Abschneiden verwenden können; genau so steht es in der Online Hilfe zum nachlesen.
Da genau das zu Verwirrungen & Problemen führte, gibt es die Option im MSSQL2008 nicht mehr. Wie man nun „unsanft“ das LOG abschneiden kann, steht ebenfalls in der BOL zum MS Sql Server 2008:
Wiederherstellungsmodel auf „Einfach“ stellen, LOG shrinken und gut.
MS weist auf Sicherheitslücke im SQL Server hin (KB961040)
Microsoft weist in einem Sicherheits-Bulletin vom 22.12.2008 auf eine Sicherheitslücke im SQL Server hin:
http://www.microsoft.com/technet/security/advisory/961040.mspx
Betroffen sind die Versionen 7.0, 2000 und 2005 bis einschl. SP2. In 2008 und 2005 mit SP3 sein das Problem nicht vorhanden.
Siehe auch Heise Newsticker
http://www.heise.de/newsticker/Kritische-Sicherheitsluecke-in-aelteren-SQL-Server-Versionen--/meldung/120865
Parameter für „Benutzerdefinierte Berichte“
Den Kontextmenü-Punkt „Berichte“ => „Benutzerdefinierte Berichte“ gab es im SSMS (Sql Server Management Studio) schon die ganze Zeit, die „Standardberichte“ für 2005 kamen erst mit dem Service Pack 2 hinzu. Buck Woody von Microsoft hat sich alle einmal genau angesehen und sie in seinem Blog beschrieben, siehe hier. Dann gibt es auch noch die Performance Dashboard-Report aus dem MS SQL Server 2005 Feature Pack als separater Download.
Wenn einem tabellarische Selektionen von bestimmten Informationen nicht reichen, sondern man sie noch entsprechend optisch aufbereiten möchte, kann man seine eigenen „Benutzerdefinierte Berichte“ erstellen.
Ist ganz einfach, man erstellt eben einen Bericht, legt den lokal (bzw. dort wo man mit der SSMS arbeitet) ab, dann im SSMS Rechte-Maus-Klick auf das gewünschte Objekt => Berichte => Benutzerdefinierte Berichte … und den Report auswählen. Das SSMS merkt sich dann für den Objekttyp den Bericht und listet ihn dann zukünftig gleich in den zuletzt verwendeten Reports auf.
Der Bericht wird dann mit der richtigen Connection aufgerufen, also wenn man einer Instanz über die Datenbank „Adventure Works“ den Bericht abruft, hat man eben Zugriff auf die DB. Welche DataSource man zur Entwurfszeit verwendet hatte, ist dabei egal.
Das funktioniert sogar mit MS SQL Server 2000 Instanzen / DBs, nur darf man dann nur Views verwenden, die es im 2000 gibt.
Zusätzlich gibt es noch folgende Parameter, die aus dem SSMS übergeben werden:
| Name | Datentyp | Standardwerte |
| DatabaseName | String | NULL |
| Filtered | Boolean | NULL |
| FontName | String | „Nicht abfragen“, Wert = Tahoma |
| ObjectName | String | NULL |
| ObjectTypeName | String | NULL |
| ServerName | String | NULL |
Für alle Parameter gilt:
Ausgeblendet = Nein
Intern = Nein
Mehrwertig = Nein
NULL-Werte zulassen = Ja
Leeren Wert zulassen = Ja
Verfügbare Werte = Nicht abfragen
Was ich noch nicht herausgefunden habe, ist wie man Einfluss auf den Berichtsnamen in SSMS nehmen kann oder wo die registrierten Berichte vermerkt werden, aber das findet sich noch.
Bei Gelegenheit werde ich den einen oder anderen Bericht von mir mal veröffentlichen.
„Tabelle öffnen“ und Daten bearbeiten
Eigentlich sind die Tools für den MS SQL Server nicht zur Datenerfassung oder Bearbeitung gedacht, aber wenn man nur mal schnell einen Datensatz ändern will, geht das schon noch.
Im Enterprise Manager konnte man sogar verknüpfte Tabellen bearbeiten, in dem man ein entsprechendes T-SQL Statement eingibt wie z.B.
SELECT *
FROM Northwind.dbo.Customers AS C
INNER JOIN Northwind.dbo.Orders AS O ON C.CustomerID = O.CustomerID
WHERE C.CustomerID = 'FURIB'
Nun konnte man sowohl die Orders Daten als auch die Customer bearbeiten. Änderte man in der ersten Zeile den CompanyName und ließ dann aktualisieren, stand der geänderte Wert in allen Datensätzen.
Soweit ich gehört habe, war das eher ein Bug als ein gewünschtes Feature. Entsprechend ist es im SSMS 2005 / 2008 nicht mehr möglich.
Was ebenfalls nicht mehr geht, ist folgendes:
Wenn man bequem ist und ein Tabelle mit sehr vielen Feldern hat, von dem man die Daten des z.B. letzten Feldes ändern wollte, konnte man eingeben
SELECT Fax, *
FROM Northwind.dbo.Customers
WHERE CustomerID = 'FURIB'
Das zweite auftretende Feld „Fax“ bekam dann automatisch das Alias „Expr1“. Das ist auch im SSMS so, nur: Sowohl das erste Feld „Fax“ also auch „Expr1“ sind nun disabled und können nicht bearbeitet werden.
„Entwurf“ bei vorhandenen Tabellen im SSMS 2008
Manche haben ja die leichte Unart, im Management Studio den Tabellenentwurf über den Designer statt über Scripte vorzunehmen (da fehlt dann irgendwie die Nachvollziehbarkeit).
Dann werden womöglich auch noch Felder mittendrin einfügt oder die Reihenfolge ändert (den Sinn der Aktion fragt man besser nicht nach).
Im Enterprise Manager und SSMS 2005 konnte man das auch ungehindert machen. Im Änderungsscript sieht man dann, das eine tmp_Tabelle als Kopie angelegt wird, Indizes erstellt werden, Daten umkopiert, die Originaltabelle gedroppt und die tmp_xxx auf den alten Namen umbenannt wird; ein Haufen Werks für eine sinnfreie Aktion.
Versucht mal das in einem frischen SSMS 2008, bekommt man die Warnung:
Das Speichern von Änderungen ist nicht zulässig. Die vorgenommenen Änderungen erfordern das das Löschen und Neuerstellen der folgenden Tabellen. Sie haben entweder Änderungen an einer Tabelle vorgenommen, die nicht neu erstellt werden kann, oder die Option 'Speichern von Änderungen verhindern, die die Neuerstellung der Tabelle erfordern' aktiviert"
Und genau diese Option ist im Standard aktiviert; sinnvoller weise wie ich finde.
Wer es weiterhin & trotzdem machen will, muss die Option abschalten.
Internals Viewer for SQL Server
Wer vermisst die Tetris-mäßigen bunten Blöcke aus Defrag von Win95/98/Me?
Wer wollte schon immer mal eine bunte Karten seiner Datenbankdatei haben, um zu sehen, wo die Daten liegen?
Bei CodePlex wurde die Version 2.0 des „Internals Viewer for SQL Server“ veröffentlicht.
http://www.codeplex.com/InternalsViewer
Es integriert sich als AddIn in das SQL Server Management Studio, ein Stand-Alone Produkt gibt es unter
http://www.sqlinternalsviewer.com/
Es zeigt u.a. mit „Map Allocation“ auf, welche Tabelle Daten wo in der Datenbank-Datei gespeichert hat.
Ganz hübsch soweit und ich werde es mir auch noch näher ansehen, nur ob man es unbedingt braucht?
