Category: Oracle
-
How to Patch Grid Using Fleet Patching
The content discusses grid patching using fleet maintenance for database servers. It outlines the process of creating a gold image for fleet patching, setting up fleet environment checks, creating a location on Software Library in EMCC, and deploying the gold image to the target cluster. The post also provides tips and advice for a smooth patching process.
-
Oracle 19c RAC Database Out of Place Patching
The content describes the process of patching database servers using out of place patching. It includes the setup list, preparation phase, and the steps involved in deploying and switching to the new software. The post emphasizes the importance of updating scripts and configuration files for the new database home.
-
Oracle 19c Grid Release Update – Out Of Place Patching
The content outlines the process of patching database servers grid infrastructure from 19.16 to 19.20 using fleet patching and out-of-place (OOP) patching methodology. It includes setup details, preparation phase, deployment instructions, and final steps. The next step is mentioned as “Step 2 – Patch My Breath Away (DB OOP Patching)”.
-
Resolving Orphan Records and DRG-10507 in Oracle
During routine checks on SYSAUX tablespace, a 2GB CTXSYS.DR$PENDING table with 15 million records was found, despite daily context index sync jobs. Investigation revealed an orphan context index record, causing a DRG-10507 error. Upon identifying and clearing the orphan records from ctxsys tables, the issue was resolved.
-
Finding failed sql queries with 10035 event tracing and database triggers in Oracle
Cursordump is essential for detecting failed SQL parses in Oracle, as these failures are not stored in the data dictionary. Starting from Oracle 10g, event 10035 reports failed parses. With the 19.16 Release Update, SQL statements failing at parsing are logged with error numbers and OSPIDs but not in the alert.log. Using tools like the x$kglob table can help, but long statements may be undetectable. Implementing triggers for error logging can capture failures, but caution is needed to handle sensitive data and manage log sizes effectively.
-
Why queries to the DBA_MVIEWS view are slow and Insights on SMON_SCN_TIME
The execution time for the “Select * from dba_mviews” query in a specific database is 45 seconds, which is unacceptable and requires improvement. The complexity of the dba_mviews view, particularly the inclusion of specific columns and full table scans of internal tables like SYS.SUMDELTA$ and SYS.SMON_SCN_TIME, contributes to this delay. Solutions suggested include excluding certain columns, creating a new view, or even indexing. Ultimately, optimizing refresh periods and managing data efficiently significantly reduced execution time, demonstrating the importance of these adjustments for performance enhancement.
Osman’s DBlog 