Corruptie

Oracle Database 11g schenkt evenveel aandacht aan het monitoren en corruptieherstel, als aan de prestaties van het aanvraagsysteem. De automatische controle op de systeemstatus is hier een erg belangrijke functionaliteit, omdat hij reactieve, wanneer zich een kritische fout voordoet, en handmatige controles uitvoert. De controles dekken de databasestructuur, integriteit van de data blocks en herhalingsopdrachten, en andere omstandigheden. Uit de controles vloeit een rapport voort, waarin vaak ook suggesties worden gegeven om een fout te repareren.

De automatische quarantaine van corrupte undo-segmenten is ronduit gaaf. Bij ontdekking van een corrupte tabelruimte voor undo's, zondert Oracle de betreffende ruimte af en zorgt het ervoor dat er geen transacties mee kunnen plaatsvinden. Op die manier wordt de schadelijke data niet verspreid.

De 'Fast Analyze'- functie neemt een hoofdpijndossier weg bij databasebeheerder met grote databases. Hiermee valt een corruptiescan van de tabelindex een stuk sneller uit te voeren dan voorheen. Dit soort opdrachten wordt veelal tijdens de vaste onderhoudsmomenten uitgevoerd, en moeten absoluut afgerond zijn voor de onderhoudsronde voorbij is.

Snapshot Standby

De technologie die zorg moet dragen voor de backup en recovery van het Oracle Database heet Data Guard. Het component beschermt tegen allerlei verschillende storingen in systemen en netwerk, en is niet gebonden aan de locatie. Zoals bij alle failover-systemen, waaronder remote mirroring en lokale clustering, is de standby hier volstrekt afwezig wanneer het primaire systeem operationeel in.

Een geweldige nieuwe functionaliteit in Data Guard heet Snapshot Standby. Daarmee kunt u de standby-database in een tijdelijke lees/schrijfmodus laten draaien, zodat veranderingen aan de database kunnen worden getest terwijl de oorspronkelijke HA/DR beveiliging nog steeds operationeel is. Deze functie kan in zijn eentje al voor een fikse verandering zorgen in de manier waarop bedrijven omgaan met best practices rond database-ontwikkeling, veranderingsbeheer, ijkpunten, upgrades aan applicaties en soortgelijke taken.

Stel: u moet een verandering doorvoeren in een opgeslagen procedure binnen uw productiedatabase. Daarbij heeft u geen idee of de verandering de prestatie van uw systeem zal verbeteren, als het al verbetert. In combinatie met Database Replay (zie hieronder) kunt u Snapshot Standby inzetten om verschillende scenario's te testen. Daarbij hoeft u alleen maar de productiewerklast van de primaire database te documenteren, de standby-database in lees/schrijfmodus te plaatsen, en de veranderingen daarin te implementeren. Vervolgens kunt u de werklast daar recreëren, en direct vergelijken met de oude situatie.

De logs van de primaire database worden wel naar de Snapshot Standby-sessie gestuurd, maar niet toegepast. Wanneer u klaar bent met testen kunt u de standby terugzetten naar lees-modus. Alle verandering worden teruggedraaid, en de logs worden alsnog toegepast. Fysiek loopt de standby daarmee nooit asynchroon met de primaire database, dat gebeurt hooguit op het logische vlak.

Snapshot Standby leent zich voor meer scenario's, van troubleshooting in de productie tot het slijpen van de index en plaatsing en opdeling van schijven. Backups en opnieuw ingedeelde indexen kunnen onder een zware gebruikslast worden getest. Eigenlijk zijn de mogelijkheden bijna eindeloos.

Nog een praktisch punt van nut; een van de grootste problemen voor de beheerder is het weren van analisten, ontwikkelaars en anderen uit het productiesysteem. Ze mogen de gegevens best uitlezen, maar om de prestaties en compliance op peil te houden is het beter om hun toegang zoveel mogelijk te beperken. Meestal is dit een kwestie van het klaarzetten van een aparte server die ze kunnen gebruiken, die vervolgens zo vaak mogelijk gesynchroniseerd wordt met de centrale database. Snapshot Standby maakt het mogelijk om dit te doen in een enkel systeem.

Active Data Guard

Ook Active Data Guard maakt gebruik van de standby-database. In dit geval kan de standby in lees-modus worden gezet, met ondersteuning voor real-time opdrachten. Dit lost een van de grootste problemen op voor gebruikers met een OLTP-database, namelijk hoe de OLTP de scheiden van de leesactiviteit terwijl de reporting bijna op realtime blijft.

Het leesbaar maken van de standby met Active Data Guard vergt weinig ingrepen in de configuratie van de client. Applicaties kunnen direct aan de standby gekoppeld worden, of u kunt een soort leesdienst instellen op de primaire servers. Die laatste leidt de werklast in de juiste banen, afhankelijk van het soort activiteit. De applicatie maakt een verbinding met een dienst als het naar de lokale OLTP-database schrijft. Dit maakt het makkelijk om te rapporteren op OLTP-gegevens.

