Redundancy Redo logs (Oracle DB)

Στο άρθρο αυτό θα περιγράψουμε το πως μπορούμε να προσθέσουμε επιπλέον redo logs σε μια βάση oracle ώστε να εξασφαλίσουμε μεγαλύτερο redundancy σε περίπτωση που δημιουργηθεί corruption στο κάποιο redo log file. 

Η oracle by default δημιουργεί κατά την δημιουργία νέου Instance 3 group redo logs που το καθένα περιέχει ένα redo log file. Σε αυτά τα redo logs files αποθυκεύοντε όλες οι αλλαγές που γίνοντε στην βάση ώστε σε περίπτωση προβλήματος η βάση να μπορεί να κάνει recover σε οποιαδήποτε χρονική στιγμή. Αν η βάση είναι σε archive log mode τότε μόλις τα αρχεία γεμίσουν αποθυκεύεται ένα αντιγραφό τους στο δίσκο (archives) και ξαναγράφοντε από την αρχή. Σε περίπτωση που γίνει corrupted ένα από τα redo logs η βάση θα κολλήσει και θα χαθεί η δυνατότητα recovery αυτής.

Για τον λόγο αυτό προτείνεται στις βάσεις παραγωγής σε κάθε group να υπάρχουν τουλάχιστον δύο logs ώστε αν υπάρχει ένα corruption αυτό να μην επιρεάζει το δεύτερο log του group και η βάση να συνεχίσει να δουλεύει κανονικά. Το μόνο μειονέκτημα αυτής της ρύθμισης είναι ο διπλασιασμός των archives. Καλύτερα όμως να έχουμε τον κεφάλη μας ήσυχο όταν έχουμε να κάνουμε με συστήματα παραγωγής δεν συμφωνείτε;.

Συνδεόμαστε στην βάση με sysdba λογαριασμό

CMD>sqlplus ‘sys/<password> as sysdba’

       

Εκτελούμε τις παρακάτω εντολές.

SQL> alter database add logfile member '/oradata/dbfiles/dbname/redo01b.log' to group 1;   
           alter database add logfile member '/oradata/dbfiles/dbname/redo02b.log' to group 2;
           alter database add logfile member '/oradata/dbfiles/dbname/redo03b.log' to group 3;

Χρήσιμα Views:

v$log              
(εμφανίζει πληροφορίες σχετικά με τα redo files)
v$logfile        
(εμφανίζει τα redo log group και τα μέλη τους καθώς και την καταστασή τους)
v$log_history
(εμφανίζει πληροφορίες για την ιστορικότητα των logs)

Διαβασε Περισσοτερα

Oracle Database - Cold Backup - Restore - Recovery

Στο άρθρο αυτό θα περιγράψουμε το Cold Backup-Restore, όπου απαιτείται για να είναι σωστό το backup η βάση να κατέβει (να γίνει δηλαδή shutdown). Αφού η βάση κατέβει είμαστε πλέον σε θέση να αντιγράψουμε όλο τον φάκελο με τα dbfiles της βάσης σε οποιοδήποτε μέσο επιθυμούμε. Αυτό το είδος του backup έχει down time ανάλογο με το μέγεθος της βάσης, αφού όσο διαρκεί το backup η βάση θα πρέπει να παραμείνει ανενεργή. Ενώ το cold backup είναι μια πολύ εύκολη διαδικασία το restore μπορεί να εξελιχθεί σε μια πιο περίπλοκη υπόθεση. Αν θέλουμε να επαναφέρουμε το backup στο ίδιο το μηχάνημα και στην ίδια τοποθεσία από όπου το πήραμε τα πράγματα είναι πολύ απλά, κάνουμε restore-copy από το backup τα dbfiles στην αρχική τοποθεσία. (πριν από αυτό σβήνουμε τα παλιά αρχεία). Τα πράγματα γίνονται πιο περίπλοκα αν θέλουμε να επαναφέρουμε την βάση σε συγκεκριμένη χρονική στιγμή, πριν ας πούμε από ένα corruption. Για να είναι δυνατόν αυτό η βάση πρέπει να είναι σε archive log mode και να γίνει χρήση τόσο του cold backup των datafiles όσο και των archives. 

Η διαδικασία είναι να κάνουμε πρώτα restore τόσο το τελευταίο cold backup της βάσης όσο και τα archives που έχουν παραχθεί μετά από αυτό. Θα πρέπει να γίνουν restore τα controlfiles, τα datafiles και τα archives στους αντίστοιχους φακέλους. Τα redo logs files θα πρέπει να σβηστούνε επειδή θα ξανά δημιουργηθούν με την εκτέλεση της εντολής resetlogs μετά την εφαρμογή των αλλαγών (archives) πάνω στην βάση. Επομένως μετά τις παραπάνω ενέργειες εκτελούμε με την σειρά τα παρακάτω:

         
Συνδεόμαστε στην βάση με sysdba λογαριασμό

CMD>sqlplus ‘sys/<password> as sysdba’
       
Ανεβάζουμε την βάση σε mount κατάσταση.

SQL> startup mount;

Εφαρμόζουμε όλες τις αλλαγές που βρίσκονται στα archives που έχουμε στον default Archive Destination (στο τέλος γράφουμε cancel για να τερματιστεί η συγκεκριμένη διαδικασία). Η παρακάτω εντολή θα εφαρμόσει όλες τις αλλαγές από όλα τα archives που υπάρχουν στο default archive destination.

SQL> recover automatic database using backup controlfile until cancel;

Σε περίπτωση που θέλουμε να εφαρμόσουμε αλλαγές μέχρι κάποια συγκεκριμένη χρονική στιγμή τρέχουμε αντίστοιχα την παρακάτω εντολή και όχι την προηγούμενη.

SQL> recover automatic database using backup controlfile until time 01-JAN;

ή

SQL> recover automatic database using backup controlfile until time '2009-10-21:06:00:00';

Ελέγχουμε την κατάσταση των datafiles και επιβεβαιώνουμε ότι βρίσκονται στην

επιθυμητή χρονική στιγμή

SQL>select status, checkpoint_change#,to_char(checkpoint_time, 'dd-mm-yyyy  hh24:mi:ss') as checkpoint_time,count(*) from v$datafile_header
group by status, checkpoint_change#, checkpoint_time
order by status, checkpoint_change#, checkpoint_time;

Ελέγχουμε αν υπάρχουν ασαφή-fuzzy αρχεία με το παρακάτω query. Αν επιστρέψει

κάτι ανάμεσα στο 0 και 8192 τότε είμαστε οκ.

SQL>select fhthr  thread, fhrba_seq sequence,fhscn scn, fhsta status,
count(*)from x$kcvfh
group by fhthr,fhrba_seq,fhscn,fhsta;

Τέλος είμαστε έτοιμοι να ανοίξουμε την βάση κάνοντας reset τα logs(η αρίθμησή τους ξεκινάει από την αρχή).

SQL>alter database open resetlogs;

Καλό είναι στην συνέχεια η βάση να κατέβει και να παρθεί ξανά backup.

Διαβασε Περισσοτερα