Schlagwort-Archive: Troubleshooting

Lock-Diagnose im RAC

In meinem Artikel „Diagnose von Locks in Oracle-Datenbanken“ von 2009 hatte ich bereits auf das bei der Oracle-Software mitgelieferte Script „utllockt.sql“ hingewiesen. Dieses Script berücksichtigt jedoch nur Locks auf einer DB-Instanz. Im Cluster-Betrieb kann jedoch eine Verkettung von Locks über mehrere Instanzen hinweg entstehen.

In diesem, kurzen Beitrag möchte ich einen Weg vorstellen, die Funktionalität von „utllockt.sql“ mit reinem SQL und RAC-fähig zu bauen.

Locked?

Bild: Mike Gabelmann / flickr / CC-BY-NC-SA

Weiterlesen

Advertisements

DBMS_SCHEDULER und die Zeitumstellung

Alle (halbe) Jahre wieder kommt die Umstellung zwischen Winterzeit und Sommerzeit. Daher stelle ich hier einen Erfahrungsbericht eines konkreten Troubleshooting-Falles ein, weil sich dabei ein paar Details zum Verhalten des Datenbank-Schedulers rund um die Zeitumstellung lernen lassen.

Anlass war ein Problem eines Kunden, bei dem nach Umstellung auf die Sommerzeit ein Job plötzlich nicht mehr zum richtigen Zeitpunkt ausgeführt wurde. Weiterlesen

JDBC, Linux und reiner Zufall

Read this article in English →

Manche Probleme — besonders die, die nur sporadisch auftreten — sind nicht so leicht zu diagnostizieren und erfordern einen tieferen Einstieg in die Materie. In diesem Praxisbeispiel bedeutet das: SQL*Net Tracing und Verständnis für die Funktionsweise des Betriebssystems, speziell die Generierung von Zufallszahlen.

Der vorliegende Fall eignet sich daher sehr gut, um eine Vorgehensweise beim Troubleshooting von Verbindungen zur Datenbank exemplarisch darzulegen.
Weiterlesen

Security Fix verhindert Recovery

Im „Security Alert Advisory for CVE-2012-3132“ wird vor einer Bedrohung gewarnt, die wieder einmal von David Litchfield entdeckt wurde. Dabei kann mithilfe von Anführungszeichen in Objektnamen SQL-Code eingeschleust und mit SYS-Rechten ausgeführt werden, wenn man

  1. einen autorisierten Zugang zur DB hat,
  2. dieser User CREATE TABLE und CREATE PROCEDURE-Privilegien hat und
  3. dieser User DBMS_STATS ausführen darf.

Im Juli 2012 wurde ein Fix veröffentlicht, jedoch gibt es auch eine Empfehlung von Oracle, wie der Gefahr ohne Einspielung eines Patches zu begegnen ist. Diese Empfehlung hat jedoch Folgen für Recovery oder Klone einer derart behandelten DB:

Weiterlesen

Bug: Basic Table Compression und lang laufende UPDATEs

Im Rahmen eines Projektes, in dem Basic Table Compression eingesetzt wird, bin ich offensichtlich in einen Bug gelaufen. Umgebung:

  • Oracle 11.2.0.3.0, Enterprise Edition
  • Solaris 10

Ziel war die Maskierung von Daten auf einer großen, partitionierten Tabelle, die mit dem Attribut COMPRESS erstellt wurde. Gegenüber einer unkomprimierten Version waren die Laufzeiten für ein Update allerdings zehn- bis zwanzigmal länger und mit 100% CPU-Last während der vollen Laufzeit verbunden.

Hier ein Testfall, der auch ohne Partitionierung (und im Prinzip auch ohne die hier verwendeten Regular Expressions) auskommt: Weiterlesen

Datenbank-Trigger zur Fehlersuche

Bei Fremdanwendungen mit unzugänglichem Code oder auch für ein schnelles Eingrenzen von Fehlern unbekannter Herkunft kann unter Zuhilfenahme einiger, neuerer Trigger-Features ganz bequem mit einem autonomen Schema- oder Database-Trigger ein Logging ausgelöst werden. Der folgende Code protokolliert einen Fehler mit seinem Errorstack und dem zugehörigen SQL und kann damit auch zum Logging von SQL-Exceptions genutzt werden:

DROP TABLE servererror_log
/
CREATE TABLE servererror_log (
  error_datetime TIMESTAMP,
, error_user VARCHAR2(30)
, error_stack VARCHAR2(2000)
, error_backtrace VARCHAR2(4000)
, captured_sql VARCHAR2(4000))
/
CREATE OR REPLACE
TRIGGER log_server_errors
AFTER SERVERERROR
ON SCHEMA -- oder auch "ON DATABASE"
DECLARE
  PRAGMA autonomous_transaction;
  sql_text DBMS_STANDARD.ora_name_list_t;
  n PLS_INTEGER;
  v_stmt VARCHAR2(4000);
BEGIN
  -- Das problematische SQL...
  n := ora_sql_txt(sql_text);
  -- ... besteht ggf. aus mehreren Teilen und wird in einer Schleife wieder zusammengefügt
  FOR i IN 1..n LOOP
    v_stmt := v_stmt || sql_text(i);
  END LOOP;

  INSERT INTO servererror_log
   ( error_datetime
   , error_user
   , error_stack
   , error_backtrace
   , captured_sql )
  VALUES
   ( systimestamp
   , sys.login_user
   , dbms_utility.format_error_stack
   , dbms_utility.format_error_backtrace
   , v_stmt );
  COMMIT;
END log_server_errors;
/
Anmerkung: Dieser Beispielcode ist nicht für den Einsatz in produktiven Umgebungen konzipiert worden!

Hier noch ein paar Links zu den im Beispiel benutzten Features: