Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

25. April 2007 um 20:24

SQL-Server: neue Hotfix-Strategie

In dem Artikel "Microsoft SQL Server Release Services : SQL Server Hotfix Release Revised" auf dem Weblog des "Global Release Services Team" des SQL-Servers (was die alles für Blogs haben!) wird beschrieben, wie es zukünftig mit den Hotfixes weitergehen soll.

  • Bisher werden kritische Hotfixes generell für jeden ("public hotfix") zur Verfügung gestellt. Da es von dieser Sorte nicht so viele gibt, ist das sehr überschaubar.
  • Auf Fehlerbereinigungen von denen nicht jeder betroffen ist, wird bisher im Rahmen eines MSDN-Artikel hingewiesen. Er wird nur an die betroffenen Kunden geschickt ("private hotfix") Und wer ihn haben will, muss sich an den MS-Support wenden.

Das soll alles so bleiben. zusätzlich dazu soll es alle zwei Monate einen kummulativen Hotfix geben, der all die kleinen unschuldigen Hotfixes zusammenfasst. Der soll dann auch wieder jedem zugänglich sein ("public").

Da bin ich ja mal gespannt. Unter dem Strich sehe ich das sehr positiv. Da wir potentiell von jedem Bug betroffen sind, lassen wir uns die Hotfixes sowieso bisher immer freischalten. So hat man wenigstens den Service, dass man keinen verpassen kann. Den Zeitraum sehe ich als ausreichend an. So viele Hotfixes waren das bisher nicht…

25. April 2007 um 20:02

Mehr Hardware-Probleme

Laut TecChannel.de hat Ontrack wieder einen neuen Bericht zur Lage an der Datenrettungsfront mit den Zahlen aus 2006 verfasst. Leider kann ich ihn auf deren Homepage nicht finden. Daher muss ich mich mit den wenigen Happen begnügen, die im Artikel "Datenverlust: Hardware empfindlicher, User schlauer, Viren harmloser" erwähnt werden.

Nahezu 60 Prozent aller Fälle von Datenverlust gehen laut dem Datenretter mittlerweile auf hardwarebedingte Probleme zurück. Im Jahr 2002 lag dieser Wert noch bei 44 Prozent.
[…]
Der Prozentanteil von Schäden durch Computerviren ist von sieben auf zwei Prozent eingebrochen.

Wobei ich es interessanter finde, wie sich die absoluten Zahlen entwickelt haben. Die Prozentangaben alleine sind mir noch nicht aussagekräftig genug, um einen Trend aufzuzeigen. Die Freunde zählen defekte Bänder übrigens auch zu den Hardware-Problemen.

Dennoch spiegelt sich in den Werten meiner Ansicht nach wieder, dass die Betriebssysteme besser geworden sind, die Datenbanksoftware weniger Fehler enthält und die Treiber stabiler. Was man eindeutig ableiten kann: Gerade heutzutage sind Hardware-Ausfälle die häufigste Ursache für Datenverluste.

Und? Heute schon ein Backup gemacht?

24. April 2007 um 18:02

Datenspeicherungsarchitektur mit SQL Server 2005 Compact Edition

Heute fand ich einen recht guten Einführungsartikel zur "SQL Server 2005 Compact Edition" bei Microsoft: "Datenspeicherungsarchitektur mit SQL Server 2005 Compact Edition". Hier geht es allerdings weniger um Architekturen, sondern um Einsatzgebiete, also für welche Art von Software die Edition taugt.

Seine Stärken liegen darin, dass er deutsch erhältlich ist und sehr ausführlich auf die verschiedenen Einsatzaspekte eingeht. Dafür geht er nicht so in die Tiefe, was für die Zielgruppe "Einsteiger" auch angemessen ist.
In nur einer Sache stimme ich nicht mit dem Autoren Brian Noyes überein: Für Webanwendungen würde ich die Edition nicht nehmen. Auch nicht für "kleinere", wie er schreibt…

24. April 2007 um 17:56

SQL-Server: Wer sind heute meine 5 Langläufer?

Im Artikel Dynamic Management Views and Functions" auf databasejournal.com fand ich folgende sehr nützlich Abfrage zur Ermittlung der durchschnittlichen CPU-Zeit der 5 längsten Abfragen:

SELECT TOP 5 total_worker_time/execution_count 'Avg CPU Time',
SUBSTRING(st.text, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset
END – qs.statement_start_offset)/2) + 1)statement_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY total_worker_time/execution_count DESC;

Risiken und Nebenwirkungen: In den "Dynamic-Management-Views" sind nur die Infos seit dem letzten Start des Dienstes enthalten…

PS: Wer wissen will, was aktuell gerade läuft, findet die Antwort mit folgender Abfrage von Urs Gehrig:

SELECT sp.spid [SPID], sp.last_batch [Executed at], st.text [SQL]
FROM sys.sysprocesses sp
OUTER APPLY fn_get_sql(sp.sql_handle) st
WHERE st.text IS NOT NULL

23. April 2007 um 23:24

Welcher Index fehlt mir?

In dem sehr nützlichen Abschnitt "Finding Missing Indexes" in den Books-Online wird beschrieben, wie man auf einfache Weise herausbekommt, welche Indexe dem SQL-Server geholfen hätten, die letzten Abfragen noch performanter auszuführen.

Der SQL-Server-2005 notiert sich die Informationen über Indexe, die er nicht fand, natürlich inklusive der Anzahl der Benutzungen. Damit kann man auf einfache Art erste Würfe für neue Indexe bekommen.

Natürlich sind mehr Indexe nicht nur gut, beim Einfügen, Löschen und Ändern kosten sie schließlich wieder Zeit. Mit diesem Feature geht die Suche nach "guten" Indexen nur einfach leichter.

Hinweis: Die Informationen werden nur bis zum nächsten Stop des Dienstes gespeichert. Nach einem Neustart ist alles vergessen…

11. April 2007 um 23:59

SQL: Conditional Joins

Für alle, die schon mal gerne eine Abfrage schreiben wollten in der je nach Status in einem Datensatz mal mit der einen und mal mit der anderen Tabelle gejoint wurde, bietet der Artikel "Conditional Joins in SQL Server" von Jeff Smith einen sehr guten Ansatz.

Das Problem ist sehr gut herausgearbeitet und die Lösung einfach und effektiv.
Er empfiehlt die Tabellen mittels Outer-Join zu verknüpfen und die Bedingungen in die jeweiligen ON-Klauseln aufzunehmen.

Lesenswert für alle angehenden SQL-Freaks!

4. April 2007 um 18:43

SQL Server Wait Events

Bei SimpleTalk.com beschreibt Mario Broodbakker in dem Artikel "SQL Server Wait Events: Taking the Guesswork out of Performance Profiling" wie man am SQL-Server anhand der Warteschlangen Performancebremsen ausmachen kann. Der Artikel ist gut zu lesen. Allerdings stößt mir etwas säuerlich auf, dass nicht deutlich genug rauskommt, dass diese Idee Tom Davidson schon vor Jahren beschrieben und eingesetzt hat.

Ich finde den originalen Artikel "SQL Server 2005 Waits and Queues" von Davidson immer noch etwas besser. Am besten ist es vermutlich beide zu lesen, weil es doch eine Menge Holz auf einmal ist. Das Dokument "Troubleshooting Performance Problems in SQL Server 2005" wird hingegen erwähnt. Auch dort stehen wirklich nützliche Dinge drin, aber der in diesem Fall relevante Teil könnte gerne länger sein. Den Artikel würde ich für später empfehlen.

Wenn man den Post von Broodbakker und den Original-Artikel gelesen hat, dann findet man die weiteren Tipps von Tom Davidson zu dem Thema sicher auch nützlich: sie stehen im Artikel "Performance and Tuning Blue Prints".

4. April 2007 um 18:34

Backups überprüfen

In dem Artikel "Oh no – my backup is corrupt too! Help!" beschreibt Paul Randal, dass man nicht nur prüfen sollte, ob die Datenbank in Ordnung ist, sondern auch die Backups prüfen sollte. Eine sehr gute Idee, allerdings gab es dazu am SQL-Server-2000 keine elegante Möglichkeit später die Konsistenz des Backups zu prüfen. Man musste schon einen RESTORE in eine andere Datenbank machen und die dann testen… echt unpraktisch und langwierig!
🙁

Mit dem SQL-Server-2005 sieht es da schon anders aus. Hier gibt es die Möglichkeit die BACKUPs mit Checksummen zu versehen. Sie arbeiten intern genauso wie die Checksummen der Datenbank-Seiten. Dann kann man einfach mit dem RESTORE zu jedem beliebigen Zeitpunkt die Prüfung durchführen:

  • BACKUP … WITH CHECKSUM
  • RESTORE … WITH VERIFYONLY
3. April 2007 um 21:02

SQL-Server-Whitepapers

Kimberly Tripp hat sich die Mühe gemacht und stundenlang (laut eigener Aussage "5+ hours of work") alle verstreuten Whitepapers von Microsoft zum SQL-Server zusammengesucht. Das Ergebnis finde ich sehr nützlich.
Sowohl sein Weblog als auch die Liste liegen jetzt in meinen Favoriten…

Gugst Du hier: SQL Server 2005 Whitepapers

gefunden bei Paul Randal
3. April 2007 um 20:51

Datenbanken zerstören

Vor ein paar Wochen habe ich mal ein paar defekte Datenbanken für den SQL-Server-2005 erstellt. Die benötigen wir für den Test der Datenbanktests: Werden die defekte auch wirklich von unserer Software gefunden und können sie automatisch beseitigt werden? Ich dachte ja nicht, dass sich auch noch andere Leute für das Thema erwärmen können, aber Tony Rogerson beschreibt eine sehr kreative Methode in dem Blog-Beitrag "How to create a corrupt database using BULK INSERT/ UPDATE and BCP – SQL Server as a HEX editor". Ich selber war da deutlich direkter: mit dbcc page und einem Hex-Editor ging es auch…
😛

gefunden bei Paul Randal
1. April 2007 um 13:28

Online-Suche in den Books-Online

Auf Live.com wird jetzt eine Online-Suche in den Books-Online (BOL), den Handbüchern des Microsoft SQL-Servers, angeboten. Ich bevorzuge die Suche in den installierten BOLs, aber wenn man sie gerade nicht griffbereit hat, dann ist das eine gute Alternative: "SQL Server 2005 Books Online Scoped Search".

1. April 2007 um 13:25

SQL-Server: Daten aus CSV oder XLS lesen

In meinem gestrigen SQL-Kurs fragte mich ein Teilnehmer, wie man Daten aus einer CSV- oder XLS-Datei in den Microsoft SQL-Server laden kann.

Dazu gibt es ein ganzes Bündel an Möglichkeiten. Wenn man selber Administrator ist und für den eigenen Bedarf Daten importieren will, dann würde ich den Einsatz von OpenRowSet bevorzugen.

Das erkläre ich im folgenden im Rahmen einer Work-Bench: Man kann den kompletten Code in das Management-Studio laden und schrittweise ausführen. Dazu markiert man die Statements,
die zwischen zwei "go" stehen und drückt auf "Ausführen". Dadurch werden nur die markierten Befehle ausgeführt.

Die benötigten Dateien kann man auf einen Schwupps speichern.

Eigentlich wollte ich es so machen, dass man den ganzen Text einfach per Cut&Paste ins Management-Studio ziehen kann, aber WordPress wandelt die einfachen geraden Anführungszeichen immer in schräge um. Damit kommt SQL aber nicht zurecht. Daher werden die Dateien dennoch benötigt.

Vorarbeiten: OpenRowSet erlauben

