News zu Oracle

Quotas auf Oracle ASM Diskgroups

Das Anlegen je einer Diskgroup pro Oracle Datenbank kann auf Systemen mit vielen Datenbanken leicht aufwändig, unüber­sichtlich und fehler­an­fällig werden. Eine perfekte Lösung für dieses Problem, stellen wir dir in diesem Beitrag vor:  FLEX-Diskgroups mit Quotagroups.

Die seit jeher im Automated Storage Management (ASM) bekannten EXTERNAL‑, NORMAL- oder HIGH-Redundancy-Diskgroups haben ein Problem gemeinsam: Datenbanken in diesen Diskgroups können sich mehr oder weniger beliebig des Platzes bedienen. Laufen mehr als eine Datenbank im ASM, konkur­rieren diese also um Platz und können sich im Extremfall durch Ausreizen des Freiplatzes gegen­seitig zum Stillstand bringen. Bei den genannten Diskgroup-Typen behilft man sich daher gern damit, für jede Datenbank eine eigene Diskgroup bereit­zu­stellen. Das kann auf Systemen mit vielen Datenbanken sehr schnell unüber­sichtlich werden. Und es schützt letztlich noch nicht davor, dass sich ein DBA mit mangelnder Selbstdisziplin „mal schnell“ aus einer anderen Diskgroup bedient, weil er gerade dringend Platz benötigt.

Diesem Problem begegnet Oracle mit einem Quotakonzept, das eines der Features von FLEX-Diskgroups ist. Die Umsetzung erfolgt dabei über zwei Konstrukte, die Filegroup und die Quotagroup, auf die wir im Folgenden genauer eingehen.

Filegroup

Das Konstrukt Filegroup beruht darauf, dass alle Files einer bestimmten Datenbank innerhalb einer bestimmten Diskgroup zu einer Filegroup zusam­men­ge­fasst werden. Das geschieht automa­tisch für alle Datenbanken, die Files in FLEX-Diskgroups ablegen. Man kann dem aber auch vorgreifen und eine Filegroup für eine noch nicht existie­rende Datenbank anlegen. So würde man auch sicher­stellen, dass bereits beim Anlegen das vorge­sehene Limit einge­halten wird.
Filegroups können diverse Attribute zugewiesen werden. Erwähnt sei hier nur die Tatsache, dass das Redundanzlevel der Filegroup insgesamt oder auch einzelner Filetypen innerhalb der Filegroup konfi­gu­rierbar ist. Denkbar wäre also z.B.:

  • Datafiles zu spiegeln
  • Redologfiles ungespiegelt zu betreiben (wenn sie innerhalb der Datenbank bereits multi­plexed sind)
  • typische write-once-File, wie Archivelogs oder Backups mit dem neuen PARITY-Level abzusi­chern und damit den Redundanzoverhead deutlich zu senken

Quotagroup

Die Quotagroup ist das Mittel zum Festlegen einer Quota innerhalb der Diskgroup. Die innerhalb einer Diskgroup definierten Filegroups werden jeweils genau einer Quotagroup zugeordnet, womit die entspre­chenden Datenbanken ihre Quota erhalten. Man kann innerhalb einer Diskgroup mehrere Quotagroups definieren und eine oder mehrere Filegroups einer Quotagroup zuordnen. Ist es das Ziel, den Platz jeder einzelnen Datenbank hart zu begrenzen, würde man für jede Datenbank (= Filegroup) eine eigene Quotagroup definieren.

Will man hingegen nur sicher­stellen, dass eine Menge von Datenbanken in Summe nicht mehr als einen festge­legten Platz verwenden, würde man dafür eine gemeinsame Quotagroup definieren und dieser mehrere Filegroups (= Datenbanken) zuweisen. Diese Datenbanken würden dann zwar unter­ein­ander wieder um den Platz konkur­rieren, aber keine Datenbanken außerhalb der Gruppe beein­flussen. Für Testdatenbanken mag das z.B. ein Kompromiss zwischen Aufwand und Verfügbarkeitsanforderung sein.

Requirements

Eine grund­le­gende Voraussetzung für FLEX-Diskgroups ist, dass sie mit mindestens zwei Failgroups plus einer quorum-Failgroup angelegt werden müssen. Das leuchtet insofern ein, als das Files innerhalb einer FLEX-Diskgroup wahlweise mit erhöhter Redundanz (MIRROR, HIGH) abgesi­chert werden können. Dafür sind ja auch in den herkömm­lichen NORMAL- oder HIGH-Redundancy-Diskgroups mindestens zwei bzw. drei Failgroups erfor­derlich. Werden die ASM-Devices vom Storage bereits redundant gehalten, hat man daher keine wirkliche Veranlassung, das MIRROR-Feature der FLEX-Diskgroup zu nutzen. Hier behilft man sich mit einem einfachen Workaround. Bei einem netto-Platzbedarf von 100 GB lässt man sich dann eben zwei 50 GB-Devices bereit­stellen. Zusätzlich ist je FLEX-Diskgroup ein quorum-Device erfor­derlich. Dafür sind aber nach meiner Beobachtung in ASM 19c 100 MB vollkommen ausrei­chend. Das ist aus Storagesicht sicher ein vertret­barer Overhead.

Anlegen einer FLEX-Diskgroup

Für Anhänger des asmca an der Stelle gleich eine schlechte Nachricht: Das Anlegen von FLEX-Diskgroups mit zwei Failgroups (plus Quorum) ist mit ihm nicht möglich. Er verweigert sich mit folgender, nicht zutref­fender, Fehlermeldung:

Fehlermeldung beim Anlegen einer Flex-Diskgroup mit zwei Failgroups plus Quorum
Fehlermeldung beim Anlegen einer Flex-Diskgroup mit zwei Failgroups plus Quorum

Bleibt also nur das Anlegen mit dem entspre­chenden SQL-Befehl:

SQL>   create diskgroup DG_DATA
2      flex redundancy disk '/mnt/nfs/db-flex-0*'
3      quorum disk '/mnt/nfs/db-flex-quorum';

Diskgroup created.

NOTE: FLEX-Diskgroups werden übrigens bereits mit der nötigen DB- und ASM-Minimalkompatibilität von 12.2.0.0.0 angelegt. Sie können daher folge­richtig auch nicht für Datenbanken der Version 12.1 oder älter verwendet werden.

Anlegen einer Filegroup

Grundsätzlich ist es uns freige­stellt, eine Filegroup vorab anzulegen. Spätestens wenn man Datenbank Files in einer FLEX-Diskgroup ablegt, wird implizit eine zugehörige Filegroup erzeugt. In ersterem Fall ist darauf zu achten, dass als database-Name (im asmca etwas unglücklich „File Group Usage Id“ genannt) der db_unique_name der Datenbank verwendet wird.
Zu Demonstrationszwecken legen wir die Filegroup vorab an. Das kann wahlweise mit dem ASM Configuration Assistant, SQL oder mit asmcmd erfolgen.…

Die Filegroup wird mit dem ASM Configuration Assistant angelegt:

Anlegen einer Filegroup mit asmca
Anlegen einer Filegroup mit asmca

Die Filegroup wird mit SQL angelegt:

SQL>   alter diskgroup dg_data 
2      add filegroup orcl_files
3      database orcl01 ;

Diskgroup altered.

Die Filegroup kann auch mit asmcmd angelegt werden, wenn man gern XML schreibt. Nachdem wir dann eine Datenbank in die +DG_DATA-Diskgroup gelegt haben, sehen wir auch eine entspre­chende Auslastung der Filegroup:

$ asmcmd lsfg -G DG_DATA
File Group          Disk Group  Quota Group   Used Quota MB   Client Name   Client Type
DEFAULT_FILEGROUP   DG_DATA      GENERIC       8
ORCL_FILES          DG_DATA      GENERIC      8000            ORCL01        DATABASE

Da wir beim Anlegen der Filegroup keine Redundanz explizit angegeben haben, werden die Files jetzt in MIRROR-Redundanz vorge­halten. Unterstellt, dass wir bereits im Storage Redundanz haben, stellen wir den Mode unserer Filegroup auf UNPROTECTED um, was der herkömm­lichen EXTERNAL-Redundancy entspricht:

SQL>   alter diskgroup dg_data
2      modify filegroup orcl_files
3      set 'redundancy'='unprotected';

Diskgroup altered.

Damit halbiert sich folge­richtig auch die Anrechnung auf die (aktuell noch nicht festge­legte) Quota:

$ asmcmd lsfg -G DG_DATA
File Group Disk Group  Quota Group Used Quota MB Client Name Client Type
DEFAULT_FILEGROUP   DG_DATA    GENERIC       8
ORCL_FILES          DG_DATA    GENERIC       3968            ORCL01        DATABASE

Anlegen einer Quotagroup

Solange Filegroups keiner Quotagroup zugeordnet sind, unter­liegen sie der GENERIC-Quotagroup und sind in ihrer Größe nicht limitiert. Jedoch könnte auch die GENERIC-Quotagroup mit einem Limit versehen werden. Nur Löschen lässt sie sich nicht. Wir wollen jedoch sicher­stellen, dass unsere Datenbank in der +DG_DATA-Diskgroup einen maximalen Platz einnimmt, z.B. 10 GB. Dazu legen wir eine neue Quotagroup mit einer 10 GB-Quota an und weisen ihr die Filegroup orcl_files zu, in der die Files der orcl-Datenbank liegen.
NOTE: Die Quota der Quotagroup ist als brutto-Wert zu verstehen. Mehrbedarf durch MIRROR- oder HIGH-Redundanz wird direkt auf die Quota angerechnet. Eine 10 GB-Quota lässt also 10 GB UNPROTECTED Files, aber nur 5 GB MIRRORed Files zu. Dazu nutzen wir entweder den asmca oder SQL.

Im Oracle ASM Configuration Assistant sieht das so aus:

Anlegen einer Quotagroup im asmca
Anlegen einer Quotagroup im asmca
Anlegen einer Quotagroup im asmca
Anlegen einer Quotagroup im asmca

In SQL muss folgender Befehl geschrieben werden:

SQL>  alter diskgroup dg_data
2     add quotagroup orcl_quota
3     set 'quota'=10G;

Diskgroup altered.

SQL>  alter diskgroup dg_data
2     modify filegroup orcl_files
3     set 'quota_group'='orcl_quota';

Diskgroup altered.

Wir sehen nun, dass unsere Datenbank der Quotagroup ORCL_QUOTA zugeordnet ist:

$ asmcmd lsfg -G DG_DATA
File Group Disk Group Quota Group Used Quota MB Client Name Client Type
DEFAULT_FILEGROUP DG_DATA GENERIC 8
ORCL_FILES DG_DATA ORCL_QUOTA 5432 ORCL01 DATABASE

… und ca. 5.5 GB einer 10 GB-Quota in dieser Quotagroup ausge­schöpft sind:

$ asmcmd lsqg -G DG_DATA
Quotagroup_Num Quotagroup_Name Incarnation Used_Quota_MB Quota_Limit_MB
1 GENERIC 1 8 0
2 ORCL_QUOTA 3 5432 10240

Vorausgesetzt, dass keine weiteren Datenbanken der ORCL_QUOTA-Gruppe zugewiesen werden, kann die ORCL-Datenbank nun also in der +DG_DATA-Diskgroup maximal 10 GB belegen. Die restlichen 20 GB, die in der 30 GB-Diskgroup verfügbar sind, bleiben dieser Datenbank vorent­halten. Testen wir es:

SQL> create table just_eat_disk (foo number) tablespace users;

Table created.

SQL> alter table just_eat_disk allocate extent (size 4G);

Table altered.

$ asmcmd lsqg -G DG_DATA
Quotagroup_Num   Quotagroup_Name   Incarnation   Used_Quota_MB   Quota_Limit_MB
1             GENERIC          1             0         0
2                ORCL_QUOTA        3             9840            10240

Nachdem wir weitere ca. 4 GB der Quota aufge­braucht haben, dürften wir jetzt nur noch ca. 150 MB in Anspruch nehmen. Folgerichtig schlägt die Anforderung eines weiteren 4 GB-Extents fehl.

SQL> alter table just_eat_disk allocate extent (size 4G);
alter table just_eat_disk allocate extent (size 4G)
*
ERROR at line 1:
ORA-01653: unable to extend table SYS.JUST_EAT_DISK by 8192 in tablespace USERS

150 MB werden uns aber noch zugestanden.

SQL>  alter table just_eat_disk allocate extent (size 150M);

Table altered.

Andere Diskgroups „schützen“

Wir haben gesehen, dass wir die Platzanforderung einer Oracle Datenbank innerhalb einer Diskgroup wirkungsvoll beschränken können. Wie können wir nun aber vermeiden, dass sich die Datenbank Platz von einer anderen Diskgroup „stiehlt“? Ohne spezielle Vorkehrung wäre es uns ja problemlos möglich, zum Beispiel weitere 1 GB einfach aus einer anderen Diskgroups zu beziehen:

SQL> alter tablespace users add datafile '+DG_MORE_DATA';

Tablespace altered.

SQL> select file_name from dba_data_files where tablespace_name='USERS'

FILE_NAME
--------------------------------------------------
+DG_DATA/ORCL01/DATAFILE/users.262.1098474727
+DG_MORE_DATA/ORCL01/DATAFILE/users.256.1098480509

SQL> alter table just_eat_disk allocate extent
2    (datafile '+DG_MORE_DATA/ORCL01/DATAFILE/users.256.1098480509' size 1g);

Table altered.

Das lässt sich unter­binden, indem man

  • eine 1 MB-Quotagroup auf dieser Diskgroup anlegt (kleiner ist nicht möglich und 0 steht für unlimited)
  • eine Filegroup für die orcl-Datenbank auf dieser Diskgroup anlegt und
  • die Filegroup der Quotagroup zuordnet:
SQL> alter diskgroup DG_MORE_DATA add quotagroup no_space set 'quota'=1M;

Diskgroup altered.

SQL> alter diskgroup DG_MORE_DATA add filegroup ORCL_FILES database orcl01
2    set 'quota_group'='no_space';

Diskgroup altered.

So abgesi­chert würde die +DG_MORE_DATA nun bereits den Versuch der orcl01 unter­binden, ein Datafile in dieser Diskgroup anzulegen:

SQL> alter tablespace users add datafile '+DG_MORE_DATA';
alter tablespace users add datafile '+DG_MORE_DATA'
*
ERROR at line 1:
ORA-01119:   error in creating database file '+DG_MORE_DATA'
ORA-17502:   ksfdcre:4 Failed to create file +DG_MORE_DATA
ORA-15437:   Not enough quota available in quota group NO_SPACE.

Fast Recovery Area Diskgroup

Da über den db_re­co­ver­y_­file_­de­s­t_size-Parameter bereits eine quasi-Quota für jede Datenbank auf der Diskgroup für die Fast Recovery Area festgelegt ist, könnte man den Einsatz einer Quotagroup in diesem Fall für überflüssig halten. Das ist aus zwei Gründen leider nicht der Fall:

  1. db_recovery_file_dest_size ist ein Wert, der vom DBA verändert werden kann. Quotagroups hingegen fallen in die Hoheit des ASM-Admins. Das können durchaus zwei verschiedene Personen sein.
  2. Die db_recovery_file_dest_size beschränkt nur den Platz für reguläre Recoveryfiles. Sie verhindert nicht das explizite Anfordern von Platz zum Beispiel für ein Datafile, wie es im Beispiel oben gezeigt wurde. Umgekehrt ist aber im Falle der FRA-Diskgroup auch der Einsatz der oben genannten 1MB-Quota nicht möglich, denn die betref­fende Datenbank muss ja in der Lage sein, Controlfiles, Redologs, Archivelogs, Backups usw teilweise unbekannter Größe in diese Diskgroup zu schreiben.

Also sollte auch die Diskgroup, die die Fast Recovery Area hält, je Datenbank eine Quota in Höhe der Fast Recovery Area Size erhalten.

Fazit

Quotas auf ASM-FLEX-Diskgroups bieten einen sicheren und flexiblen Weg die Platzbelegung von Oracle Datenbanken effektiv zu begrenzen. Es ist somit nicht mehr erfor­derlich, je Datenbank eine eigene Diskgroup zu erstellen. Das spart Aufwand und schafft mehr Übersichtlichkeit beim Storage-Admin, beim Betriebssystem-Admin und beim ASM-Admin. Letzterer bekommt zusätzlich wieder die volle Hoheit über die Platzvergabe an die Datenbanken. Sie kann vom Datenbank-Admin nicht länger ausge­hebelt werden. Die Verfügbarkeit konkur­rie­render Datenbanken bleibt weiterhin gewahrt, da auch beim Einsatz von Quotas die Konkurrenz um Plattenplatz wirksam verhindert werden kann.

Hier findest du weitere inter­es­sante Posts zu den Themen Oracle Datenbank  oder auch Backup and Recovery aus unserem News und Insights Bereich.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email