Ich muss gestehen, initial hätte ich mir auch so eine Syntax gewünscht. Bei genauerer Betrachtung stelle ich aber fest:

Transkript

1 Page 1 of 9 Betrifft Autor Online Reorganisationen mit Oracle9i Andri Kisseleff andri.kisseleff@trivadis.com Art der Info Technische Background Info November 2001 Quelle Aus dem NF9i-Kurs der Trivadis Einführung "High-Availability" wird in immer mehr Projekten zu einem "Muss". Oracle unterstützt uns Kunden seit Jahren dieses Ziel zu erreichen. So wurden in vergangenen Oracle-Versionen die Möglichkeiten zur Verfügung gestellt Indexes online zu reorganisieren. Seit Oracle8i kann man Index-Organized-Tables IOTs online reorganisieren. Was noch gefehlt hat, war die Möglichkeit "normale" Tabellen online zu reorganisieren. Mit Oracle9i ist es nun soweit! Während der DBA eine Tabelle reorganisiert, können die Benutzer INSERT-, UPDATE- und DELETE-Befehle auf die Tabelle ohne Einschränkungen durchführen. Es kann verschiedene Gründe geben, eine Tabelle reorganisieren zu wollen: Tabelle in anderen Tablespace verschieben Row-Chaining/Row-Migration eliminieren Storage und andere Parameter ändern, welche nicht online geändert werden können oder geändert werden sollten Attribute umbenennen Tabelle in eine partitionierte Tabelle umwandeln und umgekehrt Tabelle in eine IOT umwandeln und umgekehrt Stark fragmentierte Tabelle defragmentieren etc. Online Tabellen-Reorganisationen sind selbstverständlich nur eine der diversen "High- Availability-Features" von Oracle9i. Für weitere Features verweisen wir auf weitere Publikationen und selbstverständlich ebenfalls auf unseren Kurs "NF9i: New Features Oracle9i ". Auch ein Trivadis-Techno-Circle betr. "High-Availability mit Oracle9i" ist in Vorbereitung. Stay tuned! Technologie "Einfachheit" ist ein anderes Schlagwort des 9i-Marketings. So würden Sie sich wohl denken, dass so eine online Reorg etwas syntaktisch ganz einfaches sei, so à la: ALTER TABLE emp MOVE TABLESPACE data STORAGE INITIAL 16K ONLINE; Ich muss gestehen, initial hätte ich mir auch so eine Syntax gewünscht. Bei genauerer Betrachtung stelle ich aber fest:

2 Page 2 of 9 Wie würde ich damit ein Attribut umbenennen? Wie würde ich eine Tabelle in eine partitionierte Tabelle umwandeln? etc. Also lieber etwas komplizierter, dafür gibt es ja Syntax-Generatoren, und dafür mit mehr Möglichkeiten! Oracle verwendet für online Reorganisationen die Materialized View Technologie MVIEW. Der Ablauf in einigen Worten mit dem Beispiel der Tabelle EMP sei hier kurz geschildert: 1 Sie prüfen mit DBMS_REDEFINITION.CAN_REDEF_TABLE ob die Tabelle online reorganisiert werden kann Restriktionen siehe weiter unten 2 Sie erstellen eine leere Interim-Table z.b. EMP_INT. Die Attribute bei dieser Interim- Table dürfen Sie anderes nennen, es darf eine partitionierte Tabelle, eine IOT, etc. sein 1 Sie starten mit DBMS_REDEFINITION.START_REDEF_TABLE die online Reorganisation. Oracle erstellt nun auf Ihrer EMP-Tabelle ein MVIEW-Log, wo die Transaktionen, welche während der Reorganisation auf der EMP-Tabelle stattfinden geloggt werden. Auf der EMP_INT-Tabelle wird eine MVIEW "on prebuilt table" erstellt und Oracle beginnt ein Refresh Complete von der EMP Tabelle in die EMP_INT Tabelle. einfach gesagt in etwa: ein INSERT INTO SELECT FROM. Die Tabelle EMP wird während START_REDEF_TABLE für ganz kurze Zeit exklusiv gelockt. Wenn dieses Lock im Moment nicht verfügbar ist, so wartet Oracle auf das Lock. Während der eigentlichen Reorg ist keine Tabelle gelockt. 2 Nun können Sie auf der EMP_INT-Tabelle Ihre Indexes erstellen, die Constraints definieren, die Trigger erstellen, die Comments, die Grants, die Audit-Optionen, kurzum: alles was Sie nach der Reorg noch wieder haben möchten 3 Sobald die EMP_INT Tabelle wieder über alles verfügt können Sie mit DBMS_REDEFINITION.FINISH_REDEF_TABLE die Reorganisation abschliessen. Oracle macht ein letztes PUSH der im MVIEW-Log während der online-reorg angefallenen TX auf der EMP-Tabelle in die EMP_INT-Tabelle, die beiden Tabellen werden kurz gelockt und EMP wird in EMP_INT und EMP_INT in EMP umbenannt. Die MVIEW und das MVIEW-Log werden hier automatisch gedroppt. 4 Die EMP_INT-Tabelle Ihre alte EMP-Tabelle können Sie nun droppen. Etwas mehr Details Trigger und Constraints auf der EMP_INT-Tabelle sollten Sie disabled anlegen. Sie werden vom FINISH_REDEF_TABLE enabled. Oracle verlangt, dass Constraint-Namen, Index-Namen, Trigger-Namen, LOB-Segment- Namen, LOB-Index-Namen, Nested-Table Namen, etc. eindeutig pro Schema pro User und nicht etwa eindeutig pro Tabelle sein müssen. Man kann darüber streiten ob dies Bug oder Feature sei. Ich betrachte dies und diejenigen, welche bei Oracle Reorg-Tools entwickeln müssen sicherlich ebenfalls als unangenehme Einschränkung, ja als historisch bedingte Einschränkung durch das Datenmodell des Data-Dictionaries. Ein Column-Name z.b. muss ja auch nicht eindeutig pro Schema sein, sondern pro Tabelle. Was bedeutet dies in der Praxis?

