Oracle

Auslesen aller ALERT.LOG in einem RAC

Veröffentlicht von

0

Seit Oracle 10g kann man über die View sys.x$dbgalertext die alert.log auslesen. Diese stellt aber nur die Zeilen derjenigen alert.log zur Verfügung, die auf dem Server lesbar ist, an dessen Instance man angemeldet ist. Wie kann man nun aber in einem RAC – Umfeld alle alert.log Weiterlesen →

AAS und andere Key Performance Indikatoren

Veröffentlicht von

4

Das folgende SQL berechnet einige Key performance Indicators einer DB – auf Basis der AWR History Views. Speziell wird hier für Jeden Snapshot Weiterlesen →

Erstellen von Histogrammen über die Laufzeit von SQL Statements

Veröffentlicht von

0

Um einen ersten Überblick um die Laufzeit von SQL Statements, genauer gesagt über die Elapsed_time pro Execution, zu bekommen, nutze ich folgende kleines SQL Abfrage. Dadurch Weiterlesen →

Rebuild einer Tabelle mit einer LONG RAW Spalte

Veröffentlicht von

0

Bei einem Kunden trat das Problem auf, dass das Auslesen einer kleinen Tabelle (25 Zeilen mit 4 Spalten) durchschnittlich über 45 Sekunden (!) dauerte. Nach kurzer Analysze war das Problem <!–more–> klar: Die Tabelle war mal sehr groß gewesen und hatte jetzt nur noch Zeilen im ersten und im letzten Block. Dazwischen lagen ca. 4 GB allokierter, aber ungenutzter Speicher, der bei jedem Lesen überlesen werden musste.

Natürlich war die erste Idee, die Tabelle zu reorganisieren:

ALTER TABLE SMALLTAB move;

Leider hatte diese Tabelle jedoch eine LONG RAW Spalte, so dass dieses Kommando mit dem Fehler

ORA-00997: illegal USE OF LONG datatype

fehlschlug.

Da die LONG RAW Spalten nicht sehr groß waren (die Längen waren überall kleiner als 20.000 Zeichen), konnten wir das Problem in diesem Fall mit Hilfe eines kleinen PL/SQL Programms lösen. Wäre eine oder mehr Spalten länger als 32.767 Zeichen gewesen, hätten wir die Tabellen exportieren, mit TRUNCATE leeren und anschließend wieder importieren müssen.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# Umbenennen der alten
ALTER TABLE SMALLTAB RENAME TO SMALLTAB_OLD;
 
# Anlegen einer neuen
CREATE TABLE SMALLTAB( 
  id                NUMBER NOT NULL
 ,TYPE              NUMBER NOT NULL
 ,record            long raw NOT NULL
);
 
# Füllen der neuen Tabelle mit den Werten aus der alten
SET serveroutput ON
DECLARE
  v_txt VARCHAR(32767 CHAR);
  i     NUMBER              := 0;
BEGIN
  FOR r IN (SELECT id, TYPE, record FROM SMALLTAB_OLD) loop
    i := i + 1;
    v_txt := UTL_RAW.CAST_TO_VARCHAR2(r.record);
    dbms_output.put_line('Row='||i||': '||LENGTH(v_txt));
 
    INSERT INTO SMALLTAB(id,TYPE,record)
    VALUES (r.id, r.type, utl_raw.cast_to_raw(v_txt));
  END loop;
 
  commit;
END;
/
 
# die alte droppen
DROP TABLE SMALLTAB_OLD;

ORA-7445 [kkzgiojt()+8] bei Fast Refreshable MatViews nach dem Einspielen des PSU 11.2.0.3.7

Veröffentlicht von

0

Das Einspielen des Patches 11.2.0.3.7 (PSU) führt bei der Verwendung von Fast Refreshable MatViews unter anderem zu einem ORA-7445 [kkzgiojt()+8].
Dies hat zur Folge, dass alle Fast Refreshable MatViews sich nicht mehr refreshen lassen bzw. nicht mehr refreshed werden.

Dies ist bekannter Oracle Bug 17230530, der seine Ursache im besagten PSU hat. Zu diesem gibt es schon seit einiger Zeit auch den entsprechenden Patch. Dieser ist resp. wird auch in allen nachfolgenden PSU enthalten sein, so dass dieser One-Off Patch nicht mehr manuell nachgezogen werden muss, wenn weitere PSU eingespielt werden.

Detaillierte Informationen befinden sich in der ML Note 1573704.1

In meinem Fall hatte ich Fast Refreshable MatViews – on Commit eingesetzt.
Der Fehler hatte zur Folge, dass zwar alle DML auf den der MatViews zugrundeliegenden Basistabellen noch funktionierten, beim Commit dann aber die Fehlermeldung

ORA-12008: error in materialized view refresh path
ORA-01741: illegal zero-length identifier

auftrat.

Die eigentliche Anwendung, die über einen Applikationserver in Verbindung mit Hypernate auf die DB zugreifft, protokolliert dann immer nur die (Java-) Fehlermeldung 

transaction not active

ohne jedoch irgendwelche Oracle Fehlermeldung auch zu protokollieren.