Hidden Feature · ASPICON Newsarchiv

DBA Tipp: PostgreSQL Konfigurationsdateien, die dem Admin das Leben erleichtern

Jörg Hempel — Fri, 02 Aug 2024 05:33:00 +0000

Home → Hidden Feature

DBA Tipp: PostgreSQL Konfigurationsdateien, die dem Admin das Leben erleichtern

Verfasst von Jörg Hempel
02 August 2024
07:33
Datenbank, DBA Tipp, Hidden Feature, PostgreSQL

PostgreSQL kommt grundsätzlich ohne bunte Oberfläche aus – und das ist auch gut so. Denn alle Aufgaben, die du als DBA zu erledigen hast, lassen sich grundsätzlich über die Konsole abwickeln.

Das heißt allerdings nicht, dass du auf Annehmlichkeiten und Automatisierungen verzichten musst, wie der nachfolgende DBA Tipp zeigt.

Zeit beim Verbindungsaufbau sparen: mit PGSERVICE und PGSERVICEFILE

Mit dem PostgreSQL-Client psql kannst du die Verbindung zu einer Datenbank aufbauen:

postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> psql -h 
192.168.137.165 -p 5432 -U foo -d bar
Password for user foo: 
psql (16.2)
Type "help" for help.

bar=# \q
postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $>

Das funktioniert zwar, jedoch nimmt das wiederholte Eingeben von Verbindungsparametern Zeit in Anspruch.

Du kannst dir auch mit der Rückwärtssuche der Konsole behelfen. Doch es geht noch schneller: nämlich mit den Environment-Variablen PGSERVICE beziehungsweise PGSERVICEFILE.

psql sucht nach der “Connection Service File” unter ~/.pg_service.conf. Pfad und Name dieser Datei können mit der Variable PGSERVICEFILE geändert werden. Legst du eine Datei ~/.pg_service.conf an, kannst du darin Verbindungen definieren.

Hier als Beispiel zwei Verbindungen zu einer Master- und einer Standby-Instanz:

postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> cat < 
~/.pg_service.conf
[TEST16-1_foobar]
host=192.168.137.165
port=5432
user=foo
dbname=bar

[TEST16-2_foobar]
host=192.168.137.68
port=5432
user=foo
dbname=bar
EOF
postgres@jhm-pg-ws-01:~ $ chmod 0640 ~/.pg_service.conf

Gibst du PGSERVICE den Namen einer Sektion, übernimmt psql die entsprechenden Verbindungsparameter.

postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> export 
PGSERVICE=TEST16-1_foobar
postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> psql
Password for user foo: 
psql (16.2)
Type "help" for help.

bar=>

psql fragt zwar nur nach dem Passwort, doch auch das lässt sich noch beschleunigen, nämlich indem du die Sektionen in der ~/.pg_service.conf um einen Passwort-Eintrag ergänzt:

[TEST16-1_foobar]
host=192.168.137.165
port=5432
user=foo
password=foo
dbname=bar

Wie kannst du die sensiblen von den trivialen Daten trennen?

Um die sensiblen Daten von den trivialen zu trennen, erstellst du eine Datei ~/.pgpass mit einer Zeile für je eine Verbindung. Die Rechte für ~/.pgpass sollten auf 600 stehen. Sind diese zu liberal gesetzt, ignoriert psql die Datei.

postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> cat < 
~/.pgpass
# hostname:port:database:username:password
192.168.137.165:5432:bar:foo:foo
192.168.137.68:5432:bar:foo:foo
EOF
postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> chmod 600 .pgpass
postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> psql
psql (16.2)
Type "help" for help.

bar=>

psql holt sich alle nötigen Parameter selbstständig aus den entsprechenden Konfigurationsdateien.

Den PGSERVICE änderst du kurz, um dich dann zur Standby Datenbank zu verbinden:

postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> export 
PGSERVICE=TEST16-2_foobar
postgres@jhm-pg-ws-01(TEST16|16.2) [ ~ ] $> psql
psql (16.2)
Type "help" for help.

bar=>  select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t
(1 row)

bar=>

Fazit

Mit ~/.pg_service.conf und ~/.pgpass kannst du den Workflow des Verbindungsaufbaus zu einer Datenbank enorm beschleunigen, da oft genutzte Verbindungen nicht mehr per Hand angegeben werden müssen. Allerdings sind Konfigurationsdateien, besonders wenn sie Passwörter im Klartext enthalten, mit Bedacht einzusetzen. Auf Testsystemen ist diese Methode jedoch das Mittel, um Zeit und Tipp-Arbeit zu sparen.

Falls du mehr über die Arbeit mit PostgreSQL Datenbanken erfahren möchtest oder spezielle Herausforderungen zu lösen hast, schreib uns gern oder ruf uns direkt an.

Kontakt

Hier findest du weitere Features und Infos aus der Welt von » PostgreSQL aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: PostgreSQL Konfigurationsdateien, die dem Admin das Leben erleichtern erschien zuerst auf ASPICON.

DBA Tipp: Easy Connect – Auf kurzem Weg zur Datenbank

Thilo Solbrig, Oracle Certified Master — Fri, 05 Jul 2024 07:25:37 +0000

Home → Hidden Feature

DBA Tipp: Easy Connect – Auf kurzem Weg zur Datenbank

Verfasst von Thilo Solbrig, Oracle Certified Master
05 Juli 2024
09:25
Datenbank, DBA Tipp, Hidden Feature, Oracle, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Datenbank 23ai

Die wahrscheinlich gebräuchlichste und sicherlich nicht nur DBAs bekannte Methode zur Namensauflösung für Datenbankverbindungen dürfte das „Local Naming“, also die Verwendung einer tnsnames.ora sein.

Für ad hoc Zugriffe auf Datenbanken, für die sich der Aufwand zur Einrichtung einer tnsnames.ora nicht lohnt, bietet sich hingegen „Easy Connect“ an. Hier erfolgt die Beschreibung der Verbindung im Stile einer URL. Das Verfahren ist ab Client Version 10g verfügbar.

Schauen wir uns im Folgenden die Konfiguration sowie die Syntax an und welche zusätzlichen Möglichkeiten dir Easy Connect Plus bietet.

Wie konfiguriere ich Easy Connect richtig?

Die Konfiguration der unterstützten Namensauflösungsverfahren erfolgt grundsätzlich in der sqlnet.ora mit dem Parameter NAMES.DIRECTORY_PATH. Die Einträge am Client müssen sich dabei mindestens auch in der sqlnet.ora des Servers wiederfinden, da die vom Server gestatteten Namensauflösungsverfahren den Vorrang bekommen. Ist NAMES.DIRECTORY_PATH des Clients aber gleich oder eine Untermenge des NAMES.DIRECTORY_PATH des Servers, sind keine Einschränkungen zu erwarten.

Ab Version 11g ist Easy Connect per default Bestandteil des NAMES.DIRECTORY_PATH, in Version 10g musste Easy Connect noch explizit in den DIRECTORY_PATH aufgenommen werden.

Was ist bei der Syntax von Easy Connect zu beachten?

In den Releases bis 19.10 folgt Easy Connect der folgenden Syntax:

CONNECT username@[//]host[:port][/[service_name][:server_type][/instance_name]]

… wobei die einzelnen Komponenten folgende Bedeutung haben:

username

host

port

service_name

server_type

instance_name

Name des Datenbankaccounts

Host-Adresse des Listeners

Listener-Port (default: 1521)

Datenbank-Servicename

Connectionmode (DEDICATED|SHARED|POOLED)

Datenbank-Instanzname

username: Name des Datenbankaccounts

host: Host-Adresse des Listeners

port: Listener-Port (default: 1521)

service_name: Datenbank-Servicename

server_type: Connectionmode (DEDICATED|SHARED|POOLED)

instance_name: Datenbank-Instanzname

Eine vollständig beschriebene Verbindung auf einen

Datenbankaccount „system“
über den Listener des Hosts „oracle-server“, Port 1521
auf einen Service „orclsec“ der Instanz „orcl“
per dedicated server

sieht demnach folgendermaßen aus:

$ sqlplus system@//oracle-server:1521/orclsec:dedicated/orcl

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Jun 28 17:43:06 2024
Version 19.10.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Enter password: 
Last Successful login time: Fri Jun 28 2024 17:42:41 +02:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.10.0.0.0

SQL>

Das entspricht dem tnsnames-Eintrag:

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = oracle-server)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orclsec)
      (INSTANCE_NAME = orcl)
    )
  )

Die zum vollständigen Easy Connect String oben korrespondierende Kurzform ist:

$ sqlplus system@oracle-server/orclsec

Es ist übrigens zu erwähnen, dass der Passwortprompt erst ab aktuelleren Clientversionen (mutmaßlich ab 18c oder 19c) ohne weiteres erscheint. Davor musste der Connector folgendermaßen gequotet werden, da andernfalls statt eines Passwortprompts ein ORA-12504 erscheint:

$ sqlplus system@\“oracle-server/orclsec\“

Diese „Ausbaustufe“ des Easy Connect reicht schon einmal grundsätzlich aus, um Single‑, SEHA- und RAC-Datenbanken anzusprechen. Sie kommt allerdings an ihre Grenzen, wenn für einen Connect mehrere potenzielle Hosts infrage kommen. Das ist typischerweise bei physical-standby-Infrastrukturen wie DataGuard oder Dbvisit Standby der Fall. Um diese Einschränkung zu eliminieren, wurde mit Oracle 19c Easy Connect Plus veröffentlicht.

Diese zusätzlichen Möglichkeiten bietet dir Easy Connect Plus

Easy Connect Plus, neu ab Version 19c, erweitert die URL-Syntax deutlich. Die allgemeine Syntaxbeschreibung sieht jetzt folgendermaßen aus:

[[protocol:]//]host1{,host12}[:port1]{,host2:port2}[/[service_name][:server][/instance_name]][?parameter_name=value{¶meter_name=value}]

Neu gegenüber dem konventionellen Easy Connect sind:

Der protocol-Support, also die optionale Angabe des Connectprotokolls, das dem PROTOCOL-Teil des ADDRESS-Parameters entspricht
Multi-Host-Support, also die Adressierung mehrerer Listener in einem Connector
Die Angabe folgender weiterer Parameter als Name-Value-Paare:
- ENABLE
- FAILOVER
- LOAD_BALANCE
- RECV_BUF_SIZE
- SEND_BUF_SIZE
- SDU
- SOURCE_ROUTE
- RETRY_COUNT
- RETRY_DELAY
- CONNECT_TIMEOUT
- TRANSPORT_CONNECT_TIMEOUT
- SSL_SERVER_DN_MATCH
- SSL_SERVER_CERT_DN
- WALLET_LOCATION

Eine typische Verbindungsbeschreibung auf eine Primärdatenbank in einer DataGuard-Architektur könnte nach Local Naming Methode zum Beispiel folgendermaßen aussehen:

ORCL =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = oracle-srv-1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = oracle-srv-2)(PORT = 1525))
    )
    (FAILOVER = TRUE)
    (LOAD_BALANCE = FALSE)
    (TRANSPORT_CONNECT_TIMEOUT=1)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orclpri)
    )
  )

