Keed - Oracle DBA Services

Storage: Automatic Storage Management: 1 + 1 = 3

Het beheren en opzetten van storage ten behoeve van Oracles database is een ingewikkeld en complex verhaal. In de meeste gevallen zijn hierbij meerdere partijen betrokken zoals Unix / Windows beheerders en Oracle DBA'ers en zijn acties zoals bijvoorbeeld het vergroten van shared storage niet mogelijk tijdens productie. Ook het instellen van redundancy-policy met betrekking tot de bestanden waaruit een database is opgebouwd, blijkt in de praktijk vaak een moeilijke opgave. Oracle heeft deze problemen onderkend en heeft in Oracle 10g een out-of-the-box oplossing geïntroduceerd: ASM.

ASM (Automatic Storage Manager) is een geïntegreerd file system en volume manager waarbij verder wordt voorgeborduurd op de met Oracle Managed Files (OMF) ingeslagen weg. Met behulp van ASM wordt het database beheer op het gebied van storage sterk vereenvoudigd. Waar vroeger complexe verplaats-acties nodig waren wanneer de database uit haar voegen begon te groeien, is dit door de inzet van ASM kinderspel geworden.

Door de combinatie van een file-system en volume manager is de DBA minder afhankelijk geworden van file-systeem beheerders en kan de DBA zelfstandig (door middel van de bekende create/alter/drop commando's) instellen op welke manier de data moet worden opgeslagen. Hierbij zijn alle bekende technieken zoals stripping en mirroring voorhanden. Hotspots worden zelfstandig door Oracle gedetecteerd en opgelost indien er nieuwe storage (diskgroups) aan ASM wordt toegevoegd. ASM is dus self-managing.

Het gebruik van ASM biedt de volgende voordelen:

	I/O wordt automatisch door Oracle verdeeld over de beschikbare diskgroups. Indien er een nieuwe diskgroup wordt toegevoegd zal Oracle door rebalancingde beschikbare diskgroups zou efficiënt mogelijk inrichten.
	Large file support. In ASM diskgroups zijn geen limieten van toepassing met betrekking tot filesize (bijvoorbeeld de 2Gb limiet op bepaalde Unix systemen
	ASM kan eventueel gecombineerd worden met 'normale storage'. Er kan dus worden gekozen om bijvoorbeeld de (nieuwe) datafiles in ASM op te nemen, terwijl de Online Redo Log files op een Raw device worden geplaatst. Door de mogelijkheid van combineren kan stapsgewijs naar ASM worden gemigreerd. RMAN biedt hiervoor een aantal commando's.
	ASM kan geïmplementeerd worden in een Oracle RAC omgeving (wordt zelf door Oracle geadviseerd); ASM moet dan op elke clusternode worden geïnstalleerd.
	Oracle 10g Enterprise Manager kan worden gebruikt voor het beheer van ASM en disk management activiteiten.
	De I/O is direct; geen verlies als gevolg van overlappend file-system cache of database cache

Indien in de infrastructuur meerdere Oracle databases aanwezig zijn die op verschillende servers draaien, is het helaas niet mogelijk om van 1 centrale ASM gebruik te maken. ASM is alleen beschikbaar voor de databases die op dezelfde server draaien als ASM. In toekomstige versies van Oracle is het niet ondenkbaar dat dit (minor) bezwaar wordt opgelost.

Oracle heeft ASM geïmplementeerd in de vorm van een Instance welke geen fysieke files zoals controlfiles of datafiles heeft. Gezien een Oracle instance proven technology is, is er dus niet voor gekozen het wiel opnieuw uit te vinden.

Installatie van ASM

Voor dit artikel is gebruik gemaakt van een Windows 2003 server. Uitgangssituatie is een systeem waarop nog geen Oracle software is geïnstalleerd. Om ASM te kunnen gebruiken, moet er minimaal 1 extended partitie beschikbaar zijn waarin een aantal logical drives kunnen worden aangemaakt. Hieronder is te zien hoe op een Windows 2003 server een 4-tal logical drives zijn aangemaakt welke in ASM als diskgroups gebruikt zullen worden:

Figuur 1: Disk Partitionering in Windows (klik op de afbeelding voor vergroting)

Nadat de logical drives zijn aangemaakt (het is niet nodig om de drives te formatteren of er een driveletter aan toe te kennen), kan de Oracle RDBMS software (software-only install) worden geïnstalleerd. Het advies is om de software welke gebruikt wordt door ASM in een apart ORACLE_HOME te installeren als de software welke voor de Oracle database gebruikt gaat worden. De belangrijkste reden hiervoor is het onafhankelijk van elkaar kunnen patchen.

Om ASM te kunnen gebruiken zal er naast een of meerdere database Instances ook een ASM instance aangemaakt moeten worden. De footprint van de ASM database is zeer gering; een SGA van 80Mb is toereikend. De installatie van de Oracle software wordt in dit whitebook niet behandeld.

Nadat de Oracle software is geïnstalleerd, is het noodzakelijk om de aangemaakte logical drive te gaan brandmerken als ASM Filegroups. Hiervoor levert Oracle de tool asmtoolg.exe:

Figuur 2: ASMToolg

Nadat de diskgroups zijn geinitialiseerd kan met behulp van de database assistent (dbca) een ASM instance worden aangemaakt. Doordat de logical drives zijn gekenmerkt als ASM devices, zal er in dbca een extra optie verschijnen om een ASM instance aan te maken. Om ASM te kunnen gebruiken, is het noodzakelijk dat er een deel van de Oracle Readiness Services (Cluster Synchronization Services) wordt geïnstalleerd. Deze CSS wordt automatisch door de OUI geïnstalleerd. Op een Windows platform leidt dit tot de creatie van de OracleCSService. In onderstaand screenshot is ook de OracleASMService+ te zien; deze service start automatisch de ASM-instance wanneer de server gestart wordt.

Figuur 3: De additionele services benodigd voor ASM

Het aanmaken van de ASM instance is een vrij eenvoudig proces. Zelfs het toevoegen en converteren van de ASM disks naar diskgroups is kinderspel. Bij het definiëren van de diskgroups in dbca worden de beschikbare ASM disks getoond. Deze kunnen een-op-een of gegroepeerd worden benoemd als een diskgroup. Bij het aanmaken van een ASM diskgroup kan worden ingesteld welke vorm van redudancy gebruikt moet worden. De redundancy vormen worden later in dit Whitebook uiteengezet.

Hieronder is een screenshot opgenomen van het aanmaken van diskgroups met behulp van dbca:

Figuur 4: Aanmaken van Diskgroups in DBCA (klik op de afbeelding voor vergroting)

In bovenstaande afbeelding is te zien dat DG01 (Diskgroup 01) bestaat uit de ASM disks ORCLDISKDG0 en ORCLDISKDG1 waarbij er gebruikt wordt gemaakt van 'normale redundancy'.

Zoals aangegeven heeft een ASM Instance geen fysieke files met als uitzondering de SPFILE. In deze SPFILE staan een aantal specifieke ASM-parameters waarvan INSTANCE_TYPE de belangrijkste is. De waarde ASM houdt in dat de Instance wordt gebruikt als managementsysteem voor ASM. (reguliere databases hebben de standaard waarde RDBMS). Een ASM-database kan op dezelfde wijze worden gestart als een reguliere database (SQL*Plus of bijvoorbeeld Database Control).

Installatie Database gebruikmakende van ASM

Nadat de ASM instance is aangemaakt, kan door middel van dbca een database worden aangemaakt welke gebruik maakt van de storage mogelijkheden die beschikbaar worden gesteld door ASM. Voor een database moet worden aangegeven van welke ASM diskgroups gebruik gemaakt mag worden. Dit is alleen van belang indien meerdere databases op dezelfde server de ASM Instance delen. Hoewel het niet verplicht is, is het zeer verstandig om ASM in combinatie met Oracle managed files te gebruiken:

Figuur 5: Specificeren locatie datafiles in DBCA (klik op de afbeelding voor vergroting)

In bovenstaand scherm uit de dbca wordt aangegeven dat de datafiles in diskgroup DG01 moeten worden ondergebracht. De prefix '+' is de manier om aan te geven dat een ASM diskgroup betreft. Naast datafiles kunnen ook ondermeer control files, (archived) redo log files en de gehele 'Flash Recovery Area' worden ondergebracht in een diskgroup. Het aanmaken van een database die gebruik maakt van ASM is niet wezenlijk anders dan een reguliere database. Om deze reden wordt de creatie in dit Whitebook niet verder uiteengezet.

Een kijkje onder de motorkap

In de data-dictionary van de ASM is in een aantal views informatie terug te vinden over database welke van de ASM gebruik maken. Hieruit valt ondermeer op te maken in welke diskgroup de files terecht zijn gekomen en wat de redundancy-instelling is.

In de view v$asm_template (zie linkerdeel screenshot) staan alle file types welke door ASM ondersteund worden. De instellingen zoals in deze view zijn opgenomen, zullen worden gebruikt indien nieuwe files worden aangemaakt. Het is mogelijk om eigen templates samen te stellen en hiervan gebruik te maken bij de creatie van database fileszoals bijvoorbeeld Controlfiles. In de view v$asm_alias (zie rechterdeel screenshot) staan de database files welke zijn ondergebracht in de ASM:

Figuur 6: ASM instellingen basis template (klik op de afbeelding voor vergroting)

Figuur 7: Ondergebracht files in ASM (klik op de afbeelding voor vergroting)

In v$asm_alias is informatie terug te vinden over de files welke in ASM zijn ondergebracht. Omdat meerdere databases op een server gebruik kunnen maken van ASM, worden de files gegroepeerd per database weergegeven (TST is naam van de test-database). Onder de kop DATAFILE worden alle datafiles weergegeven (system, sysaux, undotbs1 en users). De datafile hebben een normale redudancy (allen opgeslagen in diskgroup 1). De controlfile en online redo log files en online redo log files hebben een high reduncancy. De mate van redundancy is terug te vinden in de linkerafbeelding. In onderstaande tabel is zijn de verschillende redundancy mogelijkheden schematisch weergegeven:

Redundancy	Coarse	Fine
Normale redundancy	Double Mirroring + striping (stripe = 1 mb)	Double Mirroring + striping (stripe = 128 kb)
Hoge redundancy	Niet beschikbaar	Triple Mirroring + striping (stripe = 128 kb)
Externe redundancy	afhankelijk van storage	afhankelijk van storage

Indien wordt gekozen voor normale redundancy wordt er double mirroring toegepast. Dit houdt in dat een kopie van de AU (allocation unit, een extent van de file) wordt opgeslagen op een andere disk). Indien voor hoge redundancy wordt gekozen, wordt er triple mirroring toegepast. Bij externe redundancy wordt striping en mirroring overgelaten aan de storage zelf (mirroring vindt plaats op Storage-device niveau zoals bijvoorbeeld RAID)

De manier waarop ASM mirroring toepast, is verschillend van wat storage-producenten verstaan onder mirroring. In het laatste geval vindt mirroring plaats op disk niveau: een 'primaire' en mirrored disk zijn dus identiek. ASM past mirroring toe op file-niveau. Dit maakt ASM flexibel om rebalancing-acties te kunnen uitvoeren.

Toevoegen storage aan ASM: Rebalancing

Een uitermate prettige eigenschap van ASM is de zogenaamde Rebalancing-feature. Indien er een wijziging plaatsvindt in de hoeveel storage (diskgroup wordt verwijderd of toegevoegd), zal ASM automatisch de files opnieuw gaan verdelen over de beschikbare diskgroups waarbij het uitgangspunt is dat er geen hotspots gaan ontstaan. Om deze Rebalancing aan te tonen, wordt er aan de bestaande diskgroup toegevoegd. De uitgangssituatie is de volgende:

Figuur 8: Uitgangssituatie Rebalancing (klik op de afbeelding voor vergroting)

Om aan de diskgroup DG01 een nieuwe disk toe te voegen, moet het volgende commando worden uitgevoerd:

Figuur 9: Toevoegen van een disk aan de diskgroup DG01 (klik op de afbeelding voor vergroting)

Met behulp van de rebalance power-clause kan worden gespecificeerd met welke snelheid (en dus impact) de rebalancing door ASM moet worden doorgevoerd: 1 is het langzaamst met de minste impact (door draaiende systemen) terwijl 11 de snelste rebalancing tot gevolg heeft. De voortgang van de rebalancing kan gevolgd worden in de view v$asm_operation:

Figuur 10: Voortgang van de Rebalance actie (klik op de afbeelding voor vergroting)

In de kolom EST_MINUTES (meest rechter kolom) wordt de resterende tijd benodigd voor rebalancing aangegeven. In de derde rij wordt de rebalancing daadwerkelijk uitgevoerd; de resterende tijd bedraagt hier 4 minuten; in de rij daaronder nog 3 minuten. Wanneer de rebalancing gereed is, verdwijnt het proces uit bovenstaande view.

Toevoegen van een tablespace aan een database

Indien een database gebruikt maakt van ASM, is het toevoegen van een tablespace (en impliciet een datafile) eenvoudig. Alleen de diskgroup waarbinnen de datafile moet worden opgeslagen en de grootte van de tablespace hoeft gespecificeerd te worden. De filename wordt bepaald door OMF (Oracle Managed Files). Wanneer de datafile wordt toegevoegd aan de diskgroup vindt direct een rebalancing actie plaats.

show parameter db_create_file_dest

NAME TYPE VALUE
------------------------------------ ----------- --------------------------
db_create_file_dest string +DG01
SQL>
SQL> create tablespace WH_TEST datafile size 100M;

Tablespace created.

SQL> select file_name from dba_data_files where tablespace_name='WH_TEST';

FILE_NAME
---------------------------------------------------------------------------

+DG01/tst/datafile/wh_test.266.619905561

SQL>

Doordat er gebruik wordt gemaakt van OMF kan door middel van de parameter DB_CREATE_FILE_DEST wordt opgegeven in welke diskgroup de datafiles moeten worden aangemaakt (in voorbeeld +DG01). Zoals uit het CREATE TABLESPACE-commando blijkt, wordt alleen de tablespace_name en grootte gespecificeerd. Indien OMF gebruikt wordt, is het in principe niet noodzakelijk om de grootte te specificeren. Indien er geen size-clause wordt meegegeven aan het create commando, wordt standaard een tablespace van 100Mb (autoextendable) aangemaakt. Bij de opslag houdt AMS rekening met de instance (TST) en het type file (datafile). De Instance is van belang omdat meerdere locale database-instances de ASM kunnen delen.

In de alert.log van de TST-database kan worden gevolgd dat er automatische rebalancing plaatsvindt bij het aanmaken van de tablespace:

create tablespace WH_TEST datafile size 100M
Sat Apr 14 19:59:37 2007
Starting background process ASMB
Starting background process RBAL
Sat Apr 14 20:00:13 2007
Completed: create tablespace WH_TEST datafile size 100M

(output is ingekort)

Backup

Het is niet mogelijk om een traditionele backup te maken van een database welke gebruik maakt van ASM. In principe is er 1 optie wat wel meteen de beste optie is: RMAN. Zoals uit de view v$asm_template blijkt, kan RMAN ook weer gebruik maken van ASM (Backup sets, changetracking). De bewezen backup-strategie van RMAN is voor databases welke gebruik maken van ASM ook van toepassing: alle database-files (datafiles, redolog, controlfiles, spfiles, enz) eerst in de Flash Recovery Area (FRA) onderbrengen (confugureer hiervoor een Disk-channel) en vervolgens met behulp van het 'Backup Recovery Area' de FRA naar tape schrijven.

Conclusie

Vele storage administrators en DBA'ers worstelen met de vraag of de database files moeten worden ondergebracht op een Raw of Cooked file-system. ASM combineert beide strategie tot een uniek concept waar de voordelen van beide keuzes gecombineerd worden. Misschien wel het belangrijkste voordeel van ASM is het automatisch rebalancing. Hierdoor is de tussenkomst van een storage administrator (en de bijbehorende handmatige acties) tot een minimum beperkt. Het gemak waarmee kan worden aangegeven welke redundancy niveau moet worden gehanteerd voor mirroring en stripping voor database files moet vele beheerders aanspreken.

Meer info

	Oracle® Database Concepts 10g Release 2 (10.2)
	Oracle® Database Administrator's Guide 10g Release 2 (10.2)
	Oracle® Database 2 Day DBA 10g Release 2 (10.2)