Standby Database per Oracle Standard Edition

mercoledì 17 dicembre 2008 alle 17:58 | Pubblicato su Backup and Recovery, Installation and Configuration | 18 commenti
Tag: , , ,

Alcuni giorni fa ho scritto un post in cui descrivevo un’implementazione artigianale ed ingenua di una soluzione di “alta affidabilità” o “disaster recovery”. La soluzione da me implementata si basava su export/import dello schema database di interessa da una macchina all’altra.  Sono contento di aver scritto tale post, ma soprattuto sono grato ad Alessandro per avermi segnalato un link a un documento  di Niall Lichtfield (il documento sta ancora sul vecchio sito di Niall) in cui si parla di una soluzione “Data Guard” per Oracle Standard Edition.

Confesso che tempo fa gia un’altra persona mi aveva detto di aver messo in piedi una soluzione Data Guard “manuale” su Oracle database Standard Edition. Non ho mai approfondito la cosa perchè mi sembrava una cosa poco pulita (nel senso al limite della “legalità”). L’accenno al fatto che una implementazione manuale di “Data Guard” può essere fatta su Standard Edition nella presentazione di Niall mi  ha spinto a fare una ricerca approfondita. Sono partito dal listino dove in realtà non ho trovato niente.  Alla fine sono andato sulla documentazione e con mia grande soddisfazione ho trovato questo.  Quindi Oracle dichiara espressamente che l’implementazione manuale di uno Standby Database è possibile su Standard Edition. A questo punto ho deciso si fare dei test, essendo una cosa che sicuramente sul lavoro mi servirà.

Siccome sulla documentazione Oracle si da spazio solo all’implementazione “Enterprise” di “Data Guard” ho cercato su internet qualche documento ed ho trovato questo interessante articolo su http://www.databasejournal.com.

Sospesi i test con Oracle 11g ho clonato la macchina virtuale con Oracle 10gR2 che ho usato per altri test e seguito le semplici istruzioni riportate sull’articolo, ho fatto un po’ di controlli incrociati con il documento e gli script di Niall Lichtfield e la documentazione della 10gR2. Ad esempio nell’articolo c’è l’indicazione di eseguire il comando

ALTER SYSTEM ARCHIVE LOG START;

cosa che con 10g non è più necessaria e deprecata (il comando non da errore ma non fa nulla, rif)

Una cosa che mi capita è che il “recover” dell’istanza di standby da sempre errore:

SQL> alter database recover automatic standby database until cancel;
alter database recover automatic standby database until cancel
*
ERROR at line 1:
ORA-00279: change 16718544 generated at 12/17/2008 12:00:44 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf
ORA-00280: change 16718544 for thread 1 is in sequence #619
ORA-00278: log file ‘/opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf’ no
longer needed for this recovery
ORA-00308: cannot open archived log
‘/opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf’
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Il numero di sequenza che cerca è quello del log corrente sull’istanza primaria. Credo che sia normale, perchè per il resto funziona tutto, infatti, prima di questo recorery (e dopo aver creato l’istanza di standby, tra l’altro con un backup a freddo copiando semplicemente tutti i datafile) ho lanciato sull’istanza principale

SQL> @?/rdbms/admin/utlsampl.sql

Che crea lo schema SCOTT e dopo il recovery sulla istanza di standby:

SQL> alter database recover cancel;

Database altered.

SQL> alter database open read only
2  /

Database altered.

SQL> conn scott/tiger
Connected.
SQL> select count(*) from user_tables;

COUNT(*)
———-
4

Infine ho fatto una prova di “switch-over”, infatti il segreto di ogni buona politica di backup è un test di ripristino. Nell’articolo di Databasejournal.com la fa facile, dicendo che basta applicare tutto il redo mancante e poi aprire in modalità read write. Io non ho trovato subito  un modo diretto per aprire in modalità read write il datbase. Seguendo le indicazioni del manuale non funziona  (credo dipenda sempre dal fatto che nel manuale è descritta solo la gestione automatica):

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
——————–
NOT ALLOWED

Ci sono riuscito ripristinando i controlfile di partenza, facendo un recovery incompleto e aprendo con l’opzione RESETLOGS (gli online redolog non li avevo copiati).

Tutti gli altri tentativi di aprire il database in modalità read write con i controlfile usati per lo standby mi davano:

ORA-01666: control file is for a standby database

Cercando meglio ho trovato la soluzione, qui.

SQL> alter database ACTIVATE STANDBY DATABASE;

Database altered.

SQL> alter database open;

Database altered.

SQL> conn scott/tiger
Connected.
SQL> create table pluto (a number);

Table created.

Qui, dice che è meglio non usare ALTER DATABASE ACTIVATE STANDBY DATABASE perché si rischia di perdere dati, ma sospetto che nella gestione manuale non vi siano molte alternative.

L’unico difetto di questa tecnica di “alta affidabilità” o “disaster recovery” come la si vuole classificare, è secondo me il fatto che la seconda istanza non può essere usata, se non in modalità read-only.  Non ho indagato a fondo, ma immagino che sia possibile usare solo physical standby database e non logical standby database con la Standard Edition.

18 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Ciao Cristian

    Volevo solo confermare che database in standby con Standard Edition non solo sono possibili ma anche utilizzate. Noi (Trivadis) abbiamo diversi clienti che usano questa possibilità. Per questo motivo abbiamo sviluppato un “pacchetto” (TvdStandby) che risolve il tutto correttamente. Per più info puoi dare un’occhiata al seguente PDF: http://www.trivadis.com/fileadmin/user_upload/Solutions/Technologieberatung/Admin_Tools/PDF_EN/TvdStandby_070603_en.pdf.

    Saluti,
    Chris

  2. Ho anch’io gli standby manuali per SE in produzione.

    ALTER DATABASE ACTIVATE STANDBY DATABASE è l’unico modo pulito per fare lo switchover nel caso manuale.

    Oracle dice che si perdono dati perché vede tutto dal punto di vista della gestione automatica di Data Guard, dove anche i redo-log online vengono utilizzati per il recovery remoto.

    L’istruzione non fa altro che convertire il controlfile da standby a primario.
    I redo-log vengono ricreati.

    Bye🙂

  3. Ciao, ho un problema in Data Guard da cui non riesco “logicamente” a venirne fuori.

    Devo gestire un DB di standby che non ha problemi nel passaggio degli archived log, ma…
    nel momento in cui eseguo RECOVER AUTOMATIC STANDBY DATABASE mi viene restituito il messaggio di errore:

    ORA-00279: change 480899648136 generated at 05/05/2009 12:46:32 needed for thread 1
    ORA-00289: suggestion : D:\ORADATA\IT\ARCH\ARCH_IT_57177.001
    ORA-00280: change 480899648136 for thread 1 is in sequence #157177
    ORA-00278: log file ‘D:\ORADATA\IT\ARCH\ARCH_IT_57177.001’ no longer needed for this recovery
    ORA-00326: log begins at change 480899665037, need earlier change 480899648136
    ORA-00334: archived log: ‘D:\ORADATA\IT\ARCH\ARCH_IT_57177.001’
    ORA-00326: log begins at change 480899665037, need earlier change 480899648136
    ORA-00334: archived log: ‘D:\ORADATA\IT\ARCH\ARCH_IT_57177.001′

    L’errore 279 collegato al 289 mi indica l’archived log che contiene il numero di sequenza da cui deve partire per il recover.
    L’archived log indicato e’ correttamente presente sul DB di standby.

    In prima battuta ho pensato che il file fosse corrotto e, fortunatamente, l’archive log corrispondente sulla macchina master era ancora presente e cosi’ l’ho ritrasmesso.

    Ma continuo a ricevere lo stesso identico messaggio di errore.

    Questa procedura ha funzionato correttamente per 9 mesi. Non sono state effettuate modifiche sui DB.

    Dove sbattere la testa?

    Grazie.

    • se cerchi su metalink per “ORA-00326 and ORA-00334” trovi alcune note, probabilmente qualcuna fa al caso tuo..
      Secondo me esiste qualche discrepanza di informazioni nel control file dello standby

      HTH
      Alessandro

  4. Ti ringrazio del consiglio.
    E\’ stato parecchio utile.

    Pare che il problema sia da collegare al fatto che andando a vedere la v$archived_log(ultimo record scritto) ottengo questo risultato:

    —————————-
    select resetlogs_time from v$archived_log
    where recid =
    (select max(recid) from v$archived_log)

    24-MAY-05
    —————————-

    Quindi deve essere successo che il DB di standby in quella data sia stato aperto in modalita\’ RESETLOGS perdendo cosi\’ l\’automatismo.

    A questo punto mi conviene provare a riaprire il DB di standby in modalita\’ NORESETLOGS?
    Ho qualche probabilita\’ di salvare la situazione?

    In definitiva e\’ l\’ultimo tentativo che mi tengo prima di ricostruire il db di standby partendo da un backup del primario.

    Grazie, Marco.

  5. Ciao a tutti.
    Il problema che avevo posto a giugno e’ stato risolto.
    In effetti erano corrotti alcuni redo log.
    Procedendo con il backup sul db primario e poi spostando i dati sul db di standby e riattivando la procedura di allineamento e’ andato tutto ok.

    Adesso ho una nuova domanda.

    Attualmente sulle due macchine e’ installata la stessa release di Oracle, la 9.0.2.6

    Nel caso di upgrade di uno dei db (rimanendo sempre all’interno della release 9) sarebbe necessario upgradare anche l’altro oppure il fatto che le versioni non siano allineate non e’ significativo?

    Grazie.

  6. se porti il primary alla 9.2.0.8 io ci porterei anche lo standby,
    ma prima di farlo in produzione comunque farei test , test , test e per concludere test🙂

    Alessandro

  7. Ad averci una macchina disponibile, senz’altro.

    Purtroppo non ce l’ho.

  8. L’installazione della patch e’ andata a buon fine sia sulla macchina primaria che su quella di standby.

    Pero’ mi si pianta quando lancio la catpatch.sql:-/

  9. questo generalmente sulla 9i avviene se ci sono statistiche sul dizionario (generalmente oggetti quindi di SYS SYSTEM), oppure per il parametro archive_log_start a false;
    è anche consigliato mettere echo off su sqlplus

  10. Si, sapevo che poteva esserci il problema sulle statistiche sulla system, ma la readme allegata alla patch diceva che bastava alzare a 150M la shared_pool_size e la java_pool_size (ed io l’avevo fatto, modificando quindi l’SPFILE con l’opzione SCOPE) per evitare questo inconveniente.

    Idem per il log archive che e’ a posto.

    La cosa brutta e’ che il tracing non indica un messaggio di errore, ma si limita a riportare un messaggio generico.

    Mi sa che e’ un casino.

  11. prova ad innalzare ulteriormente shared_pool_size e java_pool_size, che so a 300M

  12. Ma scusate: e’ possibile rimuovere lo standby?

    Ovvero, quali passi si devono compiere se si vuole rasare via la copia di standby?

    E’ sufficiente mettere il db primario in stato di NOARCHIVELOG? In fondo a quelpunto non gli passerebbe i redo e lo standby inpratica sarebbe anestetizzato.

    Oppure si puo’ scegliere un altra strada?

    Se si, quale???

    Grazie per eventuali risposte.

  13. si puo rimuovere

    mettendo
    log_archive_dest_n=”;
    log_archive_dest_state_n=defer;

    questo ti consentirà di attivare lo standby, portarlo nella opzione maximum performance ed aprirlo;

    se è governato dal DG, dovrai agire anche lì disabilitando un pò di cosette che comunque dovresti trovare nella documentazione

    a questo punto hai due DB che vivono di vita propria e lo standby a questo punto lo elimini fisicamente

    Alessandro

  14. Grazie, ottima informazione!

    Se poi in futuro volessi, potrei riattivare lo standby, rimettendo a posto i parametri dell’INIT?

    Ricreo il control file per lo standby sul primario, faccio un bakup dei datafiles, dell’init e dei control file e reimposto tutto come la prima volta che ho creato lo standby.

    Giusto?

  15. proprio così

  16. Sono sempre io🙂

    Questa volta ho una versione di Oracle 10 (versione 4) e devo creare da zero uno standby su un altra macchina.

    Mi sono impratichito sulla versione 9, ma sulla 10 non ho mai fatto questa operazione.

    Ci sono significative novita’ rispetto all versione 9?

    Guardando in giro mi pare di no, ma se qualcuno ha esperienze e puo’ regalarmele, la prima volta che lo incontro gli offro una cena🙂

  17. […] passati oltre quatto anni da quando scrissi questo post in cui parlai dell’implementazione del sistema di disaster recovery basato sullo standby […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: