Frank's Oracle Blog

um die Oberfläche auf Englisch umzustellen: # Eigene Anpassungen AddVMOption -Duser.language=en AddVMOption -Duser.region=US in die Datei ...\datamodeler\datamodeler\bin\datamodeler.conf bzw. ...\sqldeveloper\ide\bin\ide.conf (in 2017: ...\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf) eintragen, speichern, neu starten -> fertig!

Hintergrund: Laufzeiten von diversen Prozessen werden (Tool-)intern in Sekunden gemessen und meist auch so dargestellt. Für Weiterberechnungen und Auswertungen ist das Ideal. Der Lesbarkeit für den geneigten Nutzer nur bedingt dienlich. Wer erkennt schon auf den ersten Blick, wie lange 14.738sec sind? Lang halt. Lösungsansätze: Für die Lesbarkeit, kann man diese Werte natürlich entsprechend umrechnen. Aber wie? 14.738sec vermutlich am Besten in Stunden: 14.738/60/60 = 4,0939 Stunden -> Aha. Aber was ist mit 249sec? 249/60/60 = 0,069 Stunden - Wie lang bitte sind 0,069Std? 249sec also besser in Minuten umrechnen: 249/60 = 4,15 Min -> schon besser Also per CASE-Statement die unterschiedliche großen Sekundenangaben passend umrechnen? Nicht schön und umständlich. Netterweise bietet Oracle mit der to_date()-Funktion auch den Formatstring 'sssss' (5x kleines 's'). Per to_char( to_date(14768,'sssss') ,'HH24:MI:SS') werden aus den Sekunden

Um zu prüfen, ob ein Index benutzt worden ist, kann mit folgendem Script ein Monitoring an geschaltet werden: select 'alter index usr.'||index_name||' monitoring usage;' Txt from ALL_INDEXES where table_owner = 'ABC' and table_name like 'T_%'; ausschalter per ... nomonitoring usage Die eigentliche Prüfung erfolgt per: bis Oracle 12: select * from v$object_usage; ab Oracle 12: select * from user_object_usage; Bis einschl. Oracle 12.1 wird hierfür der Ausführungsplan vom SQL-Parsing genutzt. Ab Oracle 12.2 wird die Laufzeit hierfür genutzt, d.h. die Auswertung wird wesentlich genauer. Generell gilt: " Use index monitoring as a guide line, not an absolute. " weitere Infos z.B.  https://oracle-base.com/articles/10g/index-monitoring

Gute Erklärung von Tom Kyte: https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9523909800346378277 und eine Präse von Jonathan Lewis: https://jonathanlewis.files.wordpress.com/2011/12/one-pass-distinct-sampling-presentation.pdf

Problem: DROP COLUMN scheitert mit ORA-39726 "Nicht unterstützter Vorgang ... bei komprimierten Tabellen" -> Blöd, wer hat eigentlich die Komprimierung eingeschaltet? Und warum? Lösung: Wenn die Tabelle nicht per DROP und CREATE komplett neu erstellt werden kann (oder soll) wirds etwas aufwändiger: 1) Spalte auf unused setzen: alter table D_TBL set unused column X_FLAG ; select * from all_unused_col_tabs; -> hier sollten nun je Tabelle die Anzahl der nicht benutzten Spalten stehen. 2) Unbenutzte Spalten löschen: alter table D_TBL drop unused columns; Falls das nicht hilft (wg. Partitionierung???): 1) Kompression ausschalten (mit MOVE und ggfs parallel X!): alter table D_TBL move nocompress; bzw. alter table D_TBL move partition P_XYZ nocompress; 2) dann unbenutzte Spalten löschen: alter table D_TBL drop unused columns; 3) Kompression wieder einschalten (mit MOVE und ggfs parallel X!): alter table D_TBL move compress; bzw. alt