Nadeel is dat het niet mogelijk is om permanente veranderingen door te voeren op de standby. U zit dus vast aan het indexeren (en het instellen van andere configuraties) van de OLTP. Zoals databasekenners weten zijn de OLTP-indexvoorwaarden zelden hetzelfde als de voorwaarden voor de rapportage-index. Daarbij komt dat het configureren van Active Data Guard onder Windows niet bepaald gemakkelijk is. Zelf heb ik weken in contact met Oracle gestaan om het component draaiende te krijgen. Online zijn de instructies niet compleet, en een gids of troubleshooting ontbreken. In mijn eentje was het nooit gelukt.

Maar er gloort hoop: uiteindelijk zijn de instellingsmogelijkheden best te vangen in een wizard, en die gaat volgens Oracle beschikbaar komen in Grid Control 11g. Ingebouwde monitoring en waarschuwingen zou mooi meegenomen zijn. Helaas moet u uw eigen scripts en waarschuwingen vooralsnog zelf instellen.

Toch is Active Data Guard een grote sprong voorwaarts, en beheerders zullen smullen van de mogelijkheden. Als de standby eenmaal draait, loopt het als een zonnetje. Het deed precies wat ik vroeg: aanvragen, schrijven, re-synchronisatie met de primaire database bij terugschakeling. Het is gemakkelijk in gebruik, met slechts één statement kan gewisseld worden tussen de verschillende modi.

Real Application Testing

Real Application Testing bestaat uit twee onderdelen, namelijk Database Replay en SQL Performance Analyzer. De nieuwe functionaliteit maakt het mogelijk om een workload vast te leggen en uit te laten voeren op een willekeurig ander systeem, wat u toestaat om de prestaties naast elkaar te leggen. Database Replay voert de workload precies uit als op het moment dat hij gevangen is, waardoor u systeemveranderingen af kunt zetten tegen de daadwerkelijke productieworkload. U kunt zo zien wat de daadwerkelijke invloed op de database is van gemaakte veranderingen, nog voordat het daadwerkelijk in productie wordt genomen.

Database Replay bleek in mijn tests gemakkelijk in te stellen, en het voerde zijn taken naar verwachting uit. Slechts enige eenvoudige taken moet u onder de knie krijgen, zoals hoe u met de command line het mapobject moet creëren in de database om het proces te vangen. Daarna is het rechttoe rechtaan.

Ik probeerde het met een lees/schrijf gemengde workload, voor vijftig gebruikers. Tussendoor haalde ik de indexen van de tabellen weg, zodat ik zicht had op veranderingen in het aantal rapporten. Zoals verwacht versnelde dit het wegschrijven, terwijl het lezen een stuk langzamer ging. Het replaymechanisme herstelde netjes al mijn processen, en draaide ze foutloos af.

Het instellen van een opname is eenvoudig en voert u langs vier a vijf stappen. Daarbij herstart u normaalgesproken de database, maakt u een map aan om de opnamebestanden in op te slaan en stelt u de starttijd en lengte van de opname in. U kunt ook zelf op de start- en stopknop drukken uiteraard. Activiteit op systeemniveau kan in de capture desgewenst eenvoudig worden weggelaten. Het is ook mogelijk om de opname te beperken tot een specifieke applicatie of code. Zo kunt u probleemgevallen isoleren en een goed delta-overzicht krijgen. De filters hiervoor zijn eenvoudig in te stellen met een grafische interface.

Het is mogelijk om de opgenomen workload te draaien op hetzelfde systeem, wat ik heb gedaan, of op een of meerdere clients. In het geval van grot processen heeft Database Replay een calibratietool die aangeeft hoeveel clients nodig zijn.

De rapportages die eruit komen staan bol van de vergelijkingen tussen het capture-proces en het opgenomen proces. U krijgt daarbij letterlijk honderden berekeningen voor uw kiezen, en ze zijn compleet, maar ze zien er niet uit. Een paar grafieken op de plek van de eindeloze tabelletjes zouden voor het overzicht niet misstaan. De gegevens kunnen wel weer geëxporteerd worden, dus er is mee te werken.

Een alternatieve manier voor procesanalyse, en nu wel met grafieken, is het invoeren van de data in SQL Performance Analyzer. Het systeem maakt geen onderscheid tussen honderd echte gebruikers en honderd virtuele gebruikers die zijn uitgespuugd door een generator, dus de gegevens kunnen gewoon worden gevangen door Performance Analyzer tijdens het uitvoeren.

De gemakkelijkste manier om optimaal gebruik te maken van Real Application Testing is door het te combineren met Snapshot Standby. Dit slaat de status van de standby-database op, welke u later kunt terughalen met alle bijbehorende logs. Deze combinatie geeft u een krachtige en flexibele gereedschap in handen om veranderingen aan de applicaties te testen. U hoeft alleen maar de workload op de primaire database met Database Replay op te nemen, de standby in lees/schrijfmodus in te stellen, en het proces daar af te spelen met eventuele aanpassingen. Na afloop kunnen de resultaten worden vastgelegd, en alles weer terug worden gerold.

Concluderend kan gesteld worden dat Database Replay het probleem van het accuraat uittesten van live-veranderingen, zonder dat deze direct in productie genomen worden, elegant en eenvoudig oplost.

Advanced Compression

Nog een apart gelicenseerde functie: Advanced Compression, zoals de naam aangeeft een manier om gegevens op de schijf in te krimpen. Dit kan opslagkosten terugbrengen, terwijl geheugen- en netwerkbandbreedte worden gespaard en zelfs de aanvragen versneld worden.

Advanced Compression werkt door dubbele waarden (zoals de datum in bestellingen gedurende een hele dag) te verplaatsen naar een apart datablock. Eigenlijk worden de gegevens dus niet gecomprimeerd, maar genormaliseerd op een manier zoals een database-ontwerp dit doet. Hoe meer herhaling in de gegevens zit, des te effectiever werkt Advanced Compression. Omdat het op blockniveau opereert hangt de compressiekracht ook af van hoe de gegevens in de tabellen zijn geordend.

Het component kan verder de I/O-prestaties danig opschroeven. De database kan immers met kleinere gegevenspakketten werken, zodat sneller aan opdrachten kan worden voldaan. Fysiek wordt minder data uit de schijf getrokken. Het is wel even opletten dat de voordelen alleen schuilt in tabelscans, en niet in geïndexeerde zoekopdrachten.

De prestaties van sommige opdrachten gaan dus vooruit, terwijl het voor andere geen verschil maakt. Hetzelfde geldt voor de storage en bepaalde soorten gegevens. De compressie kan zelfs verschillen tussen vergelijkbare data, afhankelijk van indexering en hoe vaak herhaling in de gegevens voorkomt.

Als laatste factor noem ik de Percent Free (PCTFREE), oftewel het percentage wit op een pagina bestemd voor bijvoegsels en updates. Hoe beter de gegevens gecomprimeerd worden, des te meer past op een pagina, en des te minder pagina's verstuurd dienen te worden om aan een opdracht te voldoen. Ook hier is verbetering merkbaar.

Ik heb de functionaliteit getest op twee verschillende databases. De eerste database is gegenereerd uit de TPC-C entry benchmark. Dit simuleert een complete online transactie-omgeving. De tweede is het door Oracle aangeleverde OLTP Table Compression Test Kit.

Het is te verwachten dat verschillende tabellen en data zich verschillend zouden gedragen, en dat is ook wat uit beide tests komt. Twee tabellen in de Oracle testset werden niet alleen teruggebracht tot een kwart van zijn oorspronkelijke grootte, maar ook de afhandeling van aanvragen en zelfs het wegschrijven gingen een stuk sneller. In de TPC-C database was de compressie een stuk minder sterk, met geboekte winsten tussen de 15 en 57 procent. De prestaties van de aanvragen werd in dit geval zelfs negatief beïnvloed.

Uiteraard zult u andere resultaten zien in uw database dan mijn resultaten of die van Oracle. Houd er rekening mee dat deze soms drastisch zullen verschillen per tabel. En bedenk dat veranderingen aan het base-level tabel invloed heeft op de compressieratio. Bij veranderingen is het daardoor mogelijk om flink wat compressie te verliezen, en in het ergste geval kunt u schijfruimte ontberen.

Let er verder op dat Advanced Compression een tol kan eisen van de systeembronnen. Toen ik de leestest uitvoerde op de TPC-C gegevens, heb ik de opdracht gegeven om vergelijkbare data bij elkaar te clusteren, waarna ik specifiek die data opvroeg. Ik had verwacht dat dit de prestatie zou verbeteren. Maar nee. Goed testen dus, anders kunnen de resultaten u onaangenaam verrassen.

Advanced Compression kan een enorme hulp zijn voor de beheerder die het goed toepast. Het voegt wel complexiteit toe aan het aanbrengen van veranderingen in de database-omgeving, iets wat een goede afweging afdwingt. En er dient flink getest te worden op de mogelijkheid om terug te grijpen, nog voordat het geïmplementeerd is.

Conclusie Al met al is dit een zeer sterke uitvoering. Vooruit, er zitten een paar plooien in, maar niets dat een upgrade in de weg zou moeten staan. Met zoveel nieuwe functies biedt het iets voor iedereen, voor zowel kleine als grote bedrijven. Bron: Techworld