Es gibt fast genau so viele Operationen zum Ändern von Datenbanken wie beim Erstellen von Datenbanken. Diese Operationen aktualisieren oder löschen Aspekte der zuvor erstellten Datenbank. Dazu gehören:
Obwohl einige Objekte in einer Datenbank geändert werden können, kann die Datenbank selbst nicht geändert werden: sie muß gelöscht und neu erstellt werden. Das Löschen einer Datenbank kann weitreichende Auswirkungen haben, da alle Objekte der Datenbank, Behälter und zugehörige Dateien gelöscht werden. Die gelöschte Datenbank wird aus den Datenbankverzeichnissen entfernt (entkatalogisiert).
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Datenbank zu
löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um eine Datenbank zu löschen:
DROP DATABASE <name>
Mit dem folgenden Befehl wird die Beispieldatenbank SAMPLE gelöscht:
DROP DATABASE SAMPLE
Anmerkung: | Wenn Sie beabsichtigen, das Experimentieren mit der Beispieldatenbank SAMPLE fortzusetzen, löschen Sie sie nicht. Wenn Sie die Beispieldatenbank SAMPLE gelöscht haben, sie jedoch erneut benötigen, können Sie sie erneut erstellen. |
Detaillierte Informationen zum Ändern einer Knotengruppe finden Sie in Kapitel 29, Skalieren der Konfiguration über das Hinzufügen von Prozessoren.
Wenn Sie Knoten hinzufügen oder löschen, müssen Sie die aktuellen Daten auf die neuen Knoten in der Knotengruppe verteilen. Führen Sie dazu den Befehl REDISTRIBUTE NODEGROUP aus. Weitere Informationen zu diesem Thema finden Sie in Kapitel 30, Umverteilen von Daten auf Datenbankpartitionen. Lesen Sie außerdem die entsprechenden Informationen im Handbuch Command Reference.
Wenn Sie eine Datenbank erstellen, werden mindestens drei Tabellenbereiche erstellt: ein Katalogtabellenbereich (SYSCATSPACE), ein Benutzertabellenbereich (mit dem Standardnamen USERSPACE1) und ein temporärer Systemtabellenbereich (mit dem Namen TEMPSPACE1). Sie müssen mindestens jeweils einen dieser Tabellenbereiche beibehalten und können weitere Benutzertabellenbereiche und temporäre Tabellenbereiche nach Wunsch hinzufügen.
Anmerkung: | Sie können den Katalogtabellenbereich SYSCATSPACE nicht löschen, da immer mindestens ein temporärer Systemtabellenbereich vorhanden sein muß. Nach der Erstellung können auch die Seitengröße und die Speicherbereichsgröße eines Tabellenbereichs nicht mehr geändert werden. |
In diesem Abschnitt werden folgende Operationen zur Änderung von Tabellenbereichen behandelt:
Informationen zum Entwurf von Tabellenbereichen finden Sie in Entwerfen und Auswählen von Tabellenbereichen.
Sie können die Größe eines DMS-Tabellenbereichs (d. h. eines mit der Klausel MANAGED BY DATABASE erstellten Tabellenbereichs) erhöhen, indem Sie dem Tabellenbereich einen oder mehrere Behälter hinzufügen.
Der Inhalt des Tabellenbereichs wird auf alle Behälter neu gleichmäßig verteilt. Während dieser Neuverteilung wird der Zugriff auf den Tabellenbereich nicht eingeschränkt. Wenn mehr als ein Behälter hinzugefügt werden muß, sollten diese Behälter gleichzeitig hinzugefügt werden.
Gehen Sie wie folgt vor, um mit der Steuerzentrale einen Behälter zu einem
DMS-Tabellenbereich hinzuzufügen:
|
Geben Sie in der Befehlszeile folgendes ein, um einen Behälter zu einem DMS-Tabellenbereich hinzuzufügen:
ALTER TABLESPACE <name> ADD (DEVICE '<pfad>' <größe>)
Das folgende Beispiel erläutert das Hinzufügen von zwei neuen Einheitenbehältern (mit jeweils 10 000 Seiten) zu einem Tabellenbereich auf einem UNIX-System.
ALTER TABLESPACE RESOURCE ADD (DEVICE '/dev/rhd9' 10000, DEVICE '/dev/rhd10' 10000)
Beachten Sie, daß die Anweisung ALTER TABLESPACE es ermöglicht, auch andere Merkmale des Tabellenbereichs, die sich auf die Leistung auswirken können, zu ändern. Weitere Informationen finden Sie in Auswirkung des Tabellenbereichs auf die Abfrageoptimierung.
Sie können die Größe von Behältern in einem DMS-Tabellenbereich (d. h. einem mit der Klausel MANAGED BY DATABASE erstellten Tabellenbereich) erhöhen, indem Sie die Größe von einem oder mehreren Behältern anpassen oder einen oder mehrere dem Tabellenbereich zugeordnete Behälter erweitern.
Geben Sie in der Befehlszeile folgendes ein, um die Größe eines oder mehrerer Behälter in einem DMS-Tabellenbereich anzupassen:
ALTER TABLESPACE <name> RESIZE (DEVICE '<pfad>' <größe>)
Das folgende Beispiel erläutert das Erhöhen der Größe von zwei Einheitenbehältern (denen bereits 1 000 Seiten zugeordnet wurden) in einem Tabellenberich auf einem UNIX-System:
ALTER TABLESPACE HISTORY RESIZE (DEVICE '/dev/rhd7' 2000, DEVICE '/dev/rhd8' 2000)
Durch diese Aktion wurde die Größe der Einheitenbehälter von 1 000 Seiten auf 2 000 Seiten erhöht. Ähnlich wie beim Hinzufügen neuer Behälter wird der Inhalt des Tabellenbereichs auf alle verfügbaren Behälter neu gleichmäßig verteilt. Während dieser Neuverteilung wird der Zugriff auf den Tabellenbereich nicht eingeschränkt.
Geben Sie in der Befehlszeile folgendes ein, um einen oder mehrere Behälter in einem DMS-Tabellenbereich zu erweitern:
ALTER TABLESPACE <name> EXTEND (DEVICE '<pfad>' <größe>)
Das folgende Beispiel erläutert das Erhöhen der Größe von zwei Einheitenbehältern (denen bereits 1 000 Seiten zugeordnet wurden) in einem Tabellenberich auf einem UNIX-System:
ALTER TABLESPACE HISTORY EXTEND (DEVICE '/dev/rhd11' 1000, DEVICE '/dev/rhd12' 1000)
Durch diese Aktion wurde die Größe der Einheitenbehälter von 1 000 Seiten auf 2 000 Seiten erhöht. Ähnlich wie beim Hinzufügen neuer Behälter wird der Inhalt des Tabellenbereichs auf alle verfügbaren Behälter neu gleichmäßig verteilt. Während dieser Neuverteilung wird der Zugriff auf den Tabellenbereich nicht eingeschränkt.
Anmerkung: | Sie können die Größe der Behälter nicht reduzieren. |
Beachten Sie, daß die Anweisung ALTER TABLESPACE es ermöglicht, auch andere Merkmale des Tabellenbereichs, die sich auf die Leistung auswirken können, zu ändern. Weitere Informationen finden Sie in Auswirkung des Tabellenbereichs auf die Abfrageoptimierung.
Sie können einem vorhandenen Tabellenbereich einen neuen Namen zuordnen, ohne daß sich dies auf die einzelnen Objekte innerhalb des Tabellenbereichs auswirkt. Beim Umbenennen eines Tabellenbereichs werden alle Katalogsätze, die auf diesen Tabellenbereich verweisen, geändert.
Der Tabellenbereich SYSCATSPACE kann nicht umbenannt werden.
Tabellenbereiche, die sich im Status "Aktualisierende Wiederherstellung anstehend" oder "Aktualisierende Wiederherstellung wird ausgeführt" befinden, können nicht umbenannt werden.
Beim Zurückschreiben eines Tabellenbereichs, der seit seiner Sicherung umbenannt wurde, müssen Sie im Befehl RESTORE DATABASE den neuen Tabellenbereichsnamen verwenden. Wenn Sie den vorherigen Tabellenbereichsnamen benutzen, kann der Tabellenbereich nicht lokalisiert werden. Wenn Sie für den Tabellenbereich mit dem Befehl ROLLFORWARD DATABASE eine aktualisierende Wiederherstellung durchführen, müssen Sie ebenfalls den neuen Namen verwenden. Wenn Sie den vorherigen Tabellenbereichsnamen benutzen, kann der Tabellenbereich nicht lokalisiert werden.
Beim Löschen eines Benutzertabellenbereichs werden alle Daten in diesem Tabellenbereich gelöscht, die Behälter freigegeben, die Katalogeinträge entfernt und alle Objekte, die in dem Tabellenbereich definiert sind, entweder gelöscht oder als ungültig markiert.
Die Behälter in einem leeren Tabellenbereich können erneut verwendet werden, indem der Tabellenbereich gelöscht wird. Allerdings muß der Befehl DROP TABLESPACE mit COMMIT festgeschrieben werden, bevor Sie versuchen, die Behälter erneut zu verwenden.
Sie können einen Benutzertabellenbereich löschen, der sämtliche Tabellendaten einschließlich Index- und LOB-Daten dieses einen Benutzertabellenbereichs enthält. Sie können auch einen Benutzertabellenbereich löschen, der Tabellen beinhaltet, die sich über mehrere Tabellenbereiche erstrecken. Dabei können sich die Tabellendaten in einem Tabellenbereich, die Indizes in einem anderen Tabellenbereich und die LOB-Daten in einem dritten Tabellenbereich befinden. Sie können diese Tabellenbereiche einzeln löschen, sofern der Tabellenbereich mit den Tabellendaten als erstes gelöscht wird. Sie können die drei Tabellenbereiche aber auch gleichzeitig mit einer einzigen Anweisung löschen. Wenn sich Tabellen über mehrere Tabellenbereiche erstrecken, muß die Löschanweisung alle Tabellenbereiche enthalten, auf die sich diese Tabellen erstrecken, sonst kann sie nicht erfolgreich ausgeführt werden. Einzelheiten zum Löschen von Tabellenbereichen, die verteilte Tabellendaten enthalten, finden Sie im Handbuch SQL Reference.
Gehen Sie wie folgt vor, um mit der Steuerzentrale einen
Benutzertabellenbereich zu löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um einen Benutzertabellenbereich zu löschen:
DROP TABLESPACE <name>
Mit der folgenden SQL-Anweisung wird der Tabellenbereich ACCOUNTING gelöscht:
DROP TABLESPACE ACCOUNTING
Sie können einen temporären Systemtabellenbereich nur löschen, wenn Sie zuvor einen anderen temporären Systemtabellenbereich erstellt haben, da die Datenbank immer über mindestens einen temporären Systemtabellenbereich verfügen muß. Wenn Sie z. B. einen Behälter zu einem temporären SMS-Tabellenbereich hinzufügen wollen, müssen Sie zuerst einen neuen temporären Systemtabellenbereich hinzufügen und erst dann den alten temporären Systemtabellenbereich löschen.
Gehen Sie wie folgt vor, um mit der Steuerzentrale einen
Systemtabellenbereich zu löschen:
|
Wenn Sie nur über einen temporären Systemtabellenbereich verfügen, müssen Sie vor dem Löschen dieses Tabellenbereichs einen neuen erstellen. Hierzu können Sie in der Befehlszeile folgendes eingeben:
CREATE SYSTEM TEMPORARY TABLESPACE <name> MANAGED BY SYSTEM USING ('<einheit>')
Geben Sie anschließend zum Löschen eines Systemtabellenbereichs in der Befehlszeile folgendes ein:
DROP TABLESPACE <name>
Mit der folgenden SQL-Anweisung können Sie einen neuen temporären Systemtabellenbereich mit dem Namen TEMPSPACE2 erstellen:
CREATE SYSTEM TEMPORARY TABLESPACE TEMPSPACE2 MANAGED BY SYSTEM USING ('d')
Nach der Erstellung von TEMPSPACE2 können Sie den ursprünglichen temporären Systemtabellenbereich TEMPSPACE1 mit dem folgenden Befehl löschen:
DROP TABLESPACE TEMPSPACE1
Die Behälter in einem leeren Tabellenbereich können erneut verwendet werden, indem der Tabellenbereich gelöscht wird. Allerdings muß der Befehl DROP TABLESPACE mit COMMIT festgeschrieben werden, bevor Sie versuchen, die Behälter erneut zu verwenden.
Ein temporärer Benutzertabellenbereich kann nur gelöscht werden, wenn in diesem Tabellenbereich momentan keine deklarierten temporären Tabellen definiert sind. Wenn Sie den Tabellenbereich löschen, wird nicht versucht, alle deklarierten temporären Tabellen dieses Tabellenbereichs zu löschen.
Anmerkung: | Eine deklarierte temporäre Tabelle wird implizit gelöscht, wenn die Anwendung, die zur Deklaration verwendet wurde, die Verbindung zur Datenbank trennt. |
Bevor Sie ein Schema löschen, müssen alle Objekte, die sich in diesem Schema befinden, selbst gelöscht oder in ein anderes Schema versetzt werden. Der Schemenname muß im Katalog vorhanden sein, wenn die Anweisung DROP ausgeführt wird. Ansonsten wird ein Fehler zurückgegeben.
Gehen Sie wie folgt vor, um mit der Steuerzentrale ein Schema zu
löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um ein Schema zu löschen:
DROP SCHEMA <name>
Im folgenden Beispiel wird das Schema "joeschma" gelöscht:
DROP SCHEMA joeschma RESTRICT
Das Schlüsselwort RESTRICT erzwingt die Anwendung der Regel, daß im angegebenen Schema keine Objekte für das Schema definiert werden können, das aus der Datenbank gelöscht werden soll.
Zum Modifizieren von Struktur und Inhalt einer Tabelle sind unter anderem folgende Tasks erforderlich:
Beachten Sie, daß Sie keine Auslöser für Tabellen ändern können. Sie müssen einen Auslöser, der nicht mehr geeignet ist, löschen (siehe Löschen eines Auslösers) und den neuen Auslöser hinzufügen (siehe Erstellen eines Auslösers).
Zu einer Spaltendefinition gehören ein Spaltenname, ein Datentyp und alle nötigen Integritätsbedingungen.
Wenn eine neue Spalte einer vorhandenen Tabelle hinzugefügt wird, wird nur die Tabellenbeschreibung im Systemkatalog geändert, so daß die Zugriffszeit für die Tabelle nicht sofort betroffen ist. Vorhandene Datensätze werden physisch nicht geändert. Sie werden erst geändert, wenn eine Anweisung UPDATE ausgeführt wird. Beim Abrufen einer vorhandenen Zeile aus der Tabelle wird für die neue Spalte ein Nullwert oder der Standardwert bereitgestellt, je nachdem, wie die neue Spalte definiert wurde. Spalten, die nach Erstellung einer Tabelle hinzugefügt werden, können nicht mit NOT NULL definiert werden: Sie müssen entweder mit NOT NULL WITH DEFAULT oder mit der Angabe, daß Nullwerte möglich sind, definiert werden.
Gehen Sie wie folgt vor, um in der Steuerzentrale Spalten zu einer
vorhandenen Tabelle hinzuzufügen:
|
Geben Sie in der Befehlszeile folgendes ein, um Spalten zu einer vorhandenen Tabelle hinzuzufügen:
ALTER TABLE <tabellenname> ADD <spaltenname> <datentyp> <nullattribut>
Spalten können mit einer SQL-Anweisung hinzugefügt werden. Im folgenden Beispiel wird die Anweisung ALTER TABLE verwendet, um der Tabelle EMPLOYEE drei Spalten hinzuzufügen:
ALTER TABLE EMPLOYEE ADD MIDINIT CHAR(1) NOT NULL WITH DEFAULT ADD HIREDATE DATE ADD WORKDEPT CHAR(3)
Sie können die Merkmale einer Spalte durch Erhöhen der Länge einer vorhandenen VARCHAR-Spalte ändern. Die Anzahl der Zeichen kann bis zu einem Maximalwert erhöht werden, der von der verwendeten Seitengröße abhängt.
Gehen Sie wie folgt vor, um in der Steuerzentrale Spalten einer vorhandenen
Tabelle zu modifizieren:
|
Geben Sie in der Befehlszeile folgendes ein, um Spalten einer vorhandenen Tabelle zu modifizieren:
ALTER TABLE ALTER COLUMN <spaltenname> <modifikationstyp>
Mit der folgenden Anweisung können Sie zum Beispiel die Zeichenzahl einer Spalte auf bis zu 4.000 Zeichen erhöhen.
ALTER TABLE ALTER COLUMN COLNAM1 SET DATA TYPE VARCHAR(4000)
Sie können die Spalte einer typisierten Tabelle nicht ändern. Sie können einer vorhandenen Verweisartspalte ohne definierten Bereich jedoch einen Bereich hinzufügen. Beispiel:
ALTER TABLE ALTER COLUMN COLNAMT1 ADD SCOPE TYPTAB1
Weitere Informationen zur Anweisung ALTER TABLE finden Sie im Handbuch SQL Reference.
Integritätsbedingungen können nur durch Löschen und Hinzufügen neuer Bedingungen an ihrer Stelle geändert werden. Weitere Informationen hierzu enthalten die folgenden Abschnitte:
Weitere Informationen zu Integritätsbedingungen finden Sie in Definieren von Integritätsbedingungen.
Integritätsbedingungen werden mit der Anweisung ALTER TABLE hinzugefügt. Weitere Informationen zu dieser Anweisung, einschließlich Syntax, finden Sie im Handbuch SQL Reference.
Weitere Informationen zu Integritätsbedingungen finden Sie in Definieren von Integritätsbedingungen.
Eindeutige Integritätsbedingungen können einer vorhandenen Tabelle hinzugefügt werden. Der Name der Integritätsbedingung darf nicht mit dem Namen einer anderen Integritätsbedingung innerhalb dieser Anweisung ALTER TABLE übereinstimmen, und muß innerhalb der Tabelle eindeutig sein (dies schließt auch Namen bereits definierter referentieller Integritätsbedingungen mit ein). Vorhandene Daten werden anhand der neuen Bedingung überprüft, bevor die Anweisung erfolgreich beendet wird.
Mit der folgenden SQL-Anweisung wird der Tabelle EMPLOYEE eine eindeutige Integritätsbedingung hinzugefügt, die eine neue Methode zur eindeutigen Identifizierung von Mitarbeitern in der Tabelle darstellt:
ALTER TABLE EMPLOYEE ADD CONSTRAINT NEWID UNIQUE(EMPNO,HIREDATE)
Beim Hinzufügen von Integritätsbedingungen für umfangreiche Tabellen ist es effizienter, die Tabelle in den Status "Überprüfung anstehend" (Check pending) zu setzen, die Integritätsbedingungen hinzuzufügen und anschließend die Tabelle überprüfen und eine konsolidierte Liste der die Bedingungen verletzenden Zeilen erstellen zu lassen. Verwenden Sie die Anweisung SET INTEGRITY, um den Status "Überprüfung anstehend" explizit festzulegen: Ist die Tabelle eine übergeordnete Tabelle, wird der Status "Überprüfung anstehend" implizit auch für alle abhängigen und untergeordneten Tabellen aktiviert.
Gehen Sie wie folgt vor, um mit der Steuerzentrale Primärschlüssel
hinzuzufügen:
|
Geben Sie in der Befehlszeile folgendes ein, um Primärschlüssel hinzuzufügen:
ALTER TABLE <name> ADD CONSTRAINT <spaltenname> PRIMARY KEY <spaltenname>
Wenn ein Fremdschlüssel einer Tabelle hinzugefügt wird, werden Pakete und im Cache zwischengespeicherte dynamische SQL-Anweisungen, die folgende Arten von Anweisungen enthalten, eventuell als ungültig markiert:
Weitere Informationen finden Sie in Anweisungsabhängigkeiten beim Ändern von Objekten.
Gehen Sie wie folgt vor, um mit der Steuerzentrale Fremdschlüssel
hinzuzufügen:
|
Geben Sie in der Befehlszeile folgendes ein, um Fremdschlüssel hinzuzufügen:
ALTER TABLE <name> ADD CONSTRAINT <spaltenname> FOREIGN KEY <spaltenname> ON DELETE <aktionsart> ON UPDATE <aktionsart>
Die folgenden Beispiele zeigen die Verwendung der Anweisung ALTER TABLE zum Hinzufügen von Primär- und Fremdschlüsseln in einer Tabelle:
ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_KEY PRIMARY KEY (PROJNO) ALTER TABLE EMP_ACT ADD CONSTRAINT ACTIVITY_KEY PRIMARY KEY (EMPNO, PROJNO, ACTNO) ADD CONSTRAINT ACT_EMP_REF FOREIGN KEY (EMPNO) REFERENCES EMPLOYEE ON DELETE RESTRICT ADD CONSTRAINT ACT_PROJ_REF FOREIGN KEY (PROJNO) REFERENCES PROJECT ON DELETE CASCADE
Prüfungen auf Integritätsbedingungen können einer existierenden Tabelle mit Hilfe der Anweisung ALTER TABLE hinzugefügt werden. Der Name der Integritätsbedingung darf nicht mit dem Namen einer anderen Integritätsbedingung innerhalb dieser Anweisung ALTER TABLE übereinstimmen, und muß innerhalb der Tabelle eindeutig sein (dies schließt auch Namen bereits definierter referentieller Integritätsbedingungen mit ein). Vorhandene Daten werden anhand der neuen Bedingung überprüft, bevor die Anweisung erfolgreich beendet wird.
Beim Hinzufügen von Integritätsbedingungen für umfangreiche Tabellen ist es effizienter, die Tabelle in den Status "Überprüfung anstehend" (Check pending) zu setzen, die Integritätsbedingungen hinzuzufügen und anschließend die Tabelle überprüfen und eine konsolidierte Liste der die Bedingungen verletzenden Zeilen erstellen zu lassen. Verwenden Sie die Anweisung SET INTEGRITY, um den Status "Überprüfung anstehend" explizit festzulegen: Ist die Tabelle eine übergeordnete Tabelle, wird der Status "Überprüfung anstehend" implizit auch für alle abhängigen und untergeordneten Tabellen aktiviert.
Wenn eine Prüfung auf Integritätsbedingung in einer Tabelle hinzugefügt wird, werden Pakete und im Cache zwischengespeicherte dynamische SQL-Anweisungen, die INSERT- oder UPDATE-Operationen für die Tabelle ausführen, eventuell als ungültig markiert. Der Abschnitt Anweisungsabhängigkeiten beim Ändern von Objekten enthält weitere Informationen.
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Prüfung auf
Integritätsbedingungen in Tabellen hinzuzufügen:
|
Geben Sie in der Befehlszeile folgendes ein, um eine Prüfung auf Integritätsbedingungen in Tabellen hinzuzufügen:
ALTER TABLE <name> ADD CONSTRAINT <name> (<integritätsbedingung>)
Mit der folgenden SQL-Anweisung wird der Tabelle EMPLOYEE eine Integritätsbedingung hinzugefügt, die festlegt, daß das Gehalt (SALARY) plus Provision (COMM) für jeden Mitarbeiter mehr als 25.000 US-Dollar betragen muß:
ALTER TABLE EMPLOYEE ADD CONSTRAINT REVENUE CHECK (SALARY + COMM > 25000)
Integritätsbedingungen werden mit der Anweisung ALTER TABLE gelöscht. Weitere Informationen zu dieser Anweisung, einschließlich Syntax, finden Sie im Handbuch SQL Reference.
Weitere Informationen zu Integritätsbedingungen finden Sie in Definieren von Integritätsbedingungen.
Sie können eine eindeutige Integritätsbedingung explizit mit der Anweisung ALTER TABLE löschen. Die Namen aller eindeutigen Integritätsbedingungen für eine Tabelle befinden sich in der Systemkatalogsicht SYSCAT.INDEXES.
Mit der folgenden SQL-Anweisung wird die eindeutige Integritätsbedingung NEWID aus der Tabelle EMPLOYEE gelöscht:
ALTER TABLE EMPLOYEE DROP UNIQUE NEWID
Durch das Löschen dieser eindeutigen Integritätsbedingung werden alle Pakete und im Cache zwischengespeicherte dynamische SQL-Anweisungen ungültig gemacht, die diese Integritätsbedingung verwendet haben.
Gehen Sie wie folgt vor, um mit der Steuerzentrale einen Primärschlüssel zu
löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um einen Primärschlüssel zu löschen:
ALTER TABLE <name> DROP PRIMARY KEY
Wenn eine Integritätsbedingung über Fremdschlüssel gelöscht wird, werden Pakete oder im Cache zwischengespeicherte SQL-Anweisungen, die folgende Arten von Anweisungen enthalten, eventuell als ungültig markiert:
Der Abschnitt Anweisungsabhängigkeiten beim Ändern von Objekten enthält weitere Informationen.
Gehen Sie wie folgt vor, um mit der Steuerzentrale einen Fremdschlüssel zu
löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um einen Fremdschlüssel zu löschen:
ALTER TABLE <name> DROP FOREIGN KEY <fremdschlüsselname>
Im folgenden Beispiel werden die Klauseln DROP PRIMARY KEY und DROP FOREIGN KEY in der Anweisung ALTER TABLE verwendet, um Primär- und Fremdschlüssel zu löschen:
ALTER TABLE EMP_ACT DROP PRIMARY KEY DROP FOREIGN KEY ACT_EMP_REF DROP FOREIGN KEY ACT_PROJ_REF ALTER TABLE PROJECT DROP PRIMARY KEY
Weitere Informationen zur Anweisung ALTER TABLE finden Sie im Handbuch SQL Reference.
Eine Prüfung auf Integritätsbedingung in einer Tabelle (Table Check Constraint) kann explizit mit Hilfe einer Anweisung ALTER TABLE gelöscht oder geändert werden, oder implizit als Ergebnis einer Anweisung DROP TABLE gelöscht werden.
Durch das Löschen einer Prüfung auf Integritätsbedingung in einer Tabelle werden alle Pakete und im Cache zwischengespeicherte dynamische SQL-Anweisungen mit INSERT- oder UPDATE-Abhängigkeiten für die Tabelle ungültig gemacht. (Weitere Informationen dazu finden Sie in Anweisungsabhängigkeiten beim Ändern von Objekten.) Die Namen aller Prüfungen auf Integritätsbedingungen in einer Tabelle können mit Hilfe der Katalogsicht SYSCAT.CHECKS festgestellt werden. Vor dem Löschen einer Prüfung auf Integritätsbedingungen in einer Tabelle, die einen vom System generierten Namen hat, können Sie den Namen aus der Katalogsicht SYSCAT.CHECKS abfragen.
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Prüfung auf
Integritätsbedingungen in Tabellen zu löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um eine Prüfung auf Integritätsbedingungen in Tabellen zu löschen:
ALTER TABLE <tabellenname> DROP CHECK <name_der_prüfung_auf_integritätsbedingung>
Mit der folgenden SQL-Anweisung wird die Prüfung auf Integritätsbedingung REVENUE aus der Tabelle EMPLOYEE gelöscht:
ALTER TABLE EMPLOYEE DROP CHECK REVENUE
Eine generierte Spalte wird in einer Basistabelle definiert, bei der der gespeicherte Wert mit Hilfe eines Ausdrucks ermittelt wird, anstatt mit einer Einfüge- oder Aktualisierungsoperation angegeben zu werden. Eine generierte Spalte kann erstellt werden, wenn eine Tabelle erstellt oder eine bereits vorhandene Tabelle modifiziert wird.
Führen Sie die folgenden Schritte aus, um eine generierte Spalte zu definieren:
SET INTEGRITY FOR t1 OFF
ALTER TABLE t1 ADD COLUMN c3 DOUBLE GENERATED ALWAYS AS (c1 + c2), ADD COLUMN c4 GENERATED ALWAYS AS (CASE WHEN c1 > c3 THEN 1 ELSE NULL END))
COMMIT
Anschließend müssen Sie das Dienstprogramm db2gncol verwenden, um die generierten Spalten zu definieren. Dieses Dienstprogramm ist im Verzeichnis sqllib im Unterverzeichnis bin gespeichert. Verwenden Sie das Dienstprogramm folgendermaßen:
db2gncol -d <dbname> -s <schema> -t <tabellenname> -c <commit_zähler>
Die Variable dbname gibt hierbei einen Aliasnamen für die Datenbank an, in der sich die Tabelle befindet. Die Variable schema steht für den Schemennamen der Tabelle. Bei der Eingabe dieses Namens muß die Groß-/Kleinschreibung beachtet werden. Die Variable tabellenname gibt die Tabelle an, für die neue Werte für die mit Hilfe entsprechender Ausdrücke generierten Spalten berechnet werden müssen. Sowohl bei der Eingabe von Werten für schema als auch für tabellenname muß die Groß-/Kleinschreibung beachtet werden. Die Variable commit_zähler gibt die Anzahl der Zeilen an, die zwischen zwei internen COMMIT-Operationen zur Bereinigung der Protokolle verarbeitet werden sollen. Dieser Parameter beeinflußt die Größe des Speicherplatzes für die Protokollierung, der für das Generieren der Spaltenwerte benötigt wird.
Es gibt außerdem zwei wahlfreie Parameter, die im o. a. Beispiel nicht enthalten sind. Die Parameter -u <benutzername> und -p <kennwort> dienen zur Identifizierung des Benutzers sowie des zugehörigen Kennworts. Der Benutzer muß über die Berechtigung SYSADM oder DBADM verfügen. Wurden kein Benutzer und kein Kennwort identifiziert, wird die aktuelle Benutzer-ID verwendet.
Geben Sie folgendes ein, um den Hilfetext für dieses Dienstprogramm aufzurufen:
db2gncol -h
Wenn der Hilfeparameter verwendet wird, werden alle anderen Parameter ignoriert.
Die Tabelle wird für den gesamten Prozeß gesperrt, obwohl sie sich im Status 'Überprüfung anstehend' befindet. Die Tabelle wird gesperrt, weil auch andere Dienstprogramme, die auf Tabellen zugreifen können, sich im Status 'Überprüfung anstehend' befinden. Durch die Sperre können Konflikte mit diesen anderen Dienstprogrammen vermieden werden.
SET INTEGRITY FOR t1 IMMEDIATE CHECKED FORCE GENERATED
Anmerkung: | Zu diesem Zeitpunkt können auch Ausnahmetabellen verwendet werden. |
LOCK TABLE t1
SET INTEGRITY FOR t1 ALL IMMEDIATE UNCHECKED
UPDATE t1 SET (c3, c4) = (DEFAULT, DEFAULT) WHERE <prädikat>
SET INTEGRITY FOR t1 OFF SET INTEGRITY FOR t1 IMMEDIATE CHECKED
COMMIT
ALTER TABLE t1 ACTIVATE NOT LOGGED INITIALLY
SET INTEGRITY FOR t1 IMMEDIATE CHECKED FORCE GENERATION
COMMIT
Die Werte für die generierten Spalten können auch einfach geprüft werden, indem der Ausdruck so angewendet wird, als ob es sich um eine Gleichheitsprüfung auf Integritätsbedingungen handelt:
SET INTEGRITY FOR t1 IMMEDIATE CHECKED
Wenn die Werte z. B. mit LOAD in einer generierten Spalte plaziert wurden, und Sie wissen, daß die Werte mit dem generierten Ausdruck übereinstimmen, kann für die Tabelle der Status 'Überprüfung anstehend' inaktiviert werden, ohne die Werte zu prüfen oder zuzuordnen:
SET INTEGRITY FOR t1 GENERATED COLUMN IMMEDIATE UNCHECKED
Generierte Spalten können nur für Datentypen definiert werden, für die der Vergleichsoperator 'gleich' definiert ist. Die ausgeschlossenen Datentypen für die generierten Spalten sind die strukturierten Typen, LOBs, CLOBs, DBCLOBs, LONG VARCHAR, LONG VARGRAPHIC sowie benutzerdefinierte Typen, die unter Verwendung derselben ausgeschlossenen Datentypen definiert wurden.
Generierte Spalten können in Integritätsbedingungen, eindeutigen Indizes, referentiellen Integritätsbedingungen, Primärschlüsseln und globalen temporären Tabellen nicht verwendet werden. Eine mit LIKE erstellte Tabelle mit gespeicherten Sichten kann die Merkmale generierter Spalten nicht übernehmen.
Generierte Spalten können ohne das Schlüsselwort DEFAULT nicht eingefügt oder aktualisiert werden. Beim Einfügen verhindert die Verwendung von DEFAULT, daß die Spalten in der Spaltenliste numeriert werden müssen. Statt dessen können generierte Spalten in der Werteliste auf DEFAULT gesetzt werden. Beim Aktualisieren ermöglicht DEFAULT die erneute Berechnung der generierten Spalten, die mit SET INTEGRITY ohne Prüfung in den Online-Modus versetzt wurden.
Die Verarbeitungsreihenfolge von Auslösern macht es erforderlich, daß Vorauslöser (BEFORE) in den Kopfdaten (vor der Aktualisierung) und im Hauptteil keine Verweise auf generierte Spalten enthalten. In der Verarbeitungsreihenfolge stehen generierte Spalten nach den Vorauslösern (BEFORE).
Das Dienstprogramm db2look kann die Prüfungen auf Integritätsbedingungen, die von einer generierten Spalte erzeugt werden, nicht erkennen.
Bei der Replikation darf die Zieltabelle in der Zuordnung keine generierten Spalten verwenden. Es gibt hierbei zwei Auswahlmöglichkeiten:
Beim Arbeiten mit generierten Spalten gelten verschiedene Einschränkungen:
Eine flüchtige Tabelle ist als Tabelle definiert, deren Inhalt zwischen leer und sehr umfangreich schwanken kann. Die Flüchtigkeit bzw. extreme Veränderbarkeit dieser Tabellenart macht die von RUNSTATS gesammelten Statistikdaten relativ unzuverlässig. Statistikdaten werden zu einem bestimmten Zeitpunkt gesammelt und spiegeln nur diesen Zeitpunkt wider. Das Generieren eines Zugriffsplans, der eine flüchtige Tabelle verwendet, kann zu einem fehlerhaften oder unzureichenden Zugriffsplan führen. Wenn zum Beispiel Statistikdaten gesammelt werden, während die flüchtige Tabelle leer ist, wählt das Optimierungsprogramm vorzugsweise die Tabellensuche als Zugriffsverfahren für die flüchtige Tabelle aus und nicht die Indexsuche.
Um dies zu verhindern, kann es sinnvoll sein, die Tabelle mit Hilfe der Anweisung ALTER TABLE als "flüchtig" zu deklarieren. Wenn die Tabelle als "flüchtig" deklariert ist, verwendet das Optimierungsprogramm vorzugsweise die Indexsuche und nicht die Tabellensuche. Zugriffspläne, die als flüchtig deklarierte Tabellen verwenden, sind nicht von den vorhandenen Statistikdaten für diese Tabellen abhängig.
Gehen Sie wie folgt vor, um eine Tabelle mit der Steuerzentrale als
'flüchtig' zu deklarieren:
|
Geben Sie in der Befehlszeile folgendes ein, um eine Tabelle als 'flüchtig' zu deklarieren:
ALTER TABLE <tabellenname> VOLATILE CARDINALITY
Mit Hilfe der folgenden Anweisung können Sie eine Tabelle als "flüchtig" deklarieren:
ALTER TABLE TABLENAME VOLATILE CARDINALITY
Partitionierungsschlüssel können nur in Tabellen in Knotengruppen mit einer Einzelpartition geändert werden. Löschen Sie als erstes den vorhandenen Partitionierungsschlüssel und erstellen Sie anschließend einen anderen.
Mit der folgenden SQL-Anweisung wird der Partitionierungsschlüssel MIX_INT aus der Tabelle MIXREC gelöscht:
ALTER TABLE MIXREC DROP PARTITIONING KEY
Weitere Informationen zur Anweisung ALTER TABLE finden Sie im Handbuch SQL Reference.
Der Partitionierungsschlüssel einer Tabelle in einer Knotengruppe mit mehreren Datenbankpartitionen kann nicht gelöscht werden. Wenn Sie versuchen, ihn zu löschen, wird ein Fehler zurückgegeben.
Führen Sie eine der folgenden Operationen aus, um den Partitionierungsschlüssel in Knotengruppen mit mehreren Datenbankpartitionen zu ändern:
Keine dieser Methoden ist für große Datenbanken praktikabel. Daher ist es wichtig, den geeigneten Partitionierungsschlüssel vor der Implementierung des Entwurfs großer Datenbanken zu definieren.
Es kann Gründe geben, aus denen Tabellenattribute wie die Option zur Datenerfassung (Data Capture), der Prozentsatz freien Speicherbereichs auf jeder Seite (PCTFREE), die Größe der Sperren (Lock Size) oder der Anfügemodus (Append) geändert werden sollten.
Die Größe des Speicherbereichs, der auf jeder Seite einer Tabelle freizulassen ist, wird durch den Wert für PCTFREE angegeben und spielt eine wichtige Rolle bei der effektiven Verwendung von Clustering-Indizes. Der Betrag, der anzugeben ist, hängt von der Art der vorhandenen Daten und von den zu erwartenden zukünftigen Daten ab. Der Wert für PCTFREE wird von den Dienstprogrammen LOAD und REORG beachtet, jedoch von INSERT-, UPDATE- und IMPORT-Aktivitäten ignoriert.
Durch Angeben eines größeren Werts für PCTFREE bleibt das Clustering länger erhalten. Allerdings wird auch mehr Plattenspeicherplatz benötigt.
Sie können die Größe (Granularität) von Sperren, die beim Zugriff auf die Tabelle verwendet wird, mit Hilfe des Parameters LOCKSIZE angeben. Standardmäßig werden bei der Erstellung der Tabelle Sperren auf Zeilenebene definiert. Durch die Verwendung von Sperren auf Tabellenebene kann die Leistung von Abfragen verbessert werden, da die Anzahl der Sperren, die aktiviert und freigegeben werden müssen, beschränkt wird.
Durch die Angabe von APPEND ON können Sie die allgemeine Leistung erhöhen. Diese Angabe ermöglicht schnellere INSERT-Aktivitäten, während der Aufwand für die Verwaltung von Informationen über den freien Speicherbereich vermieden wird.
Eine Tabelle mit einem Clustering-Index kann nicht zur Aktivierung des Anfügemodus (Append On) geändert werden. Entsprechend kann auch kein Clustering-Index für eine Tabelle mit aktiviertem Anfügemodus erstellt werden.
Mit einigen Einschränkungen können Sie eine Übersichtstabelle in eine reguläre Tabelle bzw. eine reguläre Tabelle in eine Übersichtstabelle ändern. Bei anderen Tabellenarten als regulären und Übersichtstabellen ist eine Änderung der Tabellenart nicht möglich. Sie können z. B. keine replizierte Übersichtstabelle in eine reguläre Tabelle und umgekehrt ändern.
Nach dem Ändern einer regulären Tabelle in eine Übersichtstabelle wird die Tabelle in den Status 'Überprüfung anstehend' versetzt. Bei einer derartigen Änderung muß die Gesamtauswahl in der Definition der Übersichtstabelle mit der ursprünglichen Tabellendefinition übereinstimmen. Dies bedeutet folgendes:
Wenn die Übersichtstabelle für eine ursprüngliche Tabelle definiert ist, kann diese nicht in eine Übersichtstabelle geändert werden. Wenn für die ursprüngliche Tabelle Auslöser, Prüfungen auf Integritätsbedingungen, referentielle Integritätsbedingungen oder definierte eindeutige Indizes definiert sind, kann diese nicht in eine Übersichtstabelle geändert werden. Wenn Sie die Tabellenmerkmale ändern, um eine Übersichtstabelle zu definieren, ist es nicht zulässig, die Tabelle innerhalb derselben Anweisung ALTER TABLE in irgendeiner Form zu ändern.
Beim Ändern einer regulären Tabelle in eine Übersichtstabelle kann die Gesamtauswahl der Übersichtstabelle nicht über Sichten, Aliasnamen oder andere Übersichtstabellen direkt oder indirekt auf die ursprüngliche Tabelle verweisen.
Geben Sie die folgenden Befehle ein, um eine Übersichtstabelle in eine reguläre Tabelle zu ändern:
ALTER TABLE sumtable SET SUMMARY AS DEFINITION ONLY
Geben Sie die folgenden Befehle ein, um eine reguläre Tabelle in eine Übersichtstabelle zu ändern:
ALTER TABLE regtable SET SUMMARY AS <gesamtauswahl>
Die Einschränkungen, die beim Ändern einer regulären Tabelle in eine Übersichtstabelle für die Gesamtauswahl gelten, stimmen größtenteils mit den Einschränkungen überein, die für das Erstellen einer Übersichtstabelle mit der Anweisung CREATE SUMMARY TABLE gelten.
Zusätzliche Informationen zur Anweisung CREATE SUMMARY TABLE finden Sie im Handbuch SQL Reference.
Sie können die Daten in einer oder mehreren Übersichtstabellen mit Hilfe der Anweisung REFRESH TABLE aktualisieren. Die Anweisung kann in ein Anwendungsprogramm eingebettet oder dynamisch abgesetzt werden. Zur Verwendung dieser Anweisung sind die Berechtigungen SYSADM oder DBADM bzw. das Zugriffsrecht CONTROL für die zu aktualisierende Tabelle erforderlich.
Das folgende Beispiel zeigt, wie Sie die Daten in einer Übersichtstabelle aktualisieren können:
REFRESH TABLE SUMTAB1
Weitere Informationen zur Anweisung REFRESH TABLE finden Sie im Handbuch SQL Reference.
Nach dem Erstellen eines strukturierten Typs stellen Sie eventuell fest, daß Sie diesem strukturierten Typ Attribute hinzufügen oder zugeordnete Attribute löschen müssen. Verwenden Sie dazu die Anweisung ALTER TYPE (Structured). Umfassende Informationen zu strukturierten Typen finden Sie im Handbuch Application Development Guide.
Zeilen können mit Hilfe gesuchter oder positionierter DELETE-Anweisungen aus typisierten Tabellen gelöscht werden. Zeilen können mit Hilfe gesuchter oder positionierter UPDATE-Anweisungen in typisierten Tabellen aktualisiert werden. Umfassende Informationen zu typisierten Tabellen finden Sie im Handbuch Application Development Guide.
Sie können eine vorhandene Tabelle mit einem neuen Namen innerhalb eines Schemas versehen und die Berechtigungen und Indizes, die für die ursprüngliche Tabelle erstellt wurden, beibehalten.
Die vorhandene, umzubenennende Tabelle kann ein Aliasnamen sein, der eine Tabelle angibt. Die vorhandene, umzubenennende Tabelle darf nicht den Namen einer Katalogtabelle, einer Übersichtstabelle, einer typisierten Tabelle haben oder ein Objekt außer Tabelle bzw. Aliasname sein.
Auf die vorhandene Tabelle darf nicht in einem der folgenden Objekte verwiesen werden:
Außerdem darf es keine Prüfungen auf Integritätsbedingungen innerhalb der Tabelle und keine generierten Spalten außer der Identitätsspalte geben. Alle Pakete oder im Cache zwischengespeicherte dynamische SQL-Anweisungen, die von der ursprünglichen Tabelle abhängig sind, werden ungültig gemacht. Weiterhin werden vorhandene Aliasnamen, die auf die ursprüngliche Tabelle verweisen, nicht geändert.
Sie sollten mit Hilfe der entsprechenden Systemkatalogtabellen sicherstellen, daß die Tabelle, die Sie umbenennen, von keiner dieser Einschränkungen betroffen ist.
Pakete müssen erneut gebunden werden, wenn sie auf die Tabelle verweisen, die gerade umbenannt wurde. Pakete können unter folgenden Bedingungen implizit wieder gebunden werden:
Eine dieser Optionen muß durchgeführt werden, bevor ein implizites oder explizites erneutes Binden versucht wird. Wenn keine der Optionen ausgeführt wird, schlägt das erneute Binden fehl.
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine vorhandene Tabelle
umzubenennen:
|
Geben Sie in der Befehlszeile folgendes ein, um eine vorhandene Tabelle umzubenennen:
RENAME TABLE <schemaname.<tabellenname> TO <neuer_name>
Mit der folgenden SQL-Anweisung wird die Tabelle EMPLOYEE innerhalb des Schemas COMPANY in EMPL umbenannt:
RENAME TABLE COMPANY.EMPLOYEE TO EMPL
Weitere Informationen zur Anweisung RENAME TABLE finden Sie im Handbuch SQL Reference.
Eine Tabelle kann mit der SQL-Anweisung DROP TABLE gelöscht werden.
Beim Löschen einer Tabelle wird die Zeile im Katalog SYSCAT.TABLES, die die Informationen über die Tabelle enthält, gelöscht, während alle anderen von der Tabelle abhängigen Objekte auf verschiedene Weise davon betroffen sind. Beispiel:
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Tabelle zu
löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um eine Tabelle zu löschen:
DROP TABLE <tabellenname>
Mit der folgenden Anweisung wird die Tabelle DEPARTMENT gelöscht:
DROP TABLE DEPARTMENT
Eine einzelne Tabelle kann nicht gelöscht werden, wenn sie eine untergeordnete Tabelle hat. Alle Tabellen, die einer Tabellenhierarchie angehören, können jedoch mit einer einzigen Anweisung DROP TABLE HIERARCHY gelöscht werden, wie im folgenden Beispiel gezeigt:
DROP TABLE HIERARCHY person
In der Anweisung DROP TABLE HIERARCHY muß die Stammtabelle der zu löschenden Hierarchie angegeben werden.
Zwischen dem Löschen einer Tabellenhierarchie und dem Löschen einer bestimmten Tabelle bestehen folgende Unterschiede:
Weitere Informationen zur Anweisung DROP finden Sie im Handbuch SQL Reference.
Beim Löschen einer benutzerdefinierten temporären Tabelle müssen einige Aspekte berücksichtigt werden. Diese Tabellen werden mit der Anweisung DECLARE GLOBAL TEMPORARY TABLE erstellt.
Beim Löschen derartiger Tabellen muß der Tabellenname durch den Schemennamen SESSION qualifiziert werden und in einer Anwendung definiert sein, die zum Erstellen der Tabelle verwendet wurde.
Pakete dürfen nicht in einem Abhängigkeitsverhältnis zu dieser Tabellenart stehen und werden beim Löschen einer solchen Tabelle nicht ungültig.
Wird eine benutzerdefinierte temporäre Tabelle gelöscht und wurde die Erstellung dieser Tabelle vor der aktiven Arbeitseinheit bzw. dem aktuellen Sicherungspunkt durchgeführt, wird die Tabelle funktional gelöscht und die Anwendung kann nicht auf diese zugreifen. Allerdings bleibt für die Tabelle weiterhin Speicherplatz im zugehörigen Tabellenbereich reserviert. Dies verhindert, daß der temporäre Benutzertabellenbereich gelöscht wird, bevor die Arbeitseinheit festgeschrieben bzw. der Sicherungspunkt beendet ist.
Weitere Informationen zur Anweisung DROP finden Sie im Handbuch SQL Reference.
Ein Auslöserobjekt kann mit der Anweisung DROP gelöscht werden. Diese Prozedur hat jedoch zur Folge, daß abhängige Pakete als ungültig markiert werden, wie im folgenden beschrieben:
Ein Paket bleibt ungültig, bis das Anwendungsprogramm explizit gebunden bzw. neu gebunden wird oder das Anwendungsprogramm ausgeführt wird und der Datenbankmanager es automatisch erneut bindet.
Eine benutzerdefinierte Funktion (UDF), Funktionsschablone oder Funktionszuordnung kann mit der Anweisung DROP gelöscht werden.
Mit der Zuordnungsoption DISABLE können Sie eine Funktionszuordnung inaktivieren. Weitere Informationen hierzu finden Sie im Handbuch SQL Reference.
Eine benutzerdefinierte Funktion kann nicht gelöscht werden, wenn eine Sicht, ein Auslöser, eine Prüfung auf Integritätsbedingung in einer Tabelle oder eine andere benutzerdefinierte Funktion von ihr abhängig ist. Funktionen, die implizit durch die Anweisung CREATE DISTINCT TYPE generiert werden, können nicht gelöscht werden. Es ist nicht möglich, eine Funktion zu löschen, die sich im Schema SYSIBM oder im Schema SYSFUN befindet.
Andere Objekte können von einer Funktion oder Funktionsschablone abhängig sein. Alle solchen Abhängigkeiten (auch Funktionszuordnungen) müssen beseitigt werden, bevor eine Funktion gelöscht werden kann. Eine Ausnahme bilden nur Pakete, die als unbrauchbar markiert werden. Ein solches Paket wird nicht implizit erneut gebunden. Es muß entweder mit dem Befehl BIND bzw. REBIND erneut gebunden werden oder mit dem Befehl PREP vorbereitet werden. Weitere Informationen zu diesen Befehlen finden Sie im Handbuch Command Reference. Durch Löschen einer UDF werden alle Pakete oder im Cache zwischengespeicherte dynamische SQL-Anweisungen, die sie verwendet haben, ungültig gemacht.
Durch Löschen einer Funktionszuordnung wird ein Paket als ungültig markiert. Eine automatische erneute Bindeoperation wird ausgeführt, und das Optimierungsprogramm versucht, die lokale Funktion zu verwenden. Ist die lokale Funktion eine Schablone, so schlägt das implizite erneute Binden fehl.
(Weitere Informationen finden Sie in Anweisungsabhängigkeiten beim Ändern von Objekten.)
Ein benutzerdefinierter Datentyp (UDT) oder eine Typenzuordnung kann mit der Anweisung DROP gelöscht werden. Ein UDT kann nicht gelöscht werden, wenn er wie folgt verwendet wird:
Eine Standardtypenzuordnung kann nicht gelöscht, sondern nur durch Erstellen einer anderen Typenzuordnung überschrieben werden.
Der Datenbankmanager versucht dann, alle Funktionen, die von diesem einzigartigen Typ abhängig sind, zu löschen. Wenn die benutzerdefinierten Funktionen nicht gelöscht werden können, kann auch der benutzerdefinierte Typ nicht gelöscht werden. Eine benutzerdefinierte Funktion kann nicht gelöscht werden, wenn eine Sicht, ein Auslöser, eine Prüfung auf Integritätsbedingung in einer Tabelle oder eine andere benutzerdefinierte Funktion von ihr abhängig ist. Durch Löschen eines benutzerdefinierten Datentyps werden alle Pakete oder im Cache zwischengespeicherte dynamische SQL-Anweisungen, die ihn verwendet haben, ungültig gemacht.
Wenn Sie eine Umsetzung für einen UDT erstellt haben und den UDT löschen wollen, sollten Sie erwägen (falls erforderlich), die Umsetzung zu löschen. Dies kann mit der Anweisung DROP TRANSFORM geschehen. Einzelheiten zu dieser Anweisung finden Sie im Handbuch SQL Reference. Beachten Sie, daß nur Umsetzungen, die von Ihnen oder von anderen Anwendungsentwicklern definiert wurden, gelöscht werden können. Integrierte Umsetzungen und die dazugehörigen Gruppendefinitionen können nicht gelöscht werden.
Weitere Informationen zu den benutzerdefinierten Datentypen (UDT) finden Sie in den Handbüchern SQL Reference und Application Development Guide.
Die Anweisung ALTER VIEW ändert eine vorhandene Sicht durch Ändern einer Verweisartspalte zum Hinzufügen eines Bereichs. Für andere Änderungen an einer Sicht müssen Sie die Sicht löschen und erneut erstellen.
Beim Ändern der Sicht muß der Bereich einer vorhandenen Verweisartspalte (REF) hinzugefügt werden, für die noch kein Bereich definiert wurde. Zudem darf die Spalte nicht von einer übergeordneten Sicht übernommen werden.
Der Datentyp des Spaltennamens in der Anweisung ALTER VIEW muß REF sein (Typ des Namens der typisierten Tabelle oder des Namens der typisierten Sicht).
Andere Datenbankobjekte wie Tabellen und Indizes sind nicht betroffen, obwohl Pakete und im Cache zwischengespeicherte dynamische Anweisungen als ungültig markiert werden. Der Abschnitt Anweisungsabhängigkeiten beim Ändern von Objekten enthält weitere Informationen.
Zusätzliche Informationen zur Anweisung ALTER VIEW finden Sie im Handbuch SQL Reference.
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Sicht zu
ändern:
|
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Sicht zu
löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um eine Sicht zu löschen:
DROP VIEW <sichtname>
Das folgende Beispiel zeigt, wie die Sicht EMP_VIEW gelöscht wird:
DROP VIEW EMP_VIEW
Alle Sichten, die von der gelöschten Sicht abhängig sind, werden als unbrauchbar markiert. (Weitere Informationen dazu finden Sie in Wiederherstellen unbrauchbarer Sichten.)
Wie von den Tabellenhierarchien her bekannt, kann eine ganze Sichtenhierarchie durch eine einzige Anweisung gelöscht werden, in der die Stammsicht der Hierarchie angegeben wird, wie im folgenden Beispiel gezeigt:
DROP VIEW HIERARCHY VPerson
Weitere Informationen zum Löschen und Erstellen von Sichten finden Sie im Handbuch SQL Reference.
Sichten können als Ergebnis eines widerrufenen Zugriffsrechts SELECT in einer untergeordneten Tabelle unbrauchbar werden.
Eine unbrauchbare Sicht kann auf folgende Weise wiederhergestellt werden:
Wenn Sie eine unbrauchbare Sicht nicht wiederherstellen möchten, können Sie sie explizit mit der Anweisung DROP VIEW löschen, oder Sie können eine neue Sicht mit demselben Namen, aber einer anderen Definition erstellen.
Eine unbrauchbare Sicht hat nur noch Einträge in den Katalogsichten SYSCAT.TABLES und SYSCAT.VIEWS. Alle Einträge in den Katalogsichten SYSCAT.VIEWDEP, SYSCAT.TABAUTH, SYSCAT.COLUMNS und SYSCAT.COLAUTH werden entfernt.
Sie können eine Übersichtstabelle nicht ändern, aber löschen.
Alle Indizes, Primärschlüssel, Fremdschlüssel und Prüfungen auf Integritätsbedingung, die auf die Tabelle verweisen, werden gelöscht. Alle Sichten und Auslöser, die auf die Tabelle verweisen, werden unbrauchbar gemacht. Alle Pakete, die von einem gelöschten oder als unbrauchbar markierten Objekt abhängen, werden ungültig gemacht. Weitere Informationen zu Paketabhängigkeiten finden Sie in Anweisungsabhängigkeiten beim Ändern von Objekten.
Gehen Sie wie folgt vor, um mit der Steuerzentrale eine Übersichtstabelle
zu löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um eine Übersichtstabelle zu löschen:
DROP TABLE <tabellenname>
Mit der folgenden SQL-Anweisung wird die Übersichtstabelle XT gelöscht:
DROP TABLE XT
Übersichtstabellen können als Ergebnis eines widerrufenen Zugriffsrechts SELECT in einer zugrundeliegenden Tabelle unbrauchbar werden.
Eine unbrauchbare Übersichtstabelle kann eventuell auf folgende Weise wiederhergestellt werden:
Wenn Sie eine unbrauchbare Übersichtstabelle nicht wiederherstellen möchten, können Sie sie explizit mit der Anweisung DROP TABLE löschen, oder Sie können eine neue Übersichtstabelle mit demselben Namen, aber einer anderen Definition erstellen.
Eine unbrauchbare Übersichtstabelle hat nur noch Einträge in den Katalogsichten SYSCAT.TABLES und SYSCAT.VIEWS. Alle Einträge in den Katalogsichten SYSCAT.VIEWDEP, SYSCAT.TABAUTH, SYSCAT.COLUMNS und SYSCAT.COLAUTH werden entfernt.
Mit der Anweisung DROP kann eine Oberfläche aus der Datenbank gelöscht werden. Das folgenden Beispiel zeigt, wie die Oberfläche DRDA gelöscht wird:
DROP WRAPPER DRDA
Alle von der zu löschenden Oberfläche abhängigen Server, Typenzuordnungen, Funktionszuordnungen und Kurznamen werden gelöscht. Gehen Sie beim Löschen von Oberflächen mit größter Sorgfalt vor.
Sie müssen über die Berechtigung SYSADM oder DBADM verfügen, um Oberflächen mit der Anweisung DROP löschen zu können.
Weitere Informationen zm Löschen von Oberflächen finden Sie im Handbuch SQL Reference.
Die Anweisung ALTER SERVER ändert eine vorhandene Server-Definition im Katalog der zusammengeschlossenen Datenbank. Mit dieser Anweisung können Sie folgendes ausführen:
Diese Anweisung kann nicht zum Ändern der Server-Optionen dbname und node verwendet werden.
Das folgende Beispiel zeigt, wie der Server ORA1 geändert werden kann:
ALTER SERVER ORA1 OPTIONS (SET CPU_RATIO '5.0')
Server können aus der zusammengeschlossenen Datenbank gelöscht werden. Das folgende Beispiel zeigt, wie der Server ORALOC01 gelöscht wird:
DROP SERVER ORALOC01
Alle von dem zu löschenden Server abhängigen Typenzuordnungen, Funktionszuordnungen, Benutzerzuordnungen und Kurznamen werden gelöscht. Gehen Sie beim Löschen von Servern mit größter Sorgfalt vor.
Sie müssen über die Berechtigung SYSADM oder DBADM verfügen, um Server mit der Anweisung ALTER oder DROP ändern bzw. löschen zu können.
Weitere Informationen zum Löschen und Ändern von Servern finden Sie im Handbuch SQL Reference.
Mit der Anweisung ALTER NICKNAME können lokal gespeicherte Informationen über eine Datenquellentabelle oder -sicht aktualisiert werden. Mit dieser Anweisung können Sie zum Beispiel den lokalen Namen einer Spalte ändern oder einen Spaltendatentyp einem anderen Datentyp zuordnen. Außerdem können Sie mit dieser Anweisung Spaltenoptionen hinzufügen. Weitere Informationen zur Syntax von ALTER NICKNAME finden Sie im Handbuch SQL Reference.
Beim Löschen eines Kurznamens werden für diesen Kurznamen erstellte Sichten als unbrauchbar markiert. Kurznamenspalten oder -datentypen können nicht geändert werden, wenn in einer Sicht auf den Kurznamen verwiesen wird.
Sie müssen über die Berechtigung SYSADM oder DBADM, die Datenbankberechtigung CONTROL bzw. ALL für den Kurznamen oder die Schemenberechtigung ALTERIN (für das aktuelle Schema) verfügen oder der definierende Benutzer des Kurznamens in der zusammengeschlossenen Datenbank sein, um diese Anweisung verwenden zu können.
Das folgende Beispiel zeigt, wie der Kurzname TESTNN durch Ändern des lokalen Spaltennamens COL1 in NEWCOL geändert wird:
ALTER NICKNAME TESTNN ALTER COLUMN COL1 LOCAL NAME NEWCOL
Das folgende Beispiel zeigt, wie der Kurzname TESTNN gelöscht wird:
DROP NICKNAME TESTNN
Spalteninformationen werden in Form von Werten angegeben, die den als Spaltenoptionen bezeichneten Parametern zugeordnet werden. Diese Werte können in Groß- oder Kleinschreibung angegeben werden. Im Absatz über Spaltenoptionen des Abschnitts über Kurznamenkenndaten mit Auswirkungen auf Pushdown-Möglichkeiten am Ende des Kapitels mit Überlegungen zur Umgebung finden Sie Beschreibungen und zusätzliche Informationen zu diesen Werten.
Es kann keine einzige Klausel einer Indexdefinition, Indexerweiterung oder Indexspezifikation geändert werden. Der Index bzw. die Indexerweiterung muß gelöscht und anschließend neu erstellt werden. (Das Löschen eines Index oder einer Indexspezifikation führt nicht dazu, daß andere Objekte gelöscht werden, jedoch können einige Pakete ungültig gemacht werden.)
Gehen Sie wie folgt vor, um mit der Steuerzentrale einen Index, eine
Indexerweiterung oder eine Indexspezifikation zu löschen:
|
Geben Sie in der Befehlszeile folgendes ein, um einen Index, eine Indexerweiterung oder eine Indexspezifikation zu löschen:
DROP INDEX <indexname>
Mit der folgenden SQL-Anweisung wird der Index PH gelöscht:
DROP INDEX PH
Mit der folgenden SQL-Anweisung wird die Indexerweiterung IX_MAP gelöscht:
DROP INDEX EXTENSION ix_map RESTRICT
Der Name der Indexerweiterung muß sich auf eine Indexerweiterung beziehen, die im Katalog beschrieben wird. Die Klausel RESTRICT erzwingt die Anwendung der Regel, daß kein Index definiert werden darf, der in einem Abhängigkeitsverhältnis zur Indexerweiterungsdefinition steht. Wenn ein zugrundeliegender Index von dieser Indexerweiterung abhängig ist, schlägt die Löschoperation fehl.
Ein Index für den Primärschlüssel oder eindeutigen Schlüssel kann nicht explizit gelöscht werden (außer wenn es sich um eine Indexspezifikation handelt). Zum Löschen eines solchen Index gibt es folgende Methoden:
Pakete und zwischengespeicherte dynamische SQL-Anweisungen, die von den gelöschten Indizes abhängen, werden als ungültig markiert. Der Abschnitt Anweisungsabhängigkeiten beim Ändern von Objekten enthält weitere Informationen. Das Anwendungsprogramm ist von Änderungen durch das Hinzufügen oder Löschen von Indizes nicht betroffen.
Anweisungsabhängigkeiten beziehen sich auf Pakete und im Cache zwischengespeicherte dynamische SQL-Anweisungen. Ein Paket (Package) ist ein Datenbankobjekt, das die Informationen enthält, die vom Datenbankmanager zum Zugriff auf Daten in der für ein bestimmtes Anwendungsprogramm effizientesten Weise benötigt werden. Binden (Binding) ist der Prozeß, durch den das Paket erstellt wird, das der Datenbankmanager zum Zugriff auf Daten benötigt, wenn die Anwendung ausgeführt wird. Das Handbuch Application Development Guide enthält eine detaillierte Beschreibung dieser Paketerstellung.
Pakete und zwischengespeicherte dynamische SQL-Anweisungen können von vielen Arten von Objekten abhängig sein. Eine vollständige Liste dieser Objekte finden Sie im Handbuch SQL Reference.
Auf diese Objekte könnte explizit verwiesen werden, zum Beispiel, indem eine Tabelle oder eine benutzerdefinierte Funktion in einer SQL-Anweisung SELECT angegeben wird. Auf die Objekte könnte auch implizit verwiesen werden, zum Beispiel, wenn eine abhängige Tabelle überprüft werden muß, um sicherzustellen, daß keine referentiellen Integritätsbedingungen verletzt werden, wenn eine Zeile in einer übergeordneten Tabelle gelöscht wird. Pakete sind außerdem von den Zugriffsrechten abhängig, die dem Ersteller des Pakets erteilt wurden.
Wenn ein Paket oder eine im Cache zwischengespeicherte dynamische SQL-Anweisung von einem Objekt abhängig ist und dieses Objekt gelöscht wird, wird das Paket bzw. die dynamische SQL-Anweisung in den Status "ungültig" versetzt. Wenn ein Paket von einer benutzerdefinierten Funktion abhängig ist und diese Funktion gelöscht wird, wird das Paket in den Status "unbrauchbar" versetzt.
Eine im Cache zwischengespeicherte dynamische SQL-Anweisung, die sich im Status "ungültig" befindet, wird bei ihrer nächsten Verwendung automatisch erneut optimiert. Wenn ein von der Anweisung benötigtes Objekt gelöscht wurde, schlägt die Ausführung der dynamischen SQL-Anweisung möglicherweise mit einer entsprechenden Fehlernachricht fehl.
Ein Paket, das sich im Status "ungültig" befindet, wird bei der nächsten Verwendung implizit erneut gebunden. Ein solches Paket kann aber auch explizit erneut gebunden werden. Wurde ein Paket als ungültig markiert, weil ein Auslöser gelöscht wurde, kann das erneut gebundene Paket keinen Auslöser mehr aufrufen.
Ein Paket, das sich im Status "unbrauchbar" befindet, muß explizit erneut gebunden werden, damit es verwendet werden kann. Im Handbuch Application Development Guide finden Sie weitere Informationen zum Binden und erneuten Binden von Paketen.
Für Objekte zusammengeschlossener Datenbanken gelten ähnliche Abhängigkeiten. Durch das Löschen eines Servers werden z. B. alle diesem Server zugeordneten Pakete oder im Cache zwischengespeicherte, dynamische SQL-Anweisungen mit Verweisen auf Kurznamen ungültig gemacht.
In einigen Fällen ist es nicht möglich, das Paket erneut zu binden. Zum Beispiel, wenn eine Tabelle gelöscht und nicht wieder erstellt wurde, kann das Paket nicht erneut gebunden werden. In diesem Fall muß entweder das Objekt neu erstellt oder die Anwendung so geändert werden, daß sie nicht mehr auf das gelöschte Objekt zugreift.
In vielen anderen Fällen, zum Beispiel, wenn eine Integritätsbedingung gelöscht wurde, kann das Paket erneut gebunden werden.
Mit Hilfe der folgenden Systemkatalogsichten können Sie den Status eines Pakets und die Abhängigkeiten des Pakets feststellen:
Weitere Informationen zu Objektabhängigkeiten finden Sie in der Beschreibung der Anweisung DROP im Handbuch SQL Reference.