Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

1. August 2007 um 21:43

Video zum Vorgehen bei defekten Datenbanken

Wer mal Mr. Paul Randal auf Video erleben will, der kann seinen extrem kurzweiligen Vortrag "Secrets of Fast Detection and Recovery from Database Corruptions" ansehen. Es lohnt sich, es ist geradezu ein MUSS für jeden DBA! Über eine Stunde voll mit wichtigen Tipps handlich verpackt.

Aber es gibt ein paar Schattenseiten:

  • Er redet sehr schnell, aber deutlich.
  • Man muss sich allerdings bei MS anmelden. Der alte Passport-Account tat's bei mir…
  • Ich musste es mit dem IE ansehen, Firefox klappte nicht.

Mir war übrigens nicht klar, dass Page-Checksums nicht für die TempDB berechnet werden.

31. Juli 2007 um 18:20

SQL-Server-2005: neue Windows-Gruppe

Heute fragte mich ein Kollege, was es denn mit der Gruppe "SQLServer2005MSSQLUser$$" auf sich hat. Ich war ganz schön von den Socken, denn mir war bislang noch gar nicht aufgefallen, dass der SQL-Server bei der Installation eine Gruppe anlegt.

Wenn man den SQL-Server im Benutzerkontext starten will, dann muss man den Benutzer einfach nur zum Mitglied der Gruppe machen und er hat automatisch alle Rechte die erbraucht.

Im beiliegenden Artikel steht auch eine Liste der Rechte: "Setting Up Windows Service Accounts"

23. Juli 2007 um 17:00

Decrypt SQL Server Objects

Omri Bahat beschreibt im Artikel "Decrypt SQL Server Objects" (im "SQL Server Magazine", Ausgabe August 2007) wie man mit vergleichsweise wenig Aufwand den Quellcode den ENCRYPT angelegten Quellcode von Prozeduren/Funktionen/Views sichtbar machen kann. Er verwendet dazu zwei Tricks: erstens eine "Dedicated Admin Connection" (DAC, einfach beim Connect vor den Servernamen "ADMIN:" schreiben) und zweitens benutzt er ALTER, um das Objekt zu verändern, um den XOR-Schlüssel herauszubekommen (natürlich in einer Transaktion, um das Original nicht zu zerstören.

Den Artikel kann man nur als angemeldeter Leser des Magazins sehen, aber die Quelltexte der Beispiele sind freundlicherweise frei zugänglich.

Damit kann man den verschlüsselten Quelltext aus der Spalte "imageval" der Tabelle "sys.sysobjvalues" (am 2005er, siehe Datei WebListing_01.txt) lesen und dann mittels ALTER-Statement den Hex-Wert (für das XOR) ermitteln (siehe Datei Listing_03.txt). Mit den ermittelten Infos kann man den Quellcode dann entschlüsseln (siehe Listing_04.txt). Das geht auch am SQL-Server-2000, nur stehen die Infos da woanders, aber das steht auch alles in seinen Beispieldateien.

Insgesamt ist der Artikel mal erfrischend anders als die sonst eher belehrenden Artikel des Magazins. Ich weiß noch nicht, ob ich das mal benötigen werde, aber immer hin ist es gut zu wissen, dass man die Encryption des Quelltextes so leicht "knacken" kann. Langfristig wollen wir den Quelltext unserer Objekte nämlich encrypted anlegen…

Disclaimer: Hier ging es jetzt um die Datenverschlüsselung. Die ist nach wie vor richtig schön sicher…

20. Juli 2007 um 20:16

Virtuelle Instanzen des SQL-Servers

Weil wir gerade über den Einsatz von Windows-Vista in Virtuellen Maschinen plaudern (für einige Vista-Editionen ist eine Lizenz zur Installation in einer VM enthalten, für andere Editionen möchte Micosorft den Einsatz iin einer VM gleich verbieten), fiel mir ein, dass sich an dieser Stelle mit SP2 auch für den SQL-Server-2005 etwas geändert hat.

Im damaligen MSDN-Newsletter schrieb Microsoft:

Steht ab sofort zur Verfügung: Service Pack 2 für SQL Server 2005
[…] Darüber hinaus hat Microsoft die Nutzungsrechte erweitert: So können Unternehmen unbegrenzt virtuelle Instanzen auf Servern einsetzen, die vollständig für SQL Server 2005 Enterprise Edition lizenziert sind.

Das bezieht sich auch wieder nur auf eine bestimmte Edition: die Teuerste…

17. Juli 2007 um 20:55

SQL DMVStats

Tom Davidson (Wait & Queues) hat zusammen mit Sanjay Mishra den nächsten großen Coup gelandet. Die beiden sind im "customer advisory team" und haben oft mit Performance-Analysen zu tun. Mit dem neuen Werkzeug "DMVStats" werden die wertvollen Laufzeitinformationen aus den "Dynamic Management Views" (DVM) in Form einer Datenbank gesammelt.

Diese Datenbank kann dann gezielt nach Auffälligkeiten durchsucht werden. Das ist definitiv interessant für alle, die gerne ein Auge auf die Performance haben. Die wesentlichen Informationen bekommt man gleich als Bericht aufbereitet.

Weitere Infos und den Download findet man unter "SQL DMVStats – SQL Server 2005 Dynamic Management View Performance Data Warehouse".

17. Juli 2007 um 20:29

Alles über mssqlsystemresource herausfinden

Sinn und Zweck

Die MsSqlSystemResource-Datenbank ist eigentlich eine alte Idee. Auch Sybase führte schon vor etlichen Jahren eine System-Datenbank ein, die den Quellcode aller System-Proceduren (bei MS sind es auch die System-Views) enthält, dort hieß sie "SybSystemProcs". Damit wird der Code von den Daten in der Master-Datenbank getrennt. Das ist beim Patchen oder bei Installation eines Servicepacks nützlich. Jetzt kann Microsoft einfach hergehen und bei jedem Update einfach die komplette Datenbank austauschen. Umgekehrt kann man leichter auf einen vorherigen Versionsstand zurücksetzen. Hotfixes sind damit "deinstallierbar"…
Dazu muss der Dienst gestoppt werden, sie kopieren einfach nur die neuen Dateien hin.

Das wurde nötig, weil bei diesen Updates immer wieder Abbrüche beim Einspielen der neuen Skripten in die Master-Datenbank auftraten. Außerdem dauert das Einspielen der Skripte wesentlich länger als einfach die Dateien auszutauschen. Dadurch wurde der Update robuster und schneller. Leider benötigt der Hotfix damit deutlich mehr Platz…

Die inneren Werte

Neben den spärlichen Informationen in den Books-Online zum SQL-Server-2005 zur "Ressourcendatenbank", gibt es eine weitere Möglichkeit, wie man sich selber an die Erforschung machen kann.

Die Dateien der Mssqlsystemresource-Datenbank liegen unter "'C:\Programme\Microsoft SQL Server\MSSQL.n\MSSQL\Data\mssqlsystemresource.mdf/ldf'", wobei das "n" von der Installation abhängt. Die erste Instanz des SQL-Servers legt sich nach 1, die nächste nach 2 usw. Dabei zählen allerdings nicht nur SQL-Server, sondern auch die Analysis-Services usw. Wenn man die Dateien hat, dann ist eigentlich schon alles geritzt.

Die Idee ist nicht wirklich umwerfend und auch leider schon im Blog von Mladen Prajdic beschrieben: Man muss einfach nur die MDF/LDF unter anderem Namen anhängen und schon sieht man alles…

Vorgehen:

Dienst stoppen, Dateien kopieren, z.B. in mssqlsystemresource_.mdf/ldf im gleichen Verzeichnis, Dienst starten.

Jetzt kann man die DB einfach anhängen und sich selber zum Besitzer machen. (Da ich mich generell mit SA anmelde wird er im Beispiel verwendet, obwohl das in dem Fall unnötig ist.)

exec sp_attach_db 'mssqlsystemresource2'
, 'C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Data\mssqlsystemresource_.mdf'
, 'C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Data\mssqlsystemresource_.ldf'

EXEC mssqlsystemresource2..sp_changedbowner @loginame = N'sa'

Freundlicherweise wurden die Views und Procedures nicht mit "ENCRYPTION" angelegt. Daher kann man nun alle Definitionen in aller Ruhe ansehen und sogar verändern. Ganz wie früher in der guten alten Zeit… 😉

select
name as object_name,
type as object_type,
object_definition(object_id) as object_definition
from sys.system_objects

Und die echten Tabellen?

Wenn man die Views und Procedures aufmerksam studiert, dann sieht man, dass immer wieder seltsame Tabellennamen auftauchen, z.B. sys.objects$. Das sind die echten Systemtabellen an die man als Normalsterblicher nicht mehr herankommt…

16. Juli 2007 um 20:24

SQL-Server-2005: Datenbank mssqlsystemresource

Über einen Artikel zu Thema Wiederherstellung der Systemdatenbanken stieß ich auf den Hinweis von Microsoft, dass man mit einem Trick die versteckte/geheime Mssqlsystemresource-Datenbank bearbeiten kann.

Dazu muss man den Dienst in der Minimalkonfiguration starten, z.B.:

net start "SQL Server (MyYukonBox)" /f

Dann sind plötzlich ganz spannende Dinge möglich. Man kann aber nicht nur den Modus der Datenbank ändern:

ALTER DATABASE mssqlsystemresource SET READ_ONLY; -- READ_WRITE;

oder Meta-Informationen abfragen:

select db_id('mssqlsystemresource'), db_name(32767)
–> 32767 mssqlsystemresource

Man kann sogar "in die Datenabnk" rein und dort die Systemtabellen abfragen:

use mssqlsystemresource
select name, type from sys.objects

OK, es geht nicht alles, aber das Fehlende kann man mit etwas Mühe und DBCC PAGE rausfinden, z.B.:

dbcc traceon (3604)
DBCC page (32767, 1, 1, 1)

Der Anfang ist gemacht… und morgen kommt mehr.

8. Juli 2007 um 11:15

SQL-Server-2005: komischer Hotfix

Damit ich morgen daran denke dem mal nachzugehen:

Microsoft hat vorgestern Infos über einen Hotfix zum SQL-Server-2005 bereit gestellt. Von der Beschreibung her sollten sehr viele davon betroffen sein. Wir hatten das Problem aber bislang nicht. Ich hoffe mal, dass keine unserer Abteilungen die Option ausgeschaltet hat:

When you update a table that contains a nonclustered index in a Microsoft SQL Server 2005 database, the database is marked as suspect. […]
This problem occurs if the allow_page_locks option for the database is disabled.

Behoben wird das Problem im "cumulative update package 2 for SQL Server 2005 Service Pack 2 (build 3175)", daher auch das Datum vom April. Aber warum kommt die Info erst jetzt? Das finde ich komisch.

Infos von Microsoft:
"FIX: A database is marked as suspect when you update a table that contains a nonclustered index in SQL Server 2005"

7. Juli 2007 um 08:37

SQL-Server: Ausführungspläne speichern

Das man Ausführungspläne speichern kann, ist ein nettes Feature, dass ich neulich erst für mich entdeckte. Dazu muss man im SQL-Server-Management-Studio lediglich auf den angezeigten Zugriffsplan mit der rechten Maustaste das Kontextmenü aufrufen und dort auf "Speichern …" klicken.

Die abgespeicherte "*.sqlplan"-Datei ist ein normale XML-Datei, die mehr Infos enthält als an der Oberfläche angezeigt werden. Jetzt kann man die Datei einem Kollegen schicken oder für spätere Vergleiche aufheben. Um sie wieder im SQL-Server-Management-Studio anzusehen, muss man sie einfach nur öffnen.

6. Juli 2007 um 16:04

Hindernisse bei der Einführung des SQL-Servers-2005

Die letzte Umfrage des SQL-Server-Magazine beschäftigte sich mit der Frage was das größte Hindernis bei der Umstellung auf den SQL-Server-2005 war. Mich hat etwas befremdet, dass unser größtes Hindernis noch nicht mal zur Auswahl stand: die Inkompatibilitäten!

Hier geht es zu dem Artikel: Previous Poll Results
(man wird blöderweise auf die Übersichtsseite umgeleitet und muss das auf "What’s the biggest challenge you're facing as you move to SQL Server 2005?" klicken.)

25. Juni 2007 um 20:54

SQL-Server-2005: immer mit Named-Pipes

Mein Kollegen Vladimir entdeckte, dass man den SQL-Server-2005 nicht mehr so konfigurieren kann, dass er nur über Shared-Memory erreichbar ist.
Seit SQL-Slammer konfigurieren wir die an Arbeitspläzen installierten MSDEs so, dass sie nicht über das Netz erreichbar sind. Das wird auch von immer empfohlen, wenn man irgendwelche Sicherheitstipps liest.
Ist ja logisch, damit bietet der SQL-Server erheblich weniger Angriffsfläche.

Mit dem SQL-Server-2000 entfernt man einfach alle Protokolle "Server Network Utility" für die jeweilige Instanz. Dann kann man immer noch mittels Shared-Memory auf den lokalen SQL-Server zugreifen.

Der SQL-Server-2005 unterstützt das Shared-Memory-Protokoll aber nicht mehr. Im "SQL Server Configuration Manager" sieht man zwar noch das Protokoll "Shared Memory", aber das stimmt nicht. Das kann man auch ganz gut im Process-Explorer sehen, wenn man sich die beiden Prozesse ansieht. Es ist mit einem kleinen Tests aber auch leicht nachvollziehbar.
Dazu muss man einfach in dem Tool am SQL-Server-2005 alle Protokolle deaktivieren und nur Shared Memory übrig lassen. Danach muss man den Dienst neu starten.

Dann sieht man schon im Errorlog des SQL-Servers:
Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\SQLEXPRESS ].
Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$SQLEXPRESS\sql\query ].

