Anda di halaman 1dari 3

June 14, 2007

Manual Standby Database under Oracle Standard Edition


By Sean Hull Orac le's Standby tec hnology has been rebranded as DataGuardin rec ent versions of Oracle. Orac le has added a layer of tec hnologyautomation on top of the standby tec hnology, making automatic Standbytechnology seamless. But what about the folks on Standard Edition Orac le? Arethey left out in the c old? Well, it turns out that it is still possible to c reate a*manual* standby database on Orac le SE. Here's how you do it. 1. First you need to create the initial standbydatabase. Here are the steps to do that: a. Put the primary database in arc hivelogmode, if it is not already, and add at least LOG_ARCHIVE_DEST andLOG_ARCHIVE_START to your init.ora. SQL> SHUTDOWN IMMEDIATESQL> STARTUP MOUNTSQL> ALTER SYSTEM ARCHIVE LOG START; b. Next, c reate a hotbackup of theprimary database. Although you can do this with RMAN, it is probably easiestto just do it manually so you know what is going on. For each tablespace do:

SQL> alter tablespace EXAMPLE begin backup;SQL> !cp example01.dbf /my/db/backup/SQL> !cp example02.dbf /my/db/backup/SQL> !cp example03.dbf /my In the above example, the '!'symbol tells sqlplus to run the c ommand from the shell, so we're using the Unix'c p' c ommand to make copies of those files (which are now frozen in bac kupmode) in another location. c. Now, create a standby controlfilefrom primary database: ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/oracle/dbs/stbycf.ctl'; d. At this point, you want to c opyeverything over to the standby server including datafiles, standby controlfile& config files: $ scp /my/db/backup/*.dbf oracle@192.168.0.10:/export/home/oracle/ e. From the standby mac hine, editthe standby init.ora file. Use this parameter to tell Orac le where files onthe primary database will be loc ated on the standby. For example if you hadfiles in /ora/oracle on primary, and they are moved to /export/home/oracle onstandby, this would work for you: DB_FILE_NAME_CONVERT='/ora/oracle','/export/home/oracle' Note that you can use MULTIPLEpairs of values here, if you have files in different locations. Alternatively,you can startup and mount the standby database then issue: SQL> alter database rename file '/ora/oracle/myfile.dbf' to /export/home/oracle/myfile.dbf' as an example. Now you're also likely to have anew location for your arc hived redo log files, and that's where the parameterLOG_FILE_NAME_CONVERT c omes into play. Important note, neither of thesetwo parameters work for the ONLINE redolog files. Those you will have torename yourself. If you do not do so, you will get an error at the time youtry to SWITCHOVER your standby database. Such errors are easily remedied byrunning that c ommand. f. Now, it's time to start thestandby instanc e and mount it. SQL> startup nomount pfile=/export/home/oracle/admin/SEAN/pfile/initSEAN.standbySQL> atler database mount standby database; g. Almost there. Lastly, we needto rec over the standby database using the AUTO option. Note that you shouldbuild a simple shell script to startup sqlplus and run these commands. A namelike manual_standby.sh would work well. You can then run this periodically,say every half hour, from cron to apply any new archived redolog files thathave showed up via move_standby.sh below. SQL> recover standby database;AUTO h. Now, of course, you'll want totest your standby database. You do this by starting up in read-only mode. SQL> alter database open read only; i. Don't forget to put it back instandby mode so that when your manual_standby.sh sc ript runs from c ron, it won'treturn errors.

SQL> shutdown immediate;SQL> startup nomount pfile=/export/home/oracle/admin/SEAN/pfile/initSEAN.standbySQL> atler database mount standby datab 2. What scripts should run via cron on the primary andstandby database? As we mentioned earlier, a script called manual_standby.shwould work well on the standby database. This script applies new archived redologsthat have arrived from the production system. Run it every half hour and seehow that works for you. The database must be mounted in standby mode (notread-only) or this sc ript will fail. You'll also want a script on the production server. Name itmove_standby.sh, and run it every thirty minutes to start with. This can use rsyncto move redolog files from produc tion to standby. A command like this wouldwork: $ rsync -e ssh -Pazv /ora/oracle/arch/ oracle@remote:/export/home/oracle/arch/ Note that you may want to adjust options to ssh to yourneeds. In addition, this presumes you have ssh autologin configured. Read upon the ssh-keygen command. The .ssh directory c ontains a public key, which isshipped over to the standby machine, and put in the "authorized_keys"file. ssh will then login without a password. Rsync uses ssh as the transportmec hanism, so it also exec utes without a password. Rsync is very smart andonly copies blocks and pieces of files that are different, so it is very fast, andalso does c hec ksums to guarantee c onsistency. 3. Is the standby database behind the productiondatabase? Yes, keep in mind we are creating a manual standbydatabase. The standby database will tend to be behind production by about halfthe size of a redolog file. So if those files are 100M, and you generate 100Mof transactions in 30 minutes, then on average standby will be fifteen minutesbehind. 4. What types of changes and statements on productionwill not be automatically applied to standby? In database parlance, any PHYSICAL changes to the db, plusany commands, issues with the NOLOGGING option. Physical changes inc ludec reation of new tablespaces, adding new datafiles, renaming datafiles, autosizingof datafiles, altering redolog files, altering controlfiles and so on. Inaddition, primary database processes or c ommands using the UNRECOVERABLE optionwill not be propagated to the standby database. There are specific and detailed instructions for making someof these physical changes on the standby db manually, however in many c asesrecreating the entire standby database per the instructions above, might be thebest option.

5. How can we verify that the standby database is up todate? If you already have the manual_standby.sh sc ript runningfrom cron, disable it. Then login with sqlplus and issue: SQL> alter database open read only; Now that you have the database open read-only, run whateverSQL commands you want to in order to verify some change which you know about onproduction. When you are done, shutdown, and startup in standby mode again. Don'tforget to reenable manual_standby.sh in the crontab. 6. What happens if the standby system restarts? You c ould have it automatic ally start the standby database. In that case, be sure to just check the logfiles. If you want to do itmanually in those instanc es, fire up sqlplus and then issue: SQL> startup nomount pfile=/export/home/oracle/admin/SEAN/pfile/initSEAN.standbySQL> alter database mount standby database; 7. What kind of messages can I expect to see in thestandby alert.log? The alert.log is going to have a lot of extra messages sincewe are repeatedly trying to RECOVER when there may or may not be newtransaction logs. When it does this it will say, "looking for arc hived logfile1_356.dbf, not found". On the other hand, if it finds it, it will saythat it is applying it. You can use unix commands "grep" and"less" to sc an through the alert.log file quickly. 8. What other scripts should be put in place? a. a script to cleanup old archivedredo logs on primary. b. a script to cleanup old archivedredo logs on standby c. a script to rotate and archivethe alert.log file when it gets large d. a script to watc h the alert.logfile for ORA-xxxxx errors and report them to nagios if it finds any (on bothprimary and standby) e. a script to login (via ssh autologin)and c hec k what the latest archived redolog file is, and then also login to thestandby and check the alert.log file to verify that those transac tions havebeen applied. 9. How do we switchover in the event of a failure of theprimary? Switc hover *can* be done with a script, however I recommendwith our manual standby database that you (a) monitor for emergencies onproduction and (b) manually perform the failover if necessary. This will avoidfalse positives. Also, it allows you to ship additional redolog data if youhave it available from production. The switchover is a two-step proc ess. a. Apply remaining redo as we havedone before with commands in manual_standby.sh. b. Startup the database normally,in a read-write mode. 10. What network changes need to happen to failover? The listener.ora file should be already configured. You canuse the same config as primary with a different IP, or you can give this db adifferent tnsname. For instance, you c ould call primary SEANA and standbySEANB. Then in your application server configs, when you failover, yourdatabase c onnection c onfigurations need to be updated to point to SEANB. Theapp servers will probably also need to be restarted at this point. 11. Why can't the primary ship redologs and synchronouschanges? Basically they c all it a *manual* standby database for areason. DataGuard supports options that look like the following: LOG_ARCHIVE_DEST_3='SERVICE=stby1 LGWR SYNC AFFIRM'LOG_ARCHIVE_DEST_STATE_3=ENABLE Again, these are not available in Oracle SE. 12. Once we've failed over, how do we switch back to theprimary? Switc hing back to the primary database involves these steps: a. Follow the steps in item 1 aboveto create a standby database on what was the primary system. b. If you want to be perfectlyclean sync ing, do the following: SQL> shutdown immediateSQL> startup restrictSQL> alter system switch logfileSQL> shutdown immediate c. Copy over the last arc hived redologfiles d. Apply them and switc hover asdescribed in item 8 above. 13. Are there special init.ora parameters? What makesour standby database special? The main two things that make it a standby databaseare: a. The standby c ontrol file(created from primary) - alter database create standby c ontrolfileas '/my/path/to/standby.ctl b. The proc ess of mounting as astandby database - startup nomount pfile=standby.ora - alter database mount standbydatabase; There are of course some init.ora parameters which arespecial for the standby database as well: DB_FILE_NAME_CONVERTLOG_FILE_NAME_CONVERT So if you do a "shutdown immediate" on thestandby, you would start again with:

SQL> startup nomount pfile=/export/home/oracle/admin/SEAN/pfile/initSEAN.standbySQL> alter database mount standby database;

Conclusion:
Standby database technology in Oracle is a powerful highavailability solution. Even if you're using Oracle SE, you c an still takeadvantage of these features built into Orac le, with just a little scripting,hand holding, and ample monitoring. Do your researc h, test, test, and testagain on a development server. And don't forget to monitor all your logfilesfor errors. Following these guidelines, you should be in very good shape, at amuc h lower c ost.

Anda mungkin juga menyukai