Der TNS-Name ORCL löst im Beispiel auf einen role-based-Service orclpri auf, der exklusiv auf einem der beiden Server oracle-srv‑1 oder oracle-srv‑2 verfügbar ist und dort gerade die primary-Seite der orcl-Datenbank in einer DataGuard-Infrastruktur repräsentiert.

Dieser Connector ist mit der konventionellen Easy Connect-Syntax nicht darstellbar, mit Easy Connect Plus hingegen sieht es so aus:

sqlplus system@'tcp:oracle-srv-1,oracle-srv-2:1525/orclpri:dedicated?failover=true&load_balance=false&transport_connect_timeout=1'

Fasse den Connector auf Unix-/Linux-Systemen dabei bitte wie dargestellt in einfache Hochkommata ein, wenn du von der URL-Parametersyntax Gebrauch machst. Das Ampersand zur Trennung der Parameter würde andernfalls von der Shell interpretiert werden und der Connector würde wahrscheinlich anders reagieren als gewünscht. Übrigens: Easy Connect Plus ersetzt EasyConnect einfach. Es ist also keine Änderung an den sqlnet.ora deiner Systeme erforderlich.

Fazit

Unter Zuhilfenahme des Easy Connect Naming kann man Verbindungen zu Oracle Datenbanken schnell und ohne weitere Konfigurationsschritte aufbauen. Das ist insbesondere für Verbindungstests, Fehlersuche und ad hoc Abfragen interessant. Easy Connect kann für Single Instance, SEHA, RAC und Multitenant Datenbanken gleichermaßen eingesetzt werden. Es kann im RAC auch direkt eine bestimmte RAC Instanz ansprechen. Mit Easy Connect Plus erfährt es ab 19c sogar noch eine deutliche Aufwertung mit der Unterstützung von Failoverkonfigurationen, wie etwa Data Guard und Implementierung ausgewählter Net Service Parameter. Auch Verbindungen auf SSL gesicherte TCPS Endpunkte sind nun möglich.

Im Umkehrschluss macht Easy Connect einmal mehr deutlich, wie wichtig die Einrichtung wirksamer Zugangsbeschränkungen auf Oracle Datenbanken im Unternehmen ist. Auch in vermeintlich durch Windows Domänen und Richtlinien abgesicherten Infrastrukturen reichen offenbar eine IP Verbindung, ein Datenbanklogin und die Kenntnis der Server IP und des Datenbank Servicenamens für einen erfolgreichen Connect zur Datenbank aus.

Solltest du Unterstützung bei der Einrichtung von Zugangsbeschränkungen für deine Oracle Datenbanken benötigen oder diese einfach mal auf Herz und Nieren in Puncto Sicherheitskonfigurationen überprüfen wollen, sind wir gern für dich da.

Kontakt

Hier findest du weitere Features und Infos aus der Welt von » Oracle aus unserem News & Insights Bereich. Wichtige Lizenzierungsinfos rund um Oracle findest du auf unserer » Datenbank-Lizenzen-Seite.

Share this article

Der Beitrag DBA Tipp: Easy Connect – Auf kurzem Weg zur Datenbank erschien zuerst auf ASPICON.

DBA Tipp: Drei Punkte Plan, um den DBMS_SCHEDULER für Backups zu nutzen

The hidden DBA — Mon, 24 Jun 2024 06:18:00 +0000

Home → Hidden Feature

DBA Tipp: Drei Punkte Plan, um den DBMS_SCHEDULER für Backups zu nutzen

Verfasst von The hidden DBA
24 Juni 2024
08:18
Backup & Recovery, Datenbank, Hidden Feature, Oracle, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Datenbank 23ai

Die Einrichtung von Datenbank-Backups mit RMAN ist einfach. Aber welchen Scheduler nutzt man im besten Fall? Alle Betriebssysteme, seien es Windows mit den “Geplanten Tasks” oder Linux mit dem “crontab”-System bieten hierfür eine Lösung: den “DBMS_SCHEDULER”.

Der DBMS_SCHEDULER ist ein Paket in Oracle Database (seit Version 12.1), mit dem du Aufgaben planen und automatisieren kannst. Er bietet eine Reihe von Funktionen zum Erstellen, Verwalten und Ausführen von Jobs, die aus PL/SQL-Prozeduren, Skripten oder externen Programmen bestehen können.

Wie du den DBMS_SCHEDULER für deine Backups nutzt

Die Vorteile des Tools sind klar:

Planung von Aufgaben:
Du kannst Jobs so planen, dass sie zu bestimmten Zeiten oder in Intervallen ausgeführt werden, etwa täglich, wöchentlich oder monatlich.
Automatisierung von Aufgaben:
Du kannst Aufgaben automatisieren, die sonst manuell ausgeführt werden müssten, wie eben beispielsweise Datensicherungen, aber auch die Bereinigung von Daten oder das Senden von Berichten.
Verbesserte Zuverlässigkeit:
Der DBMS_SCHEDULER kann fehlgeschlagene Jobs neu starten.
Erhöhte Effizienz:
Der DBMS_SCHEDULER kann dazu beitragen, die Effizienz deiner Datenbank zu verbessern, indem er zeitaufwändige Aufgaben automatisiert und die Arbeitslast auf dem System verteilt.

Aber wie kannst du nun den DBMS_SCHEDULER für deine Backups nutzen? Wir haben einen Drei Punkte Plan für dich zusammengestellt:

1. Credentials anlegen

    begin
       -- create the credential for operating system access
       dbms_credential.create_credential(credential_name => 'OS_CREDENTIAL',
                                         username        => 'oracle',
                                         password        => 'oracle',
                                         enabled         => true,
                                         comments        => 'OS credentials for backup jobs');

       -- create credential to provide RMAN with database access
       dbms_credential.create_credential(credential_name => 'DB_CREDENTIAL',
                                         username        => 'sys',
                                         password        => 'oracle',
                                         database_role   => 'sysdba',
                                         enabled         => true,
                                         comments        => 'DB credentials for backup jobs');
       end;
       /

2. Backup – Datenbank Full

    begin
       dbms_scheduler.create_job(        job_name        => 'DAILY_BACKUP_FULL',
                                         job_type        => 'BACKUP_SCRIPT',
                                         job_action      => 'run { backup check logical database plus archivelog not
                                                            backed up;' ||
                                                            'delete noprompt archivelog until time ''sysdate-1'';' ||
                                                            'delete noprompt obsolete; }',
                                         start_date      => trunc(sysdate),
                                         repeat_interval => 'freq=daily;byhour=23;byminute=00;bysecond=0',
                                         credential_name => 'OS_CREDENTIAL',
                                         enabled         => false,
                                         auto_drop       => false,
                                         comments        => 'backup job database full (daily execution)');
       -- add the db credential to the job.
       -- this can't be done in the create_job call
       dbms_scheduler.set_attribute(     name            => 'DAILY_BACKUP_FULL',
                                         attribute       => 'CONNECT_CREDENTIAL_NAME',
                                         value           => 'DB_CREDENTIAL');
       -- after enabling the job, backups are made according to the schedule
       dbms_scheduler.enable(            name            => 'DAILY_BACKUP_FULL');
     end;
     /

3. Logging und Fehlersuche

set linesize 10000
 col job_name format a40
 col schedule_name format a40
 col schedule_type format a40
 select job_name, start_date, next_run_date,LAST_START_DATE,LAST_RUN_DURATION from dba_scheduler_jobs where schedule_type like 'CALENDAR' and job_name like 'DAILY%';
 select job_name, enabled from DBA_SCHEDULER_JOBS where job_name like 'DAILY%';

 select session_key, to_char(start_time, 'DD-MON-YYYY HH24:MI:SS') START_TIME from v$rman_backup_job_details where status!='COMPLETED' order by start_time;
 select output from v$rman_output where session_key=;

Fazit

Zusammenfassend lässt sich sagen, dass der DBMS_SCHEDULER ein leistungsstarkes Tool für die Automatisierung von Datenbank-Backups und anderen zeitkritischen Aufgaben sein kann. Unabhängig von der Aufgabenverwaltung eines Betriebssystems ist es somit möglich, Backups sorgenfrei laufen zu lassen und damit die Datensicherheit und ‑verfügbarkeit in deiner Umgebung zu verbessern.

Leider gibt es eine Einschränkung: Eine physische Standby-Datenbank hat kein aktives Scheduler-System. Will man hierbei Backups ressourcenschonend von der Datenbankkopie laufen lassen, muss man von Skripten und der systemeigenen Aufgabenplanung Gebrauch machen.

Hier findest du weitere Features und Infos aus der Welt von Oracle aus unserem News & Insights Bereich. Wichtige Lizenzierungsinfos rund um RMAN Repository und Oracle Secure Backup findest du auf unserer Datenbank-Lizenzen-Seite.

Share this article

Der Beitrag DBA Tipp: Drei Punkte Plan, um den DBMS_SCHEDULER für Backups zu nutzen erschien zuerst auf ASPICON.

Automatische SQL-Planverwaltung in Oracle Datenbanken

Jens Böttcher — Tue, 21 May 2024 09:00:39 +0000

Home → Hidden Feature

Automatische SQL-Planverwaltung in Oracle Datenbanken

Verfasst von Jens Böttcher
21 Mai 2024
11:00
Datenbank, Hidden Feature, Oracle, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Datenbank 23ai, Performance Tuning

Die automatische SQL-Planverwaltung steht seit kurzem für die Enterprise Edition der Oracle Database 23ai bereit. Eine weitere gute Nachricht ist, dass diese Änderung auch in Oracle Database 19c (ab 19.22) zurück portiert wurde und Oracle nicht abgeneigt ist, auf noch weitere Patch-Versionen zurückzugehen. (Quelle: https://blogs.oracle.com/optimizer/post/license-change-for-auto-spm)

Aber was ist eigentlich die SQL-Planverwaltung, wann brauchst du sie möglicherweise und was solltest du bei der Nutzung beachten? Lies weiter, dann erfährst du mehr.

Vorteile und Anwendungsfälle der automatischen SQL-Planverwaltung

Die automatische SQL-Planverwaltung (SPM) in Oracle Datenbanken ist ein intelligentes Feature, das die Leistung und Skalierbarkeit von Anwendungen durch Optimierung der Ausführungspläne für SQL-Abfragen verbessert. Du als Datenbankadministrator musst dich nicht mehr manuell um die Optimierung jedes einzelnen Plans kümmern, da die SPM diese Aufgabe proaktiv übernimmt und dafür sorgt, dass die Abfragen mit maximaler Effizienz ausgeführt werden.

Die Vorteile sind:

Verbesserte Performance
SPM kann die Ausführungszeit von Abfragen erheblich verkürzen, indem es suboptimale Pläne erkennt und optimierte Alternativen generiert. Dies führt zu einer spürbaren Steigerung der Anwendungsleistung und Reaktionszeiten, insbesondere bei komplexen Abfragen oder hohen Datenmengen.
Geringerer Administrationsaufwand
DBAs werden von der zeitraubenden manuellen Planoptimierung entlastet und können sich so auf wichtigere Aufgaben konzentrieren. SPM automatisiert die Planverwaltung und sorgt dafür, dass die Datenbank immer optimal läuft.
Skalierbarkeit
SPM passt sich automatisch an Änderungen in der Arbeitslast und den Datenstrukturen an. Dies gewährleistet, dass die Abfragen auch bei steigenden Anforderungen effizient ausgeführt werden und Engpässe vermieden werden.
Vereinfachte Fehlersuche
SPM protokolliert detaillierte Informationen zu den verwendeten Plänen und deren Leistung. Diese Daten können zur Analyse von Performanceproblemen und zur Identifizierung von Engpässen herangezogen werden.

Besonders hilfreich kann das Feature in Produktionsumgebungen mit hohen Anforderungen an die Performance und Skalierbarkeit, in Umgebungen mit komplexen Abfragen und großen Datenmengen sowie in Umgebungen mit häufigen Änderungen an der Anwendungslogik oder den Datenstrukturen sein.

Was du beachten solltest und wie du das Feature aktivieren kannst

Bei der Nutzung der automatischen SQL-Planverwaltung solltest du folgende Punkte beachten:

SPM ist kein Ersatz für eine gute Datenbankarchitektur und ein effizientes Datenmodell.
Die Aktivierung von SPM kann in einigen Fällen zu einem leichten Leistungsabfall führen, da die Optimierung der Pläne zusätzliche Ressourcen benötigt.
Bei komplexen Anwendungen kann es ratsam sein, SPM in Zusammenarbeit mit einem erfahrenen Oracle DBA zu implementieren und zu optimieren.

Um zu überprüfen, ob SPM aktiviert ist, kannst du folgendes Skript ausführen:

SQL> SELECT parameter_value spm_status FROM dba_sql_management_config WHERE parameter_name = 'AUTO_SPM_EVOLVE_TASK';
SPM_STATUS
----------
OFF

Aktivieren kannst du das Feature mit:

SQL> BEGIN
 DBMS_SPM.CONFIGURE('AUTO_SPM_EVOLVE_TASK','ON');
END;
/

Fazit

Die automatische SQL-Planverwaltung ist ein wertvolles Werkzeug für die Optimierung der Leistung und Skalierbarkeit von Oracle Datenbanken. Sie kann dich bei deiner Arbeit als Datenbankadministrator entlasten, die Performance deiner Systeme verbessern und die Stabilität von Anwendungen in komplexen Umgebungen gewährleisten.

Beachte jedoch, dass die Optimierung der Pläne zusätzliche Ressourcen benötigt. Solltest du Unterstützung benötigen, ruf uns gern an.

Hier findest du weitere Features und Infos aus der Welt von Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag Automatische SQL-Planverwaltung in Oracle Datenbanken erschien zuerst auf ASPICON.

Darauf haben wir gewartet: Contained Availability Groups im Microsoft SQL Server 2022

Tobias Braun — Tue, 06 Feb 2024 08:58:20 +0000

Home → Hidden Feature

Darauf haben wir gewartet: Contained Availability Groups im Microsoft SQL Server 2022

Verfasst von Tobias Braun
06 Februar 2024
09:58
AlwaysOn Availability Groups, Datenbank, Hidden Feature, Microsoft, SQL Server

Neuerungen wie der SQL Ledger oder die verbesserte Zusammenarbeit des SQL Server 2022 mit Microsoft Azure werden seitens Microsoft intensiv beworben. Allerdings verstecken sich unter der Haube des SQL Server 2022 noch andere coole und vor allem sehr nützliche Features. Eine wesentliche Verbesserung haben wir in unserem Beitrag “Was ist neu und nützlich am MS SQL Server 2022?” im vergangenen Jahr bereits kurz angerissen. Es geht um die Möglichkeit, Instanz-Konfigurationen an eine Availability Group zu binden. Damit kann die Gefahr, Konfigurationsarbeiten zu vergessen, erheblich reduziert werden. Im Microsoft SQL Server 2022 heißt diese ausgesprochen schicke Lösung “Contained Availability Groups”.

Wir sind der Meinung, dass viele SQL Server Admins (uns eingeschlossen) schon jahrelang auf diese Verbesserung gewartet haben und möchten heute ein bisschen tiefer in das Thema eintauchen. Wenn du also in der Vergangenheit schon mit Always On Availability Groups gearbeitet hast, solltest du dir die folgenden Zeilen nicht entgehen lassen.

Wie sah die Arbeit in einer klassischen Always On Availability Group bisher aus?

Um den Vorteil der Contained Availability Groups schätzen zu lernen, braucht man sich nur eine klassische Always On Availability Group vorzustellen. Dort werden alle Inhalte und Eigenschaften einer Nutzerdatenbank zwischen dem primären Replikat und allen sekundären Replikaten synchronisiert. So weit, so gut. Doch es gibt immer auch Inhalte, welche auf Instanzebene angelegt werden. Diese landen somit nicht in der Nutzerdatenbank, sondern in einer Systemdatenbank. Daraus folgt, dass eine Änderung auf dem primären Replikat auch nur dort wirkt. Die gleiche Aktion muss auf allen sekundären Replikaten separat durchgeführt werden. Keine große Sache, möchte man meinen. Doch in der Realität werden die sekundären Replikate sehr oft vergessen. Geschieht dies über einen längeren Zeitraum, geraten die sekundären Replikate (also die Instanzen) in eine Art “Aschenputtel-Situation”. Nach dem Motto “Die guten ins Töpfchen, die schlechten ins Kröpfchen” wird das primäre Replikat in Punkto Konfiguration aktuell gehalten, doch die sekundären Replikate werden regelrecht vernachlässigt und fallen hinten runter.

Folgende Inhalte landen besonders häufig in den Systemdatenbanken und geraten damit leicht in Vergessenheit:

Anmeldungen (besonders, wenn es sich um SQL-Konten handelt)
Aufträge (Jobs) des SQL Server Agents (vorwiegend mit Benutzerlogik)
Verbindungs-Server

Natürlich ist vielen Admins dieses Problem bewusst, was wiederum zu den erstaunlichsten Selfmade-Lösungen geführt hat, wie:

Export der relevanten Daten in eine Text-Datei auf Primärseite und anschließender Import jener Text-Datei auf Sekundärseite
oder
Auslesen der relevanten Daten auf der Primärseite und “Wiederholung” der Befehle mittels eines Verbindungsservers

Letzten Endes läuft es darauf hinaus, dass die Inhalte einiger Systemtabellen manuell abgeglichen wurden. Man könnte von einer Art “Synchronisation durch Replikation” für Systemdatenbanken sprechen. Tatsächlich erfolgt ja eine Art Wiederholung auf den sekundären Replikaten. Wie man in jedem Falle sieht, war der Wunsch vieler Administratoren nach einer simplen Lösung für die Konfigurationsgleichheit aller Instanzen groß. Aus unserer Sicht absolut verständlich.

Microsoft hat sich dieser Thematik angenommen und eine ausgesprochen elegante Lösung entwickelt:
Die Contained Availability Groups.

Contained Availability Groups im Microsoft SQL Server 2022: Was ist das eigentlich genau?

Zunächst einmal sei gesagt, dass es sich um vollwertige Availability Groups handelt, so dass man keine lieb gewonnenen Eigenschaften verliert. Alle bekannten Fähigkeiten und Features, wie etwa automatisches Seeding oder die bevorzugten Replikate für Datenbank-Backups, sind enthalten.

Es handelt sich vielmehr um eine Erweiterung zur verbindungsabhängigen Instanzkonfiguration. Sofern man sich gezielt (sprich mittels AG-Listener) zur AG verbindet, erhält man gewissermaßen einen anderen Blick auf die Instanz. Der Clou dabei ist, dass die gewünschten Objekte mit der AG zusammen umziehen. Gewünschte Objekte können in dem Falle sein:

Anmeldungen (Konten)
Server-Rollen
SQL Server Agent Jobs
Database Mails
und ähnliches

Das heißt also, eine Contained Availability Group kann dedizierte Konfigurationen der Instanz enthalten.

Wie funktioniert der Umgang mit den Contained Availability Groups im Microsoft SQL Server 2022?

Die eigentliche Nutzerdatenbank, welche man in einer Contained Availability Group hochverfügbar betreiben will, wird nicht verändert. Die Methodik basiert vielmehr auf einer Art Layer-Prinzip, wie man es von Views auf Tabellen kennt. Und erneut: Es ist von entscheidender Bedeutung, dass man mit dem Listener der AG verbunden ist. Denn – und das ist der eigentliche Trick – im Hintergrund werden individuelle Exemplare der Systemdatenbanken erstellt. Diese legen sich anschließend transparent über die echten Systemdatenbanken und nehmen die gewünschten Konfigurationen auf. In der Konsequenz bedeutet dies, dass beispielsweise neu angelegte Konten (Anmeldungen/Logins) nicht tatsächlich in der Instanz erstellt werden, sondern stattdessen (durch Umleitung) in einer Art “Schatten-Systemdatenbank”. Und genau diese Datenbanken sind (von Beginn an) Mitglied der Contained Availability Group und wechseln daher bei jedem Failover mit. Das Verfahren ähnelt dabei einer Überlagerung. Verbindet man sich zum Listener der AG, so sieht man die individuellen System-Datenbanken, nicht die echten.

Zum besseren Verständnis:

Man könnte sagen, der SQL Server 2022 “schummelt” beim Anlegen von Anmeldungen. Neue Logins werden nicht in der echten master-Datenbank und neue SQL Server Agent Jobs nicht in der echten msdb-Datenbank abgelegt. Aber: Der Zweck heiligt die Mittel.

Was passiert dann mit der Verwaltung einer individuellen Instanz?

An der Verwaltung einer individuellen Instanz hat sich nichts geändert. Denn der Effekt wirkt nur dann, wenn man sich von Beginn an zum Listener der AG verbindet. Baut man hingegen eine Verbindung zu einer der individuellen Instanzen auf (ohne auf primäre und sekundäre Rollen der AGs zu achten), so bleibt alles beim Alten. Man arbeitet wie gewohnt mit den echten Systemdatenbanken.

Dazu hier eine kurze Gegenüberstellung. Stellt man sich eine simple Always On Umgebung aus zwei Teilnehmern …

1. Standardinstanz auf Host SERVER1

2. Standardinstanz auf Host SERVER2

… vor, welche gemeinsam eine Contained Availability Group namens ALWAYSON bilden, die wiederum den Listener HASERVER verwendet, und legt beispielsweise eine neue SQL-Anmeldung (ein Login) an …

CREATE LOGIN                   [TestAccount]
 WITH  PASSWORD              = 'SimplePassword4Test!',
       DEFAULT_DATABASE      = [master],
       DEFAULT_LANGUAGE      = [English];

… so gilt:

bei Verbindung zu SERVER1
(dediziert)

Die Anmeldung existiert anschließend real in der [master]-Datenbank von Instanz SERVER1.

Die Nutzung dieser Anmeldung ist wie gewohnt möglich.

bei Verbindung zu SERVER2
(dediziert)

Die Anmeldung existiert anschließend real in der [master]-Datenbank von Instanz SERVER2.

Die Nutzung dieser Anmeldung ist wie gewohnt möglich.

bei Verbindung zu HASERVER
(als Listener der AG)

Die Anmeldung existiert in keiner der [master]-Datenbanken, sondern in den “Schattendatenbanken” der Contained Availability Group ALWAYSON, welche von der Synchronisation erfasst werden.

Die Nutzung dieser Anmeldung ist nur im Kontext der Contained Availability Group möglich.

Instanzen verwalten ohne Umgewöhnung

Somit ist sichergestellt, dass man ohne jegliche Umgewöhnung die einzelnen Instanzen verwalten kann. Gleichermaßen können Konfigurationsaspekte gewissermaßen an eine Availability Group gebunden werden, welche auf allen teilnehmenden Replikaten identisch sind. Und genau das ist schließlich auch das Schöne an dieser Implementierung.

Übrigens:

Jene Art der Einbindung geht sogar so weit, dass man nicht nur neue Sachen in den “Schattendatenbanken” anlegen kann. Es ist darüber hinaus möglich, vorhandene Konfigurationen zeitweilig zu überschreiben, indem man bereits existierende Objekte mit gleichnamigen überlagert. So funktioniert der zuvor beschriebene Trick nicht nur mit dem (neu anzulegenden) Konto “TestAccount”, sondern sogar mit dem ab Werk vorhandenen sa-Konto.

Fazit und Ausblick

Zur Arbeit mit Contained Availability Groups gäbe es noch viel mehr zu schreiben. Doch der wichtigste Punkt ist klar: Sie sind eine zuverlässige Möglichkeit, um einzelne Instanzeigenschaften und ‑konfigurationen an einer Availability Group festzumachen. Somit wird die Konfigurationsgleichheit aller Instanzen sichergestellt.

Die neue Art der Contained Availability Groups ist ein höchst willkommener Schritt im Hinblick auf eine langfristig sinnvolle Nutzung des Availability Group Konzepts. Egal, ob man eine Datenbank in einer kleinen und schlichten Availability Group aus zwei Instanzen, oder 20 große Datenbanken in einer Distributed Availability Group aus vier Instanzen betreibt. Es lohnt sich allein schon wegen dieses Features, auf den Microsoft SQL Server 2022 zu wechseln.

Bei Fragen zur Arbeit mit den Contained Availability Groups oder zum Upgrade auf den Microsoft SQL Server 2022 helfen wir dir gern weiter.

Hier findest du weitere Beiträge rund um Microsoft aus unserem News & Insights Bereich.

Share this article

Der Beitrag Darauf haben wir gewartet: Contained Availability Groups im Microsoft SQL Server 2022 erschien zuerst auf ASPICON.

Oracle GoldenGate Free: Kostenfreie Datenbank Replikation für kleinere Datenbanken

Alexander Glöckner — Fri, 06 Oct 2023 07:07:27 +0000

Home → Hidden Feature

Oracle GoldenGate Free: Kostenfreie Datenbank Replikation für kleinere Datenbanken

Verfasst von Alexander Glöckner
06 Oktober 2023
09:07
Datenbank, Hidden Feature, Oracle, Oracle Database, Praxistipp, Replikation

Oracle GoldenGate ist eine führende Lösung für die Replikation von Daten in Echtzeit zwischen verschiedenen Datenbanken. Mit GoldenGate kannst du deine Daten sicher und zuverlässig replizieren, konsolidieren, filtern oder transformieren, ohne die Integrität oder Verfügbarkeit deiner Informationen zu gefährden. Nun hat Oracle mit der Version “Oracle GoldenGate 21c Free” das Portfolio der kostenfreien Tools um ein weiteres ergänzt.

Wo die Einsatzgebiete von Oracle GoldenGate im Allgemeinen liegen und ob die Gratis-Version für dich geeignet ist, soll dieser Beitrag beleuchten.

Allgemeine Anwendungsmöglichkeiten von Oracle GoldenGate

Die Anwendungsmöglichkeiten von Oracles Replikationssoftware sind vielseitiger, als du vielleicht denkst. Denn die Software hilft dir unter anderem bei der Datenkonsolidierung und ‑filterung, der Datenbank-Migration und ermöglicht Echtzeitanalysen sowie Zero-Time-Upgrades.

Datenkonsolidierung und ‑filterung:
Mit Oracle GoldenGate kannst du Informationen aus verschiedenen Datenbanken in eine Datenbank zusammenführen. Das ist besonders für Unternehmen mit mehreren Standorten nützlich.
Datenbank-Migration:
Wenn du planst, deine Datenbank auf eine andere Plattform zu migrieren, sei es aus Gründen der Performance-Verbesserung oder der Kosteneffizienz, ist Oracle GoldenGate dein bester Freund. Du kannst Daten nahtlos zwischen den Datenbanken replizieren und so den Ausfallzeiten vorbeugen.
BI und Datenanalyse:
Mit Oracle GoldenGate kannst du Daten aus verschiedenen Quellen in Echtzeit sammeln, synchronisieren und analysieren, um wertvolle Erkenntnisse zu gewinnen und schnell fundierte Entscheidungen treffen zu können.
Replikation in andere Datenbanken (on Premise oder Cloud):
Oracle GoldenGate hilft dir dabei, deine Daten sicher zwischen verschiedenen Datenbanken unterschiedlicher Hersteller sowie in die Cloud zu replizieren, sei es in eine private, öffentliche oder hybride Cloud-Umgebung.
Zero-Time-Upgrade und Hochverfügbarkeit:
Das Upgrade auf eine neue Version deiner Datenbank sollte keine schlaflosen Nächte verursachen. Oracle GoldenGate gewährleistet, dass deine Daten während des Upgrades sicher und intakt bleiben – ganz ohne Ausfallzeiten.

Hinweis:

Obwohl Oracle GoldenGate eine breite Palette von Datenbanken und Plattformen unterstützt (z.B. Oracle-Datenbanken und Microsoft SQL Server), gibt es immer noch einige Einschränkungen. Stelle sicher, dass deine Ziel- und Quell-Datenbanken vollständig kompatibel sind, bevor du mit der Implementierung beginnst. Außerdem kann die Replikationssoftware erhebliche Ressourcen in Anspruch nehmen, insbesondere bei der Replikation großer Datenmengen in Echtzeit. Stelle sicher, dass deine Systeme über ausreichend Ressourcen verfügen und deine Netzwerkbandbreite ausreicht, um die zusätzliche Belastung zu bewältigen.

Vorteile und Einschränkungen von Oracle GoldenGate Free

Oracle GoldenGate 21c Free ist eine kostenlose Version ähnlich wie die Oracle Database Express Edition (DB XE). Wie in vielen kostenfreien Lösungen gibt es auch hier keine Patches und Updates. Support erhältst du über entsprechende Community-Foren. Daher ist der Einsatz eher für Unternehmen mit kleineren Datenbanken, zum Ausprobieren bzw. Validieren sowie für den privaten Gebrauch zu empfehlen.

Funktionstechnisch eingeschränkt bist du allerdings mit Oracle GoldenGate 21c Free nicht. Es werden alle Funktionen der lizenzierten Version geboten. Darüber hinaus bietet sie eine benutzerfreundliche Oberfläche, womit die Erstellung und Verwaltung von Replikations-Pipelines spielend leicht von der Hand geht. Die Free Version kann allerdings nicht mit der lizenzierten Version verbunden oder kombiniert werden. Außerdem ist die Verwendung auf eine Datenbankgröße von max. 20 GB beschränkt.

GoldenGate Free kann als Docker Container Image oder als Full Installation Image heruntergeladen werden. Du benötigst lediglich einen freien Oracle Account zum Download.

Die folgende Übersicht zeigt die Architektur der Lösung:

Nach der Installation kannst du mittels einer vereinfachten Weboberfläche die Replikation Schritt für Schritt aufbauen. Die Downloadmöglichkeiten sowie Dokumentation von Oracle GoldenGate Free findest du im → Oracle Blog.

Vorteile von Oracle GoldenGate Free:

kostenloses Einsteigerprodukt für Datenreplikation
alle Funktionen der lizenzierten Version von GoldenGate
einfache Installation und Verwaltung
vereinfachte Benutzeroberfläche

Einschränkungen von Oracle GoldenGate Free:

Verwendung mit Datenbanken bis zu einer Größe von max. 20 GB
Support gibt es nur über Community-Foren
kann nicht mit der lizenzierten GoldenGate Version interagieren
keine Patches und Updates

Fazit

Oracle GoldenGate Free ist eine kostenlose, leistungsstarke Lösung, um Daten in Echtzeit zu replizieren und in verschiedenen Szenarien anzuwenden. Egal, ob du deine Daten in eine Datenbank konsolidieren, deine Datenbanken migrieren, Hochverfügbarkeit sicherstellen oder fortschrittliche Analysen durchführen möchtest: Oracle GoldenGate hat das Potenzial, deine Arbeit zu erleichtern und deine Daten zu schützen.

Aufgrund der limitierten Datenbankgröße und des eingeschränkten Supports ist es eine gute Wahl für Unternehmen mit kleineren Datenbanken. Auch zur Validierung oder zum Produkttest bietet sich die Free Version hervorragend an. Die einfache Installation mittels Docker Container rundet das Produkt ab.

Hier findest du weitere Oracle Produkte und wie wir dir als Service Partner zur Seite stehen können.

Share this article

Der Beitrag Oracle GoldenGate Free: Kostenfreie Datenbank Replikation für kleinere Datenbanken erschien zuerst auf ASPICON.