Capture process status waiting for Dictionary Redo: first scn....

Hi
i am facing Issue in Oracle Streams.
below message found in Capture State
waiting for Dictionary Redo: first scn 777777777 (Eg)
Archive_log_dest=USE_DB_RECOVERY_FILE_DEST
i have space related issue....
i restored the archive log to another partition eg. /opt/arc_log
what should i do
1) db start reading archive log from above location
or
2) how to move some archive log to USE_DB_RECOVERY_FILE_DEST from /opt/arc_log so db start processing ...
Regard's

Hi -
Bad news.
As per note 418755.1
A. Confirm checkpoint retention. Periodically, the mining process checkpoints itself for quicker restart. These checkpoints are maintained in the SYSAUX tablespace by default. The capture parameter, checkpoint_retention_time, controls the amount of checkpoint data retained by moving the FIRST_SCN of the capture process forward. The FIRST_SCN is the lowest possible scn available for capturing changes. When the checkpoint_retention_time is exceeded (default = 60 days), the FIRST_SCN is moved and the Streams metadata tables previous to this scn (FIRST_SCN) can be purged and space in the SYSAUX tablespace reclaimed. To alter the checkpoint_retention_time, use the DBMS_CAPTURE_ADM.ALTER_CAPTURE procedure.
Check if the archived redologfile it is requesting is about 60 days old. You need all archived redologs from the requested logfile onwards; if any are missing then you are out of luck. It doesnt matter that there have been mined and captured already; capture still needs these files for a restart. It has always been like this and IMHO is a significant limitation for streams.
If you cannot recover the logfiles, then you will need to rebuild the captiure process and ensure that any gap in data captures has been resynced manually using tags tofix the data.
Rgds
Mark Teehan
Singapore

Similar Messages

Hung on "Waiting for dictionary redo: first scn"

Hi I'm on Oracle 10.2.0.4 with the following Streams setup with databases in brackets: [capture process -> capture queue -> propagation] -> [apply queue -> apply process].
The capture was running but is now stuck on "waiting for dictionary redo: first scn 12345". What caused the capture to initially pause was the target database was brought down for a week which caused the propagation on the source to become disabled after it couldn't connect anymore. I stopped/started the capture and propagation on the source once the target database was brought back online.
All of the archived log files back to the log file containing the dictionary build and specified SCN have been restored to the original archive destination directory on the source database server. I've tried stopping and starting the capture after restoring the archived log files, but it remains in the same status. The first 40 out of roughly 700 archived log files are currently registered in DBA_REGISTERED_ARCHIVED_LOG.
Do all of the archived log files need to be registered before Streams capture will start scanning/capturing again from the beginning? Or if not, what else might be needed to get the capture moving once again?
Thanks for any help.

For what it's worth, I was able to get the capture to start capture changes again.
What I had to do was...
1. stop the existing capture process
2. record the necessary first/captured SCN values for recreating the capture process (queues were empty)
3. drop the existing capture process while preserving the rule set
4. recreate the capture process with the existing rule set and appropriate first & start SCN values
5. manually register all archived logfiles, including the one with the dictionary build/first SCN and up
6. start the new capture process
I still have no idea what the issue was to begin with.

WAITING FOR DICTIONARY REDO: FIRST SCN

Hii All
I have configured streams correctly almost 4 mount ago and there wasnt a problem until today.Last night source database has power down due to ups problem.So Now I am seeing WAITING FOR DICTIONARY REDO: FIRST SCN 83683730 error in V$STREAMS_CAPTURE.The scn is pointing 4 mounts ago and I havent that archive log in my rman backups.
What is your suggestions ?
Best Regards

Hi -
Bad news.
As per note 418755.1
A. Confirm checkpoint retention. Periodically, the mining process checkpoints itself for quicker restart. These checkpoints are maintained in the SYSAUX tablespace by default. The capture parameter, checkpoint_retention_time, controls the amount of checkpoint data retained by moving the FIRST_SCN of the capture process forward. The FIRST_SCN is the lowest possible scn available for capturing changes. When the checkpoint_retention_time is exceeded (default = 60 days), the FIRST_SCN is moved and the Streams metadata tables previous to this scn (FIRST_SCN) can be purged and space in the SYSAUX tablespace reclaimed. To alter the checkpoint_retention_time, use the DBMS_CAPTURE_ADM.ALTER_CAPTURE procedure.
Check if the archived redologfile it is requesting is about 60 days old. You need all archived redologs from the requested logfile onwards; if any are missing then you are out of luck. It doesnt matter that there have been mined and captured already; capture still needs these files for a restart. It has always been like this and IMHO is a significant limitation for streams.
If you cannot recover the logfiles, then you will need to rebuild the captiure process and ensure that any gap in data captures has been resynced manually using tags tofix the data.
Rgds
Mark Teehan
Singapore

Oracle 10g Source DB Capture Process : Waiting for dictionary redo?

Hi to all,
Situation: Source DB waiting for dictionary redo first SCN
First SCN = 314353677
Start SCN = 644568684
current SCN =779444676
Don't now how to trouble shoot
Previous error is Pause for flow control
Now it is prompting dictionary redo first SCN
How to trouble shoot Step by Step
PLeeaasssssssse expertssssss need help

