Gespeicherte Prozeduren für Datenbanken von RDS für Db2 - Amazon Relational Database Service
rdsadmin.create_databaserdsadmin.deactivate_databaserdsadmin.activate_databaserdsadmin.reactivate_databaserdsadmin.drop_databaserdsadmin.update_db_paramrdsadmin.set_configurationrdsadmin.show_configurationrdsadmin.backup_databaserdsadmin.restore_databaserdsadmin.rollforward_databaserdsadmin.rollforward_statusrdsadmin.complete_rollforwardrdsadmin.db2pd_commandrdsadmin.force_applicationrdsadmin.set_archive_log_retentionrdsadmin.show_archive_log_retentionrdsadmin.list_archive_log_informationrdsadmin.fgac_command

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Gespeicherte Prozeduren für Datenbanken von RDS für Db2

Mit den in diesem Thema beschrieben integrierten gespeicherten Prozeduren werden Datenbanken von Amazon RDS für Db2 verwaltet. Um diese Prozeduren auszuführen, muss der Masterbenutzer zuerst eine Verbindung mit der Datenbank rdsadmin herstellen.

Diese gespeicherten Prozeduren werden für eine Vielzahl von Aufgaben verwendet. Diese Liste ist nicht umfassend.

In den folgenden integrierten gespeicherten Prozeduren erhalten Sie Informationen zu deren Syntax, Parametern, Nutzungshinweisen und Beispielen.

rdsadmin.create_database

Erstellt eine Datenbank.

Syntax

db2 "call rdsadmin.create_database(
    'database_name',
    'database_page_size',
    'database_code_set',
    'database_territory',
    'database_collation',
    'database_autoconfigure_str',
    'database_non-restrictive')"

Parameter

Anmerkung

Mit dieser gespeicherten Prozedur wird die Kombination der erforderlichen Parameter nicht validiert. Beim Aufrufen von rdsadmin.get_task_status kann die benutzerdefinierte Funktion aufgrund einer ungültigen Kombination von database_codeset, database_territory und database_collation einen Fehler zurückgeben. Weitere Informationen finden Sie in der IBM Db2-Dokumentation unter Choosing the code page, territory, and collation for your database.

Der folgende Parameter ist erforderlich:

database_name

Der Name der zu erstellenden Datenbank. Der Datentyp ist varchar.

Die folgenden Parameter sind optional:

database_page_size

Die Standard-Seitengröße der Datenbank. Zulässige Werte: 4096, 8192, 16384, 32768. Der Datentyp ist integer. Der Standardwert ist 8192.

Wichtig

Amazon RDS unterstützt Write-Atomizität für Seiten mit 4 KiB, 8 KiB und 16 KiB. Im Gegensatz dazu besteht bei Seiten mit 32 KiB die Gefahr, dass Schreibvorgänge beschädigt werden oder dass Teile von Daten auf die Festplatte geschrieben werden. Wenn Sie Seiten mit 32 KiB verwenden, empfehlen wir Ihnen, die point-in-time Wiederherstellung und automatische Backups zu aktivieren. Andernfalls ist nach fehlerhaften Schreibvorgängen keine Wiederherstellung möglich. Weitere Informationen erhalten Sie unter Einführung in Backups und Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS.

database_code_set

Der Codesatz für die Datenbank. Der Datentyp ist varchar. Der Standardwert ist UTF-8.

database_territory

Der zweistellige Ländercode für die Datenbank. Der Datentyp ist varchar. Der Standardwert ist US.

database_collation

Die Sortierreihenfolge, die festlegt, wie die in der Datenbank gespeicherten Zeichenfolgen sortiert und verglichen werden. Der Datentyp ist varchar.

Zulässige Werte:

  • COMPATIBILITY – Sortierreihenfolge von IBM Db2 Version 2.

  • EBCDIC_819_037 – Lateinische ISO-Codepage, Sortierung; CCSID 037 (EBCDIC US-Englisch).

  • EBCDIC_819_500 – Lateinische ISO-Codepage, Sortierung; CCSID 500 (EBCDIC International).

  • EBCDIC_850_037 – Lateinische ASCII-Codepage, Sortierung; CCSID 037 (EBCDIC US-Englisch).

  • EBCDIC_850_500 – Lateinische ASCII-Codepage, Sortierung; CCSID 500 (EBCDIC International).

  • EBCDIC_932_5026 – Japanische ASCII-Codepage, Sortierung; CCSID 5026 (EBCDIC US-Englisch).

  • EBCDIC_932_5035 – Japanische ASCII-Codepage, Sortierung; CCSID 5035 (EBCDIC International).

  • EBCDIC_1252_037 – Lateinische Windows-Codepage, Sortierung; CCSID 037 (EBCDIC US-Englisch).

  • EBCDIC_1252_500 – Lateinische Windows-Codepage, Sortierung; CCSID 500 (EBCDIC International).

  • IDENTITY – Standardsortierung. Die Zeichenfolgen werden Byte für Byte verglichen.

  • IDENTITY_16BIT – Das Kompatibilitäts-Kodierungsschema für die UTF-16:8-Bit-Sortierreihenfolge (CESU-8). Weitere Informationen finden Sie im Unicode Technical Report #26 auf der Website vom Unicode Consortium.

  • NLSCHAR— Nur zur Verwendung mit der thailändischen Codepage (CP874).

  • SYSTEM – Wenn Sie SYSTEM verwenden, nutzt die Datenbank automatisch die Sortierreihenfolge für database_codeset und database_territory.

Der Standardwert ist IDENTITY.

Darüber hinaus unterstützt RDS für Db2 die folgenden Sortierungsgruppen: language-aware-collation und locale-sensitive-collation. Weitere Informationen finden Sie in der IBM Db2-Dokumentation unter Choosing a collation for a Unicode database.

database_autoconfigure_str

Die Befehlssyntax AUTOCONFIGURE, zum Beispiel 'AUTOCONFIGURE APPLY DB'. Der Datentyp ist varchar. Der Standardwert ist eine leere Zeichenfolge oder Null.

Weitere Informationen finden Sie in der IBM Db2-Dokumentation unter AUTOCONFIGURE command.

database_non-restrictive

Die Gewährung von Standardberechtigungen und -berechtigungen innerhalb der Datenbank. Der Datentyp ist varchar. Der Standardwert ist N.

Zulässige Werte:

  • N— Die erstellte Datenbank ist restriktiv und gewährt keine Befugnisse oder Privilegien.

  • Y— Die erstellte Datenbank ist nicht restriktiv und gewährt der speziellen Gruppe PUBLIC eine Reihe von Berechtigungen. Weitere Informationen finden Sie in der IBM Db2 Dokumentation unter Standardberechtigungen, die beim Erstellen einer Datenbank gewährt werden.

Nutzungshinweise

Wenn Sie den Parameter db2_compatibility_vector ändern möchten, erledigen Sie dies vor dem Erstellen einer Datenbank. Weitere Informationen finden Sie unter Festlegen des Parameters db2_compatibility_vector.

Spezielle Anforderungen:

  • Der an die Db2-Instance gesendete Befehl CREATE DATABASE verwendet die Option RESTRICTIVE.

  • RDS für Db2 verwendet nur AUTOMATIC STORAGE-Tabellenbereiche.

  • RDS für Db2 verwendet die Standardwerte für NUMSEGS und DFT_EXTENT_SZ.

  • RDS für Db2 verwendet Speicherverschlüsselung und unterstützt keine Datenbankverschlüsselung.

Weitere Informationen zu diesen Anforderungen finden Sie in der IBM Db2-Dokumentation unter CREATE DATABASE command.

Vor dem Aufrufen von rdsadmin.create_database müssen Sie eine Verbindung mit der Datenbank rdsadmin herstellen. Ersetzen Sie im folgenden Beispiel master_username und master_password durch die Informationen Ihrer RDS for Db2-DB-Instance:

db2 connect to rdsadmin user master_username using master_password

Informationen zum Überprüfen des Erstellungsstatus einer Datenbank finden Sie unter rdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.create_database zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Im folgenden Beispiel wird eine Datenbank erstellt, die TESTJP mit einer korrekten Kombination der database_collation Parameter database_code_setdatabase_territory, und für Japan aufgerufen wird:

db2 "call rdsadmin.create_database('TESTJP', 4096, 'IBM-437', 'JP', 'SYSTEM')"

rdsadmin.deactivate_database

Deaktiviert eine Datenbank.

Syntax

db2 "call rdsadmin.deactivate_database(
    ?,
    'database_name')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

database_name

Der Name der zu deaktivierenden Datenbank. Der Datentyp ist varchar.

Nutzungshinweise

Sie können Datenbanken deaktivieren, um Speicherressourcen zu schonen oder andere Änderungen an der Datenbankkonfiguration vorzunehmen. Rufen Sie die gespeicherte Prozedur rdsadmin.activate_database auf, um deaktivierte Datenbanken wieder online zu schalten.

Durch Aufrufen der gespeicherten Prozedur rdsadmin.deactivate_database können Sie eine Datenbank auf einer Quell-DB-Instance während der Replikation nicht deaktivieren.

Informationen zum Überprüfen des Deaktivierungsstatus einer Datenbank finden Sie unter rdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.deactivate_database zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Im folgenden Beispiel wird die Datenbank TESTDB deaktiviert.

db2 "call rdsadmin.deactivate_database(?, 'TESTDB')"

rdsadmin.activate_database

Aktiviert eine Datenbank.

Informationen zu den Unterschieden zwischen rdsadmin.reactivate_database und rdsadmin.activate_database finden Sie unter Nutzungshinweise.

Syntax

db2 "call rdsadmin.activate_database(
    ?,
    'database_name')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

database_name

Der Name der zu aktivierenden Datenbank. Der Datentyp ist varchar.

Nutzungshinweise

Alle Datenbanken werden bei der Erstellung standardmäßig aktiviert. Wenn Sie eine Datenbank auf einer eigenständigen DB-Instance deaktivieren, um Speicherressourcen zu schonen oder andere Änderungen an der Datenbankkonfiguration vorzunehmen, rufen Sie die gespeicherte Prozedur rdsadmin.activate_database auf, um die Datenbank erneut zu aktivieren.

Mit dieser gespeicherten Prozedur wird nur eine Datenbank aktiviert, die sich auf einer eigenständigen DB-Instance befindet und durch Aufrufen der gespeicherten Prozedur rdsadmin.deactivate_database deaktiviert wurde. Um eine Datenbank auf einer Replikatquell-DB-Instance zu aktivieren, müssen Sie die gespeicherte Prozedur rdsadmin.reactivate_database aufrufen.

Informationen zum Überprüfen des Aktivierungsstatus einer Datenbank finden Sie unter rdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.activate_database zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Im folgenden Beispiel wird die Datenbank TESTDB aktiviert.

db2 "call rdsadmin.activate_database(?, 'TESTDB')"

rdsadmin.reactivate_database

Aktiviert eine Datenbank erneut.

Informationen zu den Unterschieden zwischen rdsadmin.activate_database und rdsadmin.reactivate_database finden Sie unter Nutzungshinweise.

Syntax

db2 "call rdsadmin.reactivate_database(
    ?,
    'database_name')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

database_name

Der Name der erneut zu aktivierenden Datenbank. Der Datentyp ist varchar.

Nutzungshinweise

Wenn Sie die gespeicherte Prozedur rdsadmin.reactivate_database aufrufen, wird mit dieser zuerst die Datenbank durch Aufrufen der gespeicherten Prozedur rdsadmin.deactivate_database deaktiviert und dann durch Aufrufen der gespeicherten Prozedur rdsadmin.activate_database aktiviert.

Nachdem Sie Änderungen an den Datenbankkonfigurationen vorgenommen haben, müssen Sie möglicherweise eine Datenbank auf einer DB-Instance von RDS für Db2 erneut aktivieren. Um zu ermitteln, ob Sie eine Datenbank erneut aktivieren müssen, stellen Sie eine Verbindung mit der Datenbank her und führen Sie db2 get db cfg show detail aus.

Eine Datenbank auf einer eigenständigen DB-Instance können Sie mit der gespeicherten Prozedur rdsadmin.reactivate_database erneut aktivieren. Wenn Sie die gespeicherte Prozedur rdsadmin.deactivate_database bereits aufgerufen haben, können Sie auch stattdessen die gespeicherte Prozedur rdsadmin.activate_database aufrufen.

Für eine Datenbank auf einer Replikatquell-DB-Instance müssen Sie die gespeicherte Prozedur rdsadmin.reactivate_database verwenden, um sie erneut zu aktivieren.

Informationen zum Überprüfen des Reaktivierungsstatus einer Datenbank finden Sie unter rdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.reactivate_database zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Im folgenden Beispiel wird die Datenbank TESTDB erneut aktiviert.

db2 "call rdsadmin.reactivate_database(?, 'TESTDB')"

rdsadmin.drop_database

Entfernt eine Datenbank.

Syntax

db2 "call rdsadmin.drop_database('database_name')"

Parameter

Der folgende Parameter ist erforderlich:

database_name

Der Name der zu entfernenden Datenbank. Der Datentyp ist varchar.

Nutzungshinweise

Sie können eine Datenbank durch Aufrufen von rdsadmin.drop_database nur dann entfernen, wenn die folgenden Bedingungen erfüllt sind:

  • Beim Erstellen der DB-Instance von RDS für Db2 mithilfe der Amazon-RDS-Konsole oder der AWS CLI haben Sie den Namen der Datenbank nicht angegeben. Weitere Informationen finden Sie unter Erstellen einer DB-Instance.

  • Sie haben die Datenbank durch Aufrufen der gespeicherten Prozedur rdsadmin.create_database erstellt.

  • Sie haben die Datenbank aus einem Offline- oder Sicherungsabbild durch Aufrufen der gespeicherten Prozedur rdsadmin.restore_database wiederhergestellt.

Vor dem Aufrufen von rdsadmin.drop_database müssen Sie eine Verbindung mit der Datenbank rdsadmin herstellen. Ersetzen Sie im folgenden Beispiel master_username und master_password durch Ihre RDS for Db2-DB-Instance-Informationen:

db2 connect to rdsadmin user master_username using master_password

Informationen zum Überprüfen des Löschstatus einer Datenbank finden Sie unter rdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.drop_database zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Im folgenden Beispiel wird die Datenbank TESTDB entfernt:

db2 "call rdsadmin.drop_database('TESTDB')"

rdsadmin.update_db_param

Aktualisiert die Datenbankparameter.

Syntax

db2 "call rdsadmin.update_db_param(
    'database_name', 
    'parameter_to_modify', 
    'changed_value',
    'restart_database')"

Parameter

Die folgenden Parameter sind erforderlich:

database_name

Der Name der Datenbank, für die die Aufgabe ausgeführt werden soll. Der Datentyp ist varchar.

parameter_to_modify

Der Name des zu ändernden Parameters. Der Datentyp ist varchar. Weitere Informationen finden Sie unter Parameter von Amazon RDS für Db2.

changed_value

Der Wert, in den der Parameterwert geändert werden soll. Der Datentyp ist varchar.

Der folgende Parameter ist optional:

restart_database

Gibt an, ob RDS die Datenbank neu startet, sofern ein Neustart erforderlich ist. Der Datentyp ist varchar. Um logprimary und logfilsiz zu ändern, legen Sie diesen Parameter auf 'YES' fest.

Nutzungshinweise

Informationen zum Überprüfen des Aktualisierungsstatus von Datenbankparametern finden Sie unter rdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.update_db_param zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Beispiel 1: Aktualisieren eines Parameters

Im folgenden Beispiel wird der Parameter archretrydelay für die Datenbank TESTDB auf 100 aktualisiert:

