Mit der View v$all_object_usage können Benutzer mit SYSDBA-Rechten schemaübergreifend Objekte abfragen.

create or replace view v$all_object_usage
(owner, index_name, table_name, monitoring, used, start_monitoring, end_monitoring)
as
select u.name, io.name, t.name, decode(bitand(i.flags, 65536), 0, ‘NO’, ‘YES’), decode(bitand(ou.flags, 1), 0, ‘NO’, ‘YES’), ou.start_monitoring, ou.end_monitoring
from sys.user$ u, sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ou
where i.obj# = ou.obj#
and io.obj# = ou.obj#
and t.obj# = i.bo#
and u.user# = io.owner#;

Download:Note: There is a file embedded within this post, please visit this post to download the file.

Mit dem folgenden SQL-Statement kann man die gegenwärtige Buffer Cache Hit Ratio abfragen:

SELECT ROUND((1-(phy.value / (cur.value + con.value)))*100,2) "Cache Hit Ratio"
FROM v$sysstat cur, v$sysstat con, v$sysstat phy
WHERE cur.name = 'db block gets'
AND con.name = 'consistent gets'
AND phy.name = 'physical reads';

Ein denkbar schlechtes Ergebnis könnte dann so aussehen:

Cache Hit Ratio
---------------
          60,99

Über den Sinn dieses Ergebnisses kann man trefflich streiten, denn mit der nun folgenden Abfrage wird diese Zahl künstlich erhöht:

DECLARE
  v_dummy dual.dummy%TYPE;
BEGIN
  FOR I IN 1..10000000 LOOP
    SELECT dummy INTO v_dummy FROM dual;
  END LOOP;
END;
/

Nach diesem mehrfachen PL/SQL-Looping sieht die Buffer Cache Hit Ratio dann so aus:

Cache Hit Ratio
---------------
          75,66

Führt man das Statement weitere Male aus, erhöht sich die Zahl weiter.

Dieser Beitrag könnte auch unter dem Motto “Warum ist man immer bestrebt, das zu bekommen, was man nicht kriegen kann?” stehen. Denn wie man sieht, lohnt der Aufwand nicht, die Buffer Cache Hit Ratio zu tunen.

Da gibt es besseres: Das ORACLE Wait Interface (OWI) zum Beispiel. Es liefert genaue Informationen darüber, was getunt werden sollte.

Hermant schreibt in seinem Blog, dass eine zu gute Buffer Cache Hit Ratio auch nicht das Gelbe vom Ei ist. Es kann dann auch sein, dass die Ausführungspläne einiger SQL-Statements zu wünschen übrig lassen. In dem Fall sollte nach Statements mit sehr hohen “Buffer Gets” gesucht werden.

Mit dieser Extension kann man Trace Files analysieren. Das Deaktivieren der Extension lässt die CPU wieder aufatmen… außerdem ist sie für das tägliche Arbeiten mit dem SQL Developer nicht unbedingt notwendig.

Es gibt noch eine Reihe anderer Ursachen, die im Oracle Forum nachgelesen werden können. Wie es aussieht, scheint die Digger-Extension jedoch bei vielen die Ursache zu sein. Bleibt eigentlich nur noch, abzuwarten, wie mit der nächsten Oracle SQL Developer Version aussieht.

Mit einfachsten ORACLE-Boardmitteln kann man doppelte Daten in einer Tabelle ausfindig machen, indem man sie gegen sich selbst verbindet – mit einem JOIN.

Als Beispielfall nehmen wir an, dass in unserer Geburtstagsübersicht doppelte Daten vorkommen. Die Tabelle BIRTHDAY sieht folgendermaßen aus:

Name                           Null     Type
------------------------------ -------- --------------
NAME                                    VARCHAR2(20)
VORNAME                                 VARCHAR2(20)
MONAT                                   NUMBER(2)
TAG                                     NUMBER(2)

Nun kommt es darauf an, welche Art doppelter Daten man ausfindig machen möchte. In unserem Beispiel ist es sinnvoll, alle Spalten der Tabelle zu selektieren, da Namensgleichheit durchaus vorkommen kann. Das SQL-Statement sieht demnach so aus:

SELECT name, vorname, monat, tag
FROM birthday A
WHERE rowid >
 (
  SELECT min(rowid)
  FROM birthday B
  WHERE B.name = A.name
   AND B.vorname = A.vorname
   AND B.monat = A.monat
   AND B.tag = A.tag
 );

Das Ergebnis dieser Abfrage könnte so aussehen:

NAME        VORNAME  MONAT  TAG
----------- -------- ------ ----
Mustermann  Max      5      23