this are all the files present in the archive folder
1_2505_705753337.log 1_4218_705753337.log 1_5932_705753337.log 1_764_705753337.log   1_9360_705753337.log
1_2506_705753337.log 1_4219_705753337.log 1_5933_705753337.log 1_7647_705753337.log 1_9361_705753337.log
1_250_705753337.log   1_4220_705753337.log 1_5934_705753337.log 1_7648_705753337.log 1_9362_705753337.log
1_2507_705753337.log 1_4221_705753337.log 1_5935_705753337.log 1_7649_705753337.log 1_9363_705753337.log
1_2508_705753337.log 1_4222_705753337.log 1_5936_705753337.log 1_7650_705753337.log 1_9364_705753337.log
1_2509_705753337.log 1_4223_705753337.log 1_593_705753337.log   1_7651_705753337.log 1_9365_705753337.log
1_2510_705753337.log 1_4224_705753337.log 1_5937_705753337.log 1_7652_705753337.log 1_9366_705753337.log
1_2511_705753337.log 1_4225_705753337.log 1_5938_705753337.log 1_7653_705753337.log 1_936_705753337.log
1_2512_705753337.log 1_4226_705753337.log 1_5939_705753337.log 1_7654_705753337.log 1_9367_705753337.log
1_2513_705753337.log 1_422_705753337.log   1_5940_705753337.log 1_7655_705753337.log 1_9368_705753337.log
1_2514_705753337.log 1_4227_705753337.log 1_5941_705753337.log 1_7656_705753337.log 1_9369_705753337.log
1_2515_705753337.log 1_4228_705753337.log 1_5942_705753337.log 1_765_705753337.log   1_93_705753337.log
1_2516_705753337.log 1_4229_705753337.log 1_5943_705753337.log 1_7657_705753337.log 1_9370_705753337.log
1_251_705753337.log   1_4230_705753337.log 1_5944_705753337.log 1_7658_705753337.log 1_9371_705753337.log
1_2517_705753337.log 1_4231_705753337.log 1_5945_705753337.log 1_7659_705753337.log 1_9372_705753337.log
1_2518_705753337.log 1_4232_705753337.log 1_5946_705753337.log 1_7660_705753337.log 1_9373_705753337.log
1_2519_705753337.log 1_4233_705753337.log 1_594_705753337.log   1_7661_705753337.log 1_9374_705753337.log
1_2520_705753337.log 1_4234_705753337.log 1_5947_705753337.log 1_7662_705753337.log 1_9375_705753337.log
1_2521_705753337.log 1_4235_705753337.log 1_5948_705753337.log 1_7663_705753337.log 1_9376_705753337.log
1_2522_705753337.log 1_4236_705753337.log 1_5949_705753337.log 1_7664_705753337.log 1_937_705753337.log
1_2523_705753337.log 1_423_705753337.log   1_5950_705753337.log 1_7665_705753337.log 1_9377_705753337.log
1_2524_705753337.log 1_4237_705753337.log 1_5951_705753337.log 1_7666_705753337.log 1_9378_705753337.log
1_2525_705753337.log 1_4238_705753337.log 1_5952_705753337.log 1_766_705753337.log   1_9379_705753337.log
1_2526_705753337.log 1_4239_705753337.log 1_5953_705753337.log 1_7667_705753337.log 1_9380_705753337.log
1_252_705753337.log   1_4240_705753337.log 1_5954_705753337.log 1_7668_705753337.log 1_9381_705753337.log
1_2527_705753337.log 1_4241_705753337.log 1_5955_705753337.log 1_7669_705753337.log 1_9382_705753337.log
1_2528_705753337.log 1_4242_705753337.log 1_5956_705753337.log 1_76_705753337.log    1_9383_705753337.log
1_2529_705753337.log 1_4243_705753337.log 1_595_705753337.log   1_7670_705753337.log 1_9384_705753337.log
1_2530_705753337.log 1_4244_705753337.log 1_5957_705753337.log 1_7671_705753337.log 1_9385_705753337.log
1_2531_705753337.log 1_4245_705753337.log 1_5958_705753337.log 1_7672_705753337.log 1_9386_705753337.log
1_2532_705753337.log 1_4246_705753337.log 1_5959_705753337.log 1_7673_705753337.log 1_938_705753337.log
1_2533_705753337.log 1_424_705753337.log   1_5960_705753337.log 1_7674_705753337.log 1_9387_705753337.log
1_2534_705753337.log 1_4247_705753337.log 1_5961_705753337.log 1_7675_705753337.log 1_9388_705753337.log
1_2535_705753337.log 1_4248_705753337.log 1_5962_705753337.log 1_7676_705753337.log 1_9389_705753337.log
1_2536_705753337.log 1_4249_705753337.log 1_5963_705753337.log 1_767_705753337.log   1_9390_705753337.log
1_253_705753337.log   1_4250_705753337.log 1_5964_705753337.log 1_7677_705753337.log 1_9391_705753337.log
1_2537_705753337.log 1_4251_705753337.log 1_5965_705753337.log 1_7678_705753337.log 1_9392_705753337.log
1_2538_705753337.log 1_4252_705753337.log 1_5966_705753337.log 1_7679_705753337.log 1_9393_705753337.log
1_2539_705753337.log 1_4253_705753337.log 1_596_705753337.log   1_7680_705753337.log 1_9394_705753337.log
1_2540_705753337.log 1_4254_705753337.log 1_5967_705753337.log 1_7681_705753337.log 1_9395_705753337.log
1_2541_705753337.log 1_4255_705753337.log 1_5968_705753337.log 1_7682_705753337.log 1_9396_705753337.log
1_2542_705753337.log 1_4256_705753337.log 1_5969_705753337.log 1_7683_705753337.log 1_939_705753337.log
1_2543_705753337.log 1_425_705753337.log   1_59_705753337.log    1_7684_705753337.log 1_9397_705753337.log
1_2544_705753337.log 1_4257_705753337.log 1_5970_705753337.log 1_7685_705753337.log 1_9398_705753337.log
1_2545_705753337.log 1_4258_705753337.log 1_5971_705753337.log 1_7686_705753337.log 1_9399_705753337.log
1_2546_705753337.log 1_4259_705753337.log 1_5972_705753337.log 1_768_705753337.log   1_9400_705753337.log
1_254_705753337.log   1_4260_705753337.log 1_5973_705753337.log 1_7687_705753337.log 1_9401_705753337.log
1_2547_705753337.log 1_4261_705753337.log 1_5974_705753337.log 1_7688_705753337.log 1_9402_705753337.log
1_2548_705753337.log 1_4262_705753337.log 1_5975_705753337.log 1_7689_705753337.log 1_9403_705753337.log
1_2549_705753337.log 1_4263_705753337.log 1_5976_705753337.log 1_7690_705753337.log 1_9404_705753337.log
1_2550_705753337.log 1_4264_705753337.log 1_597_705753337.log   1_7691_705753337.log 1_9405_705753337.log
1_2551_705753337.log 1_4265_705753337.log 1_5977_705753337.log 1_7692_705753337.log 1_9406_705753337.log
1_2552_705753337.log 1_4266_705753337.log 1_5978_705753337.log 1_7693_705753337.log 1_940_705753337.log
1_2553_705753337.log 1_426_705753337.log   1_5979_705753337.log 1_7694_705753337.log 1_9407_705753337.log
1_2554_705753337.log 1_4267_705753337.log 1_5980_705753337.log 1_7695_705753337.log 1_9408_705753337.log
1_2555_705753337.log 1_4268_705753337.log 1_5981_705753337.log 1_7696_705753337.log 1_9409_705753337.log
1_2556_705753337.log 1_4269_705753337.log 1_5982_705753337.log 1_769_705753337.log   1_9410_705753337.log
1_255_705753337.log   1_42_705753337.log    1_5983_705753337.log 1_7697_705753337.log 1_9411_705753337.log
1_2557_705753337.log 1_4270_705753337.log 1_5984_705753337.log 1_7698_705753337.log 1_9412_705753337.log
1_2558_705753337.log 1_4271_705753337.log 1_5985_705753337.log 1_7699_705753337.log 1_9413_705753337.log
1_2559_705753337.log 1_4272_705753337.log 1_5986_705753337.log 1_7700_705753337.log 1_9414_705753337.log
1_2560_705753337.log 1_4273_705753337.log 1_598_705753337.log   1_7701_705753337.log 1_9415_705753337.log
1_2561_705753337.log 1_4274_705753337.log 1_5987_705753337.log 1_7702_705753337.log 1_9416_705753337.log
1_2562_705753337.log 1_4275_705753337.log 1_5988_705753337.log 1_7703_705753337.log 1_941_705753337.log
1_2563_705753337.log 1_4276_705753337.log 1_5989_705753337.log 1_7704_705753337.log 1_9417_705753337.log
1_2564_705753337.log 1_427_705753337.log   1_5990_705753337.log 1_7705_705753337.log 1_9418_705753337.log
1_2565_705753337.log 1_4277_705753337.log 1_5991_705753337.log 1_7_705753337.log     1_9419_705753337.log
1_2566_705753337.log 1_4278_705753337.log 1_5992_705753337.log 1_7706_705753337.log 1_9420_705753337.log
1_256_705753337.log   1_4279_705753337.log 1_5993_705753337.log 1_770_705753337.log   1_9421_705753337.log
1_2567_705753337.log 1_4280_705753337.log 1_5994_705753337.log 1_7707_705753337.log 1_9422_705753337.log
1_2568_705753337.log 1_4281_705753337.log 1_5995_705753337.log 1_7708_705753337.log 1_9423_705753337.log
1_2569_705753337.log 1_4282_705753337.log 1_5996_705753337.log 1_7709_705753337.log 1_9424_705753337.log
1_25_705753337.log    1_4283_705753337.log 1_599_705753337.log   1_7710_705753337.log 1_9425_705753337.log
1_2570_705753337.log 1_4284_705753337.log 1_5997_705753337.log 1_7711_705753337.log 1_9426_705753337.log
1_2571_705753337.log 1_4285_705753337.log 1_5998_705753337.log 1_7712_705753337.log 1_942_705753337.log
1_2572_705753337.log 1_4286_705753337.log 1_5999_705753337.log 1_7713_705753337.log 1_9427_705753337.log
1_2573_705753337.log 1_428_705753337.log   1_6000_705753337.log 1_7714_705753337.log 1_9428_705753337.log
1_2574_705753337.log 1_4287_705753337.log 1_6001_705753337.log 1_7715_705753337.log 1_9429_705753337.log
1_2575_705753337.log 1_4288_705753337.log 1_6002_705753337.log 1_7716_705753337.log 1_9430_705753337.log
1_2576_705753337.log 1_4289_705753337.log 1_6003_705753337.log 1_771_705753337.log   1_9431_705753337.log
1_257_705753337.log   1_4290_705753337.log 1_6004_705753337.log 1_7717_705753337.log 1_9432_705753337.log
1_2577_705753337.log 1_4291_705753337.log 1_6005_705753337.log 1_7718_705753337.log 1_9433_705753337.log
1_2578_705753337.log 1_4292_705753337.log 1_6006_705753337.log 1_7719_705753337.log 1_9434_705753337.log
1_2579_705753337.log 1_4293_705753337.log 1_600_705753337.log   1_7720_705753337.log 1_9435_705753337.log
1_2580_705753337.log 1_4294_705753337.log 1_6007_705753337.log 1_7721_705753337.log 1_9436_705753337.log
1_2581_705753337.log 1_4295_705753337.log 1_6008_705753337.log 1_7722_705753337.log 1_943_705753337.log
1_2582_705753337.log 1_4296_705753337.log 1_6009_705753337.log 1_7723_705753337.log 1_9437_705753337.log
1_2583_705753337.log 1_429_705753337.log   1_6010_705753337.log 1_7724_705753337.log 1_9438_705753337.log
1_2584_705753337.log 1_4297_705753337.log 1_6011_705753337.log 1_7725_705753337.log 1_9439_705753337.log
1_2585_705753337.log 1_4298_705753337.log 1_6012_705753337.log 1_7726_705753337.log 1_9440_705753337.log
1_2586_705753337.log 1_4299_705753337.log 1_6013_705753337.log 1_772_705753337.log   1_9441_705753337.log
1_258_705753337.log   1_4300_705753337.log 1_6014_705753337.log 1_7727_705753337.log 1_9442_705753337.log
1_2587_705753337.log 1_4301_705753337.log 1_6015_705753337.log 1_7728_705753337.log 1_9443_705753337.log
1_2588_705753337.log 1_4302_705753337.log 1_6016_705753337.log 1_7729_705753337.log 1_9444_705753337.log
1_2589_705753337.log 1_4303_705753337.log 1_601_705753337.log   1_7730_705753337.log 1_9445_705753337.log
1_2590_705753337.log 1_4304_705753337.log 1_6017_705753337.log 1_7731_705753337.log 1_9446_705753337.log
1_2591_705753337.log 1_4305_705753337.log 1_6018_705753337.log 1_7732_705753337.log 1_944_705753337.log
1_2592_705753337.log 1_4306_705753337.log 1_6019_705753337.log 1_7733_705753337.log 1_9447_705753337.log
1_2593_705753337.log 1_430_705753337.log   1_6020_705753337.log 1_7734_705753337.log 1_9448_705753337.log
1_2594_705753337.log 1_4307_705753337.log 1_6021_705753337.log 1_7735_705753337.log 1_9449_705753337.log
1_2595_705753337.log 1_4308_705753337.log 1_6022_705753337.log 1_7736_705753337.log 1_9450_705753337.log
1_2596_705753337.log 1_4309_705753337.log 1_6023_705753337.log 1_773_705753337.log   1_9451_705753337.log
1_259_705753337.log   1_4310_705753337.log 1_6024_705753337.log 1_7737_705753337.log 1_9452_705753337.log
1_2597_705753337.log 1_4311_705753337.log 1_6025_705753337.log 1_7738_705753337.log 1_9453_705753337.log
1_2598_705753337.log 1_4312_705753337.log 1_6026_705753337.log 1_7739_705753337.log 1_9454_705753337.log
1_2599_705753337.log 1_4313_705753337.log 1_602_705753337.log   1_7740_705753337.log 1_9455_705753337.log
1_2600_705753337.log 1_4314_705753337.log 1_6027_705753337.log 1_7741_705753337.log 1_9456_705753337.log
1_2601_705753337.log 1_4315_705753337.log 1_6028_705753337.log 1_7742_705753337.log 1_945_705753337.log
1_2602_705753337.log 1_4316_705753337.log 1_6029_705753337.log 1_7743_705753337.log 1_9457_705753337.log
1_2603_705753337.log 1_431_705753337.log   1_6030_705753337.log 1_7744_705753337.log 1_9458_705753337.log
1_2604_705753337.log 1_4317_705753337.log 1_6031_705753337.log 1_7745_705753337.log 1_9459_705753337.log
1_2605_705753337.log 1_4318_705753337.log 1_6032_705753337.log 1_7746_705753337.log 1_9460_705753337.log
1_2606_705753337.log 1_4319_705753337.log 1_6033_705753337.log 1_774_705753337.log   1_9461_705753337.log
1_260_705753337.log   1_4320_705753337.log 1_6034_705753337.log 1_7747_705753337.log 1_9462_705753337.log
1_2607_705753337.log 1_4321_705753337.log 1_6035_705753337.log 1_7748_705753337.log 1_9463_705753337.log
1_2608_705753337.log 1_4322_705753337.log 1_6036_705753337.log 1_7749_705753337.log 1_9464_705753337.log
1_2609_705753337.log 1_4323_705753337.log 1_603_705753337.log   1_7750_705753337.log 1_9465_705753337.log
1_2610_705753337.log 1_4324_705753337.log 1_6037_705753337.log 1_7751_705753337.log 1_9466_705753337.log
1_2611_705753337.log 1_4325_705753337.log 1_6038_705753337.log 1_7752_705753337.log 1_946_705753337.log
1_2612_705753337.log 1_4326_705753337.log 1_6039_705753337.log 1_7753_705753337.log 1_9467_705753337.log
1_2613_705753337.log 1_432_705753337.log   1_6040_705753337.log 1_7754_705753337.log 1_9468_705753337.log
1_2614_705753337.log 1_4327_705753337.log 1_6041_705753337.log 1_7755_705753337.log 1_9469_705753337.log
1_2615_705753337.log 1_4328_705753337.log 1_6042_705753337.log 1_7756_705753337.log 1_94_705753337.log
1_2616_705753337.log 1_4329_705753337.log 1_6043_705753337.log 1_775_705753337.log   1_9470_705753337.log
1_261_705753337.log   1_4330_705753337.log 1_6044_705753337.log 1_7757_705753337.log 1_9471_705753337.log
1_2617_705753337.log 1_4331_705753337.log 1_6045_705753337.log 1_7758_705753337.log 1_9472_705753337.log
1_2618_705753337.log 1_4332_705753337.log 1_6046_705753337.log 1_7759_705753337.log 1_9473_705753337.log
1_2619_705753337.log 1_4333_705753337.log 1_604_705753337.log   1_7760_705753337.log 1_9474_705753337.log
1_2620_705753337.log 1_4334_705753337.log 1_6047_705753337.log 1_7761_705753337.log 1_9475_705753337.log
1_2621_705753337.log 1_4335_705753337.log 1_6048_705753337.log 1_7762_705753337.log 1_9476_705753337.log
1_2622_705753337.log 1_4336_705753337.log 1_6049_705753337.log 1_7763_705753337.log 1_947_705753337.log
1_2623_705753337.log 1_433_705753337.log   1_6050_705753337.log 1_7764_705753337.log 1_9477_705753337.log
1_2624_705753337.log 1_4337_705753337.log 1_6051_705753337.log 1_7765_705753337.log 1_9478_705753337.log
1_2625_705753337.log 1_4338_705753337.log 1_6052_705753337.log 1_7766_705753337.log 1_9479_705753337.log
1_2626_705753337.log 1_4339_705753337.log 1_6053_705753337.log 1_776_705753337.log   1_9480_705753337.log
1_262_705753337.log   1_4340_705753337.log 1_6054_705753337.log 1_7767_705753337.log 1_9481_705753337.log
1_2627_705753337.log 1_4341_705753337.log 1_6055_705753337.log 1_7768_705753337.log 1_9482_705753337.log
1_2628_705753337.log 1_4342_705753337.log 1_6056_705753337.log 1_7769_705753337.log 1_9483_705753337.log
1_2629_705753337.log 1_4343_705753337.log 1_605_705753337.log   1_77_705753337.log    1_9484_705753337.log
1_2630_705753337.log 1_4344_705753337.log 1_6057_705753337.log 1_7770_705753337.log 1_9485_705753337.log
1_2631_705753337.log 1_4345_705753337.log 1_6058_705753337.log 1_7771_705753337.log 1_9486_705753337.log
1_2632_705753337.log 1_4346_705753337.log 1_6059_705753337.log 1_7772_705753337.log 1_948_705753337.log
1_2633_705753337.log 1_434_705753337.log   1_6060_705753337.log 1_7773_705753337.log 1_9487_705753337.log
1_2634_705753337.log 1_4347_705753337.log 1_6061_705753337.log 1_7774_705753337.log 1_9488_705753337.log
1_2635_705753337.log 1_4348_705753337.log 1_6062_705753337.log 1_7775_705753337.log 1_9489_705753337.log
1_2636_705753337.log 1_4349_705753337.log 1_6063_705753337.log 1_7776_705753337.log 1_9490_705753337.log
1_263_705753337.log   1_4350_705753337.log 1_6064_705753337.log 1_777_705753337.log   1_9491_705753337.log
1_2637_705753337.log 1_4351_705753337.log 1_6065_705753337.log 1_7777_705753337.log 1_9492_705753337.log
1_2638_705753337.log 1_4352_705753337.log 1_6066_705753337.log 1_7778_705753337.log 1_9493_705753337.log
1_2639_705753337.log 1_4353_705753337.log 1_606_705753337.log   1_7779_705753337.log 1_9494_705753337.log
1_2640_705753337.log 1_4354_705753337.log 1_6067_705753337.log 1_7780_705753337.log 1_9495_705753337.log
1_2641_705753337.log 1_4355_705753337.log 1_6068_705753337.log 1_7781_705753337.log 1_9496_705753337.log
1_2642_705753337.log 1_4356_705753337.log 1_6069_705753337.log 1_7782_705753337.log 1_949_705753337.log
1_2643_705753337.log 1_435_705753337.log   1_60_705753337.log    1_7783_705753337.log 1_9497_705753337.log
1_2644_705753337.log 1_4357_705753337.log 1_6070_705753337.log 1_7784_705753337.log 1_9498_705753337.log
1_2645_705753337.log 1_4358_705753337.log 1_6071_705753337.log 1_7785_705753337.log 1_9499_705753337.log
1_2646_705753337.log 1_4359_705753337.log 1_6072_705753337.log 1_7786_705753337.log 1_9500_705753337.log
1_264_705753337.log   1_4360_705753337.log 1_6073_705753337.log 1_778_705753337.log   1_9501_705753337.log
1_2647_705753337.log 1_4361_705753337.log 1_6074_705753337.log 1_7787_705753337.log 1_9502_705753337.log
1_2648_705753337.log 1_4362_705753337.log 1_6075_705753337.log 1_7788_705753337.log 1_9503_705753337.log
1_2649_705753337.log 1_4363_705753337.log 1_6076_705753337.log 1_7789_705753337.log 1_9504_705753337.log
1_2650_705753337.log 1_4364_705753337.log 1_607_705753337.log   1_7790_705753337.log 1_9505_705753337.log
1_2651_705753337.log 1_4365_705753337.log 1_6077_705753337.log 1_7791_705753337.log 1_9506_705753337.log
1_2652_705753337.log 1_4366_705753337.log 1_6078_705753337.log 1_7792_705753337.log 1_950_705753337.log
1_2653_705753337.log 1_436_705753337.log   1_6079_705753337.log 1_7793_705753337.log 1_9507_705753337.log
1_2654_705753337.log 1_4367_705753337.log 1_6080_705753337.log 1_7794_705753337.log 1_9508_705753337.log
1_2655_705753337.log 1_4368_705753337.log 1_6081_705753337.log 1_7795_705753337.log 1_9509_705753337.log
1_2656_705753337.log 1_4369_705753337.log 1_6082_705753337.log 1_7796_705753337.log 1_9510_705753337.log
1_265_705753337.log   1_43_705753337.log    1_6083_705753337.log 1_779_705753337.log   1_9511_705753337.log
1_2657_705753337.log 1_4370_705753337.log 1_6084_705753337.log 1_7797_705753337.log 1_9512_705753337.log
1_2658_705753337.log 1_4371_705753337.log 1_6085_705753337.log 1_7798_705753337.log 1_9513_705753337.log
1_2659_705753337.log 1_4372_705753337.log 1_6086_705753337.log 1_7799_705753337.log 1_9514_705753337.log
1_2660_705753337.log 1_4373_705753337.log 1_608_705753337.log   1_7800_705753337.log 1_9515_705753337.log
1_2661_705753337.log 1_4374_705753337.log 1_6087_705753337.log 1_7801_705753337.log 1_9516_705753337.log
1_2662_705753337.log 1_4375_705753337.log 1_6088_705753337.log 1_7802_705753337.log 1_951_705753337.log
1_2663_705753337.log 1_4376_705753337.log 1_6089_705753337.log 1_7803_705753337.log 1_9517_705753337.log
1_2664_705753337.log 1_437_705753337.log   1_6090_705753337.log 1_7804_705753337.log 1_9518_705753337.log
1_2665_705753337.log 1_4377_705753337.log 1_6091_705753337.log 1_7805_705753337.log 1_952_705753337.log
1_2666_705753337.log 1_4378_705753337.log 1_6092_705753337.log 1_7806_705753337.log 1_953_705753337.log
1_266_705753337.log   1_4379_705753337.log 1_6093_705753337.log 1_780_705753337.log   1_954_705753337.log
1_2667_705753337.log 1_4380_705753337.log 1_6094_705753337.log 1_7807_705753337.log 1_955_705753337.log
1_2668_705753337.log 1_4381_705753337.log 1_6095_705753337.log 1_7808_705753337.log 1_956_705753337.log
1_2669_705753337.log 1_4382_705753337.log 1_6096_705753337.log 1_7809_705753337.log 1_95_705753337.log
1_26_705753337.log    1_4383_705753337.log 1_609_705753337.log   1_7810_705753337.log 1_957_705753337.log
1_2670_705753337.log 1_4384_705753337.log 1_6097_705753337.log 1_7811_705753337.log 1_958_705753337.log
1_2671_705753337.log 1_4385_705753337.log 1_6098_705753337.log 1_7812_705753337.log 1_959_705753337.log
1_2672_705753337.log 1_4386_705753337.log 1_6099_705753337.log 1_7813_705753337.log 1_960_705753337.log
1_2673_705753337.log 1_438_705753337.log   1_6100_705753337.log 1_7814_705753337.log 1_961_705753337.log
1_2674_705753337.log 1_4387_705753337.log 1_6101_705753337.log 1_7815_705753337.log 1_962_705753337.log
1_2675_705753337.log 1_4388_705753337.log 1_6102_705753337.log 1_7816_705753337.log 1_963_705753337.log
1_2676_705753337.log 1_4389_705753337.log 1_6103_705753337.log 1_781_705753337.log   1_964_705753337.log
1_267_705753337.log   1_4390_705753337.log 1_6104_705753337.log 1_7817_705753337.log 1_965_705753337.log
1_2677_705753337.log 1_4391_705753337.log 1_6105_705753337.log 1_7818_705753337.log 1_966_705753337.log
1_2678_705753337.log 1_4392_705753337.log 1_6106_705753337.log 1_7819_705753337.log 1_96_705753337.log
1_2679_705753337.log 1_4393_705753337.log 1_610_705753337.log   1_7820_705753337.log 1_967_705753337.log
1_2680_705753337.log 1_4394_705753337.log 1_6107_705753337.log 1_7821_705753337.log 1_968_705753337.log
1_2681_705753337.log 1_4395_705753337.log 1_6108_705753337.log 1_7822_705753337.log 1_969_705753337.log
1_2682_705753337.log 1_4396_705753337.log 1_6109_705753337.log 1_7823_705753337.log 1_9_705753337.log
1_2683_705753337.log 1_439_705753337.log   1_6110_705753337.log 1_7824_705753337.log 1_970_705753337.log
1_2684_705753337.log 1_4397_705753337.log 1_6111_705753337.log 1_7825_705753337.log 1_971_705753337.log
1_2685_705753337.log 1_4398_705753337.log 1_6112_705753337.log 1_7826_705753337.log 1_972_705753337.log
1_2686_705753337.log 1_4399_705753337.log 1_6113_705753337.log 1_782_705753337.log   1_973_705753337.log
1_268_705753337.log   1_4400_705753337.log 1_6114_705753337.log 1_7827_705753337.log 1_974_705753337.log
1_2687_705753337.log 1_4401_705753337.log 1_6115_705753337.log 1_7828_705753337.log 1_975_705753337.log
1_2688_705753337.log 1_4402_705753337.log 1_6116_705753337.log 1_7829_705753337.log 1_976_705753337.log
1_2689_705753337.log 1_4403_705753337.log 1_611_705753337.log   1_7830_705753337.log 1_97_705753337.log
1_2690_705753337.log 1_4404_705753337.log 1_6117_705753337.log 1_7831_705753337.log 1_977_705753337.log
1_2691_705753337.log 1_4405_705753337.log 1_6118_705753337.log 1_7832_705753337.log 1_978_705753337.log
1_2692_705753337.log 1_4406_705753337.log 1_6119_705753337.log 1_7833_705753337.log 1_979_705753337.log
1_2693_705753337.log 1_440_705753337.log   1_6120_705753337.log 1_7834_705753337.log 1_980_705753337.log
1_2694_705753337.log 1_4407_705753337.log 1_6121_705753337.log 1_7835_705753337.log 1_981_705753337.log
1_2695_705753337.log 1_4408_705753337.log 1_6122_705753337.log 1_7836_705753337.log 1_982_705753337.log
1_2696_705753337.log 1_4409_705753337.log 1_6123_705753337.log 1_783_705753337.log   1_983_705753337.log
1_269_705753337.log   1_4410_705753337.log 1_6124_705753337.log 1_7837_705753337.log 1_984_705753337.log
1_2697_705753337.log 1_4411_705753337.log 1_6125_705753337.log 1_7838_705753337.log 1_985_705753337.log
1_2698_705753337.log 1_4412_705753337.log 1_6126_705753337.log 1_7839_705753337.log 1_986_705753337.log
1_2699_705753337.log 1_4413_705753337.log 1_612_705753337.log   1_7840_705753337.log 1_98_705753337.log
1_2700_705753337.log 1_4414_705753337.log 1_6127_705753337.log 1_7841_705753337.log 1_987_705753337.log
1_2701_705753337.log 1_4415_705753337.log 1_6128_705753337.log 1_7842_705753337.log 1_988_705753337.log
1_2702_705753337.log 1_4416_705753337.log 1_6129_705753337.log 1_7843_705753337.log 1_989_705753337.log
1_2703_705753337.log 1_441_705753337.log   1_6130_705753337.log 1_7844_705753337.log 1_990_705753337.log
1_2704_705753337.log 1_4417_705753337.log 1_6131_705753337.log 1_7845_705753337.log 1_991_705753337.log
1_2705_705753337.log 1_4418_705753337.log 1_6132_705753337.log 1_7846_705753337.log 1_992_705753337.log
1_2_705753337.log     1_4419_705753337.log 1_6133_705753337.log 1_784_705753337.log   1_993_705753337.log
1_2706_705753337.log 1_4420_705753337.log 1_6134_705753337.log 1_7847_705753337.log 1_994_705753337.log
1_270_705753337.log   1_4421_705753337.log 1_6135_705753337.log 1_7848_705753337.log 1_995_705753337.log
1_2707_705753337.log 1_4422_705753337.log 1_6136_705753337.log 1_7849_705753337.log 1_996_705753337.log
1_2708_705753337.log 1_4423_705753337.log 1_613_705753337.log   1_7850_705753337.log 1_99_705753337.log
1_2709_705753337.log 1_4424_705753337.log 1_6137_705753337.log 1_7851_705753337.log 1_997_705753337.log
1_2710_705753337.log 1_4425_705753337.log 1_6138_705753337.log 1_7852_705753337.log 1_998_705753337.log
1_2711_705753337.log 1_4426_705753337.log 1_6139_705753337.log 1_7853_705753337.log 1_999_705753337.log
1_2712_705753337.log 1_442_705753337.log   1_6140_705753337.log 1_7854_705753337.log
1_2713_705753337.log 1_4427_705753337.log 1_6141_705753337.log 1_7855_705753337.logEdited by: user13640691 on Feb 23, 2011 2:35 AM

Capture WAITING FOR DICTIONARY REDO: FILE

Hi Experts,
Based on a large transaction, source A1 database archive action was auto switch for redlog files.
After this event, we destination A2 DB capture get a state---WAITING FOR DICTIONARY REDO: FILE G:\ORACLE\ORADATA\VMSDBSEA\ARCHIVE\ARC10201_0639211808.001.
we use bi-direction stream at oracle10GR4 in 32 bit windoe 2003.
I think that is a capture problem in A2 only. last weekend, stream stop capture process due low SGA.
I restart A2 capture thsi morning.
What do I need to do? just add a new first SCN or register redo file?
Please help me in detail.
I find this case at http://stanford.edu/dept/itss/docs/oracle/10g/server.101/b10727/capture.htm#1006565
1. A capture process is configured to capture changes to tables.
2. A database administrator stops the capture process. When the capture process is stopped, it records the SCN of the change it was currently capturing.
3. User applications continue to make changes to the tables while the capture process is stopped.
4. The capture process is restarted three hours after it was stopped.
However, I do not see how to set new SCN for restart capture.
Thanks,
Jim
Edited by: user589812 on Dec 29, 2008 12:11 PM

i try to register archivelog file and got message as
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 'ARC23250_0621282506.001' FOR 'STREAM_CAPTURE';
ALTER DATABASE REGISTER LOGICAL LOGFILE 'ARC23250_0621282506.001' FOR 'STREAM_CAPTURE'
ERROR at line 1:
ORA-01284: file cannot be opened
So what issue?
Thanks
JIm

Streams capture waiting for dictionary redo log

Hi ,
The stream capture is waiting for the dictionary redo log
as per the alert logs ,the logminer is able to register the logfile
RFS LogMiner: Registered logfile [TEMP_114383_1_628824420.arc] to LogMiner session id [142]
Fri Feb 13 00:00:39 2009
Capture Session Redo Total
Capture Process Session Serial Entries LCRs
Name Number ID Number State Scanned Enqueued
C_REF C001 675 2707 WAITING FOR DICTIONARY REDO 0 0
Capture Capture Capture
Process Process Positive Negative Process
Name Queue Rule Set Rule Set Status
C_REF CA_REF RULESET$_80 ENABLED
Capture Capture
Capture Process Process
Name Queue START_SCN Status STATUS_CHAN CAPTURED_SCN APPLIED_SCN USE FIRST_SCN
C_REF CA_REF 8586133398117 ENABLED 12-Feb-2009 8586133398117 8586133398117 YES 8586133398117
CONSUMER_NAM SEQUENCE# FIRST_SCN NEXT_SCN TO_DATE(FIR TO_DATE(NEX NAME
C_REF 114378 8586133399062 8586162685837 12-Feb-2009 12-Feb-2009 /TEMP_114378_1_628824420.arc
C_REF 114379 8586162685837 8586163112496 12-Feb-2009 12-Feb-2009 /TEMP_114379_1_628824420.arc
C_REF 114380 8586163112496 8586163984886 12-Feb-2009 12-Feb-2009 /TEMP_114380_1_628824420.arc
C_REF 114381 8586163984886 8586163986301 12-Feb-2009 12-Feb-2009 /TEMP_114381_1_628824420.arc
C_REF 114382 8586163986301 8586163987651 12-Feb-2009 12-Feb-2009 /TEMP_114382_1_628824420.arc
C_REF 114383 8586163987651 8586163989497 12-Feb-2009 13-Feb-2009 /TEMP_114383_1_628824420.arc
C_REF 114384 8586163989497 8586163989674 13-Feb-2009 13-Feb-2009 /TEMP_114384_1_628824420.arc
Capture Time of
Name LogMiner ID Last Redo SCN Last Redo SCN
C_REF 142 8586166339742 00:10:13 02/13/09
i am not still able to make out even after the archivelogs are registered they are not done logmining by logminer.
Can you please help ,i am stuck up this situation.i have rebuild streams by completely removing the stream configuration and also dropped and recreated the strmadmin.