db2 "call rdsadmin.update_db_param(
    'TESTDB', 
    'archretrydelay', 
    '100')"

Beispiel 2: Verzögern der Validierung von Objekten

Im folgenden Beispiel wird die Validierung von erstellten Objekten in der Datenbank TESTDB verzögert, um eine Überprüfung der Abhängigkeiten zu vermeiden:

db2 "call rdsadmin.update_db_param(
    'TESTDB', 
    'auto_reval', 
    'deferred_force')"

rdsadmin.set_configuration

Konfiguriert spezifische Einstellungen für die Datenbank.

Syntax

db2 "call rdsadmin.set_configuration(
    'name',  
    'value')"

Parameter

Die folgenden Parameter sind erforderlich:

name

Der Name der Konfigurationseinstellung. Der Datentyp ist varchar.

value

Der Wert der Konfigurationseinstellung. Der Datentyp ist varchar.

Nutzungshinweise

In der folgenden Tabelle sind die Konfigurationseinstellungen angegeben, die Sie mit rdsadmin.set_configuration steuern können.

Name Description

RESTORE_DATABASE_NUM_BUFFERS

Die Anzahl der während einer Wiederherstellung zu erstellenden Puffer. Dieser Wert muss kleiner als die Gesamtspeichergröße der DB-Instance-Klasse sein. Wenn diese Einstellung nicht konfiguriert ist, legt Db2 den Wert fest, der während der Wiederherstellung verwendet werden soll. Weitere Informationen finden Sie in der IBM Db2 Dokumentation unter dem Befehl RESTORE DATABASE.

RESTORE_DATABASE_PARALLELISM

Die Anzahl der während einer Wiederherstellung zu erstellenden Puffermanipulatoren. Dieser Wert muss kleiner als das Doppelte der Zahl von v CPUs für die DB-Instance sein. Wenn diese Einstellung nicht konfiguriert ist, legt Db2 den Wert fest, der während der Wiederherstellung verwendet werden soll. Weitere Informationen finden Sie in der IBM Db2 Dokumentation unter dem Befehl RESTORE DATABASE.

RESTORE_DATABASE_NUM_MULTI_PATHS

Die Anzahl der Pfade (oder I/O Streams), die während einer Wiederherstellung aus Amazon S3 verwendet werden sollen. Um diese Konfigurationseinstellung verwenden zu können, benötigen Sie mehrere Sicherungsdateien. Dieser Wert kann die Leistung bei der Wiederherstellung von Datenbanken mit großen Datenmengen verbessern, da er mehrere Datenbanksicherungsdateien parallel wiederherstellt. Wir empfehlen, dass Sie diesen Wert so einstellen, dass er der Anzahl Ihrer Datenbanksicherungsdateien entspricht. Weitere Informationen finden Sie in der IBM Db2 Dokumentation unter dem Befehl BACKUP DATABASE.

USE_STREAMING_RESTORE

Gibt an, ob Backup-Daten direkt während der Wiederherstellung gestreamt werden sollen, anstatt zuerst das gesamte Backup auf Ihre RDS for Db2-DB-Instance herunterzuladen und dann zu extrahieren. Die Einstellung USE_STREAMING_RESTORE auf reduziert den Speicherbedarf TRUE erheblich und kann die Wiederherstellungsleistung verbessern. Diese Einstellung erfordert IBM Db2 Engine Version 11.5.9.0.sb00063198.r1 oder höher und Amazon S3 S3-Konnektivität über das elastic network interface (ENI) Ihrer Datenbank. Weitere Informationen finden Sie in der Dokumentation unter Remotespeicher. IBM Db2

Beispiele

Beispiel 1: Angeben der Anzahl der zu erstellenden Puffer

Im folgenden Beispiel wird die Konfiguration RESTORE_DATABASE_NUM_BUFFERS auf 150 festgelegt.

db2 "call rdsadmin.set_configuration(
    'RESTORE_DATABASE_NUM_BUFFERS', 
    '150')"

Beispiel 2: Angabe der Anzahl der zu erstellenden Puffermanipulatoren

Im folgenden Beispiel wird die Konfiguration RESTORE_DATABASE_PARALLELISM auf 8 festgelegt.

db2 "call rdsadmin.set_configuration(
    'RESTORE_DATABASE_PARALLELISM', 
    '8')"

Beispiel 3: Angeben der Anzahl der Pfade oder I/O Streams, die bei der Wiederherstellung verwendet werden sollen

Im folgenden Beispiel wird die Konfiguration RESTORE_DATABASE_NUM_MULTI_PATHS auf 5 festgelegt.

db2 "call rdsadmin.set_configuration(
    'RESTORE_DATABASE_NUM_MULTI_PATHS', 
    '5')"

Beispiel 4: Einstellung der Wiederherstellung auf Stream-Backup-Daten

Im folgenden Beispiel wird die Konfiguration USE_STREAMING_RESTORE auf TRUE festgelegt.

db2 "call rdsadmin.set_configuration(
    'USE_STREAMING_RESTORE', 
    'TRUE')"

rdsadmin.show_configuration

Gibt die aktuellen Einstellungen zurück, die Sie mithilfe der gespeicherten Prozedur rdsadmin.set_configuration festlegen können.

Syntax

db2 "call rdsadmin.show_configuration(
    'name')"

Parameter

Der folgende Parameter ist optional:

name

Der Name der Konfigurationseinstellung, zu der Informationen zurückgegeben werden sollen. Der Datentyp ist varchar.

Die folgenden Konfigurationsnamen sind gültig:

  • RESTORE_DATABASE_NUM_BUFFERS— Die Anzahl der Puffer, die während eines Wiederherstellungsvorgangs erstellt werden sollen.

  • RESTORE_DATABASE_PARALLELISM— Die Anzahl der Puffermanipulatoren, die während eines Wiederherstellungsvorgangs erstellt werden sollen.

  • RESTORE_DATABASE_NUM_MULTI_PATHS— Die Anzahl der Pfade (oder I/O Streams), die während einer Wiederherstellung aus Amazon S3 verwendet werden sollen.

  • USE_STREAMING_RESTORE— Gibt an, ob Backup-Daten direkt während der Wiederherstellung gestreamt werden sollen, anstatt zuerst die gesamten Backup-Daten auf Ihre RDS for Db2-DB-Instance herunterzuladen und dann zu extrahieren.

Nutzungshinweise

Wenn Sie den Namen einer Konfigurationseinstellung nicht festlegen, gibt rdsadmin.show_configuration Informationen für alle Konfigurationseinstellungen zurück, die Sie mithilfe der gespeicherten Prozedur rdsadmin.set_configuration festlegen können.

Beispiele

Im folgenden Beispiel werden Informationen zur aktuellen Konfiguration RESTORE_DATABASE_PARALLELISM zurückgegeben.

db2 "call rdsadmin.show_configuration(
    'RESTORE_DATABASE_PARALLELISM')"

rdsadmin.backup_database

Sichert eine Datenbank von einer RDS for Db2-DB-Instance in einem Amazon S3 S3-Bucket.

Syntax

db2 "call rdsadmin.backup_database(
    ?,
    'database_name', 
    's3_bucket_name', 
    's3_prefix', 
    'backup_type',
    'compression_option',
    'util_impact_priority', 
    'num_files',
    'parallelism',
    'num_buffers')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Die folgenden Eingabeparameter sind erforderlich:

database_name

Der Name der Zieldatenbank auf einer RDS for Db2-DB-Instance, die gesichert werden soll. Der Datentyp ist varchar.

Die Datenbank muss in der DB-Instance vorhanden sein. Sie können die rdsadmin Datenbank nicht sichern.

s3_bucket_name

Der Name des Amazon S3 S3-Buckets, in dem sich Ihr Backup befinden soll. Der Datentyp ist varchar.