Der Geburtstag des Herrn Max Mustermann wurde also zweimal in die Tabelle eingetragen. Um die Duplikate zu entfernen muss das Statement umgebaut werden:

DELETE FROM birthday A
WHERE A.rowid >
 ANY (SELECT B.rowid
  FROM birthday B
  WHERE A.name = B.name
   AND A.vorname = B.vorname
   AND A.monat = B.monat
   AND A.tag = B.tag
 );

Noch einfacher ist es, die Duplikate mit ORACLE Analytic Functions zu finden und zu löschen:

DELETE FROM birthday
WHERE rowid IN
 (
  SELECT rowid
  FROM
   (
    SELECT rowid, row_number()
    OVER (PARTITION BY name, vorname, monat, tag ORDER BY name) dup
    FROM birthday
   )
  WHERE dup > 1
 );

Ein Beispiel:
Erstellen wir zunächst eine Tabelle (den Sinn dieser Tabelle betrachten wir nicht an dieser Stelle):

CREATE TABLE INDEX_MONITOR
(
COL_1 VARCHAR2(10),
COL_2 VARCHAR2(10),
COL_3 VARCHAR2(10),
COL_4 VARCHAR2(10)
);

Als nächstes befüllen wir die Tabelle mit Zufallswerten:

begin
for i in 1 .. 100 loop
INSERT INTO INDEX_MONITOR VALUES (
dbms_random.string(‘COL_1′, 10),
dbms_random.string(‘COL_2′, 10),
dbms_random.string(‘COL_3′, 10),
dbms_random.string(‘COL_4′, 10));
end loop;
end;
/

Nun erstellen wir für jede Spalte einen Index (wie gesagt, an der Sinnhaftigkeit darf gezweifelt werden, es soll ja nur ein Beispiel sein…):

CREATE INDEX IDX_COL_1 ON INDEX_MONITOR (COL_1);
CREATE INDEX IDX_COL_2 ON INDEX_MONITOR (COL_2);
CREATE INDEX IDX_COL_3 ON INDEX_MONITOR (COL_3);
CREATE INDEX IDX_COL_4 ON INDEX_MONITOR (COL_4);

Das Monitoring der Indizes wird folgendermaßen gestartet:

ALTER INDEX IDX_COL_1 MONITORING USAGE;
ALTER INDEX IDX_COL_2 MONITORING USAGE;
ALTER INDEX IDX_COL_3 MONITORING USAGE;
ALTER INDEX IDX_COL_4 MONITORING USAGE;

Mit Hilfe der V$-View v$object_usage kann ORACLE abgefragt werden, ob Indizes genutzt werden oder nicht:

SELECT index_name, used FROM v$object_usage;

Momentan sieht das Ergebnis der Abfrage noch so aus:

INDEX_NAME                     USE
------------------------------ ---
IDX_COL_1                       NO
IDX_COL_2                       NO
IDX_COL_3                       NO
IDX_COL_4                       NO

Im nächsten Schritt werden drei Abfragen ausgeführt, von denen jede einen einzelnen Index nutzen wird:

SELECT COUNT(*) FROM INDEX_MONITOR WHERE COL_1=’1234567890′;
SELECT COUNT(*) FROM INDEX_MONITOR WHERE COL_3=’1234567890′;
SELECT COUNT(*) FROM INDEX_MONITOR WHERE COL_4=’1234567890′;

Wird die V$-View v$object_usage nun erneut abgefragt…:

SELECT index_name, used FROM v$object_usage;

… liefert sie das Ergebnis zurück, dass IDX_COL_2 nicht genutzt wurde:

INDEX_NAME                     USE
------------------------------ ---
IDX_COL_1                       YES
IDX_COL_2                       NO
IDX_COL_3                       YES
IDX_COL_4                       YES

Das Monitoring der Indizes wird mit den folgenden Befehlen ausgeschaltet:

ALTER INDEX IDX_COL_1 NOMONITORING USAGE;
ALTER INDEX IDX_COL_2 NOMONITORING USAGE;
ALTER INDEX IDX_COL_3 NOMONITORING USAGE;
ALTER INDEX IDX_COL_4 NOMONITORING USAGE;

Zugegeben, der Zeitraum, in dem das Monitoring eingeschaltet ist, wird in der Regel wesentlich länger sein, typischerweise ein Tag – vielleicht auch eine Woche. Es handelt sich hier auch nur um ein Beispiel.

Voraussetzung:
In der Datenbank müssen Job-Warteschlangen aktiviert sein, d.h. der Initialisierungsparameter job_queue_processes muss mindestens den Wert 1 haben, damit ein Job automatisch startet. Dieser Parameter ist dynamisch, er kann somit im laufenden Betrieb geändert werden (ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 1;). Der Hintergrundprozess CJQ0 startet die Job-Queue-Prozesse.

Vorgehensweise:
Zur Verwaltung der internen Job-Warteschlagen stehen innerhalb des DBMS_JOB-Packages verschiedene Prozeduren zur Verfügung. Mit der Prozedur DBMS_JOB.SUBMIT können Jobs eingerichtet werden. An diese Prozedur muss neben einer OUT-Variable für die Jobnummer übergeben werden, was, wann es erstmals und in welchem Intervall es ausgeführt werden soll. Optional kann man noch angeben, wann die Angaben geparst werden sollen, der Default ist somit:

DBMS_JOB.SUBMIT(
job OUT BINARY_INTEGER,
what IN VARCHAR2,
next_date IN DATE,
interval IN VARCHAR2 DEFAUL ‘null’,
no_parse IN BOOLEAN DEFAULT FALSE);

Man sollte darauf achten, dass die Angabe der erstmaligen Ausführung vom Datentyp DATE, die Angabe des Intervalls hingegen vom Datentyp VARCHAR2 ist! “what” muss mit einem Semikolon abgeschlossen werden.
Wird kein Intervall angegeben, so wird der Job einmalig ausgeführt und danach aus der Datenbank entfernt. Damit der Job vollständig eingerichtet wird, muss mit COMMIT bestätigt werden.

Beispiel 1:
Die Prozedur dbms_stats.gather_schema_stats (analysiert Schemata – ab ORACLE Database Version 10g erfolgt das im Übrigen vollautomatisch) soll am 18.12.07 um 18:00 Uhr und danach alle 7 Tage ausgeführt werden:

DECLARE
v_jobno BINARY_INTEGER;
BEGIN
DBMS_JOB.SUBMIT(v_jobno,
‘dbms_stats.gather_schema_stats (ownname =>”Schemaname”, cascade => true);’,
to_date(’18.12.2007 6:00 PM’, ‘DD.MM.YYYY HH:MI PM’), ‘sysdate+7′);
commit;
End;

Beispiel 2:
Job für die E-Mail-Benachrichtigung (alle 10 Minuten):

DECLARE
v_jobno BINARY_INTEGER;
BEGIN
DBMS_JOB.SUBMIT(v_jobno,
‘begin PA_MailWork. p_emailBearbeiten; end;’,
to_date(’18.12.2007 10:00 AM’, ‘DD.MM.YYYY HH:MI PM’),
‘sysdate+10/(24*60)’);
commit;
End;

Job-Verwaltung:
Der Besitzer eines Jobs kann diesen später ändern (mit den Prozeduren BROKEN, CHANGE, INTERVAL, NEXT_DATE und WHAT), löschen (durch die Prozedur REMOVE) oder dessen Ausführung erzwingen (mit Hilfe der Prozedur RUN). Für jede dieser Prozeduren muss die Job-Nummer bekannt sein. ORACLE generiert diese über die Sequenz SYS.JOBSEQ. Weitere Angaben zu den Jobs der Datenbank befinden sich in der View DBA_JOBS. Zusätzliche Informationen zu den Jobs, die momentan ausgeführt werden, findet man in der View DBA_JOBS_RUNNING.

Prozedur BROKEN:
Mit Hilfe dieser Prozedur überführt man einen Job in den broken-Status, d.h. er wird nicht zum geplanten Zeitpunkt ausgeführt. ORACLE setzt den Job automatisch in den broken-Status, wenn er nach 16 Versuchen nicht erfolgreich ausgeführt werden kann.

DBMS_JOB.BROKEN(
job IN BINARY_INTEGER,
broken in BOOLEAN
next_date IN DATE DEFAULT SYSDATE);

Beispiel:

exec dbms_job.broken(7, TRUE);
commit;

Wurde ein Job auf broken gesetzt (TRUE), lässt sich dieser Vorgang wieder umkehren und die broken-Variable auf FALSE setzen.

Prozedur CHANGE:
Hiermit können die Eigenschaften des Jobs (what-Parameter, Datum, nächster Lauf, Zeitintervall) geändert werden.

DBMS_JOB.CHANGE(
job IN BINARY_INTEGER,
what IN VARCHAR2 DEFAULT NULL,
next_date IN DATE DEFAULT NULL,
interval IN VARCHAR2 DEFAULT NULL,
instance IN BINARY_INTEGER DEFAULT NULL,
force IN BOOLEAN DEFAULT FALSE);

Werden keine Werte vorgegeben oder wurden sie auf NULL gesetzt, bleiben die alten Einstellungen erhalten.

Beispiele:

exec dbms_job.change(1, NULL, NULL, ‘SYSDATE + 3′);
commit;

exec dbms_job.change(7, NULL, to_date(’28.07.2007 11:30 PM’, ‘DD.MM.YYYY HH:MI PM’) , NULL);
commit;

INTERVAL-, NEXT_DATE- und WHAT-Prozedur:
Diese Prozeduren stellen Leistungsmerkmale zur Verfügung, die bereits von der CHANGE-Prozedur angeboten werden, bei der nicht benötigte Parameter auf NULL gesetzt werden.

DBMS_JOB.NEXT_DATE(
job IN BINARY_INTEGER,
next_date IN DATE);

Beispiel:

exec dbms_job.next_date (1, SYSDATE + 1/24);
commit;

Prozedur REMOVE:
Mit der REMOVE-Prozedur entfernt man einen Job aus der Warteschlange. Der einzige Parameter ist die Job-Nummer.

DBMS_JOB.REMOVE(
job_number IN BINARY_INTEGER);

Beispiel:

exec dbms_job.remove (7);
commit;

Prozedur RUN:
RUN wird zum sofortigen Starten eines Jobs genutzt und zur Ausführung eines “broken”-Jobs.

DBMS_JOB.RUN(
job IN BINARY_INTEGER,
force IN BOOLEAN DEFAULT FALSE);

Beispiel:

exec dbms_job.run (12);
commit;

Weitere Informationen zum Thema Jobs befinden sich in der ORACLE Dokumentation:
http://www.oracle.com/technology/documentation/index.html

• Download Oracle DBA Toolbar für Internet Explorer
• Download Oracle DBA Toolbar für Mozilla Firefox

set pagesize 0
set feedback off
set trimspool on
spool compile.sql
SELECT ‘ALTER ‘||object_type||’ ‘||owner||’.”‘||object_name||’” COMPILE;’
FROM dba_objects
WHERE status <> ‘VALID’
AND object_type NOT IN (‘PACKAGE BODY’,'TYPE BODY’,'UNDEFINED’,'JAVA CLASS’,'SYNONYM’)
UNION
SELECT ‘ALTER PACKAGE ‘||owner||’.'||object_name||’ COMPILE BODY;’
FROM dba_objects
WHERE status <> ‘VALID’
AND object_type = ‘PACKAGE BODY’
UNION
SELECT ‘ALTER TYPE ‘||owner||’.'||object_name||’ COMPILE BODY;’
FROM dba_objects
WHERE status <> ‘VALID’
AND object_type = ‘TYPE BODY’
UNION
SELECT ‘ALTER MATERIALIZED VIEW ‘||owner||’.'||object_name||’ COMPILE;’
FROM dba_objects
WHERE status <> ‘VALID’
AND object_type = ‘UNDEFINED’
UNION
SELECT ‘ALTER JAVA CLASS ‘||owner||’.”‘||object_name||’” RESOLVE;’
FROM dba_objects
WHERE status <> ‘VALID’
AND object_type = ‘JAVA CLASS’
UNION
SELECT ‘ALTER SYNONYM ‘||owner||’.'||object_name||’ COMPILE;’
FROM dba_objects
WHERE status <> ‘VALID’
AND object_type = ‘SYNONYM’
AND owner <> ‘PUBLIC’
UNION
SELECT ‘ALTER PUBLIC SYNONYM ‘||object_name||’ COMPILE;’
FROM dba_objects
WHERE status <> ‘VALID’
AND object_type = ‘SYNONYM’
AND owner = ‘PUBLIC’;
spool off
set feedback on
@compile.sql

Download:Note: There is a file embedded within this post, please visit this post to download the file.

Das heißt: Den Ordner löschen, in dem sich die bisherige Version befand, und danach die neue Version hierhin kopieren. Das wäre eine Möglichkeit. Es geht aber auch einfacher: Den Inhalt des Ordners <SQLDeveloper>/sqldeveloper/system/ komplett leeren. Beim nächsten Start des Oracle SQL Developers werden die Inhalte neu angelegt und die NullPointerException gehört in dieser Version der Vergangenheit an.

Vorsicht: In dem oben genannten Ordner befinden sich zwei relativ wichtige Dateien; diese sollten zuvor gesichert werden. Hierbei handelt es sich zum einen um die Datei IDEConnections.xml. Hier werden sämtliche Informationen hinterlegt, die für den Connect zur Datenbank notwendig sind. Zum anderen ist da noch die Datei preferences.xml. In ihr sind die Einstellungen des Oracle SQL Developers gespeichert.
Wenn im Laufe der Zeit mehrere Upgrades gemacht wurden, kann es sein, dass die Dateien in verschiedenen Unterordnern von <SQLDeveloper>/sqldeveloper/system/ vorhanden sind. Man sollte sich hier für die aktuellste Version der Dateien entscheiden.