Perhaps I missed it in your post but I didn't see a version number or any information as to what form of Streams was implemented or how.
There are step-by-step instructions for debugging Streams applications at metalink. I would suggest you find the directions for your version and follow them.

Ndless waiting on 'Waiting for Dictionary Redo'

Hi All,
Thanks for all your help and sharing knowledge.
We have bi-directional replication using streams and now we have moved one database to another server.Everything else remains the same.
Capture Process is endllessly waiting for dictionary Redo file :....
We also have copied all archive files and registered.Please help.
Thanks
Kind Regards
Rahul

What is the GLOBAL_NAME and the database link name?. Do they match?. If not, follow any one of the steps below.
1. Change to the GLOBAL_NAME on the source database to map with the database link created on the downstream database.
Or
2. Create a database link at the downstream database with the same name as the GLOBAL_NAME of the source database.

CDC..waiting for dictionary redo

sry may be this question has been asked before. but I still find my stream doesnt work properly...
I try to implement Online autolog CDC where souce DB and staging DB on different computer. but when I run this SQL
select capture_name, state, total_messages_captured
from v$streams_capture
where capture_name like '%EMP_DEPT%'
CAPTURE_NAME
STATE TOTAL_MESSAGES_CAPTURED
CDC$C_EMP_DEPT_SET
WAITING FOR DICTIONARY REDO 0
I've tried some solution as suggested in http://www.business-intelligence-quotient.com/?p=14 but it still doesnt work
1st : drop my change source,I get first_scn from my source DB and try to remake change source in staging DB
2nd : make sure that I just make 1 change source for my source DB.
3rd : I run this SQL
exec procedure dbms_capture_adm.prepare_table_instantiation.
in my staging DB..but when I run it to source DB theres some error appear
4th : I run this SQL
SELECT consumer_name, name
FROM DBA_REGISTERED_ARCHIVED_LOG
WHERE dictionary_begin = 'YES'
no rows selected
in my opinion, DBA_REGISTERED_ARCHIVED_LOG should be filled automatically..any suggest?thax before.sorry for my bad english
Edited by: user12605749 on Feb 13, 2010 12:03 AM

Hi -
1. is you streams config global_names compliant, at source and destination?
2. Have you configured the log_archive_config parameter at source and destination?
3. If these are correct, are the logfiles shipping to the correct location on the destination server?
4. If so, can you manually register a logfile using ALTER DATABASE REGISTER LOGICAL LOGFILE '<complete file name>' FOR '<capture name>' ?
HTH
Mark Teehan
Singapore

WAITING FOR DICTIONARY REDO

Hi Experts,
My capture abort with memory issue. After fixed issue, I restart capture and get state as
WAITING FOR DICTIONARY REDO: FILE G:\ORACLE\ORADATA\SALE\ARCHIVE\ARC23250_0621282506.001
I can see ARC23250_0621282506.001 in file system.
I use oracle 10G( 10.0.2.04 ) in 32 bit window 2003 server. this is one way stream.
How to fix this problem?
Thanks
Jim
Edited by: user589812 on Jun 17, 2009 3:28 PM

i try to register archivelog file and got message as
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 'ARC23250_0621282506.001' FOR 'STREAM_CAPTURE';
ALTER DATABASE REGISTER LOGICAL LOGFILE 'ARC23250_0621282506.001' FOR 'STREAM_CAPTURE'
ERROR at line 1:
ORA-01284: file cannot be opened
So what issue?
Thanks
JIm

