BCV5 ist eine schnellere, effizientere und handlichere Art, Db2-Daten zu kopieren. BCV5 kopiert nicht nur die physischen Db2-Daten schnell, sondern kümmert sich auch um alle Strukturen. Dazu gehören alle grundlegenden Objekte - Ihre Datenbanken, Tablespaces, Tabellen und Indizes - und auch DDL-Features wie Views, Trigger, Aliase, Synonyme, Constraints und vieles mehr. Wenn Ihre Zielobjekte bereits existieren, werden sie auf Kompatibilität geprüft. Es generiert automatisch Jobs und führt diese aus:
- Objektdefinitionen aus dem Db2-Katalog des Quellsystems extrahieren
- Transfer the definitions to the target system.
- Rename the objects as specified and apply them in the target Db2 system (CREATE, or DROP and CREATE).
- die Quelldefinitionen mit bestehenden Zielobjekten auf Kompatibilität vergleichen
- Copy page sets from source to target Db2.
- Start the target objects for end user access.
- Sobald eine Kopieraufgabe definiert ist, kann sie jederzeit ausgeführt werden, entweder manuell oder mit Hilfe eines Job Schedulers für die periodische Ausführung.
Automatisierung reduziert den manuellen Aufwand
BCV5 automatisiert komplett. Über die integrierte ISPF-Schnittstelle lassen sich Kopiervorgänge einfach definieren, indem man Namensmuster für die zu kopierenden Objekte und die entsprechenden Verarbeitungsoptionen festlegt. Die leistungsfähige regelbasierte Umbenennungsfunktion macht die Einhaltung von Namenskonventionen im Ziel-Db2-System einfach und fehlerfrei. Ein BCV5-Kopiervorgang kann entweder manuell oder unter der Kontrolle eines Job-Schedulers ausgeführt werden. Sobald der Kopiervorgang gestartet ist, gibt es nichts mehr zu tun.
BCV5 generiert automatisch die DDL für die ausgewählten Objekte unter Verwendung der angegebenen Zielnamen. Vorhandene Zielobjekte werden auf Kompatibilität geprüft. Wenn Zielobjekte fehlen, kann es diese für Sie erstellen. Für jedes Objekt im Prozess bestimmt BCV5 den schnellsten Weg, eine Kopie zu erstellen - normalerweise eine direkte Kopie auf VSAM-Ebene.
Wenn vorhandene Zielobjekte strukturelle Unterschiede aufweisen, kann BCV5 sie entweder löschen und neu erstellen oder UNLOAD/LOAD als Fallback-Kopierwerkzeug auslösen, um die Daten trotz der Unterschiede zu kopieren. So oder so, BCV5 sorgt dafür, dass alles funktioniert, und minimiert unerwünschte Überraschungen.
Die BCV5 Komponenten
Maskierung
Stay compliant and protect sensitive data. The Masking Tool masks personally identifiable information (PII) during the copy process. It can also mask data that is currently in a table without making a copy. The Masking Tool comes with ready-to-use predefined functions that allow you to mask names, addresses, SSNs, and many other types of data. You can also customize or add your own functions to meet your specific data masking needs.
Das Masking Tool ermöglicht die Implementierung der Anonymisierung, indem es gebrauchsfertige Maskierungsalgorithmen bereitstellt. Diese Funktionen können künstliche, aber scheinbar echte Daten wie Namen, Adressen, Kreditkarten- oder Sozialversicherungsnummern erzeugen. Die generierten Daten sind plausibel, d.h. Kreditkartennummern sind gültig und Adressen haben übereinstimmende Straßennamen, Postleitzahlen, Städte und Länder.
Wenn Daten aus Tabellen stammen sollen, die rund um die Uhr verfügbar sein müssen, stellt dies ein Problem für die IT-Abteilung dar. Die Benutzer müssen auf die Tabellen ohne Unterbrechung zugreifen und aktualisieren können - ein Anhalten der Quellobjekte ist keine Option.
Gleichzeitig benötigen die Prüfer eine konsistente Kopie der Daten. Die In-Flight-Komponente von BCV5 löst dieses Problem. Sie verwendet Informationen aus dem Db2-Log, um konsistente Kopien von Tablespaces (regulär, LOB und XML) und Indizes zu erstellen. Und das alles, während die Quelle für Updates verfügbar bleibt.
Müssen Sie Db2-Daten von letzter Woche, letztem Monat oder letztem Jahr bereitstellen? Sie möchten eine automatisierte und effiziente Methode zur Wiederherstellung von DDL und Daten in Rekordzeit?
IB erstellt bei Bedarf Snapshots und ermöglicht es Ihnen, die Objekte bei Bedarf in jeder beliebigen Umgebung wiederherzustellen. Sie können die Originalnamen verwenden oder die Objekte umbenennen.
Die Icebox-Komponente von BCV5 vergleicht Strukturinformationen aus der Sicherung mit den aktuellen Strukturen und kann entweder alte Daten in den aktuellen Tabellen wiederherstellen oder die Tabellen löschen und neu erstellen, so dass sie genau so aussehen wie bei der Erstellung der Sicherung.
Einige Produktionssysteme sind physisch so weit isoliert, dass es äußerst schwierig ist, Daten effizient auf Testsysteme zu migrieren. Sie können sich auf einer separaten LPAR oder sogar auf einem separaten CEC befinden, und manchmal ist nicht einmal ein gemeinsames DASD verfügbar.
Die RC-Komponente von BCV5 macht den Datentransfer zwischen isolierten Systemen einfach. RC verwendet TCP/IP, um Strukturen und Daten von einem System auf ein anderes zu übertragen. Der gesamte Kopiervorgang ist automatisiert und genauso einfach einzurichten und auszuführen wie eine lokale Kopie.
BI bietet eine leistungsfähige Definitionssprache für das Erstellen, Ändern und Löschen von BCV5-Kopieraufgaben über Batch-Jobs. Damit können Sie BCV5 problemlos in andere Prozesse integrieren.
Sie müssen die Verarbeitungsoptionen und Regeln einer Kopieraufgabe nicht über die Oberfläche definieren, sondern können sie in einem Job bereitstellen. Wenn Sie mehrere BCV5-Installationen auf verschiedenen Systemen haben, ist die Batch-Schnittstelle auch ein bequemer Weg, um komplette Aufgabendefinitionen zwischen den Installationen zu übertragen.
UT kann Informationen über Aufgabenausführungen speichern, die Ihnen helfen, die Db2-Datenbewegungen in Ihrem Unternehmen zu verfolgen und darüber zu berichten, z. B. welche Db2-Objekte kopiert wurden, von wem, wie lange der Prozess gedauert hat, und andere Details. Dies kann wertvolle Einblicke für DBAs, Speicheradministratoren und Verantwortliche für Data Governance liefern.
The advantage of integrated parallel processing
- Automatisiert das Kopieren/Migrieren/Aktualisieren von Db2
- Spart 90% CPU-Ressourcen und Laufzeit im Vergleich zu UNLOAD/LOAD
- Drastische Reduktion der Lohnkosten durch Freisetzung von Personal
- Lässt sich nahtlos in alle IT-Umgebungen integrieren
- Eliminates the need to run RUNSTATS and REBUILD INDEX
- Kopiert direkt, kein Bedarf an temporärem DASD-Speicherplatz
The mechanism that BCV5 uses to move data is based on copying the VSAM clusters that Db2 uses to store tablespace and indexspace data. There is a Db2 utility that works in a similar way: DSN1COPY.
The speed of DSN1COPY and the built-in copy utility of BCV5 are comparable if you copy a single cluster. When you want to copy an entire database or even multiple databases with all associated tablespaces and indexspaces, the copy utility of BCV5 has the advantage of integrated parallel processing with a user-definable number of threads. To emulate this parallelism with DSN1COPY, you need to create an elaborate job chain and execute it under the control of a job scheduler. When the number of data sets becomes larger, you must also take other limitations like the maximum number of steps in a job into consideration when using DSN1COPY.
The main problem with DSN1COPY, however, is the extremely low extent of automation that is built into this utility. Before the utility can be used, you must do a manual comparison of the source and target object structure in order to ensure that all attributes of all involved objects match. Some of these attributes need to be passed to the program in the form of invocation parameters to achieve usable results. The values that you need to look up are scattered over many catalog tables and need to be retrieved using multiple queries. In addition, you sometimes have to define some of the clusters in the target environment by yourself because DSN1COPY requires that all target clusters already be present.
First of all, you need to determine which datasets to copy. Let’s say you want to copy a single tablespace with all its tables and indexes. If the tablespace is partitioned, it consists of more than one dataset. Each partition may have been subject to a fast switch operation, which changes the dataset name of the corresponding VSAM cluster. Also, the indexspaces can have a mangled name that is derived from the actual index name. Indexes, of course, may be partitioned as well. To illustrate the complexity of this seemingly simple task, here’s a query that can be used to give you the name of all datasets that belong to the tablespace DB000001.TS000001 and its indexes. Note that you have to insert the database name and tablespace name in both parts of the UNION when you want to use this query.