Zuerst den Zugriff auf externe Quellen mittels OpenRowSet erlauben
Achtung: bitte nur für den internen Bedarf oder privat einsetzen.

exec sp_configure 'show advanced options', 1
reconfigure with override

exec sp_configure 'Ad Hoc Distributed Queries', 1
reconfigure with override

XLS lesen

Hier ein Beispiel-Zugriff auf ein Blatt in einer XLS-Datei. Die XLS-Datei ist auf dem Server unter "I:\Openrowset\testing.xls" gespeichert:

select * from OPENROWSET( 'Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=I:\Openrowset\testing.xls','SELECT * FROM [Tabelle1$]')

Hätte das Blatt einen anständigen Namen, dann würde man anstelle von "Tabelle1$" diesen Namen schreiben.

In XLS schreiben

Man kann auch in ein bereits existierendes Excel-Document schreiben:
insert into OPENROWSET( 'Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=I:\Openrowset\testing.xls','SELECT * FROM [Tabelle1$]')
(Nachname, Vorname, Geburtstag, Wohnort)
values ('Bond', 'James', '4.4.1930', 'London')

– Kontrolle, ob es geklappt hat:
select * from OPENROWSET( 'Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=I:\Openrowset\testing.xls','SELECT * FROM [Tabelle1$]')

Es ist mir nicht gelungen ein neues Dokument anzulegen.

Aus XLS löschen

Das Löschen geht leider nicht:

delete from OPENROWSET( 'Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=I:\Openrowset\testing.xls','SELECT * FROM [Tabelle1$]')
where nachname = 'Bond'

Es kommt ein Fehler, weil der Provider das Löschen nicht unterstützt:
OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "(null)" returned message "ISAM unterstützt das Löschen von Daten in einer verknüpften Tabelle nicht.".
Msg 7345, Level 16, State 1, Line 1
The OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "(null)" could not delete from table "SELECT * FROM [Tabelle1$]". There was a recoverable, provider-specific error, such as an RPC failure.

Zeilen aus XLS ändern

Das Ändern von Datensätzen geht hingegen:
Update OPENROWSET( 'Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=I:\Openrowset\testing.xls','SELECT * FROM [Tabelle1$]')
set nachname = 'Blond'
where nachname = 'Bond'

– Kontrolle, ob es geklappt hat:
select * from OPENROWSET( 'Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=I:\Openrowset\testing.xls','SELECT * FROM [Tabelle1$]')

CSV lesen

Das Lesen der CSV geht auch mit dem Jet-Treiber:

SELECT * FROM OPENROWSET( 'Microsoft.Jet.OLEDB.4.0',
'Text;Database=I:\Openrowset\','SELECT * FROM [testing.csv]')

Hier gibt man als "Database" nur das Verzeichnis an, die Datei folgt im Select.

Man kann auch über ODBC lesen:
SELECT *
FROM OPENROWSET('MSDASQL',
'Driver={Microsoft Text Driver (*.txt; *.csv)};DEFAULTDIR=I:\Openrowset\;Extensions=CSV;',
'SELECT * FROM [testing.csv]')

Wenn man "komplizierte" Formate über ODBC lesen will, dann muss man in der Datei "schema.ini" die Formate definieren.

Als Beispiel habe ich die Datei mit den Losungen 2007 aus http://www.brueder-unitaet.de/download/Losung_2007_CSV.zip verwendet.

SELECT *
FROM OPENROWSET('MSDASQL',
'Driver={Microsoft Text Driver (*.txt; *.csv)};
DEFAULTDIR=I:\Openrowset\;Extensions=CSV;',
'SELECT * FROM [Losungen Free 2007.csv]')
/* Schema.ini in "I:\Openrowset\":
[losungen free 2006.csv]
ColNameHeader=True
MaxScanRows=0
CharacterSet=ANSI
Format=Delimited(;)
*/

Nacharbeiten: OpenRowSet wieder abschalten

exec sp_configure 'Ad Hoc Distributed Queries', 0
reconfigure with override

exec sp_configure 'show advanced options', 0
reconfigure with override