WAITING FOR DICTIONARY REDO: FILE

Hi all ,
I am getting WAITING FOR DICTIONARY REDO: FILE NAME state
SELECT STATE FROM V$STREAMS_CAPTURE ;
I tried to resolve it and found that some redo log file is missing.
Can anybody please let me know what could be the cause of missing redo log file?
If the cause for this is that some redo log file is not registered then how would i register it ?
I already have queried the DBA_REGISTERED_ARCHIVED_LOG and DBA_CAPTURE data dictionary views and i am getting some rows.
Thanks to all.
Regards
Nick

Hello Nick,
What you would need to check is find out if there is any archived log sequence missing in DBA_REGISTERED_ARCHIVED_LOG. If you find any archived log sequence is missing then you can register against the capture logminer session using:
CONNECT / AS SYSDBA
ALTER DATABASE REGISTER LOGICAL LOGFILE '<complete file name>' FOR '<capture name>';
Thanks,
Rijesh

Logical Standby: WAITING FOR DICTIONARY LOGS status.

Hi,
I have just configured a Logical Standby from Physical Standby, I followed all steps explained in section 4.2.1 from the Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) documentation, but now my logical standby stay on WAITING FOR DICTIONARY LOGS more than 3 days, all archives from primary DB have been replicated and registered, I don't understand whats
wrong.
SQL> SELECT * FROM V$LOGSTDBY_STATE;
PRIMARY_DBID SESSION_ID
REALTIME_APPLY
STATE
144528764 1
Y
WAITING FOR DICTIONARY LOGS
Fri Apr 8 18:05:47 2011
RFS LogMiner: Registered logfile [/archive/dbp/581440892_1_0000157573.arc] to LogMiner session id [1]
Fri Apr 8 18:10:55 2011
RFS LogMiner: Client enabled and ready for notification
Fri Apr 8 18:10:55 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 4: '/redo2a/dbp/redo4a_stb.log'
Fri Apr 8 18:10:58 2011
RFS LogMiner: Registered logfile [/archive/dbp/581440892_1_0000157574.arc] to LogMiner session id [1]
Fri Apr 8 18:15:54 2011
RFS LogMiner: Client enabled and ready for notification
Fri Apr 8 18:15:54 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 3: '/redo1a/dbp/redo3a_stb.log'
Fri Apr 8 18:15:57 2011
RFS LogMiner: Registered logfile [/archive/dbp/581440892_1_0000157575.arc] to LogMiner session id [1]Thanks in advance.
My Oracle version is: 10.2.0.4
My Platform is: AIX 6.1
Nataly.

