Kopie auf Tabellenebene

Abnahme-, Intergrations- und Regressionstests benötigen Massendaten, Gigabytes, manchmal schon Terabytes. Häufig sieht man noch Datenbereitstellungs-Prozesse, die stundenlang, wenn nicht tagelang laufen und in erheblichem Umfang DBA-Expertenzeit binden. Benötigt wird ein schnelles Verfahren, das, einmal definiert, beliebig oft benutzt werden kann, um Daten aus einer Umgebung in eine Andere zu transportieren.

Kopie 500

Auf dieser Ebene scheidet eine Klon-Methode, so schnell und effizient sie auch ist, von vorne herein aus, weil nur Auszüge des Quellsystems kopiert werden sollen und weil vermutlich Änderungen an Struktur und Daten beim Kopieren vorgenommen werden sollen.

Die Daten sind (meisten) relational, das heisst die Vorarbeiten zur Datenstruktur wie Verifikation/Erstellung Database, Tablespaces, Tabellen, Indices usw. sind nicht zu unterschätzen. Ein Tool sollte diese Aufgaben selbständig erledigen. Sodass der Anwender lediglich bestimmt, von welchem System (Prod, Vorprod) in welche Umgebung (Test, Entwicklung) kopiert werden soll, und natürlich, was zu kopieren ist. Es könnte ein komplettes Schema, oder alle Tabellen mit einem bestimmten Namensmuster, oder einfach alle Tabellen einer Liste zu kopieren sein. Weiter wären die zu kopierenden Objekt-Typen zu wählen, Indizes, Views, etc., für die Zielseite die Einbettungsregeln, fehlende Objekte sollen ergänzt (create), Vorhandene erneuert/ersetzen. Vielleicht sind Objekte umzubenennen (Creator, Schema), Daten zu modifizieren, oder zu anonymisieren, dann sollte der Prozess dies erlauben. Die Ausführung sollte bedienerlos möglich sein (Scheduler) und es sollte ein automatischer Restart möglich sein (nicht genügend Speicherplatz), sodass eine Komplettwiederholung nicht nötig wird. Die Ausführungsgeschwindigkeit sollte durch Parallelverarbeitung erhöht werden.

Zurück zu Testdatenbereitstellung