Een klant heeft een LIMS-database (Laboratorium-pakket), Oracle 9.2.0.8 Standard Edition op Windows. Voor weinig geld moet de beschikbaarheid verhoogd worden. Gekozen wordt voor een fysieke standby database, waarbij dus geen gebruik gemaakt kan worden van Data Guard.

Gebruikte bronnen:

– ‘You probably don-t need Data Guard’ by Niall Litchfield, Oaktable.net.

1. Voorbereiden primaire database


De volgende acties uitgevoerd:


– 9.2.0.8-software gedownload en geinstalleerd, standard edition.

– 9.2.0.8-database aangemaakt met naam ‘ prim ‘.

Geprobeerd met log_archive_des_1. Mag alleen met log_archive_dest parameter in de init.ora. Consequentie: 1 plaats voor de archive_log files. De archive-log files moeten later dus met een script gekopieerd worden naar de andere server.

– Op prim-database inloggen als sys:

– ALTER DATABASE FORCE LOGGING; (dan kunnen er geen acties meer plaatsvinden die niet in de log-file gelogd worden).

– SELECT NAME FROM V$DATAFILE;

Lijst ( in dit geval):

C:\ORACLE\ORADATA\PRIM\SYSTEM01.DBF

C:\ORACLE\ORADATA\PRIM\UNDOTBS01.DBF

C:\ORACLE\ORADATA\PRIM\CWMLITE01.DBF

C:\ORACLE\ORADATA\PRIM\DRSYS01.DBF

C:\ORACLE\ORADATA\PRIM\EXAMPLE01.DBF

C:\ORACLE\ORADATA\PRIM\INDX01.DBF

C:\ORACLE\ORADATA\PRIM\ODM01.DBF

C:\ORACLE\ORADATA\PRIM\TOOLS01.DBF

C:\ORACLE\ORADATA\PRIM\USERS01.DBF

C:\ORACLE\ORADATA\PRIM\XDB01.DBF

10 rijen zijn geselecteerd.

– shutdown prim: SHUTDOWN IMMEDIATE;

– copy bovenstaande dbf’s naar tijdelijke directory, in dit geval: C:\ORACLE\ORADATA\SEC\*.DBF (hier zit geen TEMP-datafile bij)

– startup prim-database

– op prim:

ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘c:\oracle\oradata\sec\sec1.ctl’ ;

create pfile=’c:\oracle\ora92\database\initsec.ora’ from spfile; Of wanneer je geen spfile hebt…. Copy de init.ora naar de tijdelijke directory. Omdat ik de ‘ sec ‘ –database op dezelfde server hebt staan, zet ik deze in de %ORACLE_HOME%/database directory.

– Kopieer al de gemaakte files naar de uitwijk-server, en zet ze op dezelfde plek neer als op de primaire server.

Op de uitwijkserver:

– Maak net als bij de primaire server nog een tweede control-file aan: b.v. copy de sec1.ctl naar de sec2.ctl.

– Aanpassing van de initsec.ora – file:

Belangrijk: db_name=zelfde als de primaire-database!!

Vetgedrukt betekent dat dit veranderd is. Vetgedrukt en onderlijnd: nieuw.

*.aq_tm_processes=1

*.background_dump_dest=’c:\oracle\admin\sec\bdump’

*.compatible=’9.2.0.0.0′

*.control_files=’c:\oracle\oradata\sec\sec1.ctl’,=’c:\oracle\oradata\sec\sec2.ctl’

*.core_dump_dest=’c:\oracle\admin\sec\cdump’

*.standby_archive_dest=’c:\oracle\oradata\sec\archive’

*.db_file_name_convert=(‘c:\oracle\oradata\prim\’,

‘c:\oracle\oradata\sec\’)

*.log_file_name_convert=(‘c:\oracle\oradata\prim\’,

‘c:\oracle\oradata\sec\’)

*.db_block_size=8192

*.db_cache_size=25165824

*.db_domain=”

*.db_file_multiblock_read_count=16

*.db_name=’prim‘

*.dispatchers='(PROTOCOL=TCP) (SERVICE=secXDB)’

*.fast_start_mttr_target=300

*.hash_join_enabled=TRUE

*.java_pool_size=33554432

*.job_queue_processes=10

*.large_pool_size=8388608

*.log_archive_dest=’c:\oracle\oradata\sec\archive’

*.standby_file_management=AUTO

*.remote_archive_enable=TRUE

*.instance_name=sec

# The following parameter is required only if the primary and standby databases