Wenn man sich nun explizit über Shared-Memory (LPC) zum SQL-Server verbindet, dann klappt der Zugriff:

>SQLCMD -S lpc:.\MyExpress -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Shared memory

(1 Zeilen betroffen)
1> exit

Der Zugriff verwendet aber nicht Shared-Memory, sondern eine spezielle Named-Pipe (obwohl Named-Pipes deaktiviert wurde):

>SQLCMD -S np:\\.\pipe\SQLLocal\MyExpress -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Shared memory

(1 Zeilen betroffen)
1> exit

Weil die alten Client, die bspw. ODBC nutzen, das "neue" Shared-Memory nicht kennen, werden sie auf etwas umgelenkt, dass sie kennen: die "bisherigen" Named-Pipes. Deswegen ist jetzt jeder SQL-Server immer auch über die Standard-Pipe erreichbar, selbst wenn das Protokoll Named-Pipes deaktiviert ist:

>SQLCMD -S np:\\.\pipe\MSSQL$MyExpress\sql\query -E
1> SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID
2> go
net_transport
—————————————-
Named pipe

(1 Zeilen betroffen)
1> exit

Man kann jetzt darüber streiten, ob das ein Sicherheitsproblem ist, aber es ist kein Bug, sondern ein beabsichtigtes Feature um abwärtskompatibel zu sein. Es ist auch kein Geheimnis, ich fand mehrere Artikel im Internet, die das bestätigen, wenn auch das Problem nicht als solches beschreiben (erkennen?), z.B. bei SQL-Protocols.

Der Zugriff über eine Remote-Pipe funktioniert hingegen nicht:

>SQLCMD -S np:\\MyPC\pipe\MSSQL$MyExpress\sql\query -E
HResult 0xE9, Level 16, State 1
Named Pipes Provider: Kein Prozess ist am anderen Ende der Pipe.

Sqlcmd: Error: Microsoft SQL Native Client : Communication link failure.
Sqlcmd: Error: Microsoft SQL Native Client : An error has occurred while
establishing a connection to the server. When connecting to SQL Server
2005, this failure may be caused by the fact that under the default settings
SQL Server does not allow remote connections..

Das geht nur, wenn man auch Named-Pipes erlaubt.

16. Juni 2007 um 13:31

SQL-Server-2005: Logon-Trigger

Wie ich heute festgestellt habe, wurde mit SP2 zum SQL-Server-2005 Logon-Trigger eingeführt. Sie werden gefeuert bevor die Benutzersitzung erstellt wird. Hier kann man dann Dinge protokollieren. Man kann die Anmeldung aber auch unter fachlichen Gesichtspunkten untersuchen und ggf. ablehnen… 😛

Damit sind solche handgestrickten Lösungen, die auf dem ungeliebten Polling aufbauen, unnötig geworden.

Eigentlich wollte ich eine kleine Beschreibung dazu verfassen, aber weil das schon so schön im " SQL Server FAQ Blog", den ich übrigens auch erst heute entdeckte, beschrieben ist, kann ich einfach darauf verweisen… 😉

Gugst Du hier: "Trigger für Anmelde (Logon) Ereignisse"

Hinweis, falls einer meiner Kollegen auf den "running Gag" kommt: Man kann damit nicht generelle Verbindungsoptionen setzen.