Many thanks to a German customer for showing me this tiny behavior change with Oracle Database RU 19.4.0. From this RU on the well known ORA-1555 won’t get reported into alert.log anymore since 19.4.0. But if you still like to see the “snapshot too old” error, then you can use a workaround.
Photo by Dariusz Sankowski on Unsplash
Why has this been changed?
Actually this is something I don’t understand completely. It may be just a side effect. Unpublished fix bug 29424999 – DUMP MINIMAL DIAGNOSTICS BY DEFAULT IN CASE OF ORA-01555 IN ADW/ATP ENV has been included into 19.4.0 to dump diagnostic information (I guess, into traces). But the bug doesn’t give an indication that the ORA-1555 disappears from the alert.log as well.
Where is this described?
Instead in this case, MOS Note: 2656624.1 – ORA-01555 is Not Reported in Alert Log Since RU 19.4.0.0.0 gives you way more information. For instance, the (customer confirmed) behavior that an ORA-1555 does not show up in the alert.log anymore.
The customer questioned here why we introduce such a behavior change in an RU.
What is different since 19.4.0?
If you get an ORA-1555, you won’t find it in the alert.log anymore but rather get a trace file. If you’d like to revert to the “old” behavior, you need to set ONLY ONE of the following events:
- a)
alter system set event='10442 trace name context forever, level 10' COMMENT=' Bug 29424999 - Bring back ORA-1555 to my alert.log - 2020_09_10' scope=spfile sid='*';
- b)
alter system set event='55521 trace name context forever, level 1' COMMENT=' Bug 29424999 - Bring back ORA-1555 to my alert.log - 2020_09_10' scope=spfile sid='*' ;
Then the behavior will be as it was before 19.4.0.
And remember to set underscores and events always with a comment as otherwise you potentially won’t remember (or your colleagues may not understand) why and when it has been added. This makes it much easier to maintain such special settings.
When is the fix included? [Nov 19. 2020]
With RU 19.9.0 (October 2020) and RURs 19.8.1 and 19.7.2 a fix for Bug 31888148 got included. This bug got filed to report the ORA-1555 to the alert.log again as before.
See also: MOS Note: 2523220.1 – Database 19 Release Updates and Revisions Bugs Fixed Lists and search for “31888148”:
More Information and Links
- MOS Note: 2656624.1 – ORA-01555 is Not Reported in Alert Log Since RU 19.4.0.0.0
- Unpublished bug 29424999 – DUMP MINIMAL DIAGNOSTICS BY DEFAULT IN CASE OF ORA-01555 IN ADW/ATP ENV
- Unpublished bug 31888148 – ORA-01555 IS NOT REPORTED IN ALERT LOG AFTER RU 19.4.0.0.0
–Mike
So is there any difference between the two events?
Should one be used over the other in different situations?
There is not much information on the 55521 event whilst 10442 has been around a long time but has mentions that “There have been issues with 10g and 11g on RAC using 10442. ” for those still running any of those versions
Both lead to the same result – and both are internal and not documented further I guess.
Cheers,
Mike
Hello Mike,
I tried this new feature. I have generated an error ORA-1555, and effectively there is nothing into alert.log file. But I have none trace generated to explain this error ORA-1555 !
Is there something else todo to get this trace ? The Mos note said a trace file is generated, but it is not the case. I do this test a 19.5 DB.
Thank’s a lot.
Pierre
Hi Pierre,
thanks for confirming. And the bug is very unspecific what EXACTLY gets generated.
But we are following up on this.
Thanks,
Mike
I have this wild conspiracy theory, that development did something very bad with ORAUNDO in 19.4 . Something like 113474.1, but worse, much worse. So they deactivated alert log message to hide this from DBAs.
When users come to administrators, they hear only “Which errors? There are no errors!”. This makes crazy both users and DBAs …
And now finally development fixed it, so they return alert log messages in 19.9
How do they say? “Open your eyes, do your own reseach!” 🙂
Hi Luca,
I doubt that this is conspiracy – it has to do with the Autonomous database deployments where you don’t have access to the alert.log. The person who implemented this “fix” did not realize that this may have a negative impact for on-prem customers. But hopefully we will get this fixed.
Cheers,
Mike
Yes, I know – it was just a joke about conspiracy.
And they fixed it already (patch 31888148) and included it into standard 19.9, don’t they?
Yes, you are correct – it is in 19.9.0, 19.8.1 and 19.7.2
I will update the blog post 🙂
Cheers,
Mike