News zu Oracle
Das Anlegen je einer Diskgroup pro Oracle Datenbank kann auf Systemen mit vielen Datenbanken leicht aufwändig, unübersichtlich und fehleranfä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, konkurrieren diese also um Platz und können sich im Extremfall durch Ausreizen des Freiplatzes gegenseitig zum Stillstand bringen. Bei den genannten Diskgroup-Typen behilft man sich daher gern damit, für jede Datenbank eine eigene Diskgroup bereitzustellen. Das kann auf Systemen mit vielen Datenbanken sehr schnell unübersichtlich 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.
Das Konstrukt Filegroup beruht darauf, dass alle Files einer bestimmten Datenbank innerhalb einer bestimmten Diskgroup zu einer Filegroup zusammengefasst werden. Das geschieht automatisch für alle Datenbanken, die Files in FLEX-Diskgroups ablegen. Man kann dem aber auch vorgreifen und eine Filegroup für eine noch nicht existierende Datenbank anlegen. So würde man auch sicherstellen, dass bereits beim Anlegen das vorgesehene Limit eingehalten 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 konfigurierbar ist. Denkbar wäre also z.B.:
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 entsprechenden 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 sicherstellen, dass eine Menge von Datenbanken in Summe nicht mehr als einen festgelegten Platz verwenden, würde man dafür eine gemeinsame Quotagroup definieren und dieser mehrere Filegroups (= Datenbanken) zuweisen. Diese Datenbanken würden dann zwar untereinander wieder um den Platz konkurrieren, aber keine Datenbanken außerhalb der Gruppe beeinflussen. Für Testdatenbanken mag das z.B. ein Kompromiss zwischen Aufwand und Verfügbarkeitsanforderung sein.
Eine grundlegende 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) abgesichert werden können. Dafür sind ja auch in den herkömmlichen NORMAL- oder HIGH-Redundancy-Diskgroups mindestens zwei bzw. drei Failgroups erforderlich. 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 bereitstellen. Zusätzlich ist je FLEX-Diskgroup ein quorum-Device erforderlich. Dafür sind aber nach meiner Beobachtung in ASM 19c 100 MB vollkommen ausreichend. Das ist aus Storagesicht sicher ein vertretbarer Overhead.
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 zutreffender, Fehlermeldung:
Bleibt also nur das Anlegen mit dem entsprechenden 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 folgerichtig auch nicht für Datenbanken der Version 12.1 oder älter verwendet werden.
Grundsätzlich ist es uns freigestellt, 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:
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 entsprechende 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 vorgehalten. Unterstellt, dass wir bereits im Storage Redundanz haben, stellen wir den Mode unserer Filegroup auf UNPROTECTED um, was der herkömmlichen EXTERNAL-Redundancy entspricht:
SQL> alter diskgroup dg_data
2 modify filegroup orcl_files
3 set 'redundancy'='unprotected';
Diskgroup altered.
Damit halbiert sich folgerichtig auch die Anrechnung auf die (aktuell noch nicht festgelegte) 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
Solange Filegroups keiner Quotagroup zugeordnet sind, unterliegen 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 sicherstellen, 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:
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 ausgeschö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 vorenthalten. 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 aufgebraucht 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.
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 unterbinden, indem man
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 abgesichert würde die +DG_MORE_DATA nun bereits den Versuch der orcl01 unterbinden, 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.
Da über den db_recovery_file_dest_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:
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.
Quotas auf ASM-FLEX-Diskgroups bieten einen sicheren und flexiblen Weg die Platzbelegung von Oracle Datenbanken effektiv zu begrenzen. Es ist somit nicht mehr erforderlich, 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 ausgehebelt werden. Die Verfügbarkeit konkurrierender Datenbanken bleibt weiterhin gewahrt, da auch beim Einsatz von Quotas die Konkurrenz um Plattenplatz wirksam verhindert werden kann.
Hier findest du weitere interessante Posts zu den Themen Oracle Datenbank oder auch Backup and Recovery aus unserem News und Insights Bereich.
Share this article