In den letzten Tagen wurde das Patchset 10.2.0.5 für Linux x86 & x86-64 unter der Patchnummer 8202632 veröffentlicht.

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.

Gerettet hat mich der Beitrag “Installing APEX 3.2.1” von Sara Blair im APEX-Blog. Er baut zwar auf die Dokumentation von ORACLE auf, geht aber auch explizit auf die Bilder-Problematik ein. Neben diesem Beitrag, in dem das ZIP-File der Version 3.2.1 in das Verzeichnis APEX3.2 direkt im Hauptverzeichnis entpackt wird, habe ich auch Blogbei- und Foreneinträge entdeckt, in denen man nach C:\TEMP entpacken soll. Selbst das ging in meinem Fall nicht…

Gut, ich habe mich nicht hundertprozentig an die vorgeschlagene Vorgehensweise von Sara gehalten. Sie schlägt vor, die neue Version in einen neuen Tablespace zu packen. Bei der Datenbank-Installation von 11gR1 wird APEX im Tablespace SYSAUX installiert. Da die Installation selbst bei meinen Versuchen stets funktioniert hat, habe ich also wieder SYSAUX gewählt. Mit anderen Worten: Der Installationbefehl

@apexins SYSAUX SYSAUX TEMP /i/

und das Laden der deutschen Sprache

(Achtung: vorher NLS_LANG auf GERMAN_GERMANY.AL32UTF8 setzen!)

@load_trans de

liefen fehlerfrei durch. Der alles entscheidende Befehl war dann:

@apxldimg.sql C:\APEX3.2\

und die Seite sah 1a aus, und Bilder waren auch zu sehen…

An dieser Stelle also: THX to Sara!

Das Einrichten einer ORACLE 11gR1 Datenbank unter Windows Server 2oo8 64-Bit ist an und für sich kein Problem, es sei denn, die Sicherheitseinstellungen auf dem System sind extrem hoch eingestellt (z.B. wegen BSI-Vorgaben). Da kann es schonmal vorkommen, dass man unter dem Account, unter dem man installiert hat, selbst den Listener nicht mal mehr stoppen kann. Das Starten und die Statusabfrage funktioniert.

Damit man als – angeblicher – Eigentümer des Listeners diesen auch wieder stoppen kann, ist folgende Zeile in der listener.ora einzutragen:

SQLNET.AUTHENTICATION_SERVICES = NONE

Sollte diese Zeile in der listener.ora bereits vorhanden sein, muss lediglich der Wert in NONE geändert werden.

Normalerweise sollten Benutzerrechte auf Unterordner vererbt werden. Das dachte ich auch, bis ich die Datenbank auf dem System mit sehr hohen Sicherheitseinstellungen eingerichtet hatte. Danach gehörte “mir” nicht mal der Ordner mit den .dbf-Files. Da ich Adminrechte hatte, ließ sich das ändern…

Die erste Hürde ist genommen, die Datenbank ist installiert und man kann sich connecten. Zur nächsten Baustelle – der Installation von VMware vCenter Server: Der Installationanleitung ist zu entnehmen, dass VMware vCenter Server den 32-Bit-ODBC-Treiber von ORACLE nutzt; wir befinden uns aber auf einem 64-Bit-System. Unter Windows 2008 sind alle systemnahen 32-Bit-Dienste in dem Verzeichnis

%windir%\SysWOW64

zu finden, so auch die Datei odbcad32.exe. Da jedoch die 64-Bit-Version von ORACLE 11g installiert ist, ist der Treiber nicht an dieser Stelle zu finden, sondern in der Systemverwaltung, also in der Standardumgebung. Erstellt man eine ODBC-Verbindung regulär über die Systemverwaltung, wird diese später von der VMware-Setup-Routine nicht erkannt, stattdessen erscheint folgendes:

In einem Thread des Oracle-Forums steht, dass man die ORACLE Database Gateways installieren soll, damit der Treiber auch in der 32-Bit-Umgebung steht. Das kann ich leider nicht bestätigen. Erst die Installation des 32-Bit-Clients – bzw. davon nur die ODBC-Verbindung – brachte den gewünschten Erfolg.
Man musste nach der Client-Installation lediglich die Datenbank in die tnsnames.ora des Client-ORACLE_HOME eintragen und die ODBC-Verbindung unter %windir%\SysWOW64\odbcad32.exe einrichten, und das Setup von VMware vCenter Server konnte ohne weiteres fortgesetzt werden.

Da ist zum einen das SQL-Script in dem Beitrag von Hölschi bei killer-tomate.de. Er fragt damit die Index- und Tabellengrößen im eigenen User-Schema ab und stellt die Größen in MByte dar.

Etwas detaillierter ist das SQL-Script von Held Informatik (meine persönliche Meinung…). Es beschränkt sich auf explizit Tabellen und der DBA hat die Möglichkeit, die Tabellengrößen einzelner Schemata oder der Datenbank insgesamt abzufragen. Auch die Darstellung der Größe ist etwas benutzerfreundlicher.

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.

Ja, was tun? Nennt man jetzt die allokierte Tablespace-Größe des Users, der ihm/ihr bekannt ist, oder nennt man nur den gegenwärtigen Daten-Füllgrad des Tablespaces? Oder geht man einen Schritt weiter und beziffert die Größe der Datenbank mit der Summe aller Datafiles? Mancher DBA fügt dieser Summe sogar die Größe der Tempfiles hinzu.

Was ist aber mit den Redologs und Controlfiles? Die gehören schließlich auch zur Datenbank! Die Größe der Datenbank in Bezug auf sämtliche Dateien, aus denen sie besteht – Datafiles, Tempfiles, Redologs und Controlfiles, lässt sich mit Hilfe einer kleinen PL/SQL Prozedur ermitteln.

set serveroutput on
set feedback off
declare
db_name varchar2(25);
alloc_database_size number;
used_database_size number;
alloc_datafile_size number;
used_datafile_size number;
alloc_tempfile_size number;
used_tempfile_size number;
redologfile_size number;
controlfile_size number;
begin
select db_unique_name into db_name from v$database;
select sum(bytes) data_file_size into alloc_datafile_size from dba_data_files;
select sum(bytes) temp_file_size into alloc_tempfile_size from dba_temp_files;
select sum(bytes_used) used_temp_file_size into used_tempfile_size from v$temp_space_header;
select sum(bytes) redo_log_size into redologfile_size from v$log;
select (a.bytes-b.bytes) bytes_used into used_datafile_size from (select sum(bytes) bytes from dba_data_files) a, (select sum(bytes) bytes from dba_free_space) b;
select (block_size * (1 + file_size_blks)) control_file_size into controlfile_size from v$controlfile where rownum = 1;
alloc_database_size := round((alloc_datafile_size + alloc_tempfile_size + redologfile_size + controlfile_size)/1024/1024/1024,3);
used_database_size := round((used_datafile_size + used_tempfile_size + redologfile_size + controlfile_size)/1024/1024/1024,3);
alloc_datafile_size := round(alloc_datafile_size/1024/1024/1024,3);
used_datafile_size := round(used_datafile_size/1024/1024/1024,3);
alloc_tempfile_size := round(alloc_tempfile_size/1024/1024/1024,3);
used_tempfile_size  := round(used_tempfile_size /1024/1024/1024,3);
redologfile_size := round(redologfile_size/1024/1024/1024,3);
controlfile_size := round(controlfile_size/1024/1024/1024,3);
dbms_output.put_line(‘Groesse der Datenbank ‘|| db_name);
dbms_output.put_line(‘—————————–’);
dbms_output.put_line(‘allokiert: ‘ || alloc_database_size || ‘ GB’);
dbms_output.put_line(‘genutzt:   ‘ || used_database_size || ‘ GB’);
dbms_output.put_line(‘—————————–’);
dbms_output.put_line(‘Details:’);
dbms_output.put_line(‘Groesse der Datafiles   : ‘ || alloc_datafile_size || ‘ GB’);
dbms_output.put_line(‘-> davon genutzt        : ‘ || used_datafile_size || ‘ GB’);
dbms_output.put_line(‘Groesse der Tempfiles   : ‘ || alloc_tempfile_size || ‘ GB’);
dbms_output.put_line(‘-> davon genutzt        : ‘ || used_tempfile_size || ‘ GB’);
dbms_output.put_line(‘Groesse der Redologfiles: ‘ || redologfile_size || ‘ GB’);
dbms_output.put_line(‘Groesse der Controlfiles: ‘ || controlfile_size || ‘ GB’);
end;
/

In der Prozedur wird sowohl die Größe der einzelnen Dateien als auch deren Füllgrad (bei Datafiles und Tempfiles) berücksichtigt. Selbstverständlich kann das Script dahin gehend erweitert werden, dass z.B. die Tablespaces einzeln aufgelistet werden. Sollte die Datenbank im Archivelog Mode gefahren werden (was für produktive Umgebungen zu empfehlen ist), können in der Prozedur auch die Archivelogs berücksichtigt werden.

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

Der ORACLE Real Application Cluster scheint für einige Anwendungen übers Ziel hinauszuschießen, diese Anwendungen müssen unter Umständen auch erst RAC-tauglich geproggt werden; da ist der ORACLE Data Guard die sinnigere Lösung. Der administrative Aufwand ist wesentlich geringer, auch die Kosten für Software halten sich im Rahmen.

Im Linux-Magazin befindet sich zu diesem Thema ein sehr informativer Beitrag.

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.

Beispiel:

Objekttyp SCHEMA_EXPORT/SEQUENCE/SEQUENCE wird verarbeitet
ORA-39083: Objekttyp SEQUENCE konnte nicht erstellt werden, Fehler:
ORA-00933: SQL-Befehl wurde nicht korrekt beendet
Fehlerhafte SQL ist:
CREATE SEQUENCE USER.TEST_SEQ MINVALUE 1 MAXVALUE 1,00000000000000E+27 INCREMENT BY 1 START WITH 1 CACHE 20 NOORDER NOCYCLE

oder die englische Version:

Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
ORA-39083: Object type SEQUENCE failed to create with error:
ORA-00933: SQL command not properly ended
Failing sql is:
CREATE SEQUENCE USER.TEST_SEQ MINVALUE 1 MAXVALUE 1,00000000000000E+27 INCREMENT BY 1 START WITH 1 CACHE 20 NOORDER NOCYCLE

ORACLE DataPump hat für den MAXVALUE der Sequence den falschen Wert im CREATE SEQUENCE-Statement generiert. Im ORACLE DataPump Export Dump File steht der Wert 1,00000000000000E+27 (siehe Beispiele oben). Der korrekte Wert müsste jedoch 9999999999999999999999999 sein. Der Fehler tritt auf, wenn das ORACLE DataPump Export Dump File mit NLS Parametern (= NLS Territory settings) erstellt wurde, die das Komma (“,“) als numerisches Dezimaltrennzeichen nutzen (beispielsweise NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15) und nicht den Punkt (“.“).

Um zu prüfen, welche Werte der NLS_NUMERIC_CHARACTERS in der ORACLE Datenbank Instance gesetzt sind, führt man in SQL*Plus die folgende Abfrage aus:

SQL> SELECT * FROM nls_session_parameters WHERE parameter IN (‘NLS_LANGUAGE’, ‘NLS_TERRITORY’, ‘NLS_NUMERIC_CHARACTERS’);

Das Ergebnis kann dann zum Beispiel so aussehen:

NLS_LANGUAGE                   GERMAN
NLS_TERRITORY                  GERMANY
NLS_NUMERIC_CHARACTERS         ,.

Die Lösungen

Das Problem tritt in ORACLE Database 10g Release 1 bis zum Patchset 10.1.0.3.0 auf. Mit Auslieferung des Patchsets 10.1.0.4.0 bzw. mit ORACLE Database Release 2 (10.2.0.1.x) wurde es gefixt.

Lösungsansatz 1:
Einspielen des Patchsets 10.1.0.4 im ORACLE_HOME der Quell-Datenbank, danach den ORACLE Datapump Export/Import erneut ausführen.

Lösungsansatz 2:
Setzen der Umgebungsvariable NLS_LANG mit dem Wert AMERICAN_AMERICA.[characterset] (z.B.: WE8ISO8859P15) auf dem Quell-System (im Übrigen ist der Fehler plattformunabhängig… ):

• Windows
  set NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15

• Unix C-Shell
  setenv NLS_LANG ‘AMERICAN_AMERICA.WE8ISO8859P15′

• Unix KORN-shell
  export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15

• VMS
  DEFINE/NOLOG NLS_LANG “AMERICAN_AMERICA.WE8ISO8859P15″

Danach ORACLE DataPump Export/Import erneut ausführen.

Lösungsansatz 3:
Die Fehler ignorieren und die Sequences nach dem ORACLE Datapump Import manuell in SQL*Plus erstellen, zum Beispiel so (vgl. den oben genannten Fehler):

SQL> CREATE SEQUENCE USER.TEST_SEQ MINVALUE 1 MAXVALUE 9999999999999999999999999 INCREMENT BY 1 START WITH 1 CACHE 20 NOORDER NOCYCLE;

Weitere Informationen gibt es im ORACLE Metalink:
Bug 3601775 – Impdp Generates Invalid Sql For Sequences With Large Maxvalue Ora-39083 Ora-933
Note 340300.1 – Import DataPump: ORA-39083 and ORA-933 when Importing Sequences With Non “.” NLS Decimal Character
Note 278937.1 – Import DataPump: ORA-39083 and PLS-103 when Importing Statistics Created with Non “.” NLS Decimal Character
Note 30778.1 – Init.ora Parameter “NLS_NUMERIC_CHARACTERS” Reference Note

1. beim Login
2. beim Stoppen des Enterprise Manager Services
3. beim Ändern des IAS_ADMIN Passworts

Wenn man das Passwort dieses Accounts vergessen hat, ist die nachfolgende Prozedur hilfreich, um es zurückzusetzen. Ich erläutere den Vorgang am Beispiel einer IAS-Installation unter Microsoft Windows; unter UNIX/Linux ist die Vorgehensweise jedoch ähnlich. Um das Passwort zurücksetzen zu können, muss man als der User angemeldet sein, unter dem der ORACLE IAS installiert wurde.

1. Die folgende Datei in einem Editor öffnen und diejenige Zeile finden, in der die Berechtigungen (credentials) des Users IAS_ADMIN definiert sind.
   

   %ORACLE_HOME%/sysman/j2ee/config/jazn-data.xml

   Das folgende Beispiel zeigt die Sektion der Datei jazn-data.xml mit dem Credentials-Tag des Users IAS_ADMIN

   <jazn-realm>
   <realm>
   <name>enterprise-manager</name>
   <users>
   …
   <user>
   <name>ias_admin</name>
   <credentials>{903}2Qt9qc/6zSZilslDB1/7NgtgMnA2Wnnlyd+xnHb+7WQ=</credentials>
   </user>
   …
   </users>
   </realm>
   </jazn-realm>

2. Die gesamte Zeile mit dem Credentials-Tag löschen.
3. Im Kommandozeilenfenster den folgenden Befehl eintragen und ausführen.
   

   %ORACLE_HOME%\bin\emctl set password reset <neues_passwort>

4. Neustart des Rechners; danach wird die Enterprise Manager Website das neue Passwor nutzen.

1. Am Server mit einem Administrator-Account anmelden
2. SQL Server Management Studio öffnen und mit Windows-Authentifizierung einloggen
3. Neues Abfragefenster öffnen und folgenden Befehl eintragen/ausführen:
   

   exec sp_password @new = 'neues_Passwort', @loginame = 'sa'

4. Im Objekt-Explorer den Punkt “Sicherheit” aufklappen und im Menü “Anmeldungen” auf “sa” doppelklicken.
5. Seite “Status” auswählen und prüfen, ob “Login:” zugelassen ist.

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.

Beim Rollout von 10gR2 wurde SLES10 noch nicht supportet. Da dies mittlerweile aber der Fall ist, gibt es eine sehr detaillierte – wenn auch leider nur englischsprachige – Step by Step Anleitung CoolSolutionsWiki von Novell.
http://www.novell.com/products/server/oracle/oracle10g_install.html

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

Das Poster, das zur Zeit zum Download zur Verfügung steht, basiert auf der ORACLE Database 10g Enterprise Edition 10.2.0.2.0. Es zeigt die Views sortiert nach wichtigen Funktionen.

Es sollte Grundwissen eines jeden ORACLE DBAs sein, aber noch mal zur Erinnerung: V$-Views sind eine Ergänzung zum Data Dictionary und enthalten wertvolle Informationen aus der SGA. Die Views, die ab ORACLE Database 10g neu sind, sind auf dem Poster nach dem Name mit “(10g)” gekennzeichnet. Views, die sich geändert haben (z.B. durch Hinzufügen, Umbenennen oder Löschen von Spalten), sind mit dem Zeichen “(*)” nach dem Name gekennzeichnet.
Darüber hinaus gibt es eine Reihe von GV$-Views, die identisch sind mit den V$-Views, mit dem Zusatz einer Instance ID Spalte (inst_id). Somit können multiple Instancen in einer Umgebung mit mehreren Servern abgefragt werden.

TUSC bietet auch Präsentationen, sortiert nach Autor, Kategorie, Veranstaltung oder Jahr, zu diversen Themen in Bezug auf ORACLE zum Download an. Und unter Miscellaneous Downloads findet man ein paar nette Goodies.

• 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.

C:\>del C:\oracle\ora92\network\log\listener.log
C:\oracle\ora92\network\log\listener.log
Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

Viele DBAs stoppen an dieser Stelle einfach den TNS Listener Prozess, benennen die Datei um oder entfernen sie; danach starten sie den TNS Listener Prozess wieder. Das führt aber zu Verbindungsfehlern bei Benutzern, die in dieser Zeit versuchen, auf die Datenbank zuzugreifen.
Selbst unter Unix kann es zu Problemen kommen, wenn versucht wird, die Datei listener.log umzubenennen, während der TNS Listener Prozess aktiv ist. Wie Windows so blockiert auch Unix den File-Handler. Unter Unix kann allerdings die Datei gelöscht werden, aber ORACLE wird beim nächsten Versuch, die Datei zu beschreiben, diese nicht neu anlegen. Der TNS Listener muss gestoppt und neu gestartet werden, damit die Datei listener.log neu angelegt werden kann.

Hier ist für Windows und Unix nun eine Lösung, wie die Datei listener.log umbenannt oder gelöscht werden kann, ohne den TNS Listener zu stoppen und neu zu starten: