Found out a scheduled export- and import job was broken. Error: ORA-31626: job does not exist. After checking the scheduled jobs I realized that it’s not the scheduled job, but the datapump-job. And it’s all related to being cost-effective in the cloud….
Remember the old days. You had just a few processes to watch. Something has changed along the way. A lot of processes should be running on your database system (with infrastructure), but how are they connected to eachother and what is the startup sequence ? Or.. what processes I can kill without any other proces starting it up… 🙂
Since 184.108.40.206 there’s a new parameter, “_datafile_write_errors_crash_instance” to prevent the intance to crash when a write error on a datafile occurs . But.. should I use this or not. The official text of this parameter:
This fix introduces a notable change in behaviour in that
from 220.127.116.11 onwards an I/O write error to a datafile will
now crash the instance.
Before this fix I/O errors to datafiles not in the system tablespace
offline the respective datafiles when the database is in archivelog mode.
This behavior is not always desirable. Some customers would prefer
that the instance crash due to a datafile write error.
As the documentation about restoring an OCR did not work as it should be, the following has been succesfully tested…
Log on as “root”
# . oraenv +ASM1
# ./ocrconfig -showbackup
# ./ocrconfig -showbackup manual
Stop the cluster on all nodes
# crsctl stop crs
In a datawarehouse environment (18.104.22.168 on RedHat) with compressed tablespaces, tried to drop some columns in the following way:
alter table DWH.TEST_TABLE set unused column COLUMN_SIX;
alter table DWH.TEST_TABLE drop unused columns;
This took a very long time, let it run for 24 hours (!), noticed that the undo-tablespace (80GB…) completely was filled up. Then I killed the command. No penalty, everything was back to normal.
So my intention was to use the addition ‘checkpoint 100000’ , and came across a very old but good explanation at Tom’s site here.