As we have seen in previous posts, the whole instance crashes at checkpoint, even when a PDB only datafile is missing. Okay, we have to think about that behaviour change (and that’s for a future blog post) but usually the application is down when a datafile is missing, so better to stop everything.īut the problem is in multitenant. If “_datafile_write_errors_crash_instance” is set to true, the instance crashes only when the datafiles is a system one. By default, since 11.2.0.2, and without changing the “_datafile_write_errors_crash_instance” default value, the instance crashes as soon as a file is missing at checkpoint. On a non-CDB – or on the CDB$ROOT of a CDB – it’s simple. But if the file is not there we can’t checkpoint it. This is fine when we can write into the datafiles in order to checkpoint them. Look at the file fuzziness: SQL> select file#,con_id,fuzzy from v$datafile_header FILE# CON_ID FUZĮxcept for the UNDO which is in CDB$ROOT, none of my PDB files are fuzzy. even if it’s called ‘close abort’ a checkpoint occured. Let’s see from alert.log what it did: 06:59:51.487000 +01:00ĪLTER SYSTEM: Flushing buffer cache inst=0 container=3 localĬompleted: ALTER PLUGGABLE DATABASE CLOSE ABORT This is why we have online redo logs so that an instance recovery can be used to recover those changes.īut if I shutdown abort only a PDB the instance is still there.
And shutdown abort crashes the instance – loosing all changes made in buffer cache and not yet checkpointed. The shutdown abort we know in non-CDB – or in a CDB from CDB$ROOT – is used when the instance cannot checkpoint before closing the file. Can we shutdown abort a PDB? Let’s try: SQL> show con_id
0 kommentar(er)