Der S3-Bucket muss vor dem Aufruf vorhanden seinrdsadmin.backup_database, sich in derselben Zieldatenbank AWS-Region wie die Zieldatenbank in der RDS for Db2-DB-Instance befinden, die Sie sichern möchten, und über die der DB-Instance zugeordnete IAM-Rolle zugänglich sein.

s3_prefix

Das Präfix des Pfads zu Amazon S3, in den RDS for Db2 die Sicherungsdateien hochlädt. Der Datentyp ist varchar.

Das Präfix ist auf 1024 Zeichen begrenzt. Es darf keinen führenden oder abschließenden Schrägstrich (/) enthalten. Aufgrund einer Einschränkung beim IBM Streaming zu Amazon S3 empfehlen wir, dass das Präfix Unterverzeichnisse einschließt.

Für eine bessere Dateiverwaltung erstellt RDS for Db2 anschließend zusätzliche Verzeichnisse. s3_prefix RDS für Db2 lädt alle Sicherungsdateien auf hoch. s3_prefix/dbi_resource_id/db_name Wenn Sie einen num_files höheren Wert als 1 angeben, enthält das db_name Verzeichnis mehr als eine Sicherungsdatei.

Im Folgenden finden Sie ein Beispiel für einen Amazon S3 S3-Speicherort für Sicherungsdateien. Im Beispiel backups/daily ist der Wert für den s3_prefix Parameter festgelegt.

backups/daily/db-5N7FXOY4GDP7RG2NSH2ZTAI2W4/SAMPLEDB
backup_type

Der Sicherungstyp, der bestimmt, ob die Datenbank während der Sicherung verfügbar bleibt. Der Datentyp ist varchar.

Zulässige Werte:

  • OFFLINE— Die Datenbank ist während der Sicherung nicht verfügbar. Dieser Typ ist schneller, verursacht aber Ausfallzeiten.

  • ONLINE— Die Datenbank bleibt während des Backups verfügbar. ONLINE ist standardmäßig auf INCLUDE LOGS festgelegt.

Die folgenden Parameter sind optional:

compression_option

Die Art des verwendeten Komprimierungsalgorithmus, der sich auf die Backup-Zeit, die CPU-Auslastung und die Speicherkosten auswirkt. Der Datentyp ist varchar. Der Standardwert ist NONE.

Zulässige Werte:

  • NONE— Die größte Dateigröße, die geringste CPU-Auslastung und die günstigsten Speicherkosten.

  • STANDARD— Standard-Db2-Komprimierung. Nutztlibdb2compr.so.

  • ZLIB— Verbesserte Db2-Komprimierung. Verwendet libdb2zcompr.so Speicherplatz, ist aber rechenintensiver und kostet am teuersten.

util_impact_priority

Die Einstellung, mit der die Auswirkungen des Backups auf die Systemressourcen gesteuert werden. Der Datentyp ist integer. Gültige Werte: 1 — 100 (von niedrig bis hoch). Der Standardwert ist 50.

Niedrigere Werte reduzieren die Auswirkungen des Backups auf die Systemressourcen, können jedoch die Zeit verlängern, die für die Sicherung der Datenbank benötigt wird. Höhere Werte können die Sicherung der Datenbank möglicherweise schneller abschließen, können sich jedoch auf andere Vorgänge auswirken. Die tatsächlichen Auswirkungen hängen von der Gesamtsystemauslastung und der util_impact_lim Einstellung ab. Sie können die util_impact_lim Einstellung in Parametergruppen anzeigen und ändern. Weitere Informationen finden Sie unter Parameter von Amazon RDS für Db2.

num_files

Die Anzahl der parallel Upload-Streams zu Amazon S3. Der Datentyp ist integer. Gültige Werte: 1–256.

Wir empfehlen, diesen Parameter erst festzulegen, nachdem Sie die Backup-Leistung auf die Standardwerte eingestellt haben, die Amazon RDS automatisch berechnet. Höhere Werte können die Leistung für große Backups verbessern, insbesondere bei Verbindungen mit hoher Bandbreite, aber ab einem bestimmten Punkt verschlechtern höhere Werte die Leistung. Achten Sie außerdem darauf, Ihre verfügbaren Systemressourcen und Netzwerkkapazitäten zu berücksichtigen.

parallelism

Die Anzahl der Tablespaces, die das Backup-Hilfsprogramm parallel lesen kann. Der Datentyp ist integer. Gültige Werte: 1–256.

Es wird empfohlen, diesen Parameter erst festzulegen, nachdem Sie die Backup-Leistung auf den Standardwert eingestellt haben, den die Db2-Engine automatisch als optimalen Wert berechnet. Wenn Sie diesen Parameter festlegen, validiert Amazon RDS anhand der verfügbaren Prozessoren und führt die Backup-Anfrage nicht aus, wenn die Rechenleistung nicht ausreicht.

num_buffers

Die Anzahl der zu verwendenden Puffer. Der Datentyp ist integer. Gültige Werte: 1–268435456.

Wir empfehlen, diesen Parameter erst festzulegen, nachdem Sie die Backup-Leistung auf die Standardeinstellung eingestellt haben, die Amazon RDS automatisch auf der Grundlage des Speichers berechnet. Wenn Sie diesen Parameter festlegen, validiert Amazon RDS anhand des verfügbaren Speichers und führt die Backup-Anfrage nicht aus, wenn der verfügbare Speicher nicht ausreicht. Wenn Sie an mehreren Speicherorten sichern (num_filesist auf mehr als eingestellt1), kann eine höhere Anzahl von Puffern die Leistung verbessern. Wenn Sie dies nicht tun compression_optionNONE, können Sie die Leistung verbessern, indem Sie num_buffers und parallelism erhöhen.

Nutzungshinweise

Diese gespeicherte Prozedur erstellt asynchrone Backup-Aufgaben, die das Backup Ihrer Datenbank mithilfe der Amazon S3 S3-Integration direkt in Ihren Amazon S3 S3-Bucket streamen. Sie können Backups sowohl von Ihrem lokalen Server als auch von einer RDS for Db2-DB-Instance erstellen, sie auf Amazon S3 streamen und sie dann wiederherstellen, wo immer Sie möchten. Informationen zum Wiederherstellen einer Datenbank auf einer RDS for Db2-DB-Instance finden Sie unter. rdsadmin.restore_database

Bevor Sie die gespeicherte Prozedur aufrufen, lesen Sie die folgenden Hinweise:

Vor dem Aufrufen von rdsadmin.backup_database müssen Sie eine Verbindung mit der Datenbank rdsadmin herstellen. Ersetzen Sie im folgenden Beispiel master_username und master_password durch Ihre RDS for Db2-DB-Instance-Informationen:

db2 connect to rdsadmin user master_username using master_password

Nachdem Sie Ihre Datenbank gesichert haben, stellen Sie sicher, dass Sie die Verbindung beenden.

terminate

Hinweise zur Überprüfung des Status einer Datenbanksicherung finden Sie unterrdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.backup_database zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Alle Beispiele sichern eine Datenbank, die im Amazon S3 S3-Bucket aufgerufen amzn-s3-demo-bucket und s3_prefix auf gesetzt wirdbackups/daily. MYDB

Beispiel #1: Geben Sie an, dass die Datenbank offline und nicht verfügbar ist, bei durchschnittlicher Auslastung und einem einzigen Upload-Stream

Im folgenden Beispiel ist die Datenbank offline, was schneller ist, aber bedeutet, dass die Datenbank während des Backups nicht verfügbar ist. Das Beispiel führt keine Komprimierung der Dateien durch, hat mittlere Auswirkungen auf die Systemressourcen und verwendet einen einzigen Upload-Stream zu Amazon S3.

db2 call "rdsadmin.backup_database(
    ?, 
    'MYDB',
    'amzn-s3-demo-bucket', 
    'backups/daily',
    'OFFLINE',
    'NONE', 
    50, 
    1)"

Beispiel #2: Angabe der Datenbank online und verfügbar mit verbesserter Komprimierung, Medianauslastung und wenigen parallel Upload-Streams

Im folgenden Beispiel ist die Datenbank online und während der Sicherung verfügbar. In diesem Beispiel wird eine verbesserte Komprimierung durchgeführt, was zu einer geringen Dateigröße führt, aber CPU-intensiv ist. Es hat einen etwas überdurchschnittlichen Einfluss auf die Systemressourcen und verwendet fünf Upload-Streams zu Amazon S3.

db2 call "rdsadmin.backup_database(
    ?, 
    'MYDB',
    'amzn-s3-demo-bucket', 
    'backups/daily',
    'ONLINE',
    'ZLIB', 
    60, 
    5)"

Beispiel #3: Mit Standardwerten und Systemberechnungen wird angegeben, dass die Datenbank offline und nicht verfügbar ist

Im folgenden Beispiel ist die Datenbank offline, was schneller ist, aber bedeutet, dass die Datenbank während der Sicherung nicht verfügbar ist. Das Beispiel verwendet die Standardkomprimierung der Dateien und die Auswirkungen auf die Systemressourcen. Es ermöglicht RDS for Db2 auch, die Anzahl der parallelen Upload-Streams zu Amazon S3, Tablespaces, die parallel gelesen werden sollen, und die zu verwendenden Puffer zu berechnen.

db2 "call rdsadmin.backup_database(
    ?, 
    'MYDB', 
    'amzn-s3-demo-bucket',
    'backups/daily', 
    'OFFLINE')"

Beispiel #4: Angabe, dass die Datenbank offline und nicht verfügbar ist, ohne Komprimierung, hohe Auslastung und benutzerdefinierte Berechnungen

Im folgenden Beispiel ist die Datenbank offline, was schneller ist, aber bedeutet, dass die Datenbank während der Sicherung nicht verfügbar ist. Das Beispiel führt keine Komprimierung der Dateien durch, hat einen hohen Einfluss auf die Systemressourcen und verwendet 20 Upload-Streams zu Amazon S3. Es legt die maximale Anzahl von Tablespaces fest, die parallel gelesen werden sollen, was dazu führen kann, dass die Backup-Anfrage fehlschlägt, wenn die Rechenleistung nicht ausreicht. Außerdem wird die maximale Anzahl der zu verwendenden Puffer festgelegt, was dazu führen kann, dass die Backup-Anfrage fehlschlägt, wenn der Arbeitsspeicher nicht ausreicht.

db2 "call rdsadmin.backup_database(
    ?, 
    'MYDB', 
    'amzn-s3-demo-bucket', 
    'backups/daily', 
    'OFFLINE', 
    'NONE', 
    90, 
    20, 
    256, 
    268435456)"

rdsadmin.restore_database

Stellt eine Datenbank aus einem Amazon-S3-Bucket für die DB-Instance von RDS für Db2 wieder her.

Syntax

db2 "call rdsadmin.restore_database(
    ?,
    'database_name', 
    's3_bucket_name', 
    's3_prefix', 
    restore_timestamp, 
    'backup_type')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Die folgenden Eingabeparameter sind erforderlich:

database_name

Der Name der Zieldatenbank, die in RDS für Db2 wiederhergestellt werden soll. Der Datentyp ist varchar.

Wenn der Quelldatenbankname beispielsweise lautete TESTDB und Sie database_name auf eingestellt habenNEWDB, stellt Amazon RDS NEWDB als Quelldatenbank wieder her.

s3_bucket_name

Der Name des Amazon-S3-Bucket, in dem sich das Backup befindet. Der Datentyp ist varchar.

s3_prefix

Das Präfix, das beim Download für den Dateiabgleich verwendet werden soll. Der Datentyp ist varchar.

Wenn dieser Parameter leer ist, werden alle Dateien im Amazon S3 S3-Bucket verarbeitet. Nachfolgend ist ein Beispielpräfix angegeben:

backupfolder/SAMPLE.0.rdsdb.DBPART000.20230615010101
restore_timestamp

Der Zeitstempel für das Abbild des Datenbank-Backups. Der Datentyp ist varchar.

Der Zeitstempel ist im Namen der Backup-Datei enthalten. Beispielsweise ist 20230615010101 der Zeitstempel für den Dateinamen SAMPLE.0.rdsdb.DBPART000.20230615010101.001.

backup_type

Der Typ des Backups. Der Datentyp ist varchar. Zulässige Werte: OFFLINE, ONLINE.

Verwenden Sie ONLINE für Migrationen mit geringster Ausfallzeit. Weitere Informationen finden Sie unter Migrieren von Linux zu Linux fast ohne Ausfallzeit für Amazon RDS für Db2.

Nutzungshinweise

Sie können diese gespeicherte Prozedur verwenden, um eine Db2-Datenbank zu einer DB-Instance von RDS für Db2 zu migrieren. Weitere Informationen finden Sie unter Nutzung von AWS-Services zur Migration von Daten von Db2 zu Amazon RDS für Db2. Sie können diese gespeicherte Prozedur auch verwenden, um mehrere Kopien derselben Datenbank mit unterschiedlichen Datenbanknamen zu erstellen, die dasselbe Wiederherstellungsabbild nutzen.

Bevor Sie die gespeicherte Prozedur aufrufen, lesen Sie die folgenden Hinweise:

  • Bevor Sie eine Datenbank wiederherstellen, müssen Sie Speicherplatz für Ihre RDS for Db2-DB-Instance bereitstellen, der größer ist als die ursprüngliche Db2-Datenbank auf der Festplatte. Wenn Sie diese Option aktiviert habenUSE_STREAMING_RESTORE, streamt Amazon RDS bei der Wiederherstellung Ihres Backups die Sicherungsdateien direkt von Ihrem S3-Bucket auf Ihre RDS for Db2-DB-Instance. Wenn Sie die Aktivierung nicht aktivierenUSE_STREAMING_RESTORE, müssen Sie Speicherplatz für Ihre RDS for Db2-DB-Instance bereitstellen, der mindestens der Summe aus Backup-Größe und der ursprünglichen Db2-Datenbank auf der Festplatte entspricht. Weitere Informationen finden Sie unter Insufficient disk space.

  • Wenn Sie das Backup wiederherstellen, extrahiert Amazon RDS die Backup-Datei auf der DB-Instance von RDS für Db2. Jede Backup-Datei darf maximal 5 TB umfassen. Wenn eine Sicherungsdatei größer als 5 TB ist, müssen Sie die Sicherungsdatei in kleinere Dateien aufteilen.

  • Um alle Dateien mithilfe der gespeicherten Prozedur rdsadmin.restore_database wiederherzustellen, geben Sie das Dateinummernsuffix nicht nach dem Zeitstempel in die Dateinamen ein. Das stellt beispielsweise die folgenden s3_prefix backupfolder/SAMPLE.0.rdsdb.DBPART000.20230615010101 Dateien wieder her:

    SAMPLE.0.rdsdb.DBPART000.20230615010101.001
SAMPLE.0.rdsdb.DBPART000.20230615010101.002
SAMPLE.0.rdsdb.DBPART000.20230615010101.003
SAMPLE.0.rdsdb.DBPART000.20230615010101.004
SAMPLE.0.rdsdb.DBPART000.20230615010101.005

  • RDS für Db2 unterstützt keine nichtautomatische Speicherung. Weitere Informationen finden Sie unter Tablespaces not restored.

  • RDS für Db2 unterstützt keine Routinen ohne Fencing. Weitere Informationen finden Sie unter Non-fenced routines not allowed.

  • Um die Leistung von Datenbankwiederherstellungsvorgängen zu verbessern, können Sie die Anzahl der Puffer, Puffermanipulatoren und die Anzahl der mehreren Sicherungspfade, die RDS verwenden soll, konfigurieren. Um die Speichernutzung zu optimieren und die Leistung potenziell zu verbessern, können Sie ein Backup auch direkt von Amazon S3 streamen. Verwenden Sie rdsadmin.show_configuration, um die aktuelle Konfiguration zu überprüfen. Verwenden Sie rdsadmin.set_configuration, um die Konfiguration zu ändern.