3 Page 3 of 9 Wenn Sie auf der Tabelle EMP eine Constraint EMP_PK, einen Index EMP_ENAME und einen Trigger EMP_TRG haben, so können Sie diese drei "Objekte" auf der EMP_INT Tabelle nicht identisch nennen. Am Ende der Reorg heissen also Ihre Constraints, Trigger, Indexes, etc. anders. Für Trigger und Indexes ist dies kein Problem. Hier stehen ALTER... RENAME Befehle zur Verfügung. Für Constraints und andere "Objekte" fehlt aber leider dieser RENAME Befehl. Man muss also damit leben können, dass z.b. Constraints auch wenn man diese online mit dem Reorg-Wizard des OEM-Tuning Packs reorganisiert, danach anders heissen. Wenn während der Reorg viele TX anfallen, so kann es wünschenswert sein die TX in die Interim-Table zu pushen, bevor man dort wieder weitere Indexes erstellt. Hierzu steht DBMS_REDEFINITION.SYNC_INTERIM_TABLE zur Verfügung. Syntax-Generatoren Meines Wissens stehen heute zwei Syntax-Generatoren produktiv zur Verfügung um das oben geschilderte zu automatisieren. Reorg Wizard des Oracle Enterprise Manager Tuning Pack und TabReorg von Trivadis. Am Beispiel von durch TabReorg generierter Syntax sei das oben erwähnte noch etwas syntaktisch visualisiert: Aufruf von TabReorg: *****> Schema Name Owner and Table Name are case sensitive EMP, emp, EMP%, e%, etc. TABLE name to reorganise or wildcard...: EMP OWNER of the table no wildcards...: SCOTT Online Reorg Y/<N>...: Y DBMS_STATS Estimate % Statistics: 0-99, <50>: Histograms? NONE, REPEAT, <SKEWONLY> : N default = do the same as COMPRESS = Y of EXP/IMP do *NOT* compress, but *COMBINE* the allocated extents?? ex. 10 = compress the table and make the initial extent?? pct larger than the really *REQUIRED* space 0 = initial extent = required space no reserve Compress table <N>/?? pct larger than used space : 10 Do you want to compile dependent objects during the reorg? - this takes more time, especially if you reorg many tables at the same time. Manually calling DBMS_UTILITY.COMPILE_SCHEMA at the end of the reorg might be faster in such cases... Compile dependent objects <Y>/N:

4 Page 4 of 9 etc., etc.. Die generierte Syntax Teilausschnitte: Prüfen ob die Tabelle Online reorganisiert werden kann: execute dbms_redefinition.can_redef_table - uname => '"SCOTT"', - tname => '"EMP"'; Die Interim-Tabelle erstellen: create table "SCOTT"."trQEMP" "EMPNO" NUMBER4,0 NULL, "ENAME" VARCHAR210 BYTE NULL, "JOB" VARCHAR29 BYTE NULL, "MGR" NUMBER4,0 NULL, "HIREDATE" DATE NULL, "SAL" NUMBER7,2 NULL, "COMM" NUMBER7,2 NULL, "DEPTNO" NUMBER2,0 NULL storage /* table */ initial next minextents 1 maxextents 249 pctincrease 50 buffer_pool DEFAULT freelists 1 freelist groups 1 pctfree 10 pctused 40 initrans 1 maxtrans 255 logging nocache nomonitoring norowdependencies parallel degree 1 instances 1 tablespace /* TS of the table */ "SYSTEM" / Falls die Tabelle z.b. neu partitioniert sein sollte, oder ein Attribut umbenannt werden sollte, so würden wir dies hier entsprechend editieren. Falls die Tabelle in einem anderen Tablespace, mit anderen Parametern, etc. angelegt werden soll, so editieren wir dies ebenfalls hier vor der Ausführung des Scripts. Die Reorg starten: execute dbms_redefinition.start_redef_table - uname => '"SCOTT"', - orig_table => '"EMP"', - int_table => '"trqemp"', - col_mapping => ' -

5 Page 5 of 9 "EMPNO" "EMPNO" -,"ENAME" "ENAME" -,"JOB" "JOB" -,"MGR" "MGR" -,"HIREDATE" "HIREDATE" -,"SAL" "SAL" -,"COMM" "COMM" -,"DEPTNO" "DEPTNO" - ' ; Falls wir während der Reorg ein Attribut umbenennen möchten, so wäre dies in der generierten COL_MAPPING Liste zu editieren. Indexes, Grants, Triggers, Constraints, etc. auf der Interim-Tabelle erstellen Teilausschnitt: create UNIQUE index "SCOTT"."trQPK_EMP_0" on "SCOTT"."trQEMP" "EMPNO" ASC storage initial next minextents 1 maxextents 249 pctincrease 50 buffer_pool DEFAULT freelists 1 freelist groups 1 pctfree 10 initrans 2 maxtrans 255 logging parallel degree 1 instances 1 nocompress tablespace "SYSTEM"; alter table "SCOTT"."trQEMP" add constraint "trq00pk_emp" primary key "EMPNO" / alter session set current_schema="scott"; create or replace trigger "SCOTT"."trQEMP_TRG_1" BEFORE INSERT OR UPDATE ON "SCOTT"."trQEMP" REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW begin :NEW.ename := UPPER:NEW.ename; end;

6 Page 6 of 9 / alter trigger "SCOTT"."trQEMP_TRG_1" disable; alter session set current_schema="system"; comment on table "SCOTT"."trQEMP" is 'Employees table'; audit SELECT on "SCOTT"."trQEMP" by access whenever NOT successful; execute dbms_stats.gather_table_stats - ownname => '"SCOTT"', - tabname => '"trqemp"', - estimate_percent => 50, - cascade => true; execute dbms_stats.gather_table_stats - ownname => '"SCOTT"', - tabname => '"trqemp"', - estimate_percent => 50, - method_opt => 'for all columns size skewonly'; Die Reorg abschliessen: execute dbms_redefinition.finish_redef_table - uname => '"SCOTT"', - orig_table => '"EMP"', - int_table => '"trqemp"'; Die alte Tabelle droppen und die Indexes und Trigger umbenennen: drop table SCOTT."trQEMP" cascade constraints; lock table "SCOTT"."EMP" in exclusive mode; alter trigger "SCOTT"."trQEMP_TRG_1" rename to "EMP_TRG"; alter trigger "SCOTT"."EMP_TRG" compile; REM here we create the triggers again actually, as they have been spoiled by finish_redef REM Bug Oracle lock table "SCOTT"."EMP" in EXCLUSIVE MODE; alter session set current_schema="scott"; create or replace trigger "SCOTT"."EMP_TRG" BEFORE INSERT OR UPDATE ON "SCOTT"."EMP" REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW begin :NEW.ename := UPPER:NEW.ename; end; / alter session set current_schema="system"; commit; execute prccoa; lock table "SCOTT"."EMP" in exclusive mode; alter index "SCOTT"."trQPK_EMP_0"

7 Page 7 of 9 rename to "PK_EMP"; TabReorg gibt aus, wie die Constraints neu heissen: REM Table: SCOTT.EMP Constraint now: "trq00pk_emp" REM Table: SCOTT.EMP Constraint now: "trq00fk_deptno" Wenn Sie diese Tabelle ein zweites mal online reorganisieren, so haben die Constraints übrigens wieder ihren ursprünglichen Namen. Schön, dass es Tools gibt, welche die ganze Syntax generieren. All dies tippen möchte ich auf jeden Fall nicht. Einschränkungen Es gibt zwei Kategorien von Einschränkungen: Tabellen, welche von DBMS_REDEFINITION nicht reorganisiert werden können Tabellen, welche vom Reorg Wizard Tuning Pack noch nicht online reorganisiert werden können Auf Zweitere möchte ich hier aus Gründen der Fairness nicht eingehen. DBMS_REDEFINITION Einschränkungen/Bemerkungen: Nicht unterstützt sind: Table ohne Primary Key Original Table und interim Table müssen PK über die gleichen Columns haben Table mit Materialized View Log und Materialized View auf zu reorganisierender Tabelle Advanced Queuing Tables Overflow Table einer IOT Tables mit User defined Types Tables mit LONG, LONG RAW und BFILE Tables, die zu einem Cluster gehören Tables im Schema SYS und SYSTEM Temporäre Tables WHERE-Bedingung horizontales Partitionieren und Sub-Queries während der Reorg Neue Columns mit NOT NULL nachträglich ändern R/I zwischen Original-Table und Interim-Table Reorg-Tools testen: Wenn Sie ein Reorg-Tool testen möchten, so stelle ich Ihnen gerne eine "Checkliste zur Evaluation von Oracle Reorg-Tools" zur Verfügung andri.kisseleff@trivadis.com. Bei ONLINE-Reorgs mit Oracle9i sollten Sie insbesondere auch testen: Kann man eine Tabelle mit Triggern 2 x oder mehr online reorganisieren? Kann man eine Tabelle mit Grants online reorganisieren? Kann man eine Tabelle, welche über FK-Constraints bei einem anderen Schema verfügt

8 Page 8 of 9 online reorganisieren? Sind Trigger und Constraints welche disabled sind und auch disabled sein sollten nach einer Reorg enabled oder disabled? Hat man die Möglichkeit die generierte Syntax zu editieren/grafisch zu verändern, falls die Attribute neu anders heissen sollen, die Tabelle partitioniert sein soll, etc. Stabilität DBMS_REDEFINITION ist eine neue Technologie. Für eine erste Version ist die Technologie schon sehr ausgereift. Wenn aber komplexe Tabellen reorganisiert werden z.b. die Tabelle DEPT meines Test-Users IKISS und diverse andere Tabellen, so kann es schon mal sein, dass die Reorg entweder bei FINISH_REDEF_TABLE oder aber vor allem auch beim DROP TABLE der Interim Table mit ORA oder mit ORA abstürzt. Ich empfehle allen Anwendern von Online-Reorgs ob manuell, mit TabReorg oder mit Reorg Wizard oder sonstigem generiert die online Reorg einer bestimmten Tabelle zuerst auf einem Test-System zu prüfen. Hier empfehle ich vor allem auch diese Tabelle nicht nur einmal zu testen, sondern mindestens zwei mal. TabReorg Neben Online-Reorgs unterstützt TabReorg auch bereits diverse andere 9i-Features. u.a.: List Partitioning Hash-partitionierte IOTs BITMAP-Indexes und Mapping-Tables auf IOTs AUTO UNDO MANAGEMENT AUTO SPACE MANAGEMENT Die ROWDEPENDENDCIES-Clause Alle neuen Oracle9i-Datatypes wie "TIMESTAMP", "TIMESTAMP WITH TIMEZONE", "TIMESTAMP WITH LOCAL TIMEZONE", "INTERVAL YEAR TO MONTH", "INTERVAL DAY TO SECOND", etc. BYTE/CHAR-Semantik Varrays und Objects in partitionierten IOTs etc. Wo Sie mehr über 9i erlernen können? Besuchen Sie den neuen NF9i-Kurs 4 Tage in einem unserer Schulungszentren. Viel Erfolg und viel Spass mit Online Reorgs in Oracle9i! PS: TabReorg hat mich beauftragt Ihnen einen Gruss zu übermitteln. Ich soll Ihnen ausrichten: "Man kann mich kaufen!" Andri Kisseleff

9 Page 9 of 9 Trivadis AG Kanalstrasse 5 CH-8152 Glattbrugg Tel: Fax: Internet: