1. Vergelijkende studie Oracle - MS SQL server 2008(backup en restore) Katholieke Hogeschool KempenCampus GeelDepartement Handelswetenschappen en Bedrijfskunde3de jaar Toegepaste InformaticaAcademiejaar 2009 -2010Beheer van databanken Paul Jr Geudens (3Ti3)Ben Van de Pol (3TI3)Bart Braet (3TI4)Mickey Dillen (3TI4) TOC
1-5
1Inleiding PAGEREF _Toc246343786 1 2Back-up PAGEREF _Toc246343787 2 2.1Algemene back-uptypes PAGEREF _Toc246343788 2 2.2Back-up bij Oracle PAGEREF _Toc246343789 4 2.2.1Database back-ups PAGEREF _Toc246343790 4 2.2.2Database strategieën PAGEREF _Toc246343791 4 2.2.2.1Cold of Off-line Back-ups PAGEREF _Toc246343792 4 2.2.2.2Hot of On-line Back-ups PAGEREF _Toc246343793 4 2.2.2.3RMAN Back-ups PAGEREF _Toc246343794 4 2.2.3RMAN Backups concepts PAGEREF _Toc246343795 5 2.2.3.1Image copies PAGEREF _Toc246343796 5 2.2.3.2Backup sets PAGEREF _Toc246343797 5 2.2.3.3Full back-up PAGEREF _Toc246343798 6 2.2.3.4Partial database backup PAGEREF _Toc246343799 6 2.2.3.5Incremental Backup PAGEREF _Toc246343800 6 2.2.4Database consistentie PAGEREF _Toc246343801 6 2.2.4.1Consistent Backups PAGEREF _Toc246343802 6 2.2.4.2Inconsistent Backups PAGEREF _Toc246343803 6 2.3Backup bij MS SQL Server PAGEREF _Toc246343804 7 2.3.1Back-up types PAGEREF _Toc246343805 7 2.4Vergelijking PAGEREF _Toc246343806 7 2.5Conclusie PAGEREF _Toc246343807 7 3Restore PAGEREF _Toc246343808 7 3.1Algemene restore procedures (als die er zijn) PAGEREF _Toc246343809 7 3.2Restore bij Oracle PAGEREF _Toc246343810 7 3.3Restore bij MS SQL Server PAGEREF _Toc246343811 8 3.4Vergelijking PAGEREF _Toc246343812 8 3.5Conclusie PAGEREF _Toc246343813 8 Inleiding Databases zijn een essentieel onderdeel van onze informatiemaatschappij. Steeds meer gegevens worden in een database opgeslagen. Het functioneren van de overheid, onze school, ziekenhuizen, bedrijven en wetenschap is tegenwoordig niet meer mogelijk en praktisch onhaalbaar zonder databases. Zeer lang geleden gebeurde gegevensopslag in sequentiële bestanden maar gelukkig is dat tijdperk voorbij. Het systeem dat in databases de opgeslagen gegevens beheert wordt aangeduid als een databasemanagementsysteem of kortweg DBMS. Databases bestaan hoofdzakelijk uit drie onderdelen: de ruwe data of gegevens, het programma waarmee de gegevens worden onderhouden (DBMS) en een gebruikers-interface die het gebruikers mogelijk maakt om de gegevens te beheren. Bekende en veelgebruikte programma’s zijn Microsoft SQL Server, Oracle en MySQL. Naast het DBMS is er een andere cruciale factor die bijdraagt tot kwalitatief hoogstaande gegevens nl. de database administrator, kortweg DBA. De taken van de DBA zijn uit te splitsen naar drie niveaus: strategisch, tactisch en operationeel. Dit werkstuk behandelt slechts een klein deel uit het operationele niveau. Een onmisbaar onderdeel bij het beheren van databases is zonder twijfel back-up en restore. Sinds ‘9-11’ wordt wereldwijd zeer veel aandacht besteed aan het ontwikkelen van goede Business Continuity Plans. Het bleek dat bedrijven die in de torens van het WTC zaten en die beschikten over een degelijke back-up en restore procedures, veel sneller weer operationeel konden worden gebracht dan de bedrijven die al hun data waren verloren. In veel gevallen konden deze bedrijven de klap niet meer te boven komen. Sindsdien is men zich er veel bewuster van geworden dat degelijke back-ups, gedocumenteerde en uitgeoefende noodprocedures, en een goed en up-to-date disaster recovery plan van onmisbaar belang zijn. In dit werkstuk maken we een vergelijking op gebied van back-up en restore tussen 2 DBMS’en. We bespreken de verschillende procedures die Oracle hanteert en vergelijken die met de procedures van Microsoft SQL Sever. Back-up Algemene back-uptypes Er zijn verschillende manieren om de gegevens uit je database veilig te stellen tegen fatale fouten. De types bij de verschillende databaseproducenten komen vrijwel overeen. De naamgeving verschilt soms wel wat. De verschillende types back-up zijn: Full backup en incremental backup Een full backup is een volledige back-up van zowel de database bestanden als van de transaction log. Het is een punt waarop andere back-ups veelal worden opgebouwd. Deze back-up duurt vaak lang en vraagt veel processorkracht. Incremental backups zijn backups van een bepaalde staat van het transactie logbestand. De combinatie van de twee is de meest gebruikelijke manier van back-uppen. Server-side backup en client-side backup Via een SQL-statement kan een database door een client worden geback-upt op de server waardoor server back-ups makkelijk kunnen worden opgenomen in applicaties. Server-side backups zijn over het algemeen veel sneller omdat de data niet moet worden verzonden tussen client en server. Archive backup en image backup Een archief back-up kopieert de database bestanden en het transactie log naar één archief bestand, meestal op een tape. Dit type back-up gebeurt steeds aan de server kant en het kan enkel als volledige back-up. Image backups maken een kopie van de database bestanden en/of de transactie logbestanden, niet naar één bestand maar per type databasebestand een apart back-upbestand. Zo blijven transactie logbestanden en databasebestanden steeds gescheiden. Een image backup biedt meer flexibiliteit dan een archive backup. Online backup en offline backup Back-up van een database die in gebruik is levert een snapshot van een consistente database op, ook al is de database op het moment van de back-up in gebruik door één of meerdere gebruikers. Dit zijn de online backups. Bij een offline back-up worden bestanden simpelweg gekopieerd. Offline back-ups mogen dan ook alleen worden uitgevoerd wanneer de database buiten gebruik is en op de goede manier is afgesloten. Live backup Live backup is het continu back-uppen van de database wanneer deze in gebruik is. Het beschermt tegen fatale fouten waarbij het systeem het volledig begeeft. Vaak zijn het extra back-up oplossing om redundantie te verhogen van backups van transactie logbestanden. Deze kopie kan gebruikt worden om een tweede systeem te herstarten wanneer het primaire systeem faalt. De live backup loopt constant op de achtergrond en wordt enkel beëindigd wanneer de server wordt afgesloten. Het grote voordeel van dit type back-up is dat er vrij snel een tweede systeem kan worden opgezet indien het primaire systeem heeft gefaald. Aan de andere kant vraagt dit type back-up extra processorkracht en kan het zijn dat wanneer de processor druk bezet is niet alle transacties opgeslagen zijn in het back-upbestand. Conclusie Er zijn zeer veel back-upmogelijkheden en verschillende types om je gegevens veilig te stellen tegen systeemfalen. De types worden steeds in combinatie met elkaar gebruikt afhankelijk van de verschillende factoren zoals de snelheid van het eventueel herstel, de belangrijkheid van de gegevens, de mate van nauwkeurigheid die van een back-up verwacht wordt, etc. Hier zal de databasebeheerder een juiste keuze moeten maken tussen de verschillende back-uptypes, hoe en wanneer alles wordt geback-upt. Elk type heeft zijn voor- en nadelen en specifieke doel. Back-up bij Oracle Database back-ups Bij Oracle zijn database back-ups fysiek en/of logisch opgebouwd. Fysieke back-ups zijn van primaire belang bij een goede back-up en recovery strategie. Het zijn exacte kopieën van de fysieke databasebestanden. Fysieke back-ups worden in Oracle gemaakt met het RMAN. RMAN is een back-uptool die standaard geïntegreerd is met het DBMS. Zie punt REF _Ref246164364 2.2.3 hieronder voor een gedetailleerde uitleg bij RMAN. Logische back-ups bevatten logische data zoals tabbellen en stored procedures. Deze kunnen geëxtraheerd worden met een Oracle Database utility zoals “Data Pump Export” en slagen de back-up op als binair bestand. Logische back-ups vullen fysieke back-ups aan. Fysieke back-ups zijn minder specifiek, hebben een minder groot transportvermogen en zijn zeer snel. Logische back-ups hebben een zeer specifiek doel en een zeer groot transportvermogen. Het nadeel is dat deze methode aanzienlijk trager is dan bij de fysieke back-ups. Database strategieën Cold of Off-line Back-ups Om deze back-up uit te voeren dient het ganse systeem correct te worden afgesloten. Daarna wordt het gehele databasebestand samen met de log bestanden en de controlebestanden geback-upt. Deze manier is zeer veilig maar heeft als nadeel dat het gehele systeem niet kan gebruikt worden tijdens het nemen van de back-up. Hot of On-line Back-ups Voor deze methode hoeft het systeem niet te worden afgesloten. Toch zullen de gegevenstabellen die worden geback-upt
gelocked
worden tijdens het nemen van de backup. De controlebestanden moeten apart geback-upt worden omdat ze niet automatisch in dit soort back-up geïntegreerd zit. RMAN Back-ups De RMAN-methode kan zowel in de off als on-line modus uitgevoerd worden. Hiervoor moet je het RMAN “tooltje” gebruiken om de back-up uit te voeren. RMAN zit standaard bij het DBMS van Oracle. Het is aangeraden om een combinatie van verschillende methoden te gebruiken. Bijvoorbeeld wanneer u kiest om een online back-up te maken, maak dan ook steeds database exports. Test hierbij ook steeds alle back-up en recovery scenario’s zorgvuldig. Je neemt best steeds het zeker voor het onzekere! Welke back-up strategie je ook gebruikt vergeet niet om steeds je “software libaries”, parameter bestanden, paswoord bestanden, enz. te back-uppen. RMAN Backups concepts RMAN staat voor “Recovery Manager” en is een “tool” die back-ups van een Oracle database kan maken en in staat is een database met fouten te recoveren en restoren. Het RMAN BACKUP commando ondersteunt de volgende “file types” : Datafiles and control files Server parameter file Archived redo logs RMAN back-ups Men moet wel rekening houden met een aantal belangrijke bestanden die niet geback-upt kunnen worden met het RMAN BACKUP commando. Tot deze bestanden horen “network configuration files”, “password files” en inhoud van Oracle Home. Als je deze toch wilt back-uppen moet je een ander commando gebruiken. Wanneer u het BACKUP RMAN commando in voert, is het resultaat altijd één of meer back-up sets of één of meer “image” exemplaren. Standaard maakt de RMAN back-up sets. Database back-ups gecreëerd door de RMAN worden steeds opgeslagen als “image copies” of “back-up sets”. Zie punt REF _Ref246164747 2.2.3.1 en REF _Ref246164795 2.2.3.2 hieronder voor een meer gedetailleerde uitleg over
image copies
en
backup sets
. Image copies “Image copies” zijn exacte byte-voor-byte kopieën van bestanden. Een “image” kan gewoon op het bestandsniveau van het besturingssysteem opnieuw gekopieerd worden. Image copies die gemaakt zijn via RMAN of “Database Control” zijn opgenomen in de RMAN “repository” zodat RMAN deze kopieën kan gebruiken tijdens een eventueel systeemherstel. RMAN kan bestanden herstellen indien zij worden opgenomen in de RMAN “repository”. Backup sets Backup sets zijn logische entiteiten die worden gemaakt met het RMAN BACKUP commando. Deze opdracht kan één of meer backup sets op de harde schijf of media-apparaten creëren. RMAN kan backup sets slechts op één media-apparaat schrijven. Elke backup set bevat meerdere fysieke bestanden, ook wel back-up stuks genoemd. Een back-up stuk slaat de back-up van één of meer database-bestanden op in een compacte RMAN-specifiek formaat. Een voordeel van back-up sets is dat RMAN gebruik maakt van “unused block compression” om ruimte te besparen in de back-ups van gegevensbestanden. Alleen de blokken in de databestanden die zijn gebruikt voor het opslaan van gegevens zijn opgenomen in de back-up set. RMAN is afhankelijk van serversessies en processen die worden uitgevoerd op de database server. Het maken van back-ups of het herstellen van een database vragen uiteraard flink wat processorkracht. Elke serversessie, op zijn beurt, komt overeen met een RMAN kanaal, dat een stroom van gegevens naar of van een back-up apparaat krijgt. RMAN ondersteunt parallellisme, dit is het gebruik van meerdere kanalen en server sessies die een back-up of herstel taak uit voeren. Correct gebruik van parallellisme kan back-up en “recovery” prestaties flink verhogen. Full back-up Een volledige back-up van een data-bestand bevat alle gebruikte blokken van dat data-bestand. Een “image” kopie is een bit-voor-bit kopie van een gegevens bestand, en bevat dus ook de ongebruikte blokken in de databasebestanden. Partial database backup Een “partial database backup” bevat een subset van de database: individuele “tablespaces” of data bestanden. Een “tablespace” back-up is een back-up van alle data bestanden in een “tablespace” of in meerdere “tablespaces”. Tablespace back-ups, consistent of inconsistent, zijn alleen valide als de database operationeel is in de ARCHIVELOG modus omdat de “redo” functie beschikbaar moet zijn om de “restored tablespace” consistent te maken met de rest van de database. Incremental Backup Een RMAN “incremental backup” kopieert enkel de blokken in de “data-file” die wijzigen tussen de back-ups. Een niveau 0 “incremental backup” kopieert alle blokken in de “data-file” en word gebruikt als vertrekpunt voor een “incremental backup strategy”. “Incremental backup” op niveau 1 kopieeren alleen “images” van de blokken die zijn gewijzigd sinds de vorige “incremental backup”. Niveau 1 back-ups kunnen cumulatief zijn, in welk geval alle blokken die veranderd zijn sinds de meest recente back-up op niveau 0 zijn opgenomen, of differentiële, in welk geval alleen blokken die veranderd zijn sinds de meest recente niveau 0 of niveau 1 “incremental backup” zijn opgenomen. Een typische strategie voor het maken van “incremental backups” van niveau 1 is op vaste tijdstippen, zoals een keer per dag. Database consistentie Consistent Backups Wanneer een database consistent is kan pas een consistente back-up gemaakt worden. De database is in een consistente staat als ze is afgesloten met het commando SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, of SHUTDOWN TRANSACTIONAL. Een consistente shutdown garandeert dat elke “redo” is toegepast op de datafiles. Als u de database laad (mount) en een back-up maakt op dit punt, dan kunt u de database herstellen zonder het uitvoeren van de “media recovery”. Inconsistent Backups Een back-up is inconsistent wanneer die wordt gemaakt als de database in werking is of wanneer er een back-up is gemaakt na een defect of SHUTDOWN ABORT commando. Nadat de database hersteld is van een inconsistente back-up moet u met behulp van Oracle media de database terug openen. Als deze geopend is, is het afwachten of de toepassing eventuele wijzigingen ten opzichte van de logs opnieuw moet uitvoeren. Backup bij MS SQL Server Back-up types Ook Microsoft maakt gebruik van de typische back-upmethodes. Er zijn voornamelijk 4 types te onderscheiden, namelijk: Full backup Differential backup Een “differential backup” kopieert alle data veranderingen sinds de laatste “Full backup”. Deze back-ups zijn dan ook kleiner en sneller dan de “Full backups”. In verloop van tijd zullen er steeds meer dataveranderingen gebeuren zullen de “differential backups” steeds groter en groter worden. Een “Full backup” creëert steeds een “Check Point” wat betekent dat als er een “Differential backup” uitgevoerd word steeds vanaf die laatste “check point” begint. Vergelijking Conclusie Restore Algemene restore procedures Restore-procedures worden uitgevoerd wanneer een database corrupt geraakt is, de gegevensdragers van de database fysiek beschadigd zijn of het besturingssysteem van de database-server gecrashed is. Andere redenen kunnen ook zijn dat de gebruiker gegevens verwijderd heeft die niet verwijderd of bijgewerkt mochten worden. Zoals hierboven beschreven is het bijhouden van backups belangrijk en een taak die regelmatig moet uitgevoerd worden. De frequentie van full backups in combinatie met differential of incremental backups bepaalt hoe groot het recovery window is bij een fatale crash. Logischerwijs is het restoren van een database gemakkelijker en eenvoudiger te doen wanneer er een zo recent mogelijke full backup wordt gebruikt waar daarna een differential backup wordt overheen gerestored. Incrementele backups hebben dan als voordeel dat men toch met kleinere backupfiles per keer kan terugkeren in een bepaald punt in het verleden. Restore bij Oracle Restore bij MS SQL Server Restoren van databases Voor MS-SQL is er een proces dat ervoor zorgt dat een database in orde en consistent blijft, dit proces heet SQL Server Recovery process en is een intern mechanisme. Als deze service wordt herstart wordt automatisch een recovery-proces geïnitieerd. Het proces begint te zoeken naar het laatste checkpoint en vervolgens worden voltooide transacties naar de database geschreven. Tot slot worden op onvoltooide transacties een rollback uitgevoerd. Dit hele proces kan ook manueel gestart worden. Voor dat een restore procedure wordt uitgevoerd wordt eerst een Safety Check gedaan; dit interne mechanisme zorgt er voor dat een restore-procedure goed kan starten. In enkele gevallen wordt een restore-procedure niet uitgevoerd: Als de databasenaam in RESTORE DATABASE verschilt met de naam in de back-up of als de database-naam al bestaat in de SQL-server waar de back-up op wordt teruggeplaatst. Als de bestanden op de SQL-doelserver verschillend zijn van de bestanden in de back-up Als niet alle bestanden voor handen zijn om een goede restore uit te voeren Bij het restoren van een database moet men zich er van vergewissen dat in de eerste plaats de database in “single-usermode” staat. Dit houdt in dat de database in een modus staat waarin slechts een gebruiker toegang heeft tot de gegevens. Dit is om te vermijden dat tijdens de restore clients gegevens opvragen of aanpassen met een corrupte database tot gevolg. In single-usermode is de enige gebruiker die wordt toegelaten meestal de sysadmin, dbcreator of db_owner. Bij het restoren van een differential backup verschilt samen met de syntax (in dit geval in Transact-SQL) ook het principe; men moet in acht houden dat er eerst een full-backup geplaatst is waarop die ene differential-backup dan op kan verderbouwen. Dit in tegenstelling tot incremental backups waarbij iedere incremental backup de andere moet opvolgen sinds de restore van een full-backup. Indien een van deze incremental backups mist of corrupt is kan men niet verder gaan met de volgende incremental backups. Het risico op data-corruptie of een te klein window dat in de tijd terug gaat wordt hierdoor aanzienlijk groter. Het is daarom aangeraden om met full in combinatie met differential backups te werken. Naast het restoren van de database-gegevens zelf moet er ook een backup teruggeplaatst worden van de Transaction Log. In deze log worden de laatste acties bijgehouden die weggeschreven zijn naar de database. Het belang van deze log is voor de hand liggend: aan de hand hiervan kan tijdens het live zijn van de database gekeken worden wat er al geschreven is en kan in combinatie met de backups een zo recent mogelijke versie van de database bekomen worden. Beveiligingsmaatregelen bij restoren backups onder MS SQL Bij het restoren van een database onder MS SQL is het ook belangrijk dat men verifieert of de bron waar de backups van komen wel een vertrouwde en gekende bron is. Backups die van een andere bron komen kunnen vervuild zijn of kwaadaardig code bevatten die onbedoelde en nare gevolgen in Transact SQL kan hebben. Voor het gebruik van een backup of andere database die van een minder bekende en vertrouwde bron komt kan men best een check doen met behulp van “DBCC CHECKDB” en een grondige analyse uitvoeren van de stored procedures op een niet-productie server. Vergelijking Conclusie