Informationen zum Onlineschalten der Datenbank und zum Anwenden zusätzlicher Transaktionsprotokolle nach dem Wiederherstellen der Datenbank finden Sie unter rdsadmin.rollforward_database.

Informationen zum Überprüfen des Wiederherstellungsstatus der Datenbank finden Sie unter rdsadmin.get_task_status.

Informationen zu Fehlermeldungen, die beim Aufrufen von rdsadmin.restore_database zurückgegeben werden, finden Sie unter Fehler bei gespeicherten Prozeduren.

Beispiele

Das folgende Beispiel stellt eine Offline-Sicherung mit einer einzelnen Datei oder mehreren Dateien wieder her, die Folgendes aufweisen s3_prefixbackupfolder/SAMPLE.0.rdsdb.DBPART000.20230615010101:

db2 "call rdsadmin.restore_database(
    ?,
    'SAMPLE',
    'amzn-s3-demo-bucket',
    'backupfolder/SAMPLE.0.rdsdb.DBPART000.20230615010101',
    20230615010101,
    'OFFLINE')"

rdsadmin.rollforward_database

Schaltet die Datenbank online und wendet zusätzliche Transaktionsprotokolle an, nachdem eine Datenbank durch Aufrufen von rdsadmin.restore_database wiederhergestellt wurde.

Syntax

db2 "call rdsadmin.rollforward_database(
    ?,
    'database_name',
    's3_bucket_name', 
    s3_prefix, 
    'rollforward_to_option', 
    'complete_rollforward')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Die folgenden Eingabeparameter sind erforderlich:

database_name

Der Name der Datenbank, für die der Vorgang ausgeführt werden soll. Der Datentyp ist varchar.

s3_bucket_name

Der Name des Amazon-S3-Bucket, in dem sich das Backup befindet. Der Datentyp ist varchar.

s3_prefix

Das Präfix, das beim Download für den Dateiabgleich verwendet werden soll. Der Datentyp ist varchar.

Wenn dieser Parameter leer ist, werden alle Dateien im S3-Bucket heruntergeladen. Im Folgenden ist ein Beispielpräfix angegeben:

backupfolder/SAMPLE.0.rdsdb.DBPART000.20230615010101

Die folgenden Eingabeparameter sind optional:

rollforward_to_option

Der Punkt, zu dem Sie ein Rollforward ausführen möchten. Der Datentyp ist varchar. Gültige Werte: END_OF_LOGS, END_OF_BACKUP mit dem Zeitstempel im Format YYYY-MM-DD-HH.MM.SS. Der Standardwert ist END_OF_LOGS.

complete_rollforward

Gibt an, ob der Rollforward-Prozess abgeschlossen werden soll. Der Datentyp ist varchar. Der Standardwert ist TRUE.

Wenn TRUE, dann ist die Datenbank nach Abschluss online und es kann darauf zugegriffen werden. Wenn FALSE, dann verbleibt die Datenbank im Status ROLL-FORWARD PENDING.

Nutzungshinweise

Sie können rds.rollforward_database für ein Online-Backup mit enthaltenen Protokollen verwenden, die in vielen verschiedenen Szenarien On-Premises erstellt werden.

Szenario 1: Wiederherstellen der Datenbank, Ausführen von Rollforward der enthaltenen Protokolle und Onlineschalten der Datenbank

Nachdem rdsadmin.restore_database() abgeschlossen wurde, verwenden Sie die Syntax in Beispiel 1, um die Datenbank mit den Transaktionsprotokollen online zu schalten.

Szenario 2: Onlineschalten der Datenbank, ohne ein Rollforward der enthaltenen Protokolle auszuführen

Nachdem rdsadmin.restore_database() abgeschlossen wurde, verwenden Sie die Syntax in Beispiel 2, um die Datenbank ohne die Transaktionsprotokolle online zu schalten.

Szenario 3: Ausführen eines Rollforward der im Backup enthaltenen Protokolle und Anwenden zusätzlicher Transaktionsprotokolle, wenn sie On-Premises erstellt werden

Nachdem rdsadmin.restore_database() abgeschlossen wurde, verwenden Sie die Syntax in Beispiel 3 oder Beispiel 4, um ein Rollforward der Protokolle auszuführen, ohne die Datenbank online zu schalten.

Wenn Sie complete_rollforward auf FALSE festlegen, befindet sich die Datenbank im Status ROLL-FORWARD PENDING und ist offline. Um die Datenbank online zu schalten, müssen Sie rdsadmin.complete_rollforward aufrufen.

Informationen zum Überprüfen des Rollforward-Status der Datenbank finden Sie unter rdsadmin.rollforward_status.

Beispiele

Beispiel 1: Onlineschalten der Datenbank mit Transaktionsprotokollen

Im folgenden Beispiel wird ein Rollforward zu einem Online-Backup der Datenbank mit Transaktionsprotokollen ausgeführt und die Datenbank dann online geschaltet:

db2 "call rdsadmin.rollforward_database(
    ?,
    null,
    null,
    'END_OF_LOGS',
    'TRUE')"

Beispiel 2: Onlineschalten der Datenbank ohne Transaktionsprotokolle

Im folgenden Beispiel wird ein Rollforward zu einem Online-Backup der Datenbank ohne Transaktionsprotokolle durchgeführt und die Datenbank dann online geschaltet:

db2 "call rdsadmin.rollforward_database(
    ?,
    'TESTDB',
    'amzn-s3-demo-bucket',
    'logsfolder/,
    'END_OF_BACKUP',
    'TRUE')"

Beispiel 3: Nicht-Onlineschalten der Datenbank mit Transaktionsprotokollen

Im folgenden Beispiel wird ein Rollforward zu einem Online-Backup der Datenbank mit Transaktionsprotokollen ausgeführt und die Datenbank dann nicht online geschaltet:

db2 "call rdsadmin.rollforward_database(
    ?,
    'TESTDB',
    null,
    'onlinebackup/TESTDB',
    'END_OF_LOGS',
    'FALSE')"

Beispiel 4: Nicht-Onlineschalten der Datenbank mit zusätzlichen Transaktionsprotokollen

Im folgenden Beispiel wird ein Rollforward zu einem Online-Backup der Datenbank mit zusätzlichen Transaktionsprotokollen ausgeführt und die Datenbank dann nicht online geschaltet:

db2 "call rdsadmin.rollforward_database(
    ?,
    'TESTDB',
    'amzn-s3-demo-bucket',
    'logsfolder/S0000155.LOG',
    'END_OF_LOGS',
    'FALSE')"

rdsadmin.rollforward_status

Gibt die Ausgabe von ROLLFORWARD DATABASE database_name QUERY STATUS zurück.

Syntax

db2 "call rdsadmin.rollforward_status(
    ?,
    'database_name')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

database_name

Der Name der Datenbank, für die der Vorgang ausgeführt werden soll. Der Datentyp ist varchar.

Nutzungshinweise

Nach dem Aufrufen von rdsadmin.rollforward_database können Sie rdsadmin.rollforward_status aufrufen, um den Status des Rollforward in der Datenbank zu überprüfen.

Informationen zum Überprüfen des Status dieser gespeicherten Prozedur finden Sie unter rdsadmin.get_task_status.

rdsadmin.complete_rollforward

Schaltet die Datenbank aus dem Status ROLL-FORWARD PENDING online.

Syntax

db2 "call rdsadmin.complete_rollforward(
    ?,
    'database_name')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

database_name

Der Name der Datenbank, die Sie online schalten möchten. Der Datentyp ist varchar.

Nutzungshinweise

Wenn Sie rdsadmin.rollforward_database aufgerufen haben, wobei complete_rollforward auf FALSE festgelegt ist, befindet sich die Datenbank im Status ROLL-FORWARD PENDING und ist offline. Rufen Sie rdsadmin.complete_rollforward auf, um den Rollforward-Prozess abzuschließen und die Datenbank online zu schalten.

Informationen zum Überprüfen des Abschlussstatus des Rollforward-Prozesses finden Sie unter rdsadmin.rollforward_status.

Beispiele

Im folgenden Beispiel wird die Datenbank TESTDB online geschaltet:

db2 "call rdsadmin.complete_rollforward(
    ?,
    'TESTDB')"

rdsadmin.db2pd_command

Sammelt Informationen zu einer Datenbank von RDS für Db2.

Syntax

db2 "call rdsadmin.db2pd_command('db2pd_cmd')"

Parameter

Der folgende Eingabeparameter ist erforderlich:

db2pd_cmd

Der Name des Befehls db2pd, den Sie ausführen möchten. Der Datentyp ist varchar.

Der Parameter muss mit einem Bindestrich beginnen. Eine Liste der Parameter finden Sie in der IBM Db2-Dokumentation unter db2pd - Monitor and troubleshoot Db2 database command.

Die folgenden Optionen werden nicht unterstützt:

  • -addnode

  • -alldatabases

  • -alldbp

  • -alldbs

  • -allmembers

  • -alm_in_memory

  • -cfinfo

  • -cfpool

  • -command

  • -dbpartitionnum

  • -debug

  • -dump

  • -everything

  • -file | -o

  • -ha

  • -interactive

  • -member

  • -pages

    Anmerkung

    -pages summary wird unterstützt.

  • -pdcollection

  • -repeat

  • -stack

  • -totalmem

Die Unteroption file wird nicht unterstützt. Beispiel: db2pd -db testdb -tcbstats file=tcbstat.out.

Die Verwendung der Option stacks wird nicht unterstützt. Beispiel: db2pd -edus interval=5 top=10 stacks.

Nutzungshinweise

Mit dieser gespeicherten Prozedur werden Informationen gesammelt, die bei der Überwachung und Problembehandlung von Datenbanken von RDS für Db2 hilfreich sein können.

Die gespeicherte Prozedur verwendet das IBM-Dienstprogramm db2pd, um verschiedene Befehle auszuführen. Für das Dienstprogramm db2pd ist die Autorisierung SYSADM erforderlich, über die der Masterbenutzer von RDS für Db2 nicht verfügt. Mit der gespeicherten Amazon-RDS-Prozedur kann der Masterbenutzer das Dienstprogramm jedoch zum Ausführen verschiedener Befehle verwenden. Weitere Informationen zum Dienstprogramm finden Sie in der IBM Db2-Dokumentation unter db2pd - Monitor and troubleshoot Db2 database command.

Die Ausgabe ist auf maximal 2 GB beschränkt.

Informationen zum Überprüfen des Erfassungsstatus von Datenbankinformationen finden Sie unter rdsadmin.get_task_status.

Beispiele

Beispiel 1: Zurückgeben der Betriebszeit einer DB-Instance

Im folgenden Beispiel wird die Betriebszeit einer DB-Instance von RDS für Db2 zurückgegeben:

db2 "call rdsadmin.db2pd_command('-')"

Beispiel 2: Zurückgeben der Betriebszeit einer Datenbank

Im folgenden Beispiel wird die Betriebszeit der Datenbank TESTDB zurückgegeben:

db2 "call rdsadmin.db2pd_command('-db TESTDB -')"

Beispiel 3: Zurückgeben der Speicherauslastung einer DB-Instance

Im folgenden Beispiel wird die Speicherauslastung einer DB-Instance von RDS für Db2 zurückgegeben:

db2 "call rdsadmin.db2pd_command('-dbptnmem')"

Beispiel 4: Zurückgeben von Speichersätzen einer DB-Instance und Datenbank

Im folgenden Beispiel werden die Speichersätze einer DB-Instance von RDS für Db2 und der Datenbank TESTDB zurückgegeben:

db2 "call rdsadmin.db2pd_command('-inst -db TESTDB -memsets')"

rdsadmin.force_application

Erzwingt die Deaktivierung von Anwendungen aus einer Datenbank von RDS für Db2.

Syntax

db2 "call rdsadmin.force_application(
    ?,
    'applications')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

applications

Die Anwendungen, für die Sie die Deaktivierung aus einer Datenbank von RDS für Db2 erzwingen möchten. Der Datentyp ist varchar. Gültige Werte: ALL oder application_handle.

Trennen Sie die Namen mehrerer Anwendungen durch Kommas. Beispiel: 'application_handle_1,application_handle_2'.

Nutzungshinweise

Mit dieser gespeicherten Prozedur wird die Deaktivierung aller Anwendungen aus einer Datenbank erzwungen, sodass Sie Wartungsarbeiten durchführen können.

Die gespeicherte Prozedur verwendet den IBM-Befehl FORCE APPLICATION. Für den Befehl FORCE APPLICATION ist die Autorisierung SYSADM, SYSMAINT oder SYSCTRL erforderlich, über die der Masterbenutzer von RDS für Db2 nicht verfügt. Mit der gespeicherten Amazon-RDS-Prozedur kann der Masterbenutzer den Befehl jedoch verwenden. Weitere Informationen finden Sie in der IBM Db2-Dokumentation unter FORCE APPLICATION command.

Informationen zum Überprüfen des Status der erzwungenen Deaktivierung von Anwendungen aus einer Datenbank finden Sie unter rdsadmin.get_task_status.

Beispiele

Beispiel 1: Festlegen aller Anwendungen

Im folgenden Beispiel wird die Deaktivierung aller Anwendungen aus einer Datenbank von RDS für Db2 erzwungen.

db2 "call rdsadmin.force_application(
    ?,
    'ALL')"

Beispiel 2: Festlegen mehrerer Anwendungen

Im folgenden Beispiel wird die Deaktivierung der Anwendungs-Handles 9991, 8891 und 1192 aus einer Datenbank von RDS für Db2 erzwungen:

db2 "call rdsadmin.force_application(
    ?,
    '9991, 8891, 1192')"

rdsadmin.set_archive_log_retention

Konfiguriert den Zeitraum (in Stunden) für die Beibehaltung von Archivprotokolldateien für die angegebene Datenbank von RDS für Db2.

Syntax

db2 "call rdsadmin.set_archive_log_retention(
    ?,            
    'database_name',  
    'archive_log_retention_hours')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Die folgenden Eingabeparameter sind erforderlich:

database_name

Der Name der Datenbank, für die die Beibehaltung des Archivprotokolls konfiguriert werden soll. Der Datentyp ist varchar.

archive_log_retention_hours

Die Anzahl der Stunden, die die Archivprotokolldateien beibehalten werden sollen. Der Datentyp ist smallint. Der Standardwert ist 0 und der Höchstwert 168 (7 Tage).

Wenn der Wert 0 ist, behält Amazon RDS die Archivprotokolldateien nicht bei.

Nutzungshinweise

Standardmäßig behält RDS für Db2 Protokolle 5 Minuten lang bei. Wenn Sie Replikationstools wie AWS DMS Change Data Capture (CDC) oder verwenden, empfehlen wirIBM Q Replication, die Protokollspeicherung in diesen Tools für mehr als 5 Minuten festzulegen.

Sie können die aktuelle Einstellung für die Beibehaltung von Archivprotokollen durch Aufrufen von rdsadmin.show_archive_log_retention einsehen.

Sie können die Einstellung für die Beibehaltung von Archivprotokollen in der Datenbank rdsadmin nicht konfigurieren.

Beispiele

Beispiel 1: Festlegen des Beibehaltungszeitraums

Im folgenden Beispiel wird der Beibehaltungszeitraum des Archivprotokolls für die Datenbank TESTDB auf 24 Stunden festgelegt.

db2 "call rdsadmin.set_archive_log_retention(
    ?,
    'TESTDB', 
    '24')"

Beispiel 2: Deaktivieren des Beibehaltungszeitraums

Im folgenden Beispiel wird die Beibehaltung des Archivprotokolls für die Datenbank TESTDB deaktiviert.

db2 "call rdsadmin.set_archive_log_retention(
    ?,
    'TESTDB', 
    '0')"

rdsadmin.show_archive_log_retention

Gibt die aktuelle Einstellung für die Beibehaltung des Archivprotokolls für die angegebene Datenbank zurück.

Syntax

db2 "call rdsadmin.show_archive_log_retention(
    ?,
    'database_name')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

database_name

Der Name der Datenbank, für die die Beibehaltungseinstellung des Archivprotokolls angezeigt werden soll. Der Datentyp ist varchar.

Beispiele

Im folgenden Beispiel wird die Einstellung für die Beibehaltung des Archivprotokolls für die Datenbank TESTDB veranschaulicht.

db2 "call rdsadmin.show_archive_log_retention(
    ?,
    'TESTDB')"

rdsadmin.list_archive_log_information

Gibt Details zu den Archivprotokolldateien zurück, z. B. die Größe, das Datum und die Uhrzeit der Erstellung sowie den Namen der einzelnen Protokolldateien für die angegebene Datenbank. Außerdem wird die Gesamtspeichermenge zurückgegeben, die von den Protokolldateien in der Datenbank belegt wird.

Syntax

db2 "call rdsadmin.list_archive_log_information(
    ?,
    'database_name')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Der folgende Eingabeparameter ist erforderlich:

database_name

Der Name der Datenbank, für die die Archivprotokollinformationen aufgeführt werden sollen. Der Datentyp ist varchar.

Beispiele

Im folgenden Beispiel werden Archivprotokollinformationen für die Datenbank TESTDB zurückgegeben.

db2 "call rdsadmin.list_archive_log_information(
    ?,
    'TESTDB')"

rdsadmin.fgac_command

Führt fein abgestufte Befehle zur Zugriffskontrolle (FGAC) aus.

Syntax

db2 "call rdsadmin.fgac_command(
    ?,
    'database_name',
    'fgac_cmd')"

Parameter

Der folgende Ausgabeparameter ist erforderlich:

?

Eine Parametermarkierung, die eine Fehlermeldung ausgibt. Dieser Parameter akzeptiert nur ?.

Die folgenden Eingabeparameter sind erforderlich:

database_name

Der Name der Datenbank, für die Sie FGAC-Befehle ausführen möchten. Der Datentyp ist varchar.

fgac_cmd

Der detaillierte Zugriffskontrollbefehl, den Sie ausführen möchten. Der Datentyp ist varchar.

Die folgenden Befehle sind gültig:

  • ALTER MASK— Ändert eine bestehende Spaltenmaske in der Zugriffskontrolle für Zeilen und Spalten (RCAC).

  • ALTER PERMISSION— Ändert die Eigenschaften einer bestehenden Zeilenberechtigung in RCAC.

  • ALTER SECURITY POLICY— Ändert eine bestehende Sicherheitsrichtlinie für RCAC.

  • ALTER SECURITY LABEL— Ändert die Eigenschaften eines vorhandenen Sicherheitslabels in der Label-Based Access Control (LBAC).

  • ALTER TABLE— Ändert die Tabellenstruktur, einschließlich des Hinzufügens von RCAC- oder LBAC-Steuerelementen.

  • CREATE MASK— Erzeugt eine neue Spaltenmaske für RCAC.

  • CREATE PERMISSION— Erzeugt eine neue Zeilenberechtigung für RCAC.

  • CREATE SECURITY LABEL— Erzeugt ein neues Sicherheitslabel für LBAC.

  • CREATE SECURITY POLICY— Erstellt eine neue Sicherheitsrichtlinie für RCAC.

  • DROP MASK— Löscht eine bestehende Spaltenmaske.

  • DROP PERMISSION— Löscht eine bestehende Zeilenberechtigung.

  • DROP SECURITY LABEL— Löscht ein Sicherheitslabel von LBAC.

  • DROP SECURITY POLICY— Löscht eine bestehende RCAC-Sicherheitsrichtlinie.

  • GRANT EXEMPTION ON RULE— Ermöglicht einem Benutzer, bestimmte LBAC-Regeln zu umgehen.

  • GRANT SECURITY LABEL— Weist einem Benutzer ein LBAC-Sicherheitslabel zu.

  • REVOKE EXEMPTION ON RULE— Entfernt die Ausnahme eines Benutzers von den LBAC-Regeln.

  • REVOKE SECURITY LABEL— Entfernt ein LBAC-Sicherheitslabel von einem Benutzer.

Nutzungshinweise

Diese gespeicherte Prozedur steuert den Zugriff auf Zeilen- oder Spaltenebene auf Tabellendaten in Ihrer Datenbank auf einer RDS for Db2-DB-Instance. RDS for Db2 unterstützt zwei Arten von FGAC in der Datenbank:

  • Labelbasierte Zugriffskontrolle (LBAC)

  • Zugriffskontrolle für Zeilen und Spalten (RCAC)

Bevor Sie die gespeicherte Prozedur aufrufen, lesen Sie die folgenden Hinweise:

  • Um ein einfaches Anführungszeichen (') zu umgehen, verwenden Sie ein zusätzliches einfaches Anführungszeichen. Die folgenden Beispiele zeigen, wie man 'apple''banana', und maskiert'fruit'.

    db2 "call rdsadmin.fgac_command(
    ?,
    'testdb',
    'CREATE SECURITY LABEL COMPONENT FRUITSET SET{''apple'',''banana''}')"
    db2 "call rdsadmin.fgac_command(
    ?, 
    'testdb', 
    'CREATE SECURITY LABEL COMPONENT FRUITTREE TREE(''fruit'' ROOT, ''apple'' UNDER ''fruit'', ''banana'' UNDER ''fruit'')')"

  • Um Klammern ([]) zu umgehen, verwenden Sie einen umgekehrten Schrägstrich (\). Das folgende Beispiel zeigt, wie Sie entkommen können. [''apple'',''banana''] 

    db2 "call rdsadmin.fgac_command(
    ?, '
    testdb', 
    'CREATE SECURITY LABEL COMPONENT FRUITARRAY ARRAY\[''apple'',''banana''\]')"

Beispiele

In den folgenden Beispielen werden alle FGAC-Befehle in einer Datenbank namens ausgeführt. testdb

Beispiel 1: Erstellen einer neuen Sicherheitsbeschriftung namens FRUITSET 

db2 "call rdsadmin.fgac_command(
    ?,
    'testdb',
    'CREATE SECURITY LABEL COMPONENT FRUITSET SET{''apple'',''banana''}')"

Beispiel 2: Erstellen einer neuen Maske für die EMP_ID Spalte, die aktiviert ist, wenn sie auf weniger als drei gesetzt EMP_ID ist

db2 "call rdsadmin.fgac_command(
    ?,
    'testdb',
    'CREATE MASK id_MASK ON EMPLOYEE FOR COLUMN EMP_ID RETURN CASE WHEN (EMP_ID < 3) THEN EMP_ID ELSE NULL END ENABLE')"

Beispiel 3: Erstellen einer neuen Maske für die DEPARTMENT Spalte, die aktiviert ist, wenn auf gesetzt SESSION_USER ist security_user 

db2 "call rdsadmin.fgac_command(
    ?,
    'testdb',
    'CREATE MASK DEPARTMENT_MASK ON EMPLOYEE FOR COLUMN DEPARTMENT RETURN CASE  WHEN SESSION_USER = ''security_user'' THEN DEPARTMENT ELSE NULL END ENABLE')"

Beispiel 4: Erstellen einer neuen Sicherheitsbeschriftung namens treelabel 

db2 "call rdsadmin.fgac_command(
    ?,
    'testdb',
    'CREATE SECURITY LABEL COMPONENT treelabel  TREE(''COMPANY'' ROOT, ''HR'' UNDER ''COMPANY'', ''FINANCE'' UNDER ''COMPANY'', ''IT'' UNDER ''COMPANY'')')"