[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:	Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:	RDB_60 is archived, please use RDB_70..
Moderator:	NOVA::SMITHISON

Created:	Fri Mar 18 1994
Last Modified:	Fri May 30 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5118
Total number of notes:	28246

5109.0. "fast commit - fixed aijs - switchover" by M5::JHAYTER () Wed Mar 05 1997 14:40

Hi,

Customer has posed an interesting question that now has him and I confused.

With fast commit turned on, circular aijs.  Assume disk with current aij
crashes.  Next available aij is on a different disk.  AIJ switchover is
supposed to take place, but....

Section 9.8.1.4 (V7) in the Guide to Database Maintenance says "...when
journaling switches to another available after-image journal file, a
checkpoint occurs. The checkpoint ensures that all commited transactions
are writtten to disk FROM the after-image journal file before it becomes
unavailable."

That is not my understanding of a checkpoint.  The checkpoint should cause
processes to flush their buffers to the DB, a checkpoint record is written
to the NEW aij (in this case), and all should be well.  The wording
"FROM the after-image journal file before it becomes unavailable." is a bit
misleading or if true - trouble is headed our way in this situation.

So, is the doc wording misleading or is there potential for AIJTERMINATE?

Thanks,
Jerry

T.R	Title	User	Personal Name	Date	Lines
5109.1		NOVA::R_ANDERSON	Oracle Corporation (603) 881-1935	`Thu Mar 06 1997 08:13`	21
	>Section 9.8.1.4 (V7) in the Guide to Database Maintenance says "...when >journaling switches to another available after-image journal file, a >checkpoint occurs. The checkpoint ensures that all commited transactions >are writtten to disk FROM the after-image journal file before it becomes >unavailable." Yeah, that's not really correct. A checkpoint occurs AFTER the AIJ switchover completes, recording the various checkpoint records in the NEW AIJ journal. When all of the processes have checkpointed into the NEW AIJ journal, the previous AIJ journal is "available" (meaning it can be backed up or overwritten, etc). The definition of "available" is "an AIJ journal is not recovered for recovery". Also, (obviously) the checkpoint operation is the act of flushing buffers NOT the AIJ journal :-) Thanks! Rick
5109.2	Offline before switchover	M5::PSOEHL	The area is secured, Ripley!!!	`Thu Mar 06 1997 19:39`	24
	I think Jerry and I are talking to the same customer. But the question that they've posed to me has a few more twists. Documentation says, in Guide to DB maintenance for 6.0, page 9-30 that "loss of the current .AIJ file is handled through the automatic failover mechanism". The way the previous paragraphs are worded, I infer this to include disk failures. Is that true? I recently tried this, by powering down the drive the active aij file is on. Once it discovered the drive was not there, before the 60 minute timeout expired, attaches were terminated with the AIJTERMINATE message. This is what I would have expected, not that the swithover would automatically occur. An attempt to force a switchover, using rmu/set after/switch also got an aij terminate message. It DID let me /disable and then do the drop add and enable thing. But, the switchover did NOT occur. Oh, yeah. Rdb v6.1-02, axp vms 6.2 What say the gurus? Bug in the sw or "misleading" documentation? Also, customer wants to know if in this scenario, if they've commited but they haven�t checkpointed, is there a window where he could lose some transactions? Thanks
5109.3	.-1 reformatted for the 'windows impared	HOTRDB::LASTOVICA	Is it possible to be totally partial?	`Thu Mar 06 1997 19:54`	27
	I think Jerry and I are talking to the same customer. But the question that they've posed to me has a few more twists. Documentation says, in Guide to DB maintenance for 6.0, page 9-30 that "loss of the current .AIJ file is handled through the automatic failover mechanism". The way the previous paragraphs are worded, I infer this to include disk failures. Is that true? I recently tried this, by powering down the drive the active aij file is on. Once it discovered the drive was not there, before the 60 minute timeout expired, attaches were terminated with the AIJTERMINATE message. This is what I would have expected, not that the swithover would automatically occur. An attempt to force a switchover, using rmu/set after/switch also got an aij terminate message. It DID let me /disable and then do the drop add and enable thing. But, the switchover did NOT occur. Oh, yeah. Rdb v6.1-02, axp vms 6.2 What say the gurus? Bug in the sw or "misleading" documentation? Also, customer wants to know if in this scenario, if they've commited but they haven�t checkpointed, is there a window where he could lose some transactions? Thanks
5109.4		NOVA::R_ANDERSON	Oracle Corporation (603) 881-1935	`Fri Mar 07 1997 06:56`	17
	The loss of the "current" AIJ journal (for any reason) causes an immediate fail-over to any other "available" AIJ journal. The 60 minute timeout period is not relevant unless there are no "available" AIJ journals (which seems to be your case). If no other "available" AIJ journals can be located, then the AIJTERMINATE error is issued and the database is immediately shutdown to maintain database integrity. Note that if you are using Rdb7 circular AIJ journals with the ALS server, you can use the "Emergency AIJ" feature to prevent your database from being shutdown (assuming you have 1 or more free AIJ slots). This operation works fine for me. Are you sure you had one or more "available" AIJ journals? Rick
5109.5		M5::PSOEHL	The area is secured, Ripley!!!	`Fri Mar 07 1997 09:26`	8
	The "aij information" screen shows the other journals as accessible prior to the AIJTERMINATE. I didn't capture that screen. I did capture the ones after it. I'll run the test again and show the screens before and after. I'm off today. I work Sunday. I'll run the test Sunday.