Frank's Oracle Blog

Wenn ein Index "kaputt" geht, geht bisweilen nicht mehr viel mit der zugehörigen Tabelle. Zum Prüfen, ob Indizes 'unbenutzbar' sind: (Wichtig ist die getrennte Prüfung für Index, Partition und Subpartition, daher der union all; die Spalten partition_name und ddl_type werden später zur Generierung des SQL benötigt.) select owner      , index_name      , null partition_name      , null ddl_type   from all_indexes  where table_owner = UPPER ('IPUCT3')    and status = 'UNUSABLE' union all select index_owner      , index_name      , partition_name      , 'partition' ddl_type   from all_ind_partitions  where     (index_owner, index_name) in (select owner, index_name                           ...

Um Daten direkt in eine bestimmte Partition einzufügen gibt es folgende zwei Varianten: a) mit Partitionsnamen: insert /*+ APPEND */ into myTbl2   partition ( P_123 )      ( K_PARTITION_KEY      , Col2      ) select T1 . K_PARTITION_KEY      , T1.Col2   from myTbl T1   where T1 . K_PARTITION_KEY = 123; b) mit Partitionswert (LIST-Partitioniert): insert /*+ APPEND */ into myTbl2   partition for ( 123 )      ( K_PARTITION_KEY      , Col2      ) select T1 . K_PARTITION_KEY      , T1.Col2   from myTbl T1   where T1 . K_PARTITION_KEY = 123; Vorteil: Es wird nur die betroffene Partition gelocked. Andere Partitionen können parallel "bearbeitet". Nachteil: Der Partitionsname oder -wert muss vorher mitgegeben werden -> also dyn. SQL....

Manchen Operationen (wie z.B. truncate oder drop partition) können nicht mit aktiven Constraints auf die Tabelle ausgeführt werden. Daher hat sich folgender Ablauf bewährt: - aktive Constraints abzuschalten - eigentliches Drop / truncate - obige Constraints wieder einschalten (Idealerweise "merkt" man sich die betroffenen Constraints und schaltet nicht pauschal alle Constraints wieder ein.) Im Code kann das dann so aussehen: Vorab - Typen definieren und Fehlerhandling vorbereiten -- Type für Drop_Partition_FS definieren   -- Datentypen aus SYS.ALL_CONSTRAINTS   type x IS     record     (       OWNER VARCHAR2 (128 Char),       TABLE_NAME VARCHAR2 (128 Char),       CONSTRAINT_NAME VARCHAR2 (128 Char),       STATUS VARCHAR2 (8 Char)) ;   type y IS     TABLE OF x;     z y; -- globale Variablen   part_missed EXCEPTION;   PRAGMA EXCEPTION_INIT ...

Ein echtes Problem beim Partition Exchange war bisher, die zu tauschende Tabelle in genau der Struktur zu erstellen, dass diese mit der partitionierten Tabelle zusammen passt. Spätestens mit den hidden columns, die Oracle ggfs. selbst anlegt, wurde Partition Exchange zum Lotto-Spiel. Ab Oracle 12 gibt es eine Lösung hierfür: CREATE TABLE myTbl_tmp FOR EXCHANGE WITH TABLE myTbl Es macht genau das, was es soll :-) ...gefunden bei Dani Schnider: https://danischnider.wordpress.com/2017/02/09/partition-exchange-in-oracle-12-2/

Ein Beispiel für eigenes Fehlerhandling: DECLARE   obj_missed EXCEPTION;   PRAGMA EXCEPTION_INIT ( obj_missed , -942); BEGIN EXECUTE IMMEDIATE('DROP TABLE mytst'); EXCEPTION   WHEN  obj_missed  THEN NULL;   WHEN OTHERS THEN RAISE; END; / Eine weitere Variante: BEGIN     EXECUTE IMMEDIATE 'DROP TABLE  mytst '; EXCEPTION     WHEN OTHERS     THEN         IF SQLCODE = -942           THEN  NULL;           ELSE  RAISE;         END IF; END; /

Wenn der Zeichensatz am Client nicht passt und eine Änderung der Session-Umgebung nicht möglich (oder unpraktisch) ist, kann die Ausgabe trotzdem angepasst werden: durch die Ergänzung von TO_CHAR um eine NLS-Angabe. Beispiel: select to_char(sysdate,'Day') from dual; TO_CHAR(SYSDATE,'DAY') ----------------------- Friday Es wird das englische "Friday" geliefert. Wird das deutsche "Freitag" benötigt, dann so: select to_char(sysdate,'Day','NLS_DATE_LANGUAGE=GERMAN') from dual; TO_CHAR(SYSDATE,'DAY','NLS_DATE_LANGUAGE=GERMAN') ------------------------------------------------- Freitag Zu beachten: Es steht der komplette NLS-String in einfachen Hochkomma 'NLS_DATE_LANGUAGE=GERMAN'

Mit Version 19.1. werden die IG in APEX noch besser benutzbar (Detail u.a. bei Carsten hier:  https://blogs.oracle.com/apex/new-declarative-options-for-interactive-grid ) Ein Problem bleibt: Wenn über der Tabelle myTAB1 das IG aufgesetzt wird funktioniert alles super. Will man aus myTAB2 weitere Daten auch nur anzeigen wirds schwierig: APEX reklamiert fehlende Berechtigungen für myTAB2, obwohl es hier nur select-Rechte benötigt. Also ein select für das Grid auf eine Tabelle ist kein Problem: SELECT Col1_A      , Col1_B      , Col1_C   FROM myTAB1; Soll aus myTAB2 z.B. eine Summe angezeigt werden, wirds spannender: SELECT Col1_A      , Col1_B      , Col1_C      , D.Anz   FROM myTAB1        JOIN (  SELECT Col2_A, COUNT (*) Anz                  FROM myTAB2              GROUP...