Archiv der Kategorie: DBA

Instant Client und cx_Oracle per yum installieren

Kleine Nachricht am Rande:
Der Oracle Instant Client musste bisher separat heruntergeladen werden. Ein wesentlicher Grund dafür war, dass Oracle sich vor dem Download stets die Lizenzbedingungen bestätigen lassen wollte.
Für Oracle Linux 6 und 7 geht das jetzt aber endlich als Paketinstallation über yum!
Dazu muss (OL7) das Repository „ol7_developer“ aktiviert sein, dann geht das wie folgt:
yum install -y oracle-instantclient18.3-basic
Oder implizit bei der Installation von „cx_Oracle“, dem Python-Modul für Oracle DB-Operationen:
yum install -y python-cx_Oracle

Beides ist eine sinnvolle Verbesserung, da somit

  • Die Installation (und damit auch die Deployment-Automatisierung) vereinfacht wird;
  • Spätere Updates einheitlich über das Paket-Management des Betriebssystems gemacht werden können.

Referenzen

 

Windows Large Pages

Vor einiger Zeit hatte ich hier über Linux HugePages geschrieben. Die sind ja mittlerweile kein Geheimtipp mehr, und ab Oracle 12.2 lässt sich mit dem DBCA sogar eine Datenbank bei einem RAM > 4GB nur noch mit HugePages anlegen (oder es erscheint die Fehlermeldung „[DBT-11211]“).

Etwas anders scheint es nach meinem Eindruck um die Windows Large Pages bestellt zu sein. Da Oracle jedoch ab 4 GB SGA empfiehlt, auch unter Windows die größeren Speicherseiten zu nutzen, möchte ich hier eine kurze Einführung dazu schreiben.

Weiterlesen

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

Schaltsekunde, Linux und Oracle

In wenigen Tagen ist es schon wieder soweit:
Am 1.7.2015 wird der Sekundenzeiger um 01:59:59 Uhr eine Sekunde länger stehenbleiben.

Auf Servern wird das u.U. anders gehandhabt: Hier kann es passieren, dass die UTC-Uhr 23:59:60 anzeigt. Wird so ein Datum in ein DATE-Feld eingefügt, führt das unter Oracle zu einem ORA-01852.
Schlimmer kann es noch bei älteren Linux-Versionen kommen, da kann das System schlicht stehen bleiben oder exzessiv CPU verbrauchen.

Maris Elsins von Pythian hat zwei ausführliche, englische Artikel zum Thema verfasst (1.: Welche Probleme entstehen können, 2.: Umgang mit diesen Problemen unter Linux). Daher liefere ich hier übersetzt nur

Die allerwichtigsten Maßnahmen für Linux in Kürze:

  • ntpd sollte mit der Option „-x“ laufen. Dadurch werden Zeitdifferenzen über einen längeren Zeitraum gestreckt („die Sekunden werden länger“), eine Schaltsekunde wird nicht benötigt.
    Alleine mit dieser Konfiguration können fast alle anderen Probleme umgangen werden.
  • file /etc/localtime“ sollte „no leap seconds“ zurückgeben. Sprich: das Betriebssystem ist nicht für das Einfügen einer Schaltsekunde konfiguriert.
  • Laut Oracle sind Kernel-Versionen von 2.4 bis 2.6.39 von Hängern betroffen. Ab Version 2.6.39-200.29.3 sind die bislang bekannten Bugs gefixt.

Weblinks

Linux Huge Pages: Schnellstart

If you’re not using HugePages, you’re doing it wrong!  (Mark J. Bobak)

Sie haben eine SGA von mehreren GB Größe, dazu mehrere Hundert Sessions auf der Datenbank? Ihr DB-Server läuft unter Linux, aber ohne Einsatz von HugePages? Dann verschenken Sie RAM und CPU-Leistung, und zwar nicht zu knapp!

Über Linux HugePages wurde schon viel geschrieben (s. Literaturliste unten), jedoch hauptsächlich auf Englisch und meist sehr ausgedehnt. Dieser Artikel soll die wichtigsten Fakten und Maßnahmen in Kürze aufzeigen.

Szenario

Ein Praxisbeispiel vorweg: Eine Data Warehouse-DB mit 20 GB SGA und etwa 300 Sessions läuft auf einem Server mit 32 GB RAM. Gelegentlich gerät der Server unter höhere Last und fängt daraufhin an, massiv zu swappen; die Performance geht in die Knie. Was ist passiert?

Weiterlesen

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