Yesterday, we encountered a disk issue on one of our CentOS servers. Some of the disks had either failed, or were predicting failure, so our vendor swooped in, changed some of the disks, as well as the RAID controller. Unfortunately, this worked for only a short time, before we started seeing “input/output error” verbiage in the console. The concern was data loss, so we tried to shutdown, reboot: same “input/output error”.
Sometimes expdp jobs fail for any number of reasons. Re-running the tool, I noticed that the number had increased since the prior run; e.g., SYS_EXPORT_SCHEMA_02 instead of SYS_EXPORT_SCHEMA_01. As it turns out, these are potentially orphaned jobs, so clean ’em up!
Generally, copied from Anar Godjaev’s excellent blog post:
SQL> select owner_name, job_name, operation, job_mode, state, attached_sessions from dba_datapump_jobs; SQL> drop table {owner_name}.SYS_EXPORT_SCHEMA_01; SQL> purge table {owner_name}.SYS_EXPORT_SCHEMA_01;
Work around for this issue is to increase the amount of space allocated to db_recovery_file_dest; e.g.,
$ sqlplus sys as sysdba SQL> show parameter db_recovery_file; db_recovery_file_dest string /opt/oracle/flash_recovery_area db_recovery_file_dest_size big integer 20G Compare this with the output of ‘du -sh’; e.g.,
$ du -sh /opt/oracle/flash_recovery_area 21G /opt/oracle/flash_recovery_area 21 vs 20, so set it to something a bit bigger; e.g.,
SQL> alter system set db_recovery_file_dest_size = 30G; Extracted from this link on Remedian.
Apple Park, it starts with the first event held today at the Steve Jobs Theatre.
Today at Apple, it seems to be huge. I can’t attest to this though, haven’t been at the Orchard Road one.
Apple Watch No. 1 apparently, leapfrogging Rolex. New heart rate metrics (e.g., resting heart rate, recovery rate) in watchOS 4.
Next generation Watch, series 3. Built-in cellular connectivity (eSIM), so you can remain connected whilst away from the phone.