# are located on the same system.

*.lock_name_space=sec

*.log_archive_format=’%t_%s.dbf’

*.log_archive_start=true

*.open_cursors=300

*.pga_aggregate_target=25165824

*.processes=150

*.query_rewrite_enabled=’FALSE’

*.remote_login_passwordfile=’EXCLUSIVE’

*.shared_pool_size=50331648

*.sort_area_size=524288

*.star_transformation_enabled=’FALSE’

*.timed_statistics=TRUE

*.undo_management=’AUTO’

*.undo_retention=10800

*.undo_tablespace=’UNDOTBS1′

*.user_dump_dest=’c:\oracle\admin\sec\udump’

Korte engelstalige uitleg uit een documentje geplukt:

  • db_name – Not modified. The same name as the primary database.
  • compatible – Not modified. The same as the primary database
  • control_files – Specify the path name and filename for the standby control file.
  • log_archive_start – Not modified. The same as the setting for the primary database, TRUE.
  • standby_archive_dest – Specify the location of the archived redo logs that will be received from the primary database.
  • db_file_name_convert – Specify the location of the primary database datafiles followed by the standby location of the datafiles. This parameter will convert the filename of the primary database datafiles to the filename of the standby datafile filenames. If the standby database is on the same system as the primary database or if the directory structure where the datafiles are located on the standby site is different from the primary site then this parameter is required.
  • log_file_name_convert – Specify the location of the primary database logs followed by the standby location of the logs. This parameter will convert the filename of the primary database log to the filenames of the standby log. If the standby database is on the same system as the primary database or if the directory structure where the logs are located on the standby site is different from the primary site then this parameter is required.
  • log_archive_format – Specify the format for the archived redo logs using a DBID (%d), thread (%t), and sequence number (%s).
  • log_archive_dest_1 – Specify the location where the redo logs are to be archived on the standby system. (If a switchover occurs and this instance becomes the primary database, then this parameter will specify the location where the online redo logs will be archived.)
  • standby_file_management – Set to AUTO.
  • remote_archive_enable – Set to TRUE.
  • instance_name – If this parameter is defined, specify a different value for the standby database than the primary database when the primary and standby databases reside on the same host.
  • lock_name_space – Specify the standby database instance name.

Use this parameter when you create the physical standby database on the same system as the primary database. Change the INSTANCE_NAME parameter to a value other than its primary database value, and set this LOCK_NAME_SPACE initialization parameter to the same value that you specified for the standby database INSTANCE_NAME initialization parameter.

2. Voorbereiden uitwijk-database.

– Maak een windows service aan voor de nieuwe database:

oradim -NEW -SID sec -STARTMODE manual

– Wanneer niet aanwezig: maak een listener aan en configureer deze hetzelfde als bij primaire database, database zal zich aanmelden bij de listener.

– enablen van ‘dead connections’ : zet de volgende regel in sqlnet.ora op de uitwijk-server:

SQLNET.EXPIRE_TIME=2

– Let op: wanneer een password-file wordt gebruikt (in init.ora staat ‘remote_login_passwordfile=’EXCLUSIVE” dan moet er een passwordfile gemaakt worden, anders foutmelding bij opstarten.

Orapwd file=c:\oracle\ora92\database\PWDsec password=

.ora entries=2

– Nog steeds op de uitwijk-node:

set oracle_sid=sec

sqlplus /nolog

connect /as sysdba

– Maak evt. een spfile:

CREATE SPFILE FROM PFILE=’c:\oracle\ora92\database\initsec.ora’;

– Opstarten standby-database:

STARTUP NOMOUNT;

ALTER DATABASE MOUNT STANDBY DATABASE;

Normaliter volgt dan het commando voor het automatisch applyen van de log-files die in archive-log directory gezet worden. Helaas wordt dit niet ondersteund door de Standard Edition. Hij geeft geen foutmelding, maar doet niets, dus niet uitvoeren !!: (ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;)

3. Bijwerken Stand-by database met archive log files.

De standby database is nu gereed om archive log files te ontvangen en door te recoveren. Hiervoor worden de volgende commando’s gebruikt die in een script, of handmatig uitgevoerd kunnen worden:

Onder sys uitvoeren:

alter database recover automatic standby database until cancel;

alter database recover cancel;

Dit zal uiteindelijk altijd een fout opleveren, daar Oracle probeert door te recoveren, en net zolang archive-log files probeert in te lezen dat hij op een gegeven moment om een archivelog-file vraagt via een soort foutmelding. Deze is nog niet niet gemaakt door de primaire database, dus het is eigenlijk geen foutmelding!!!

Voorbeeld van een dergelijke melding:

Media Recovery Log H:\ORACLE\AGRBUP\ARCHIVE\1_7433.DBF

Media Recovery Log H:\ORACLE\AGRBUP\ARCHIVE\1_7434.DBF

Errors with log H:\ORACLE\AGRBUP\ARCHIVE\1_7434.DBF.

ORA-279 signalled during: alter database recover automatic standby database …

Tue Feb 24 00:09:25 2004

alter database recover cancel

Media Recovery Cancelled

Completed: alter database recover cancel

4. Van standby naar read-only.

Met het commando ‘ ALTER DATABASE OPEN READ ONLY ‘ kan de database weer beschikbaar gemaakt worden om te raadplegen (na ‘ALTER DATABASE MOUNT STANDBY DATABASE’ ).

5. Van read-only naar standby.

Om de database hierna weer te laten bijwerken (dus evt. na de ‘ALTER DATABASE OPEN READ ONLY’):

Shutdown

Startup nomount

ALTER DATABASE MOUNT STANDBY DATABASE;

alter database recover automatic standby database until cancel;

alter database recover cancel;

6. Maken temporary tablespace.

We hebben alleen op de sec-database nog geen temporary tablespace. Hiervoor moet de database in read-only mode geopend worden. Het commando genereert geen writes, en kan dus zonder gevaar uitgevoerd worden.

‘ ALTER DATABASE OPEN READ ONLY’

ALTER TABLESPACE temp ADD TEMPFILE ‘c:\oracle\oradata\sec\temp01.dbf’ SIZE 10M REUSE;

7. Beheeracties die effect hebben op de standby-database.

 



Welke acties op de primaire database hebben effect op de secundaire database maar behoeven geen actie (worden automatisch door het verwerken van log-files meegenomen:


· Wanneer een ALTER DATABASE statement wordt gebruikt met de ENABLE THREAD or DISABLE THREAD-clausule.


· Wanneer de status van een tablespace veranderd (een verandering van read/write or read-only, het online- of offline zetten).


· Het toevoegen van een datafile of een tablespace wanneer de STANDBY_FILE_MANAGEMENT initialization parameter op AUTO staat. In het geval wanneer geen Data Guard wordt gebruikt geldt dit niet en is er actie van de DBA benodigd.


Welke acties op de primaire database hebben effect op de secundaire database en behoeven actie van de DBA:


    

  • Toevoegen van een      datafile, of de creatie van een tablespace (wanneer de parameter STANDBY_FILE_MANAGEMENT      op Manual staat, c.q. geen gebruik wordt gemaakt van Data Guard).
    • 

  • Droppen/verwijderen      van een tablespace c.q. datafile. 
    • 

  • Renamen van een      datafile
    • 

  • Toevoegen of      verwijderen online redo logs.
    • 



Ad1. Toevoegen van een datafile of creatie van een tablespace.


Op ‘prim’-database:


CREATE TABLESPACE testjob DATAFILE ‘c:\oracle\oradata\prim\testjob.dbf’


SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;


Ff checken:


SQL> SELECT NAME FROM V$DATAFILE;


· Place the new tablespace offline:


SQL> ALTER TABLESPACE new_ts OFFLINE;




Kopieer de nieuwe tablespace/file naar de uitwijk-omgeving of naar een tijdelijke omgeving, als het kopieren naar de uitwijk naar verwachting erg lang gaat duren:


Copy c:\oracle\oradata\prim\testjob.dbf c:\oracle\oradata\sec\testjob.dbf


Niet vergeten de tablespace op de ‘prim’ weer online te zetten:


SQL> ALTER TABLESPACE testjob ONLINE;


Wanneer dan de redo-log wordt bijgewerkt op de normale manier, dan is de standby-database weer up-to-date. Kan er niet op gewacht worden: 


op de primaire database: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;


kopieren van de log-file naar de standby-locatie.


Bijwerken via :


Shutdown (optioneel)


Startup nomount (optioneel)


ALTER DATABASE MOUNT STANDBY DATABASE; (optioneel)


alter database recover automatic standby database until cancel;


alter database recover cancel;


Ad2.  Droppen/verwijderen van een tablespace c.q. datafile. 


Drop de tablespace op ‘prim’ :


SQL> DROP TABLESPACE testjob;


SQL> ALTER SYSTEM SWITCH LOGFILE;


Delete c:\oracle\oradata\prim\testjob.dbf




Zorg ervoor dat de logfile op de standby wordt bijgewerkt:






Shutdown (optioneel)


Startup nomount (optioneel)


ALTER DATABASE MOUNT STANDBY DATABASE; (optioneel)


alter database recover automatic standby database until cancel;


alter database recover cancel;


Verwijder hierna de corresponderende datafile:


Delete c:\oracle\oradata\sec\testjob.dbf


Ad3. Renamen van een datafile


Eerst de actie op de primaire database:


Neem de tablespace offline op de ‘prim’ database:


SQL> ALTER TABLESPACE testjob OFFLINE;


Op O.S-niveau: ‘ rename testjob.dbf testjob1.dbf ‘


Binnen SQL:


ALTER TABLESPACE testjob RENAME DATAFILE ‘c:\….testjob.dbf’ TO ‘c:\…..testjob1.dbf’;


ALTER TABLESPACE testjob ONLINE;


Nu bijwerken van de secundaire database:


 Bijwerken van alle logs:




Shutdown (optioneel)


Startup nomount (optioneel)


ALTER DATABASE MOUNT STANDBY DATABASE; (optioneel)


alter database recover automatic standby database until cancel;


alter database recover cancel;


 Breng de standby database down:


SQL> SHUTDOWN;


 Op O.S.-niveau : : ‘ rename testjob.dbf testjob1.dbf ‘


Startup nomount


ALTER DATABASE MOUNT STANDBY DATABASE;


Hierna moet de datafile nog hernoemd worden in de ‘sec’ database:


ALTER TABLESPACE testjob RENAME DATAFILE ‘c:\….testjob.dbf’ TO ‘c:\…..testjob1.dbf’;


Hierna kunnen de log-files weer aan de standby-database aangeboden worden.


Wanneer besloten wordt om de datafile niet te hernoemen, dan zal de standby-database gebruik willen maken van de hernoemde datafile (zoals in control-file vermeld staat), maar niet kunnen vinden. Dan zullen de volgende meldingen in de alert-log komen te staan:


ORA-00283: recovery session canceled due to errors


ORA-01157: cannot identify/lock data file 4 – see DBWR trace file


ORA-01110: data file 4: ‘c:\oracle\oradata\sec\testjob1.dbf’


Ad4. Het toevoegen of verwijderen van online redo log. 




Wanneer op de primaire database een log-file is toegevoegd of verwijderd moet dit ook gebeuren op de uitwijksite. Hiervan zijn de commando’s slechts een klein beetje anders.


Het toevoegen van een redologfile op de ‘sec’-database;


 


SQL> ALTER DATABASE ADD STANDBY LOGFILE 'prim3.log' SIZE 100K;


 


Het verwijderen van een redologfile op de ‘sec’-database;


 


SQL> ALTER DATABASE DROP STANDBY LOGFILE 'prim3.log';


8. Switchover.


In het geval van een calamiteit : switchover naar de SEC-database.


De database mounten met ‘startup mount’ of openen met ‘ALTER DATABASE OPEN’ werkt niet daar de init.ora parameters helemaal op standby staan gericht.


Eerst alle archive-logs bijwerken op de uitwijk-database.


ALTER DATABASE ACTIVATE STANDBY DATABASE;


SHUTDOWN IMMEDIATE;


STARTUP MOUNT;


ALTER DATABASE OPEN; of, als er nog geen redolog-files zijn: ALTER DATABASE OPEN RESETLOGS;


 De tnsnames op de applicatie moet naar de uitwijkdatabase wijzen.


Wellicht moet de applicatie herstart worden.


Om weer naar de primaire database terug te gaan, moet deze eerst weer als uitwijk opgezet worden, en daarna de switchover toegepast zodat alles weer in de oorspronkelijke staat is teruggebracht.


9. Check primair / uitwijk.


Hoe kan je zien of de uitwijkdatabase steeds bijgewerkt is. 


Als de uitwijk-database in de mount-fase staat om te recoveren, is het vrij lastig te bepalen of de database wel wordt bijgewerkt. Wanneer de alert-file wordt bekeken, kan bepaald worden of het recoveren goed gaan, maar is lastig te automatiseren.


Een andere manier is om een eigen tabel te maken in de primaire database en daar elke dag of elk uur een time-stamp in te zetten. Deze kan dan in de uitwijkdatabase uitgelezen worden. Nadeel is dat deze uitwijkdatabase in ‘read-only’ moet worden geopend. Voordeel is dat dit wel te scripten is.