RE: Common Oracle RDBMS Misconceptions - standby db?
Title: RE: Common Oracle RDBMS Misconceptions - standby db? I guess that's the scenario I was thinking of, Stephane. Primary completely hosed and needing modification in one way or the other... and several hours between failover and switching back with the possibility of a few lost transactions. Thanks for your comments. Lisa -Original Message- From: Stephane Faroult [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 8:28 PM To: Multiple recipients of list ORACLE-L Subject: Re: Common Oracle RDBMS Misconceptions - standby db? But in practice, why would you switch to the standby database, unless the primary database is crashed or worse? You know how it is in a production environment, the database crashes. Even if failover is easy, you always have to instruct users to connect as scott/tiger@backup instead of scott/tiger@prod - or perhaps modify the tnsnames.ora to make it transparent, or perhaps play with IP addresses which may mean trouble for a while with in-memory routing tables etc. My point is that, even if the switch can be quasi-immediate, it is not so easy, so people will naturally try to make the main machine work first, there will be some delay assessing the damage, waiting until 2am to ring the VP in his bed to get the authorization to switch, etc. In real life, half-an-hour or an hour is easily passed before everybody is back at work on the backup machine, busy trying to catch up on the wasted time. Do not forget that since the transmission of redo logs is asynchronous (I have heard about improvements with 9i) some transactions - committed ones - will have been lost, so users will have to check and probably reenter the missing transactions. At this point the main machine will probably be totally out of order. Wait another 2 or 4 hours to have somebody to come if it's a hardware problem, I guess that when everything is over everybody will be on their knees and the last thing they will have in mind is make the old primary database the new standby - assuming of course that all files are intact. And even if the ex-standby machine is possibly less powerful, everybody will probably wait until a quieter time, say the W/E, to switch back to the initial configuration. At which time, in all likelihood, a full database copy will have become necessary; I think that the simple fact of having reentered a couple of transactions not transmitted yet to the standby database would require it. Do I err ? -- Regards, Stephane Faroult Oriole Corporation Voice: +44 (0) 7050-696-269 Fax: +44 (0) 7050-696-449 Performance Tools Free Scripts -- http://www.oriole.com, designed by Oracle DBAs for Oracle DBAs -- Jeremiah Wilton wrote: With graceful standby failover (I demo'd it last year at OOW), you can switch back and forth, back and forth as many times as you want without recopying any database. Basically, when you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile reuse database blah noresetlogs' at this point. Other people don't have to. Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off. The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database. You can go back and forth in this way as many times as you want, and one just picks up the chain of SCNs where the last one left off. You never get a divergence of changes. I have talked to people who found this out, and looked like they were going to cry, thinking of the countless hours they had spent after every standby failover, recopying to the standby to get it rollong forward again. In 9i, they have an automated graceful failover mechanism for standby database. I haven't taken a look at it yet. Probably it is a massive java-based GUI that instantly consumes 512Mb or RAM. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, Koivu, Lisa wrote: OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed
RE: Common Oracle RDBMS Misconceptions - standby db?
Title: RE: Common Oracle RDBMS Misconceptions - standby db? Thank you Jeremiah for your explanation. But to clarify, you can't have both databases open at the same time, can you? That's where I hosed stuff up the first time, and I realized why it didn't work immediately after seeing my error (incompatible archive logs). Or am I off track? -Original Message- From: Jeremiah Wilton [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 7:21 PM To: Multiple recipients of list ORACLE-L Subject: RE: Common Oracle RDBMS Misconceptions - standby db? With graceful standby failover (I demo'd it last year at OOW), you can switch back and forth, back and forth as many times as you want without recopying any database. Basically, when you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile reuse database blah noresetlogs' at this point. Other people don't have to. Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off. The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database. You can go back and forth in this way as many times as you want, and one just picks up the chain of SCNs where the last one left off. You never get a divergence of changes. I have talked to people who found this out, and looked like they were going to cry, thinking of the countless hours they had spent after every standby failover, recopying to the standby to get it rollong forward again. In 9i, they have an automated graceful failover mechanism for standby database. I haven't taken a look at it yet. Probably it is a massive java-based GUI that instantly consumes 512Mb or RAM. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, Koivu, Lisa wrote: OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed to make complete sense to me. I can see how opening a database read only will work and not invalidate the standby, but r/w? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Common Oracle RDBMS Misconceptions - standby db?
tears of happiness thank you, thank you, thank you... /tears of happiness --- Jeremiah Wilton [EMAIL PROTECTED] wrote: With graceful standby failover (I demo'd it last year at OOW), you can switch back and forth, back and forth as many times as you want without recopying any database. Basically, when you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile reuse database blah noresetlogs' at this point. Other people don't have to. Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off. The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database. You can go back and forth in this way as many times as you want, and one just picks up the chain of SCNs where the last one left off. You never get a divergence of changes. I have talked to people who found this out, and looked like they were going to cry, thinking of the countless hours they had spent after every standby failover, recopying to the standby to get it rollong forward again. In 9i, they have an automated graceful failover mechanism for standby database. I haven't taken a look at it yet. Probably it is a massive java-based GUI that instantly consumes 512Mb or RAM. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, Koivu, Lisa wrote: OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed to make complete sense to me. I can see how opening a database read only will work and not invalidate the standby, but r/w? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: mohammed bhatti INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Common Oracle RDBMS Misconceptions - standby db?
Also check out the notes on metalink: #90817.1. It states all the steps and
concept clearly!
Winnie
--
\ /~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~~``~
(@ @) @}-`-,-`-,--- Winnie Liu ---'-,-'-,-{@`~`~
/ V \ Oracle Database Administrator`~`~
o--m-m--o Infonet Services Corporation `~`~
# mailto:[EMAIL PROTECTED]`~`~
~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~
mohammed
bhatti To: Multiple recipients of list ORACLE-L
mkb125@yahoo[EMAIL PROTECTED]
.comcc:
Sent by: Subject: RE: Common Oracle RDBMS
Misconceptions -
root@fatcity.standby db?
com
06/27/01
09:20 AM
Please
respond to
ORACLE-L
tears of happiness
thank you, thank you, thank you...
/tears of happiness
--- Jeremiah Wilton [EMAIL PROTECTED] wrote:
With graceful standby failover (I demo'd it last
year at OOW), you can switch
back and forth, back and forth as many times as you
want without recopying any
database.
Basically, when you fail over to a standby, you shut
down the primary, apply all
the archived redologs to the standby, then copy all
the online logs and the
controlfile from the primary to the standby. People
who use incremental
checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a
'create controlfile reuse
database blah noresetlogs' at this point. Other
people don't have to.
Finally, you recover database to get the last one
or two online logs and open
the standby noresetogs. The standby just picks up
the chain of SCNs where the
primary left off.
The old primary can be immediately pressed into
service as a standby. Just
generate a standby controlfile on the new primary,
copy it into place on the old
primary and start it up as a standby database.
You can go back and forth in this way as many times
as you want, and one just
picks up the chain of SCNs where the last one left
off. You never get a
divergence of changes.
I have talked to people who found this out, and
looked like they were going to
cry, thinking of the countless hours they had spent
after every standby
failover, recopying to the standby to get it rollong
forward again.
In 9i, they have an automated graceful failover
mechanism for standby
database. I haven't taken a look at it yet.
Probably it is a massive
java-based GUI that instantly consumes 512Mb or RAM.
--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton
On Tue, 26 Jun 2001, Koivu, Lisa wrote:
OK. I admit my knowledge on standby is minimal,
having only read up on it,
fiddled with it and used the idea sparingly for
migrations.
However, Jeremiah, I'm very curious. You state
that 'Must reinstantiate
standby after failover by recopying' is a
misconception. Yes, like many of
the things you state below, the documentation does
say that - once you open
a standby db in r/w mode, it is no longer a valid
standby after switching
back to the primary.
Can someone shed some light on why this is not
true? It seemed to make
complete sense to me. I can see how opening a
database read only will work
and not invalidate the standby, but r/w?
--
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
--
Author: Jeremiah Wilton
INET: [EMAIL PROTECTED]
Fat City Network Services-- (858) 538-5051 FAX:
(858) 538-5051
San Diego, California-- Public Internet
access / Mailing Lists
Re: Common Oracle RDBMS Misconceptions - standby db?
On Tue, 26 Jun 2001, Stephane Faroult wrote: But in practice, why would you switch to the standby database, unless the primary database is crashed or worse? - Hardware replace/repair - Move to a larger host - O/S upgrade - File layout revision - Planned/impending infrastructure outage - Database problem in which datafiles are corrupted but redologs are not - Frequent memory faults - Any chronic but not terminal host-related problem - Migration to a new I/O subsystem You know how it is in a production environment, the database crashes. Even if failover is easy, you always have to instruct users to connect as scott/tiger@backup instead of scott/tiger@prod - or perhaps modify the tnsnames.ora to make it transparent, or perhaps play with IP addresses which may mean trouble for a while with in-memory routing tables etc. Well, I guess the presumption is that if someone went to the trouble of setting up a standby, they would actually have a way to point people at the standby in the event of a failover. As you point out, there are a number of scriptable solutions that are suitable. The easiest, and one you mention, is IP address assumption. This is the same method that is used by HA cluster solutions like Veritas HA, HP MC Serviceguard and Compaq TruCluster. It is easy to script, manage and execute. Contrary to your belief, no problems with in-memory routing tables arise, and the change is immediate. It is a simple matter of 'ifconfig delete' and 'ifconfig alias.' These actions take all necessary steps to notify routers and switches on your subnet that ther MAC address of the IP has changed and that packets should be routed accordingly. Using a dedicated IP address just for the database service is a good idea even if you aren't building a standby or HA solution. It comes in handy if you ever decide you want to rehost the database. My point is that, even if the switch can be quasi-immediate, it is not so easy, so people will naturally try to make the main machine work first, there will be some delay assessing the damage, waiting until 2am to ring the VP in his bed to get the authorization to switch, etc. Well, not everyone has to have authorization from a VP to fail over to a standby. The endless troubleshooting is a real problem. At many sites, they set an upper bound on time spent on diagnostics, and require a failover (if a failover is appropriate) after some number of minutes. The various failover scenarios are scripted and packaged in advance. You don't rush around trying to figure it out when the system is failing. In real life, half-an-hour or an hour is easily passed before everybody is back at work on the backup machine, busy trying to catch up on the wasted time. Do not forget that since the transmission of redo logs is asynchronous (I have heard about improvements with 9i) some transactions - committed ones - will have been lost, so users will have to check and probably reenter the missing transactions. At this point the main machine will probably be totally out of order. Wait another 2 or 4 hours to have somebody to come if it's a hardware problem, I guess that when everything is over everybody will be on their knees and the last thing they will have in mind is make the old primary database the new standby - assuming of course that all files are intact. And even if the ex-standby machine is possibly less powerful, everybody will probably wait until a quieter time, say the W/E, to switch back to the initial configuration. At which time, in all likelihood, a full database copy will have become necessary; I think that the simple fact of having reentered a couple of transactions not transmitted yet to the standby database would require it. Do I err ? Basically, the only time you wouldn't do a graceful failover is in the rare event that you didn't have access to the last few logs the primary had written. In that case, you would be forced to activate the standby database as of the time of the last log you have. This is one of the risks you take with a standby database, and the standby must be presented to others within the company as a redundant solution that may result in the loss of some large number of transactions, depending on how how often the standby pulls logs. There must be a contingency plan in place to handle this eventuality that takes your application and data into account. Synchronous log update on the standby side is available in 9.0, and available on previous versions using third-party technologies such as EMC SRDF or Veritas SRVM. These products can be employed to mirror the online logs and controlfile, in order to create a no-loss standby. The problem with this configuration is that it makes the primary beholden to network latency for log writes. This can have a significant impact on performance. I discuss *all* of these considerations at some length in my HA paper on my site. http://www.speakeasy.org/~jwilton/241.pdf -- Jeremiah
RE: Common Oracle RDBMS Misconceptions - standby db?
I'm not sure, but he was probably referring to resyncing a standby. Some people think that in order to get the standby back up after a crash, they need to start over by copying all of the datafiles. Instead, all you have to do is ftp the archive log files over, recover standby database and apply the logs, and put into managed recovery mode. Mike From: Koivu, Lisa [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Common Oracle RDBMS Misconceptions - standby db? Date: Tue, 26 Jun 2001 11:12:24 -0800 OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed to make complete sense to me. I can see how opening a database read only will work and not invalidate the standby, but r/w? Thanks Lisa Koivu Ft. Lauderdale, FL, USA -Original Message- From: Rachel Carmichael [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 1:57 PM To: Multiple recipients of list ORACLE-L Subject:Re: Common Oracle RDBMS Misconceptions Jeremiah, Marlene and I did an exploding the myths paper very similar to what you are doing.. always set pctincrease on your temporary tablespace to 1 and my OOW submission is very very similar to yours. Not quite, but really close. It will be interesting to see if they choose one, both or neither of our papers :) Rachel From: Jeremiah Wilton [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: Common Oracle RDBMS Misconceptions Date: Tue, 26 Jun 2001 09:05:27 -0800 All right folks, I'm collecting misconceptions, of the type held by newbies and oldtimers alike. My OOW proposal this year is for a presentation and paper on a whole laundry list of these things, similar to what I wrote for hot backup. I want to share what I have so far and solicit input for your favorites (pet peeves). I most certainly will credit individuals and this list for any ideas I glean. So far my favorite misconceptions are: * Hot backup stops writing to datafiles * All network communication is done through the listener * Always 'switch logfile' after (before, inbetween) hot backups * Media recovery is required if you crash during backup mode * Cold backup once a week (just in case, as a 'baseline') * Export is a good way to back up your database * Shutdown abort is bad, crash recovery time is as long as 'shutdown immediate' * Listener.log/alert.log clearing confusion * ORA-1555 can be solved by setting transaction (use specific rollback seg) * Big batch jobs should use one big RBS * ORA-600 means you have corruption / just call support for ORA-600 * Lots of extents are bad * Databases can't be renamed * Select count (1) is better than count (*). * Listeners have to be started before the instance * NOLOGGING turns off logging for all operations * Oracle Corp. won't support NFS datafiles * checkpoint not complete - misguided solutions * Must reinstantiate standby after failover by recopying * redolog size change requires outage What's *your* pet misconception? -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, novicedba wrote: I visited Jeremiah Wilton's web page http://www.speakeasy.net/~jwilton I was shocked to read Hot backup mode explained If this is true then I may be a victim of a disease called 'Common Oracle RDBMS Misconceptions' . Somebody help me!! (Jim carrey-MASK style) Please help me. If some one has few more articles like this enlighten me -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). _ Get your FREE download of MSN Explorer at http://explorer.msn.com -- Please see the official ORACLE-L
RE: Common Oracle RDBMS Misconceptions - standby db?
Title: RE: Common Oracle RDBMS Misconceptions - standby db? OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed to make complete sense to me. I can see how opening a database read only will work and not invalidate the standby, but r/w? Thanks Lisa Koivu Ft. Lauderdale, FL, USA -Original Message- From: Rachel Carmichael [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 1:57 PM To: Multiple recipients of list ORACLE-L Subject: Re: Common Oracle RDBMS Misconceptions Jeremiah, Marlene and I did an exploding the myths paper very similar to what you are doing.. always set pctincrease on your temporary tablespace to 1 and my OOW submission is very very similar to yours. Not quite, but really close. It will be interesting to see if they choose one, both or neither of our papers :) Rachel From: Jeremiah Wilton [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: Common Oracle RDBMS Misconceptions Date: Tue, 26 Jun 2001 09:05:27 -0800 All right folks, I'm collecting misconceptions, of the type held by newbies and oldtimers alike. My OOW proposal this year is for a presentation and paper on a whole laundry list of these things, similar to what I wrote for hot backup. I want to share what I have so far and solicit input for your favorites (pet peeves). I most certainly will credit individuals and this list for any ideas I glean. So far my favorite misconceptions are: * Hot backup stops writing to datafiles * All network communication is done through the listener * Always 'switch logfile' after (before, inbetween) hot backups * Media recovery is required if you crash during backup mode * Cold backup once a week (just in case, as a 'baseline') * Export is a good way to back up your database * Shutdown abort is bad, crash recovery time is as long as 'shutdown immediate' * Listener.log/alert.log clearing confusion * ORA-1555 can be solved by setting transaction (use specific rollback seg) * Big batch jobs should use one big RBS * ORA-600 means you have corruption / just call support for ORA-600 * Lots of extents are bad * Databases can't be renamed * Select count (1) is better than count (*). * Listeners have to be started before the instance * NOLOGGING turns off logging for all operations * Oracle Corp. won't support NFS datafiles * checkpoint not complete - misguided solutions * Must reinstantiate standby after failover by recopying * redolog size change requires outage What's *your* pet misconception? -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, novicedba wrote: I visited Jeremiah Wilton's web page http://www.speakeasy.net/~jwilton I was shocked to read Hot backup mode explained If this is true then I may be a victim of a disease called 'Common Oracle RDBMS Misconceptions' . Somebody help me!! (Jim carrey-MASK style) Please help me. If some one has few more articles like this enlighten me -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). _ Get your FREE download of MSN Explorer at http://explorer.msn.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Common Oracle RDBMS Misconceptions - standby db?
With graceful standby failover (I demo'd it last year at OOW), you can switch back and forth, back and forth as many times as you want without recopying any database. Basically, when you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile reuse database blah noresetlogs' at this point. Other people don't have to. Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off. The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database. You can go back and forth in this way as many times as you want, and one just picks up the chain of SCNs where the last one left off. You never get a divergence of changes. I have talked to people who found this out, and looked like they were going to cry, thinking of the countless hours they had spent after every standby failover, recopying to the standby to get it rollong forward again. In 9i, they have an automated graceful failover mechanism for standby database. I haven't taken a look at it yet. Probably it is a massive java-based GUI that instantly consumes 512Mb or RAM. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, Koivu, Lisa wrote: OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed to make complete sense to me. I can see how opening a database read only will work and not invalidate the standby, but r/w? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Common Oracle RDBMS Misconceptions - standby db?
But in practice, why would you switch to the standby database, unless the primary database is crashed or worse? You know how it is in a production environment, the database crashes. Even if failover is easy, you always have to instruct users to connect as scott/tiger@backup instead of scott/tiger@prod - or perhaps modify the tnsnames.ora to make it transparent, or perhaps play with IP addresses which may mean trouble for a while with in-memory routing tables etc. My point is that, even if the switch can be quasi-immediate, it is not so easy, so people will naturally try to make the main machine work first, there will be some delay assessing the damage, waiting until 2am to ring the VP in his bed to get the authorization to switch, etc. In real life, half-an-hour or an hour is easily passed before everybody is back at work on the backup machine, busy trying to catch up on the wasted time. Do not forget that since the transmission of redo logs is asynchronous (I have heard about improvements with 9i) some transactions - committed ones - will have been lost, so users will have to check and probably reenter the missing transactions. At this point the main machine will probably be totally out of order. Wait another 2 or 4 hours to have somebody to come if it's a hardware problem, I guess that when everything is over everybody will be on their knees and the last thing they will have in mind is make the old primary database the new standby - assuming of course that all files are intact. And even if the ex-standby machine is possibly less powerful, everybody will probably wait until a quieter time, say the W/E, to switch back to the initial configuration. At which time, in all likelihood, a full database copy will have become necessary; I think that the simple fact of having reentered a couple of transactions not transmitted yet to the standby database would require it. Do I err ? -- Regards, Stephane Faroult Oriole Corporation Voice: +44 (0) 7050-696-269 Fax:+44 (0) 7050-696-449 Performance Tools Free Scripts -- http://www.oriole.com, designed by Oracle DBAs for Oracle DBAs -- Jeremiah Wilton wrote: With graceful standby failover (I demo'd it last year at OOW), you can switch back and forth, back and forth as many times as you want without recopying any database. Basically, when you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile reuse database blah noresetlogs' at this point. Other people don't have to. Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off. The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database. You can go back and forth in this way as many times as you want, and one just picks up the chain of SCNs where the last one left off. You never get a divergence of changes. I have talked to people who found this out, and looked like they were going to cry, thinking of the countless hours they had spent after every standby failover, recopying to the standby to get it rollong forward again. In 9i, they have an automated graceful failover mechanism for standby database. I haven't taken a look at it yet. Probably it is a massive java-based GUI that instantly consumes 512Mb or RAM. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, Koivu, Lisa wrote: OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed to make complete sense to me. I can see how opening a database read only will work and not invalidate the standby, but r/w? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists
RE: Common Oracle RDBMS Misconceptions - standby db?
there is a paper out on Metalink called Graceful Switchover and Switchback by Lawrence To (who is my hero G) that describes this concept. Revised and valid for 7.3, 8.0 and 8.1 Rachel From: Jeremiah Wilton [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: RE: Common Oracle RDBMS Misconceptions - standby db? Date: Tue, 26 Jun 2001 15:21:00 -0800 With graceful standby failover (I demo'd it last year at OOW), you can switch back and forth, back and forth as many times as you want without recopying any database. Basically, when you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile reuse database blah noresetlogs' at this point. Other people don't have to. Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off. The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database. You can go back and forth in this way as many times as you want, and one just picks up the chain of SCNs where the last one left off. You never get a divergence of changes. I have talked to people who found this out, and looked like they were going to cry, thinking of the countless hours they had spent after every standby failover, recopying to the standby to get it rollong forward again. In 9i, they have an automated graceful failover mechanism for standby database. I haven't taken a look at it yet. Probably it is a massive java-based GUI that instantly consumes 512Mb or RAM. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, Koivu, Lisa wrote: OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying' is a misconception. Yes, like many of the things you state below, the documentation does say that - once you open a standby db in r/w mode, it is no longer a valid standby after switching back to the primary. Can someone shed some light on why this is not true? It seemed to make complete sense to me. I can see how opening a database read only will work and not invalidate the standby, but r/w? -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jeremiah Wilton INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). _ Get your FREE download of MSN Explorer at http://explorer.msn.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Common Oracle RDBMS Misconceptions - standby db?
Stephane, Um, how about because hardware maintenance is needed on the primary server? I know I would much rather gracefully schedule a fallover and fallback to do something like that, given the luxury of actually being able to close the database for the few minutes it takes to complete the switch. In the case of a crash, of course all bets are off -- you can't really DO a graceful switchover (well,remote mirroring the online logs maybe) But we all always forget that there are on occasion SCHEDULED downtimes to build procedures for Rachel From: Stephane Faroult [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: Common Oracle RDBMS Misconceptions - standby db? Date: Tue, 26 Jun 2001 16:27:34 -0800 But in practice, why would you switch to the standby database, unless the primary database is crashed or worse? You know how it is in a production environment, the database crashes. Even if failover is easy, you always have to instruct users to connect as scott/tiger@backup instead of scott/tiger@prod - or perhaps modify the tnsnames.ora to make it transparent, or perhaps play with IP addresses which may mean trouble for a while with in-memory routing tables etc. My point is that, even if the switch can be quasi-immediate, it is not so easy, so people will naturally try to make the main machine work first, there will be some delay assessing the damage, waiting until 2am to ring the VP in his bed to get the authorization to switch, etc. In real life, half-an-hour or an hour is easily passed before everybody is back at work on the backup machine, busy trying to catch up on the wasted time. Do not forget that since the transmission of redo logs is asynchronous (I have heard about improvements with 9i) some transactions - committed ones - will have been lost, so users will have to check and probably reenter the missing transactions. At this point the main machine will probably be totally out of order. Wait another 2 or 4 hours to have somebody to come if it's a hardware problem, I guess that when everything is over everybody will be on their knees and the last thing they will have in mind is make the old primary database the new standby - assuming of course that all files are intact. And even if the ex-standby machine is possibly less powerful, everybody will probably wait until a quieter time, say the W/E, to switch back to the initial configuration. At which time, in all likelihood, a full database copy will have become necessary; I think that the simple fact of having reentered a couple of transactions not transmitted yet to the standby database would require it. Do I err ? -- Regards, Stephane Faroult Oriole Corporation Voice: +44 (0) 7050-696-269 Fax:+44 (0) 7050-696-449 Performance Tools Free Scripts -- http://www.oriole.com, designed by Oracle DBAs for Oracle DBAs -- Jeremiah Wilton wrote: With graceful standby failover (I demo'd it last year at OOW), you can switch back and forth, back and forth as many times as you want without recopying any database. Basically, when you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby. People who use incremental checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile reuse database blah noresetlogs' at this point. Other people don't have to. Finally, you recover database to get the last one or two online logs and open the standby noresetogs. The standby just picks up the chain of SCNs where the primary left off. The old primary can be immediately pressed into service as a standby. Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database. You can go back and forth in this way as many times as you want, and one just picks up the chain of SCNs where the last one left off. You never get a divergence of changes. I have talked to people who found this out, and looked like they were going to cry, thinking of the countless hours they had spent after every standby failover, recopying to the standby to get it rollong forward again. In 9i, they have an automated graceful failover mechanism for standby database. I haven't taken a look at it yet. Probably it is a massive java-based GUI that instantly consumes 512Mb or RAM. -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Tue, 26 Jun 2001, Koivu, Lisa wrote: OK. I admit my knowledge on standby is minimal, having only read up on it, fiddled with it and used the idea sparingly for migrations. However, Jeremiah, I'm very curious. You state that 'Must reinstantiate standby after failover by recopying