On standby alert no error messages found.
RFS LogMiner: Client enabled and ready for notification
Mon Apr 11 18:09:58 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 4: '/redo2a/mefsf/redo4a_stb.log'
Mon Apr 11 18:10:01 2011
RFS LogMiner: Registered logfile [/archive/mefsf/581440892_1_0000157782.arc] to LogMiner session id [1]
Mon Apr 11 18:23:16 2011
RFS LogMiner: Client enabled and ready for notification
Mon Apr 11 18:23:16 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 3: '/redo1a/mefsf/redo3a_stb.log'
Mon Apr 11 18:23:18 2011
RFS LogMiner: Registered logfile [/archive/mefsf/581440892_1_0000157783.arc] to LogMiner session id [1]Continues
On primary alertlog,
There is a common message:
ORACLE Instance bdprod - Archival Error. Archiver continuing.
Mon Apr 11 18:22:57 2011
Errors in file /oracle/app/oracle/admin/bdprod/bdump/bdprod_arc4_2818414.trc:
ORA-00308: cannot open archived log '/archive/bdprod/581440892_1_0000157545.arc'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
Mon Apr 11 18:22:57 2011
FAL[server, ARC4]: FAL archive failed, see trace file.
Mon Apr 11 18:22:57 2011
Errors in file /oracle/app/oracle/admin/bdprod/bdump/bdprod_arc4_2818414.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Mon Apr 11 18:22:57 2011
ORACLE Instance bdprod - Archival Error. Archiver continuing.
Mon Apr 11 18:22:57 2011
Errors in file /oracle/app/oracle/admin/bdprod/bdump/bdprod_arc1_7078038.trc:
ORA-00308: cannot open archived log '/archive/bdprod/581440892_1_0000157546.arc'
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
Mon Apr 11 18:22:57 2011
FAL[server, ARC1]: FAL archive failed, see trace file.
Mon Apr 11 18:22:57 2011
Errors in file /oracle/app/oracle/admin/bdprod/bdump/bdprod_arc1_7078038.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Mon Apr 11 18:22:57 2011
ORACLE Instance bdprod - Archival Error. Archiver continuing.

LNS wait for LGWR redo

Hi,
quick question:
The LNS wait for LGWR redo is the first event in my top 5 events and i would love to solve this issues and reduce the time
LNS wait for LGWR redo 5,631,165 39,623 7 27.3
DB is 10.1.0.5
OS: Linux X86-64
DataGaurd DB.
setting the log_archive_dest_s is SERVICE=DB_NAME LGWR ASYNC=20480 NOAFFIRM REOPEN=30
i am thinking to increase from 20480 to double or should i add more redo log file.
what do you think the best solution.
Thanks

Hi,
You are assuming that this wait event is problematic, which is not necessarily true.
Explanation: The particular wait event is normal when you are using LGWR ASYNC. If you are using this transport, the ASYNC LNS process waits in a loop (relinquishes the CPU in the loop) waiting for more redo from the LGWR. If your system is idle, the LGWR is not producing any redo. In this case, the ASYNC LNS process is bascially idle - the time seen in this event
is essentially an indication of that.
Every sleep we have to add to relinquish the CPU had to be accounted for in a wait event, and there was no way to get around this other than by creating a new waitevent. There was a time when we could specify 0 for the wait event class (meaning don't care), but that class was not available in 10.1 onwards.
The new async model in 10.2 has addressed this issue and will not show under top wait events.
So , There is no action is required and it is normal as it is an indication of ASYNC LNS process being idle. This does not cause any impact on the database.
As you state you are on 10.1.0.5 and therefore encountering this behaviour, and as per above, no action is required.
HTH.

Top Event: LNS wait for LGWR redo

CONFIGURATION: 10.1.0.5.0 with DataGuard On RedHat.
We often find the wait event called "LNS wait for LGWR redo" into the "Top 5 Timed Events" section of the AWR report.
I'm unable to find a complete descrition of this event.
Can I minimize this kind of wait?

I cannot find the exact wait name into the note.
The most similar is:
"LNS wait on LGWR"
     This wait event monitors the amount of time spent by the network server
     waiting to receive messages on KSR channels from the log writer (LGWR)
     process.
Am I right?

Logical standby stuck waiting for dictionary logs

Hello,
I created a logical standby (v. 10.2.0.3). It is in state 'WAITING FOR DICTIONARY LOGS', for a few days now.
Does anyone know how to get past this? It looks like the log that contained the Logminer Dictionary was applied
already.
Thanks in advance for any insight you can provide.

Make sure the archivelogs are reaching the standby. Check your alert logs on both databases to confirm there is no archival problem.

EPMA 11.1.2 Essbase Hangs at status waiting for Update

I know that in 11.1.1.3 there were issues deploying an essbase cube from EPMA, 11.1.2 however claims to be able to do this, but I am having a problem getting the cube deployed.
I am on 64-Bit Windows 2008, all hyperion products are version 11.1.2 with SQL backend.
I can validate a simple cube just fine from EPMA.
I can create cubes in EAS.
I however cannot deploy a simple cube from EPMA. I have checked all conditions on permissions and followed the guidelines.
The essbase application is registering to Shared Services (thus I can make sure the permissions are Provisioned).
The system gets stuck at "Waiting for Status Update..." it will remain at that level (50%) without ever updating. I have changed the awproperties file to time out after 45 minutes. I am not seeing any errors recorded in any of the logs to indicate what problem is going on.
I need some suggestions as to where to look to force some form of error logs that will give me some clue to the next errors I need to deal with. Or some advice from anyone that has experienced this issue. This is an essbase cube not a planning application. I have EPMA HFM Applications, as well as FCM, FDM deployed on the same foundation without issue.
The only issue I can find close to this is a Planning deploy with problems about JVM size but nothing about Essbase application JVMs.
Any ideas?

Is this an essbase only application? It seems like the property is defaulting to stored and then flipping the initial stored member to shared because Essbase isn't interpreting the deployment correctly. I would try using ShareData as the datastorage property (I think that is the correct spelling). Also, I believe the correct way to set IsPrimary is Y/N and not 0/1.
If that did not work I would try the following in this order:
1 - I would first extract the dimension in question using the file generator and confirm that the properties are indeed correct.
2 - If they were correct. I would toggle the dimension from shared->local->shared. EPMA is still a little nutty and this will fix a fair amount of issues as it will 'refresh' the application's version of the dimension. I would then deploy
3 - deploy from EPMA->Planning only (no essbase creation), then deploy to essbase separately after ensuring the property represents itself in planning. If it is essbase only - create the outlnie instead of refresh.
4 - create a duplicate app in EPMA and deploy the copy of the app - and see if it has the same problem
Try that and see how it goes.

Capture process status waiting for Dictionary Redo: first scn....

Similar Messages

Maybe you are looking for