Praxistipp · ASPICON Newsarchiv

Ansible und Outbound-Proxy: Ein Environment für alle Plays

Michael Decker — Fri, 06 Nov 2026 09:57:41 +0000

Home → Praxistipp

Ansible und Outbound-Proxy: Ein Environment für alle Plays

Verfasst von Michael Decker
06 November 2026
10:57
Automatisierung, Cheat Sheet, DBA Tipp, Praxistipp

Ein Ansible-Playbook lässt sich mit wenig Aufwand so schreiben, dass es unabhängig von Betriebssystem, Version und einem vorhandenen HTTP-Proxy funktioniert. Es läuft in der Lab-Umgebung ohne Proxy und im Kundennetz mit Outbound-HTTP-Proxy, ohne dass du es anpassen musst. Eine naheliegende Lösung – das Proxy-Environment an jedem Task zu setzen – skaliert schlecht: Jeder neue Task braucht diese Angabe, und ein vergessener Task fällt erst im Netz mit Proxy auf.

Bisher haben wir in unseren Cheat Sheets Befehle und Tests unter die Lupe genommen. Diesmal geht es nicht um einen Befehl, sondern um ein Ansible-Muster, welches dir im Automatisierungs-Alltag helfen kann. Es gibt viele verschiede Möglichkeiten, ein Proxy-Environment mitzugeben, die wir hier nicht alle beleuchten können. Wir definieren in diesem Beitrag das Environment einmal als Variable und binden sie auf Play-Ebene ein. Ein Environment an jedem einzelnen Task entfällt damit. Einen naheliegenden Weg dorthin schauen wir uns zuerst an, denn er hat seine Tücken.

Der Weg: erst mit set_fact

Der naheliegende erste Schritt ist, das Environment in einem Task zusammenzubauen und als Fact abzulegen:

- name: Mein Play
  hosts: all
  environment: "{{ proxy_environment | default({}) }}"
  tasks:
    - name: Build proxy environment
      ansible.builtin.set_fact:
        proxy_environment: >-
          {{
            {
              'http_proxy': proxy_http | default('', true),
              'HTTP_PROXY': proxy_http | default('', true),
              'https_proxy': proxy_https | default('', true),
              'HTTPS_PROXY': proxy_https | default('', true),
              'no_proxy': proxy_no_proxy | default('', true),
              'NO_PROXY': proxy_no_proxy | default('', true)
            }
            | dict2items
            | selectattr('value', 'truthy')
            | items2dict
          }}

Die Lösung funktioniert, erzeugt aber eine unnötige Abhängigkeit zwischen der Initialisierung durch set_fact und der späteren Verwendung.

default('', true):
Behandelt neben undefinierten Variablen auch null und andere falsy Werte. Diese werden durch einen Leerstring ersetzt. Für die anschließende Filterung mit truthy ist das nicht zwingend erforderlich, da dieser Test auch null und andere falsy Werte entfernt.
selectattr('value', 'truthy'):
Entfernt alle Einträge mit falsy Werten aus dem Dictionary. Sind keine Proxy-Variablen definiert beziehungsweise enthalten diese keine gültigen Werte, entsteht ein leeres Dictionary {}. Damit werden keine zusätzlichen Proxy-Umgebungsvariablen gesetzt.
default({}) am Play:
Das Play-Keyword environment wird im Kontext der jeweiligen Task-Ausführung ausgewertet. Das gilt auch für das automatische gather_facts vor den eigentlichen Tasks. Solange proxy_environment durch set_fact noch nicht existiert, verhindert default({}) einen Fehler durch eine undefinierte Variable.
set_fact und mehrere Plays:
set_fact erzeugt eine hostspezifische Variable, die auch in nachfolgenden Plays desselben Playbook-Laufs verfügbar bleibt. Allerdings nur für Hosts, auf denen der Task tatsächlich ausgeführt wurde. Andere Hosts, übersprungene Initialisierungen oder ein direkter Einstieg in ein späteres Play können dazu führen, dass die Variable fehlt. Außerdem wird eine einmal erzeugte Variable nicht automatisch neu berechnet, wenn sich ihre Eingangsvariablen ändern.

Die Lösung: Environment als lazy Variable

Ansible wertet Variablen erst aus, wenn sie benutzt werden. Das nutzen wir: Das Environment wird als Ausdruck definiert, nicht als Task-Ergebnis. Die Definition kann z.B. in group_vars/all.yml oder im Play stehen:

proxy_environment: >-
  {{
    {
      'http_proxy': proxy_http | default('', true),
      'HTTP_PROXY': proxy_http | default('', true),
      'https_proxy': proxy_https | default('', true),
      'HTTPS_PROXY': proxy_https | default('', true),
      'no_proxy': proxy_no_proxy | default('', true),
      'NO_PROXY': proxy_no_proxy | default('', true)
    }
    | dict2items
    | selectattr('value', 'truthy')
    | items2dict
  }}

Im Play genügt dann eine Zeile:

- name: Prepare the hosts user
  hosts: all
  environment: "{{ proxy_environment }}"
  tasks:

    - name: Ausgehende IP ermitteln (Proxy-Test)
      ansible.builtin.uri:
        url: https://icanhazip.com
        return_content: true
      register: proxy_test


    - name: Ergebnis anzeigen
      ansible.builtin.debug:
        msg: "Ausgehende IP: {{ proxy_test.content | trim }}"

Vorteile:

Lazy Evaluation:
Ansible wertet den Jinja2-Ausdruck der Variable proxy_environment bei ihrer Verwendung aus. Die Variable muss daher nicht vorher durch einen Task erzeugt werden. Der Wert ergibt sich aus den zu diesem Zeitpunkt verfügbaren Eingangsvariablen.
Keine Initialisierung erforderlich:
Da proxy_environment bereits über die Variablendefinition verfügbar ist, entfällt der set_fact-Task vollständig. Ebenso ist kein default({}) am Play erforderlich, sofern die zentrale Variablendefinition für alle betroffenen Hosts geladen wird.
Unabhängigkeit von der Ausführungsreihenfolge:
Jedes Play kann proxy_environment unmittelbar verwenden. Es spielt keine Rolle, ob andere Plays zuvor ausgeführt wurden, ob das Playbook über import_playbook eingebunden oder einzeln gestartet wird.
Hostspezifische Auswertung:
Die Definition wird im jeweiligen Hostkontext ausgewertet. Unterschiedliche Hosts können damit unterschiedliche Proxy-Konfigurationen erhalten, ohne dass separate Initialisierungstasks notwendig sind.
Dynamische Auswertung:
Im Gegensatz zu set_fact wird kein einmalig berechnetes Ergebnis gespeichert. Ändern sich die zugrunde liegenden Variablen während des Playbook-Laufs, kann die nächste Auswertung von proxy_environment diese Änderungen berücksichtigen.
Zentrale Wartung:
Die Proxy-Logik existiert nur an einer Stelle. Jedes Play benötigt lediglich environment: "{{ proxy_environment }}". Änderungen an der Filterung oder den unterstützten Proxy-Variablen müssen deshalb nicht in mehreren Tasks gepflegt werden.

Fazit

Ein Keyword auf Play-Ebene und eine lazy Variable ersetzen die Task-Lösung. Du pflegst das Proxy-Environment an einer einzigen Stelle, jedes Play bindet es mit einer Zeile ein, und das Playbook läuft mit und ohne Proxy, ohne dass du etwas anpassen musst.

Der Vorteil zeigt sich vor allem im Alltag: Beim nächsten Playbook musst du nicht mehr überlegen, ob der Proxy schon gesetzt wurde. Und wenn du zwischen Lab und Kundennetz wechselst, bleibt die Proxy-Logik dort, wo sie hingehört.

Hier findest du weitere » Cheat Sheets die dir das Leben als Linux-Admin leichter machen.

Share this article

Der Beitrag Ansible und Outbound-Proxy: Ein Environment für alle Plays erschien zuerst auf ASPICON.

Bash Cheat Sheet: Vergleichsoperatoren & Tests

Michael Decker — Fri, 04 Sep 2026 12:00:40 +0000

Home → Praxistipp

Bash Cheat Sheet: Vergleichsoperatoren & Tests

Verfasst von Michael Decker
04 September 2026
14:00
Cheat Sheet, DBA Tipp, Linux, Praxistipp

Kennt ihr das? Ihr benötigt Befehle, Operatoren und kleine Helfer für eure tägliche Arbeit als DBA oder Infrastruktur-Administrator gerade oft genug, um zu wissen, dass es sie gibt. Die genaue Syntax habt ihr aber bis zum nächsten Einsatz schon wieder vergessen.

Mir geht es zumindest regelmäßig so. Gerade bei Bash sind es oft die kleinen Details: Wie prüfe ich nochmal, ob eine Datei existiert und nicht leer ist? Und kann ich eigentlich prüfen, ob eine Datei ein Hardlink ist?

Genau dafür habe ich mir ein kleines Bash Cheat Sheet zusammengestellt. Daraus möchte ich heute einen kleinen Auszug zum Thema Vergleichsoperatoren und Tests mit euch teilen. Kein Bash-Grundkurs, sondern eine schnelle Gedächtnisstütze für den nächsten „Wie war das nochmal?”-Moment.

Vergleich von Strings

STRING1 = STRING2   : Wahr, wenn beide Strings identisch sind. Verwendung mit dem Test-Kommando [ ... ]
STRING1 == STRING2  : Wahr, wenn beide Strings übereinstimmen. Innerhalb von [[ ... ]]

STRING1 =~ STRING2  : Wahr, wenn STRING1 zum angegebenen regulären Ausdruck (REGEX) passt
STRING1 != STRING2  : Wahr, wenn beide Strings nicht identisch sind

Beispiel: String mit regulärem Ausdruck prüfen

In dem nachfolgenden Beispiel wird der vollständige Hostname des Systems mit ‘hostname ‑f‘ ermittelt und anschließend gegen ein fest definiertes Namensschema geprüft. Erwartet wird ein Hostname nach dem Muster ‘-..‘, zum Beispiel ‘postgres-01.example.com‘. Entspricht der ermittelte Hostname diesem Aufbau, wird die Prüfung erfolgreich abgeschlossen; andernfalls bricht das Skript mit einem Fehler ab.

# Vollständigen Hostnamen ermitteln
HOSTNAME="$(hostname -f)"

# Prüfen, ob der Hostname dem Schema "-.." entspricht
if [[ "${HOSTNAME}" =~ ^[[:alnum:]-]+-[0-9]{2}\.[[:alnum:]-]+\.[[:alpha:]]+$ ]]; then
    echo "Hostname entspricht dem erwarteten Namensschema: ${HOSTNAME}"
else
    echo "Hostname entspricht nicht dem erwarteten Namensschema: ${HOSTNAME}"
    exit 1
fi

Aufschlüsselung des Regex:

^                  # Anfang des Strings
[[:alnum:]-]+      # String aus Buchstaben, Ziffern und "-"
-                  # Trennzeichen vor der Nummer
[0-9]{2}           # Genau zwei Ziffern
\.                 # Punkt
[[:alnum:]-]+      # Domain
\.                 # Punkt
[[:alpha:]]+       # TLD aus Buchstaben
$                  # Ende des Strings

Vergleich von Zahlen

-eq :    =
-ne :    !=
-gt :    >
-ge :    >=
-lt :    <
-le :    <=

Beispiel: Numerischer Vergleich – „größer oder gleich“

Vor dem Start eines Backups wird geprüft, ob auf dem Ziel-Dateisystem noch ausreichend freier Speicherplatz vorhanden ist. Der aktuell verfügbare Speicherplatz wird mit df ermittelt und anschließend mit einem definierten Mindestwert verglichen. Nur wenn der verfügbare Speicherplatz größer oder gleich dem Mindestwert ist, wird die Verarbeitung fortgesetzt.

BACKUP_DIR="/backup"
MIN_FREE_SPACE_GB=20

# Verfügbaren Speicherplatz des Backup-Dateisystems in GiB ermitteln
FREE_SPACE_GB="$(df --output=avail -BG "${BACKUP_DIR}" | tail -n 1 | tr -dc '0-9')"

# Prüfen, ob mindestens der benötigte Speicherplatz verfügbar ist
if [[ "${FREE_SPACE_GB}" -ge "${MIN_FREE_SPACE_GB}" ]]; then
    echo "Ausreichend Speicherplatz vorhanden."
else
    echo "Nicht ausreichend Speicherplatz vorhanden."
    exit 1
fi

Der eigentliche Vergleich ist:

[[ "${FREE_SPACE_GB}" -ge "${MIN_FREE_SPACE_GB}" ]]

Dabei steht ‑ge für greater than or equal, also: >= .

Dateien, Verzeichnisse & Co. testen

Manchmal muss ein Skript herausfinden, womit es überhaupt arbeitet. Gibt es das Backup-Verzeichnis? Existiert die Konfigurationsdatei? Ist ein Pfad ein symbolischer Link? Ist ein Socket vorhanden?

Dafür bringt Bash eine ganze Reihe fertiger Tests mit:

-d FILE        # FILE ist ein Verzeichnis
-b FILE        # FILE ist ein Blockgerät
-c FILE        # FILE ist ein Zeichengerät
-p FILE        # FILE ist eine Pipe
-h FILE        # FILE ist ein symbolischer Link
-L FILE        # FILE ist ein symbolischer Link
-S FILE        # FILE ist ein Socket
-t DESCRIPTOR  # File-Descriptor ist mit einem Terminal verbunden

Für reguläre Dateien und deren Eigenschaften sind vor allem diese Kandidaten praktisch:

-e FILE        # FILE existiert
-f FILE        # FILE ist eine reguläre Datei
-r FILE        # FILE ist lesbar
-s FILE        # FILE existiert und ist nicht leer
-w FILE        # FILE ist beschreibbar
-x FILE        # FILE ist ausführbar

Rechte und Besitzer prüfen

Auch einige speziellere Dateieigenschaften lassen sich direkt abfragen:

-g FILE        # Set-GID-Bit (SGID) ist gesetzt
-u FILE        # Set-UID-Bit (SUID) ist gesetzt
-k FILE        # Sticky-Bit ist gesetzt

-O FILE        # FILE gehört dem aktuellen Benutzer
-G FILE        # FILE gehört zur effektiven Gruppe
-N FILE        # FILE wurde seit dem letzten Lesen verändert

Gerade wenn Skripte mit unterschiedlichen Benutzern oder Berechtigungen laufen, können solche Checks helfen, Voraussetzungen frühzeitig zu überprüfen, statt erst beim eigentlichen Befehl in einen Fehler zu laufen.

Leere Strings erkennen

Eine weitere kleine, aber nicht ganz triviale Prüfung, um beispielsweise einen fehlenden Datenbanknamen abzufangen:

-z STRING      # STRING ist leer
-n STRING      # STRING ist nicht leer

Gerade bei Skripten, die Werte über Parameter oder Umgebungsvariablen erhalten, ist das schnell eingebaut und verhindert, dass mit unvollständigen Angaben weitergearbeitet wird.

Welche Datei ist neuer?

Auch Dateien lassen sich direkt anhand ihres Änderungszeitpunkts vergleichen:

FILE1 -nt FILE2     # FILE1 ist neuer als FILE2
FILE1 -ot FILE2     # FILE1 ist älter als FILE2

So lässt sich ohne zusätzlichen stat-Aufruf entscheiden, ob ein weiterer Verarbeitungsschritt notwendig ist.

Für den nächsten „Wie war das nochmal?“-Moment

Natürlich ist das nur ein Ausschnitt dessen, was sich mit Bash abbilden lässt. Aber genau diese Vergleiche und Tests tauchen im Admin-Alltag eben ab und zu mal wieder auf: Werte vergleichen, Schwellwerte prüfen, Dateien und Verzeichnisse validieren oder sicherstellen, dass die Voraussetzungen für den nächsten Schritt stimmen.

Die Herausforderung ist dabei oft gar nicht, wie sich eine bestimmte Prüfung umsetzen lässt. Vielmehr muss man erst einmal wissen – oder sich daran erinnern –, was Bash bereits von Haus aus mitbringt. Bevor man also selbst einen umständlichen Test baut, lohnt sich manchmal ein kurzer Blick auf die vorhandenen Operatoren. Genau dafür ist dieses Cheat Sheet gedacht: nicht zum Bash-Lernen von null an, sondern als Gedächtnisstütze, wenn die Lösung eigentlich bekannt ist – nur die verdammte Syntax gerade nicht mehr.

Im nächsten Teil geht es dann um String-Manipulation und Variablen – also unter anderem darum, Dateinamen und Pfade direkt mit Bash-Bordmitteln auseinanderzunehmen, Default-Werte zu setzen und mit Bash-Sondervariablen zu arbeiten.

Hier findest du weitere » Cheat Sheets die dir das Leben als Linux-Admin leichter machen.

Share this article

Der Beitrag Bash Cheat Sheet: Vergleichsoperatoren & Tests erschien zuerst auf ASPICON.

Cheat Sheet: OpenSSL für Zertifikate

Michael Decker — Tue, 04 Aug 2026 11:57:53 +0000

Home → Praxistipp

Cheat Sheet: OpenSSL für Zertifikate

Verfasst von Michael Decker
04 August 2026
13:57
Cheat Sheet, DBA Tipp, Linux, Praxistipp

Ab und zu spült mir der Algorithmus verschiedene “Cheat Sheets” in die Timeline. Viele davon enthalten mehr oder weniger vollständige Sammlungen von grundlegenden Befehlen z.B. für Podman, Docker und Kubernetes oder auch Ansible, Terraform und unzählige weitere Tools.

Das ist durchaus interessant. Trotzdem frage ich mich häufig, ob ein Cheat Sheet mit den Basics von 200 verschiedenen Tools im Arbeitsalltag wirklich weiterhilft.

Deshalb teile ich hier künftig Tipps aus meinem Admin-Alltag – praxisnah, ohne Buzzwords und mit dem Fokus auf Dinge, die sich im täglichen Betrieb bewährt haben. Heute habe ich zwei einfache OpenSSL-Befehle für dich, die dir in typischen Alltagssituationen weiterhelfen werden.

Das ist durchaus interessant. Trotzdem frage ich mich häufig, ob ein Cheat Sheet mit den Basics von 200 verschiedenen Tools im Arbeitsalltag wirklich weiterhilft.

Stell dir vor, du bist ein “DevOps Engineer” – oder wie das früher mal hieß: “Linux Admin” – und möchtest nach einem Deployment oder einer Infrastrukturänderung schnell prüfen, ob ein Service wie erwartet erreichbar ist.

Typische Situationen sind beispielsweise:

Kontrolle nach Deployments
Untersuchung von Störungen
Netzwerk- und Infrastruktur-Changes
“Transparente” Proxies

In genau solchen Fällen gehören für mich netcat und openssl zu den Werkzeugen, auf die ich immer wieder zurückgreife.

1. Schnell prüfen, ob ein Service erreichbar ist

Mein erster Griff geht fast immer zu netcat (nc). Wenn ich herausfinden möchte, ob ein Dienst überhaupt auf dem erwarteten Host und Port lauscht, reicht oft schon ein einfacher TCP-Check:

nc -vz

Damit lässt sich in wenigen Sekunden feststellen, ob grundsätzlich eine TCP-Verbindung aufgebaut werden kann.

2. Wenn der Port offen ist – der Client aber trotzdem nicht funktioniert

Manchmal reicht ein offener Port allerdings nicht aus. Der Dienst ist erreichbar, der Client verbindet sich trotzdem nicht oder das Zertifikat scheint Probleme zu verursachen. Die entsprechenden Fehler- oder Logmeldungen sind nicht immer so eindeutig, wie man sich das wünscht.

In diesen Fällen ist folgender Befehl für mich einer der wertvollsten Helfer.

Instruiere OpenSSL doch bitte, als Client mit FQDN an Port PORT zu sprechen und zu fragen, wie das Zertifikat aussieht.

openssl s_client -showcerts -connect :

Beispiel:

openssl s_client -showcerts -connect foo.bar.lan:25

Der Befehl baut eine Verbindung zum Dienst auf und zeigt unter anderem das präsentierte Zertifikat an.

Noch übersichtlicher wird die Ausgabe mit:

openssl s_client -showcerts -connect :

Damit erhältst du die Zertifikatsinformationen in einer deutlich besser lesbaren Form. Anschließend kannst du die Ausgabe nach Belieben weiter filtern – beispielsweise mit grep, um gezielt nach Informationen wie Issuer, Subject, Not Before oder Not After zu suchen.

SNI nicht vergessen

Gerade bei Load Balancern oder Webservern mit mehreren virtuellen Hosts kann es notwendig sein, zusätzlich den gewünschten Servernamen per SNI (Server Name Indication) mitzugeben. Andernfalls bekommst du möglicherweise das falsche Zertifikat präsentiert.

Das sieht dann beispielsweise so aus:

openssl s_client -showcerts \
-servername bar.foo.lan \
-connect bar.foo.lan:443

Fazit

Natürlich kann OpenSSL deutlich mehr, als nur als Client auftreten. Zusammen mit Werkzeugen wie nc, curl, dig, ss oder netstat gehört es für mich zu den wichtigsten Helfern bei der täglichen Fehlersuche.

Wenn es darum geht, Services mit TLS-Zertifikaten schnell zu überprüfen, lassen sich mit den beiden vorgestellten Befehlen die Fehlerquellen schnell und zuverlässig eingrenzen.

Hier findest du weitere » Cheat Sheets die dir das Leben als Linux-Admin leichter machen.

Share this article

Der Beitrag Cheat Sheet: OpenSSL für Zertifikate erschien zuerst auf ASPICON.

Härtung von Oracle Linux Betriebssystemen Teil II

Isabel Dahl — Tue, 17 Jun 2025 06:20:00 +0000

Home → Praxistipp

Härtung von Oracle Linux Betriebssystemen Teil II

Verfasst von Isabel Dahl
17 Juni 2025
08:20
Oracle, Oracle Linux, Praxistipp, Security

Deine Oracle Linux Betriebssysteme sind das Herzstück deiner IT und verdienen damit in puncto Sicherheit besondere Aufmerksamkeit. Diese auf ein Top-Niveau zu bringen ist kein Hexenwerk, wenn du weißt, wo du ansetzen musst.

Der CIS Benchmark Report liefert dir eine klare Analyse potenzieller Schwachstellen. In unserer Beitragsserie zur IT-Sicherheit navigieren wir dich durch den Fachjargon und erklären die wichtigsten Aspekte des Reports – verständlich, praxisnah und auf den Punkt gebracht. Denn echte Sicherheit beginnt mit dem Verständnis, und dem richtigen Partner!

Teil I unserer Beitragsserie “Härung von Oracle Linux Betriebssystemen” drehte sich um den Bereich “Netzwerkkonfiguration”. Außerdem haben wir dort einige wichtige Punkte zum allgemeinen Verständnis des CIS Benchmark Reports erörtert. Falls du nochmal nachlesen möchtest: » Hier der Link

Heute werfen wir unseren Blick auf den zweiten Teil des CIS Benchmark Reports und verraten dir, welche Dienste du möglichst deaktivieren oder zumindest maskieren solltest, wie du dein Betriebssystem auf Sparflamme installieren kannst und warum auch ausgewählte Service Clients entfernt werden sollten.

Ausgewählte Empfehlungen zur Härtung eines Oracle Linux Betriebssystems
Teil II: Services

Eine der besten Möglichkeiten, das System vor (noch nicht gemeldeten) Schwachstellen zu schützen, liegt darin, alle Dienste zu deaktivieren, die für den normalen Betrieb des Systems nicht erforderlich sind. Dies verhindert die Ausnutzung von Sicherheitslücken, die möglicherweise erst zu einem späteren Zeitpunkt entdeckt werden. Denn wenn ein Dienst nicht aktiviert ist, kann er auch nicht ausgenutzt werden. Die Maßnahmen im Abschnitt “Services” des CIS Reports geben Hinweise darauf, welche Dienste unter welchen Umständen sicher deaktiviert oder besser maskiert werden können.

Punkt 1: Spezielle Dienste deaktivieren / maskieren

Im Folgenden haben wir einige Dienste aufgeführt, die du in deinen Systemen – abhängig von der Rolle des jeweiligen Systems – deaktivieren solltest:

Avahi Server
CUPS Server
DHCP Server
DNS Server
VSFTP Server
TFTP Server
HTTP Proxy Server
SNMP Server
NFS Server
Rsync Daemon

Falls die Installation aufgrund von Paketabhängigkeiten unumgänglich ist, sollten die zugehörigen Dienste zumindest maskiert werden.

Beachte bitte, dass es sich dabei lediglich um einen Auszug aus dem CIS Report handelt und die Liste keinen Anspruch auf Vollständigkeit erhebt. Außerdem solltest du im Vorfeld genau prüfen, ob die Deaktivierung mögliche Auswirkungen auf deinen Systembetrieb haben könnte.

Punkt 2: Betriebssysteminstallation auf Sparflamme

Bereits bei der Betriebssysteminstallation eines Linuxservers kannst du unnötige Dienste weitgehend außen vor lassen, indem du das Minimalprofil anstelle des Serverprofils wählst. Unbedingt für die Rolle des Systems erforderliche Dienste, die nicht im Minimalumfang enthalten waren, installierst du dann später einfach nach.

Ein Blick auf die aktuell auf deinem System gebundenen Ports kann ein guter Einstieg sein, um zu überprüfen, welche Dienste Verbindungen “von außen” annehmen würden und ob diese tatsächlich für das betreffende System erforderlich sind. Hierzu kannst du beispielsweise den Befehl “ss” aus dem iproute-Paket nutzen. In der Ausgabe sind insbesondere die Spalten “Local Address:Port” und “Process” von Interesse:

