dbHero – stop waiting for SQL Server

Well finally, those guys from the code Hero team came up with a tool, which puts an end to those nerv wracking procedures when it comes to taking a snapshot from a database and put it back in.

Imagine, you’re a tester or business analyst or project manager or developer or …. whatever ;)

Today, your task is it, to do some test on a large 3-tier web based system. Some of those tables in the database have millions of records in them. The whole application is quite complex, and well, you start testing the new functionality, the guys from the dev team just added.

Well, you do your tests, find some bugs (surprise, surprise ;) ) circle back to the developers and they fix them (even more surprise ;) ).

So, next day, you do your testing again. Well, you’ld like to BUT, since your tests, influenced the data of the system, some of your tests hit a different scenario. And maybe, your testing doesn’t trigger the buggy behavior anymore, or maybe, the bugs have been fixed. The point is, you don’t know for sure, as your starting point in the test system was a different than the day before…

So you need to take a snapshot of  some of those tables in the database before you start testing, and put it back in afterwards. That gives you exactly the same starting point for any consecutive tests.

Yes, MAYBE you can do this – but not if you’re talking about massive datasets like thousands of records, or ten housands, or hundret thousends… well, you get my point ;)

Using SQL insert scripts, will bring the Enterprise Manager to a halt (if not a crash) if you use tables with more than some ten thousands of records (and maybe you have a couple of those tables in your database and in that script).

The only way, you can use that SQL Insert script is to manually truncate it into smaller chunks, so the Enterprise Manager can work with it. That’s gonna take you ages – and may lead to some mistakes. Even if the Enterprise Manager swallows the whole script in one piece, it’s very, very slow.

The code Hero guys, where annoid about this, in their day to day work and created dbHero. That tool creates either SQL Inserts from SQL Server databases (no, we don’t want to use them), AND so called POWER scripts ;) The POWER scripts are an enhanced way of bulk copy scripts. They are damn fast – (code Hero says more than 50 times faster). Enhanced, why ? Well, also the standard bulk copy has got some issues ;) ) The code Hero guys, don’t reveal all of them (wonder why … ;) ) but point into the direction of encoding schemas, delimiters and string problems, among a few others…. At the same time, they even improved the already good speed of the bulk copy scripts.

Anyhow. Using dbHero makes taking those snapshots in POWER script modus a breath of fresh air ;) Instead of waiting hours or sometimes forever (when Enterprise Manager decides to go dark on you with too larg scripts ;) ), the job is done in seconds to minutes.

That saves time – and yes, you know what I’m gonna say – money ;)

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • E-mail this story to a friend!
  • LinkedIn
  • MySpace
  • Netvibes
  • ThisNext
  • TwitThis
  • Yahoo! Buzz
  • MisterWong.DE
  • Webnews.de
  • Blogosphere News

Testen mit Datenbank, ganz ohne Odyssee

Kaum eine Anwendung kommt ohne Daten aus einer Datenbank aus, und kaum ein Entwickler möchte ohne die aufs grüne Lämpchen gehenden Unit-Tests an größeren Projekten arbeiten.
Um Datenbanken und Unit-Tests miteinander verheiraten zu können, gibt es mehrere Ansätze.

Natürlich ist der erste und auch gute Ansatz von Unit-Tests, die Bausteine mit hardcodierten Standard-Daten zu penetrieren, die nicht aus einer Datenbank kommen: schließlich ist das Zusammenspiel mit der Datenbank schon ein großer Schritt in Richtung Integrationstest und gibt zeitgleich auch noch die Möglichkeit zu prüfen, ob die Klassen aus der Datenbankschicht wie erwartet funktionieren. Je mehr Variationen an Daten man dahingehend testen möchte, desto dringender wird es, die Methode der datenbank-getriebenen Tests gegenüber denen mit festverdrahteten Eingabeparametern zu präferieren. Und ganz nebenbei bemerkt: man trennt sich auch weiter von der Gefahr, ausschließlich mit idealisierten Daten zu testen, und nimmt dann doch jene Daten zur Brust, die in einem richtigen user-generierten Einsatz gewonnen wurden, ohne mittelfristig mehr Code für die Tests als die eigentliche Auftragsarbeit zu entwickeln.

Durch Ignorieren des Eventuellen werden Unit-Tests schließlich nach und nach immer weniger wert – insbesondere dann, wenn diese falsch positiv auf grün gehen.

Um diesen Wertverlust zu vermeiden, kann man sich eigentlich nur noch behelfen, in dem man die Datenbank wieder an einen wohldefinierten Ausgangspunkt zurückversetzt, mittels einem Script jene Datensätze erzeugt, die Grundlage für die weitergehenden Tests auf der Datenbank werden sollen und anschließend wieder aufräumt, um die Tests bis zur Reife der Programmierung immer und immer wieder anstoßen zu können. Dies kann man natürlich mit der Hilfe von Transaktionen machen: was allerdings bei vielen aufeinander aufbauenden Tests schnell unübersichtlich werden kann.

Einfacher ist es dann doch, sich den Auszug mit einem Vorher-Stand an Testdaten nebenhin zu legen und diese Daten dann vor den Tests einmalig konsistent zu reimportieren. Bei drei Tabellen mag man vielleicht das ganze noch per Hand pflegen. Aber auch hier schon ist es doch wesentlich einfacher und sicherer, auf einen Knopf zu drücken, der einem die aus dem Einsatz entstandenen Daten aus einer Datenbank zieht und zum immer wieder Einspielen archiviert. Auch aus dieser Motivation heraus entstand dbHero – ein schmuckes Tool, welches bei der täglichen Arbeit bei uns nicht mehr wegzudenken ist. Denn getrost kann man mit real-world Tests ein stückweit grüner auf grün gehen.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • E-mail this story to a friend!
  • LinkedIn
  • MySpace
  • Netvibes
  • ThisNext
  • TwitThis
  • Yahoo! Buzz
  • MisterWong.DE
  • Webnews.de
  • Blogosphere News

Nur noch schnell einen BULK INSERT von einem Share …

Wer kennt das nicht? Noch schnell die Daten von einem Share in einen SQL Server laden und fertig. Der SQL Server Dienst läuft aber in der Regel unter einem lokalen Account (Local System, Local Service oder  Network Service). Dieser hat naturgemäß keinen Zugriff auf Netzwerk Laufwerke. Es sei denn:

  • das Share hat die NTFS Berechtigung “Jeder” und die Freigabe Berechtigung “Jeder”.
  • Man läßt den SQL Server Dienst unter einem Account der Domaine laufen, welcher die notwendigen Permissions hat.
  • Man meldet sich mit einem Domain Account anstatt einem SQL Login am Server an.
  • Mehr dazu kann man unter “Security Considerations” und “Bulk Importing from a Remote Data File” bei http://msdn.microsoft.com/en-us/library/ms175915.aspx gelesen werden.

Frustriert hat man es Stunden später vielleicht doch hinbekommen oder sich einen anderen Weg überlegt.

Aber mal angenommen wir möchten ein DAT Datei von einem Share adhoc in den SQL Server laden:

BULK INSERT [T_TEST]
FROM '\\server\share\test\T_TEST.dat'
WITH (
DATAFILETYPE = 'char',
TABLOCK,
CODEPAGE = '1252',
KEEPNULLS,
KEEPIDENTITY
);

Gegebenfalls hat das sogar von dem lokalen SQL Server funktioniert, aber auf dem eigentlichen Server will er das nicht laden.


Msg4861, Level 16, State 1, Line 2
Cannot bulk load because the file "\\server\share\test\T_TEST.dat" could not be opened. Operating system error code 5(Zugriff verweigert).

 

Um die Daten jetzt irgendwie doch (noch schnell) reinzuladen, können wir mal nachschauen, ob wir überhaupt in dem Verzeichnis lesen dürfen. Dafür brauchen wir kurzfristig die xp_cmdshell.

-- ‘Erweiterte Optionen anzeigen’ einschalten.
EXEC sp_configure 'show advanced options', 1;
-- Das System aktualisieren.
RECONFIGURE;
-- xp_cmdshell anschalten.
EXEC sp_configure 'xp_cmdshell', 1;
-- Das System aktualisieren.
RECONFIGURE;

 

Nun können wir den DIR Befehl auf den Zielpfad ausführen:

exec xp_cmdshell 'dir \\server\share\temp\'


Zugriff verweigert

Wir geben uns die notwendigen Rechte mit

exec xp_cmdshell 'net use \\server\share /user:<user>@<domain> <passwort>'


Der Befehl wurde erfolgreich ausgeführt.

Dann wiederum sollte der oben erwähnte DIR Befehl auch die Dateien in dem Verzeichnis anzeigen.

Volume in Laufwerk \\server\share\temp\: hat keine Bezeichnung.
Volumeseriennummer: 10XX-X58X
NULL
Verzeichnis von \\server\share\temp\
NULL
23.01.2008 10:16 8.423.195 T_TEST.dat
Nun den BULK INSERT ausführen und dieser sollte seine Arbeit mit der gewünschten Meldung quittieren:

(334.714 row(s) affected)

Jetzt noch aufräumen mit

-- Share trennen
exec xp_cmdshell 'net use \\server\share /delete';
-- xp_cmdshell abschalten.
EXEC sp_configure 'xp_cmdshell', 0;
-- Das System aktualisieren.
RECONFIGURE;

Abschließen bleibt noch zu sagen, das diese Variante nur dazu gedacht ist, mal Daten auf die Schnelle zu laden. xp_cmdshell ist „evil“ und sollte nur mit Bedacht genutzt werden. So wie man einen DIR absetzen kann, so kann man auch alle anderen Befehle absetzen !

Zu Risiken und Nebenwirkungen fragen Sie Ihren Administrator ;)

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • E-mail this story to a friend!
  • LinkedIn
  • MySpace
  • Netvibes
  • ThisNext
  • TwitThis
  • Yahoo! Buzz
  • MisterWong.DE
  • Webnews.de
  • Blogosphere News