# ss -tulpn
Netid State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process 
udp   UNCONN  0       0             0.0.0.0:23149      0.0.0.0:*     users:(("rpc.statd",pid=133747,fd=8)) 
udp   UNCONN  0       0             0.0.0.0:111        0.0.0.0:*     users:(("rpcbind",pid=133741,fd=5),("systemd",pid=1,fd=117)) 
udp   UNCONN  0       0           127.0.0.1:323        0.0.0.0:*     users:(("chronyd",pid=159183,fd=5)) 
udp   UNCONN  0       0             0.0.0.0:41579      0.0.0.0:* 
udp   UNCONN  0       0           127.0.0.1:787        0.0.0.0:*     users:(("rpc.statd",pid=133747,fd=5)) 
udp   UNCONN  0       0                [::]:62413         [::]:* 
udp   UNCONN  0       0                [::]:31278         [::]:*     users:(("rpc.statd",pid=133747,fd=10)) 
udp   UNCONN  0       0                [::]:111           [::]:*     users:(("rpcbind",pid=133741,fd=7),("systemd",pid=1,fd=119)) 
udp   UNCONN  0       0               [::1]:323           [::]:*     users:(("chronyd",pid=159183,fd=6)) 
tcp   LISTEN  0       64            0.0.0.0:32043      0.0.0.0:* 
tcp   LISTEN  0       4096          0.0.0.0:23927      0.0.0.0:*     users:(("rpc.statd",pid=133747,fd=9)) 
tcp   LISTEN  0       128           0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=158566,fd=3)) 
tcp   LISTEN  0       4096          0.0.0.0:111        0.0.0.0:*     users:(("rpcbind",pid=133741,fd=4),("systemd",pid=1,fd=115)) 
tcp   LISTEN  0       64               [::]:21585         [::]:* 
tcp   LISTEN  0       128              [::]:22            [::]:*     users:(("sshd",pid=158566,fd=4)) 
tcp   LISTEN  0       4096             [::]:111           [::]:*     users:(("rpcbind",pid=133741,fd=6),("systemd",pid=1,fd=118)) 
tcp   LISTEN  0       4096             [::]:19055         [::]:*     users:(("rpc.statd",pid=133747,fd=11)) 
```

Punkt 3: Service Clients konfigurieren

Wie im Punkt 1 bereits genannt, gibt es eine Reihe von potenziell unsicheren Diensten. Wenngleich die Deaktivierung der Serverseite dieser Dienste einen erfolgreichen Angriff verhindert, ist es zusätzlich ratsam, auch die entsprechenden Clients aus der Infrastruktur zu entfernen, sofern sie nicht benötigt werden. Ein Client ist zwar nicht direkt angreifbar, seine unbedarfte Nutzung kann aber durchaus Informationen ins Netzwerk streuen, die abgefangen und missbräuchlich verwendet werden können (z.B. unverschlüsselte Passworte, Informationen über die Infrastruktur etc).

Typische Clients, die in der Regel nicht benötigt werden und daher entfernt werden sollten, sind:

telnet client
LDAP client
TFTP client
FTP client

Bitte beachte, dass es sich bei den genannten Punkten lediglich um einen Bruchteil der Themen handelt, die im Report beleuchtet werden. Sie sollen dir lediglich einen Eindruck der Herangehensweise vermitteln. In weiterführenden Beiträgen werden wir uns noch weitere Punkte anschauen.

Selbstverständlich lassen sich die CIS Benchmark Reports auch für andere Enterprise Linux Betriebssysteme wie Red Hat Enterprise Linux erstellen sowie für Oracle Datenbanken, SQL Server Datenbanken und Windows Server Betriebssysteme.

Du hast Fragen dazu oder benötigst Unterstützung?
Ruf uns gern an oder schreibe uns.

Kontakt

Marcel
Senior Account Manager bei ASPICON

Hier findest du weitere Infos rund um Oracle und Security aus unserem News & Insights Bereich.

Share this article

Der Beitrag Härtung von Oracle Linux Betriebssystemen Teil II erschien zuerst auf ASPICON.

DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen

Thilo Solbrig, Oracle Certified Master — Wed, 04 Jun 2025 07:40:01 +0000

Home → Praxistipp

DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen

Verfasst von Thilo Solbrig, Oracle Certified Master
04 Juni 2025
09:40
Datenbank, DBA Tipp, Oracle, Performance Tuning, Praxistipp

Nach größeren Löschoperationen entstehen Lücken in Datenblöcken, die sich negativ auf Performance und Platzbelegung auswirken. Werden sie in der Tabelle nicht zeitnah durch neue Daten aufgefüllt, empfiehlt sich ein Online-Shrink der betroffenen Tabellen. Ein Ansatz zur Abschätzung stark fragmentierter Tabellen wird in diesem DBA-Tipp vorgestellt.

Warum überhaupt defragmentieren?

Das Löschen einer größeren Menge von Zeilen aus einer Tabelle führt in aller Regel dazu, dass die Datenblöcke der Tabelle stark fragmentiert werden. Das heißt es gibt dann also viele Blöcke, die nur wenige Daten enthalten. Diese Fragmentierung hat zwei wesentliche Nachteile:

Verschwendung von Speicherplatz, wenn die Lücken nicht im Laufe der Zeit wieder durch neue Zeilen gefüllt werden. Da der Freiplatz fest von einer bestimmten Tabelle allokiert ist, steht er auch keinen anderen Objekten in der Datenbank zur Verfügung.
Auch wenn der Platz nach und nach wiederverwendet wird, wirkt sich diese Fragmentierung bis dahin negativ auf die Performance aus. Der Buffer Cache der Datenbank, eine der wichtigsten Komponenten im Bezug auf Datenbankperformance, arbeitet rein blockbasiert. Folglich verschwenden Datenblöcke einer Tabelle Platz im Buffer Cache, wenn sie fragmentiert sind, da auch der leere Anteil im Block auf den Buffer Cache angerechnet wird. Die „Nutzdatenrate“ ist damit schlechter als bei unfragmentierten Blöcken, die Performance sinkt durch eine geringere Buffer Cache Hit Ratio.

Es kann also nach größeren Löschoperationen interessant sein, welche Tabellen mittels:

alter table … shrink space cascade;

geshrinkt werden können, um zum einen unbelegten Platz freizugeben und zum anderen die Buffer Cache Effizienz hoch zu halten. Dafür kannst du dir zwei Tabellenstatistiken zu Nutze machen – die Zeilenzahl und die durchschnittliche Zeilenlänge – und diese mit der tatsächlichen Platzbelegung in Bezug setzen. Es ist zu beachten, dass es sich dabei nicht um exakte Werte handelt. Wenn die Statistiken jedoch aktuell sind, stellen sie für diesen Zweck recht zuverlässige Schätzungen dar. Grundsätzlich kannst du davon ausgehen, dass Tabellen, in denen große Datenmengen gelöscht wurden, auch vom nächtlichen Autotask „auto optimizer stats collection“ erkannt und analysiert wurden. Andernfalls rechnest du mit geeigneten Prozeduren des dbms_stats-Package die Statistiken einfach selbst neu.

Vergleich erwarteter Platzbedarf und tatsächlich belegter Platz

Zur Abschätzung des Platzes, den wir durch das Shrinken voraussichtlich einsparen, stellen wir nun einen Vergleich zwischen dem erwarteten Platzbedarf (Zeilenzahl * durchschnittliche Zeilenlänge) und dem tatsächlich belegten Platz (Summe der Segmentgrößen) an:

WITH table_subset AS
( SELECT owner,table_name
FROM dba_tables
WHERE owner='SOE'
)
SELECT exp.owner,
exp.table_name,
ROUND((used_space-expected_space)/power(1024,2)) estimated_savings_mb,
used_space,
expected_space,
ROUND((1-expected_space/used_space)*100) estimated_savings_pct
FROM
(SELECT owner,
table_name,
num_rows*avg_row_len expected_space
FROM dba_tables t
WHERE (owner,table_name) IN
(SELECT * FROM table_subset s)
AND num_rows IS NOT NULL
AND avg_row_len IS NOT NULL
) exp,
(SELECT owner,
segment_name,
SUM(bytes) used_space
FROM dba_segments
WHERE (owner,segment_name) IN
(SELECT * FROM table_subset s)
GROUP BY owner,
segment_name
HAVING SUM(bytes)>0
) used
WHERE exp.owner =used.owner
AND exp.table_name=used.segment_name
ORDER BY estimated_savings_mb DESC

Wie wir sehen, hat in unserem Beispiel die Tabelle SOE.ORDER_ITEMS ein Einsparungspotenzial von ca. 1.1GB. Sie belegt aktuell 1.4 GB Platz, obwohl sie gemäß ihrer Statistiken nur 209 MB belegen müsste. Wir können sie also als einen geeigneten Kandidaten für eine Online-Shrink-Operation ansehen:

ALTER TABLE SOE.ORDER_ITEMS ENABLE ROW MOVEMENT;
ALTER TABLE SOE.ORDER_ITEMS SHRINK SPACE CASCADE;

Eine erneute Auswertung zeigt, dass die Tabelle, wie erwartet, ihren ungenutzten Platz freigegeben hat. Im Tablespace stehen nun 1.1GB mehr Platz zur freien Verfügung.

Am Beginn des SELECT-Statements findest du die Inline-View

WITH table_subset AS
( SELECT owner,table_name
FROM dba_tables
WHERE owner='SOE'
)

Hierüber kannst du einstellen, welche Tabellen in die Betrachtung einbezogen werden sollen. Wir beschränken uns hier zum Beispiel auf das Schema SOE. Eine Auswertung über alle Tabellen einer Datenbank dürfte meist zu lange dauern und auch nur selten erforderlich sein. So ist zum Beispiel das Shrinken von SYS-Objekten ohnehin nicht empfohlen und in vielen Fällen auch nicht möglich.

Fazit

Größere Löschoperationen führen häufig zu Fragmentierung in Oracle-Tabellen – mit negativen Auswirkungen auf Speicherplatz und Performance. Der vorgestellte Ansatz ermöglicht es dir als DBA, stark fragmentierte Tabellen systematisch zu identifizieren und gezielt per Online-Shrink zu optimieren. So lassen sich ungenutzte Reserven im Tablespace freigeben und die Effizienz des Buffer Caches nachhaltig verbessern.

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen erschien zuerst auf ASPICON.

Härtung von Oracle Linux Betriebssystemen Teil I

Isabel Dahl — Wed, 02 Apr 2025 12:57:30 +0000

Home → Praxistipp

Härtung von Oracle Linux Betriebssystemen Teil I

Verfasst von Isabel Dahl
02 April 2025
14:57
Oracle, Oracle Linux, Praxistipp, Security

In der IT-Sicherheit gibt es keine Kompromisse – besonders, wenn es um geschäftskritische Infrastrukturen wie deine Oracle Linux Betriebssysteme geht. Als IT-Dienstleister im Bereich Datenbanken und datenbankbasierte IT-Systeme wissen wir: Eine ungehärtete Umgebung ist ein gefundenes Fressen für Angreifer.

Doch welchen Parametern solltest du bei der Härtung besondere Aufmerksamkeit schenken? Ein CIS Benchmark Report kann hier für Klarheit sorgen. Mit dem Report können deine Systeme detailliert auf potenzielle Schwachstellen analysiert werden, um Sicherheitsrisiken zu erkennen.

Das ist dir alles zu abstrakt? Kein Problem! In unserer neuen Beitragsreihe stellen wir dir ausgewählte Parameter aus den CIS Benchmarks vor und erklären deren Bedeutung. Das hilft dir möglicherweise dabei, Licht ins Dunkel zu bringen – denn Sicherheit beginnt mit Wissen!

Allgemeines zum CIS Benchmark Report für die Härtung eines Oracle Linux Betriebssystems

Kurz zum allgemeinen Verständnis des CIS Benchmark Reports: Der Report zeigt dir, inwiefern das gescannte System den Sicherheitsempfehlungen innerhalb des gewünschten Security Levels (1 oder 2) des Center for Internet Security (CIS) folgt. Der Grad der Erfüllung bemisst sich systemübergreifend und zusätzlich für einzelne Themenkomplexe jeweils mit einem ungewichteten, prozentualen Score (Score / Max). Ziel sollte es stets sein, sich mit vertretbaren Härtungsmaßnahmen der 100% Marke bestmöglich zu nähern.

Folgende Themenkomplexe werden im CIS Benchmark Report beleuchtet:

Netzwerkkonfiguration
Konfiguration spezieller Dienste und Service Clients
Zugang, Authentifizierung und Autorisierung
Logging and Auditing
Systemwartung

Im ersten Teil unserer Beitragsreihe schauen wir uns ausgewählte Punkte aus dem Bereich der Netzwerkkonfiguration an. Wir haben für unser Beispiel eine Oracle Linux 9 Konfiguration gewählt.

Teil I – Netzwerkkonfiguration: Ausgewählte Empfehlungen zur Härtung eines Oracle Linux Betriebssystems

Punkt 1: Deaktivieren nicht verwendeter Netzwerkprotokolle und ‑geräte

Im Abschnitt “Netzwerkkonfiguration” des CIS Reports erfährst du alles zur Sicherung der Netzwerkkonfiguration deiner Systeme durch Kernelparameter, Zugriffslistenkontrolle und Firewall-Einstellungen. Ein Beispiel ist das Deaktivieren nicht verwendeter Netzwerkprotokolle und ‑geräte: Um die Angriffsfläche deiner Systeme zu verringern, sollten nicht verwendete Netzwerkprotokolle und ‑geräte deaktiviert werden. Die Linux-Kernelmodule unterstützen mehrere Netzwerkprotokolle, die nicht häufig verwendet werden. Wenn diese Protokolle nicht benötigt werden, empfiehlt es sich, sie im Kernel zu deaktivieren.

Punkt 2: Sicherstellen, dass ICMP-Umleitungen nicht akzeptiert werden

ICMP-Redirect-Nachrichten sind Pakete, die Routing-Informationen übermitteln und den Host (der als Router fungiert) anweisen, Pakete über einen alternativen Pfad zu senden. Auf diese Weise kann ein externes Routing-Gerät die Routing-Tabellen deines Systems aktualisieren. Angreifer könnten gefälschte ICMP-Redirect-Nachrichten verwenden, um die Routing-Tabellen des Systems böswillig zu verändern und sie dazu zu bringen, Pakete an falsche Netzwerke zu senden, so dass deine Systempakete abgefangen werden können. Deine Systeme sollten also keine ICMP-Redirect-Nachrichten akzeptieren.

Punkt 3: Sicherstellen, dass Broadcast-ICMP-Anfragen ignoriert werden

Die Annahme von ICMP-Echo- und Zeitstempel-Anfragen mit Broadcast- oder Multicast-Zielen für dein Netzwerk könnte dazu verwendet werden, deinen Host dazu zu bringen, einen Smurf-Angriff zu starten (oder daran teilzunehmen). Ein Smurf-Angriff beruht darauf, dass ein Angreifer große Mengen von ICMP-Broadcast-Nachrichten mit einer gefälschten Quelladresse sendet. Alle Hosts, die diese Nachricht empfangen und darauf antworten, senden Echo-Antwort-Nachrichten an die gefälschte Adresse zurück, die wahrscheinlich nicht routbar ist. Wenn viele Hosts auf die Pakete antworten, könnte sich der Datenverkehr im Netz erheblich vervielfachen. Deine Systeme sollten also möglichst alle ICMP-Echo- und Zeitstempel-Anfragen an Broadcast- und Multicast-Adressen ignorieren.

Du hast Fragen dazu oder benötigst Unterstützung?
Ruf uns gern an oder schreibe uns.

Kontakt

Marcel
Senior Account Manager bei ASPICON

Hier findest du weitere Infos rund um Oracle und Security aus unserem News & Insights Bereich.

Share this article

Der Beitrag Härtung von Oracle Linux Betriebssystemen Teil I erschien zuerst auf ASPICON.

DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen

Isabel Dahl — Thu, 20 Feb 2025 14:20:16 +0000

Home → Praxistipp

DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen

Verfasst von Isabel Dahl
20 Februar 2025
15:20
Backup & Recovery, Datenbank, DBA Tipp, Oracle, Praxistipp

Oracle bietet in seinen Datenbankprodukten das Feature Flashback an. Mittels Flashback ist es möglich, einzelne Daten in der Datenbank oder die komplette Datenbank zu einem früheren Zeitpunkt wiederherzustellen. Dabei werden die Daten durch logische Operationen wiederhergestellt, wie beispielsweise durch Zurückrollen von Transaktionen.

In diesem DBA Tipp beschäftigen wir uns mit den Voraussetzungen für die Nutzung von Oracle Flashback und stellen dir die verschiedenen Varianten sowie deren Einsatzgebiete vor.

Voraussetzungen für die Nutzung von Oracle Flashback

Voraussetzung für die Nutzung der Flashback-Technologie ist ein großer Undo-Tablespace, um hinreichend viele Daten für Flashbackoperationen zur Verfügung zu stellen. Da die benötigte Größe des Undo-Tablespaces sehr stark von den Änderungen in der Datenbank abhängt, bietet sich hier das Auto Extend für den Tablespace an. Die Retention Guarantee stellt dabei sicher, dass die Undo-Daten ausreichend lange im Undo-Tablespace vorgehalten werden.

Flashback-Varianten und ihre Einsatzgebiete

1. Flashback Query

Mit Flashback Query werden alle Daten zu einem spezifischen Zeitpunkt abgefragt. Es werden hier keine Datenänderungen durchgeführt. Flashback Query ist auf der geöffneten Datenbank (online) durchführbar und bereits in der Standard Edition 2 enthalten.

2. Flashback Transaction Query*

Für die Diagnose von durch User oder Anwendungen verursachten logischen Fehlern eignet sich die Flashback Transaction Query. Innerhalb eines bestimmten Zeitraums durchgeführte Transaktionen und dazugehörige Metadaten können mittels Flashback Transaction Query abgefragt und ausgegeben werden.

3. Flashback Version Query

Mit der Flashback Version Query können verschiedene Versionen einer Zeile innerhalb eines vorgegebenen Zeitraums ausgegeben werden. Dabei werden u.a. die Start- und End-SCN, die Start- und Endzeit für die Gültigkeit dieser Version, sowie die jeweilig durchgeführten Operationen (Insert, Update, Delete) ausgegeben, die zu der Version dieser Zeile führten.

4. Flashback Transaction*

Mit Flashback Transaction ist es möglich, einzelne Transaktionen zurückzurollen, so dass Daten, die durch Statements in dieser Transaktion geändert wurden, anschließend wieder im ursprünglichen Zustand vorliegen. Diese Variante führt DML-Statements aus bzw. rollt diese zurück.

5. Flashback Table – gelöschte Tabelle wiederherstellen*

Um eine gelöschte Tabelle wiederherzustellen, muss sich diese noch im ‘Recycle Bin’ befinden. Der Undo-Tablespace wird hierfür nicht benötigt und die Operation kann online durchgeführt werden. Wurde die gelöschte Tabelle aus dem ‘Recycle Bin’ gelöscht, lässt sie sich nur noch durch ein Flashback Database oder mittels Point-in-Time-Recovery wiederherstellen. Beides würde jedoch die komplette Datenbank verändern und auf einen früheren Zeitpunkt zurücksetzen.

6. Flashback Table – Tabelle zum früheren Zeitpunkt wiederherstellen*

Um Daten einer Tabelle mittels Flashback zu einem früheren Zeitpunkt wiederherstellen zu können, müssen die entsprechenden Daten noch im Undo-Tablespace vorhanden sein. Zudem dürfen zwischen dem gewünschten Wiederherstellungszeitpunkt und dem aktuellen Zeitpunkt keine DDL Statements ausgeführt worden sein, die die Struktur der Tabelle geändert haben. Ein Flashback Table wird abgebrochen, wenn während der Flashback Operation Constraints der Tabelle verletzt werden. Die Tabelle wird in diesem Fall nicht geändert. Die Operation ist online durchführbar, läßt sich jedoch nicht auf System-Tabellen anwenden.

7. Flashback Database*

Mit Flashback Database kann die Datenbank zeitlich in einen früheren Zustand versetzt werden, vergleichbar mit dem Zurückspulen eines Tonbands. Ein Restore aus dem Backup und ein Point-in-Time-Recovery führt zwar zum selben Ergebnis, braucht aber in den meisten Fällen mehr Zeit.

Für ein Flashback Database werden die sogenannten Flashback Logs benötigt, die in der Fast Recovery Area abgelegt werden. Zusätzlich kann ein Flashback Retention Target festgelegt werden, dass das obere Limit in Minuten festlegt, wie weit das Flashback Database maximal zurückgehen kann. Voraussetzung hierfür ist hinreichend viel Platz in der Fast Recovery Area, um die Menge an Flashback Logs vorhalten zu können.

Wird ein Datenfile nach dem Aktivieren des Flashback Database gelöscht, kann es mittels Flashback Database nicht wiederhergestellt werden. Für Flashback Database muss die Datenbank im Exclusive Mode sein.

8. Flashback Time Travel (vorher: Flashback Data Archive)

Daten über einen langen Zeitraum zu archivieren und dabei jede Änderung mitzuverfolgen, fällt in den Bereich des Flashback Time Travel, früher Flashback Data Archive genannt. Dabei werden Änderungen an entsprechend berücksichtigten Tabellen ‘getrackt’ und im Flashback Archive abgelegt. Mit den Flashback Queries können dann die Daten zu jedem beliebigen Zeitpunkt in der Vergangenheit – soweit er in die Retention Policy des Flashback Archive fällt – abgefragt werden. Daten die außerhalb der Retention Policy liegen, werden automatisch gelöscht.

Basic Flashback Time Travel steht bereits in der Standard Edition 2 zur Verfügung. Optimization for Flashback Time Travel benötigt die Oracle Advanced Compression Option und steht daher nur in der Enterprise Version zur Verfügung.

* Für die Nutzung ist die Enterprise Edition nötig.

Fazit

Flashback bietet viele Möglichkeiten, logisch verlorene Daten wiederherzustellen oder alte Daten anzusehen und zu vergleichen. Mit Ausnahme von Flashback Query und Flashback Time Travel (als Basic Variante) stehen jedoch alle Flashback Varianten erst in der Enterprise Edition zur Verfügung. Vorausgesetzt, es ist hinreichend Speicherplatz verfügbar, steht dann bei passender Konfiguration einem Sprung in die Vergangenheit nichts mehr im Weg.

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen erschien zuerst auf ASPICON.

DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren

Thilo Solbrig, Oracle Certified Master — Fri, 07 Feb 2025 10:55:58 +0000

Home → Praxistipp

DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren

Verfasst von Thilo Solbrig, Oracle Certified Master
07 Februar 2025
11:55
Datenbank, DBA Tipp, Oracle, Performance Tuning, Praxistipp

Cursor Sharing hat zweifellos eine große Bedeutung für die Performance, insbesondere das Vermeiden des Hard Parsing. Auf den ersten Blick nicht offensichtlich, kann das Vorhalten vieler nicht-wiederverwendbarer Statements im Library Cache aber auch zur Verschwendung von Buffer Cache führen. Wie du Cursor-Sharing-Kandidaten in deiner Datenbank findest und welche zwei Möglichkeiten dir zur Optimierung zur Verfügung stehen, zeigt dieser DBA Tipp.

Cursor-Sharing datenbankweit erzwingen

Oracles Diagnosetools AWR und statspack speichern in ihren Repositories neben Ausführungsstatistiken auch Ausführungspläne ab. Diese werden regulär per INSERT-SELECT aus entsprechenden Data Dictionary-Views in die Repositories übertragen. Je mehr Statements sich im Shared Pool befinden, desto mehr SELECT-Statements werden ausgeführt und entsprechend Datenblöcke durch den Buffer Cache geschleust. Das verdrängt unter Umständen in großem Umfang Datenblöcke, die für die eigentliche Datenbankanwendung dort gepuffert waren und performancerelevant wären.

Zudem haben wir oft beobachtet, dass vergleichsweise große Shared Pools mit sehr vielen nicht-wiederverwendbaren Statements zu einer erhöhten Anzahl von „library cache: mutex X“ oder „library cache pin“ Wait-Events führen. Du kannst Cursor Sharing an der Anwendung vorbei datenbankweit mit dem Parameter CURSOR_SHARING=FORCE erzwingen. In diesem Fall ersetzt die Datenbank von sich aus Literale in SQL-Statements durch Bindevariablen.

Anpassung über Anwendungshersteller

Nicht alle Anwendungshersteller gestatten das jedoch. Zum Teil gibt es auch Ressentiments gegen diese Einstellung, die aus sogenannten bind peeking Problemen aus Versionen vor 11.2.0.4, herrühren. Hat man entsprechenden Zugang zum Support des Anwendungsentwicklers, kann es daher von Interesse sein, ihm die konkreten Statements mitzuteilen, die wegen Verzicht auf Bindevariablen den Library Cache besonders exzessiv verschwenden. Diese können dann in puncto Bindevariablen im Code angepasst werden.

Zu Demonstrationszwecken gehen wir von einem Szenario aus, in dem ein SELECT-Statement 10.000 Mal ausgeführt wird – jedes Mal mit einer anderen ID:

SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 1;
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 2;
...
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 9999;
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = 10000;

NAME                                                VALUE

---------------------------------------------- ----------
execute count                                       10351
parse count (describe)                                  0
parse count (failures)                                  0
parse count (hard)                                  10037
parse count (total)                                 10200
parse time cpu                                        677
parse time elapsed                                    648

Wiederverwendbare Statements erstellen

Wie unschwer zu erkennen ist, könnte dieses Statement durch Ersetzen des Literals für CUSTOMER_ID zu einem wiederverwendbaren Statement abgeändert werden. Statt 10.000 Hard Parses mit je einer Ausführung, wäre dann nur noch 1 Hard Parse erforderlich. Das geparste Statement könnte dann die nächsten 9999 Mal wiederverwendet werden und würde erheblich ressourcensparender arbeiten. Ob das über den Datenbankparameter CURSOR_SHARING=FORCE oder durch Änderung der Anwendung erfolgt, ist hierbei letztlich unerheblich.

SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY, POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID = :ID;

NAME                                                 VALUE
----------------------------------------------- ----------
execute count                                        10015
parse count (describe)                                   0
parse count (failures)                                   0
parse count (hard)                                      39
parse count (total)                                  10201
parse time cpu                                          81
parse time elapsed                                      67

Auffinden der Cursor-Sharing-Kandidaten

Zum Auffinden solcher „tunenswerter“ Statements in einer Datenbank bedient man sich der Data-Dictionary-View v$sql. Sie führt zu jedem gecachten Statement in der Spalte FORCE_MATCHING_SIGNATURE eine Signatur seines Äquivalents bei Verwendung von CURSOR_SHARING=FORCE mit. Die Anzahl der Einträge in v$sql mit jeweils gleicher Signatur ist also ein gutes Maß dafür, wie viele Ausprägungen eines Statements im Cache liegen, nur weil unterschiedliche Literale verwendet wurden.

In unserem Beispiel würde das Ergebnis aus der v$sql ohne Cursorsharing in etwa so aussehen:

select force_matching_signature,count(*) anzahl
from v$sql
group by force_matching_signature
order by 2;


FORCE_MATCHING_SIGNATURE 	ANZAHL
------------------------ ----------
 	1253587301725552198     2
 	7928100255923163774     2
	17867806445150202466    3
	10927028642624449365    3
 	5494157341192764346     3
	11682584117507924582    3
	17301900507670644855    3
	17274913944183326537    3
   	    	0    121
 	8094602905134864270  	10000

In unserem Testfall ist das unterste Statement mit der höchsten Ausprägung (10.000 Einträge mit der gleichen FORCE_MATCHING_SIGNATURE 8094602905134864270) vordergründig interessant. Mit einigen Samples könnten wir uns jetzt ein ungefähres Bild verschaffen, um welche Statements es sich handelt:

select sql_text from v$sql
where force_matching_signature=8094602905134864270
fetch first 5 rows only;


SQL_TEXT
----------------------------------------------------------------------------------------------------
SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =9933


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =8082


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =2080


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =6237


SELECT ADDRESS_ID, CUSTOMER_ID, DATE_CREATED, HOUSE_NO_OR_NAME, STREET_NAME, TOWN, COUNTY, COUNTRY,
POST_CODE, ZIP_CODE FROM ADDRESSES WHERE CUSTOMER_ID =7514

Fazit

Statements, die Literale statt Bindvalues verwenden, können sich durch erhöhten Parseaufwand und Verschwendung von Library und auch Buffer Cache negativ auf die Performance auswirken. Ist eine globale Lösung durch Verwendung des Datenbankparameters CURSOR_SHARING=FORCE nicht möglich, können die potentiell problematischen Statements dynamisch ermittelt und so dem Anwendungshersteller für eine gezielte Anpassung mitgeteilt werden.

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren erschien zuerst auf ASPICON.

Praxistipp · ASPICON Newsarchiv

Ansible und Outbound-Proxy: Ein Environment für alle Plays

Ansible und Outbound-Proxy: Ein Environment für alle Plays

Der Weg: erst mit set_fact

Die Lösung funktioniert, erzeugt aber eine unnötige Abhängigkeit zwischen der Initialisierung durch set_fact und der späteren Verwendung.

Die Lösung: Environment als lazy Variable

Vorteile:

Fazit

Bash Cheat Sheet: Vergleichsoperatoren & Tests

Bash Cheat Sheet: Vergleichsoperatoren & Tests

Vergleich von Strings

Vergleich von Zahlen

Dateien, Verzeichnisse & Co. testen

Rechte und Besitzer prüfen

Leere Strings erkennen

Welche Datei ist neuer?

Für den nächsten „Wie war das nochmal?“-Moment

Cheat Sheet: OpenSSL für Zertifikate

Cheat Sheet: OpenSSL für Zertifikate

1. Schnell prüfen, ob ein Service erreichbar ist

2. Wenn der Port offen ist – der Client aber trotzdem nicht funktioniert

SNI nicht vergessen

Fazit

Härtung von Oracle Linux Betriebssystemen Teil II

Härtung von Oracle Linux Betriebssystemen Teil II

Ausgewählte Empfehlungen zur Härtung eines Oracle Linux BetriebssystemsTeil II: Services

Punkt 1: Spezielle Dienste deaktivieren / maskieren

Punkt 2: Betriebssysteminstallation auf Sparflamme

Punkt 3: Service Clients konfigurieren

DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen

DBA Tipp: Tablespacefreiplatz und Buffer Cache Hit Ratio erhöhen durch Defragmentierung von Tabellen

Warum überhaupt defragmentieren?

Es kann also nach größeren Löschoperationen interessant sein, welche Tabellen mittels:

Vergleich erwarteter Platzbedarf und tatsächlich belegter Platz

Fazit

Härtung von Oracle Linux Betriebssystemen Teil I

Härtung von Oracle Linux Betriebssystemen Teil I

Allgemeines zum CIS Benchmark Report für die Härtung eines Oracle Linux Betriebssystems

Teil I – Netzwerkkonfiguration: Ausgewählte Empfehlungen zur Härtung eines Oracle Linux Betriebssystems

Punkt 1: Deaktivieren nicht verwendeter Netzwerkprotokolle und ‑geräte

Punkt 2: Sicherstellen, dass ICMP-Umleitungen nicht akzeptiert werden

Punkt 3: Sicherstellen, dass Broadcast-ICMP-Anfragen ignoriert werden

DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen

DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen

Voraussetzungen für die Nutzung von Oracle Flashback

Flashback-Varianten und ihre Einsatzgebiete

1. Flashback Query

2. Flashback Transaction Query*

3. Flashback Version Query

4. Flashback Transaction*

5. Flashback Table – gelöschte Tabelle wiederherstellen*

6. Flashback Table – Tabelle zum früheren Zeitpunkt wiederherstellen*

7. Flashback Database*

8. Flashback Time Travel (vorher: Flashback Data Archive)

Fazit

DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren

DBA Tipp: Cursor-Sharing-Kandidaten in der Anwendung identifizieren

Cursor-Sharing datenbankweit erzwingen

Anpassung über Anwendungshersteller

Wiederverwendbare Statements erstellen

Auffinden der Cursor-Sharing-Kandidaten

Fazit

Ausgewählte Empfehlungen zur Härtung eines Oracle Linux Betriebssystems
Teil II: Services