Oracle out of place patching reduces database downtime

To minimize downtime during patching of NON-RAC databases Out of Place Patching can be used. You can apply this approach to any Oracle patch starting from Oracle database 11g (11.2.0.2.0+) using OPatch utility. In this case time spent installing the software can be saved from the total database downtime required. However, some downtime is required for switching database services to the new Oracle database home and applying a post-upgrade script. A basic overview of the steps is below:

– Clone the existing database home online
– Apply required patch to the cloned database home using OPatch
– Switch the database services to the cloned database home
– Complete the post installation tasks for the patch applied

Notes:
– Oracle database 11g and 12c documentation describe DB_HOME cloning only in OFFLINE mode (when DB is down)
http://docs.oracle.com/cd/E11882_01/em.112/e12255/oui6_cloning.htm#OUICG298
http://docs.oracle.com/database/121/LADBI/app_cloning.htm#LADBI7853

– However, there should be no requirement to shutdown any databases, listeners, agents etc. that are running from the source home while cloning the Oracle Home directory because any processes that load the static binaries or libraries into memory should not hold a write lock.

– Oracle Out of Place patching is supported by SAP

– Out of Place patching is a recommended patching method that is used in out of the box deployment procedure of Oracle Enterprise Manager (OEM) Cloud Control 12c+ version

Oracle 12c database Out of Place patching reduce downtime

Oracle database Out of Place patching

Below we will use a combination of Oracle documentation, a few MOS Notes and a little bit of experience to manually conduct Out of Place patching of Oracle database 12c
Read more »

Oracle database client silent installation without response file

I’m often asked questions on Oracle database or client software installation in Silent Mode with using response file. I used to do it in the past but not anymore. The silent software installation with Oracle response file is still available but I found another handy option in Oracle 11g/12c of doing the same. The same silent installation can be done directly from the command prompt without using an Oracle response file but it requires a minimum set of variables (from the response file) as arguments to the Oracle Universal Installer (OUI) (i.e “runInstaller or setup.exe”).

I give a few tested examples below to install Oracle software in Silent mode without a response file:

Oracle Database 11.2 on Linux silent installation (Enterprise Edition Software Only)

cd /opt/oracle/stage/database
./runInstaller -silent -debug -force \ Read more »

Oracle database housekeeping methods – ADR files purge

Since Oracle Database 11g, all traces, incident dumps and packages, the alert log, Health Monitor reports, core dumps, and more files are stored in the ADR, a file-based Automatic Diagnostic Repository for simplified database diagnostic data management. In spite of that new 11g feature, the housekeeping or purging of those files got not considerably simplified. Unfortunately the new Oracle utility ADRCI can not purge all the files that Oracle database generates in ADR. Thus, you should use the other Unix OS methods and tools to accomplish Oracle 11g database housekeeping. In previous posts I described the Unix log rotation mechanism and SYS auditing files purge in adump directory. This time we will talk exactly about ADR purge functionality. But before, let’s look at some basics.

Location for Diagnostic Traces

Location of Diagnostic Traces of Oracle ADR

Location of Diagnostic Traces in Oracle 11g ADR

The table shown above in the slide describes the different classes of trace data and dumps that reside both in Oracle Database 10g and 11g.
With Oracle Database 11g, there is no distinction between foreground and background trace files. Both types of files go into the $ADR_HOME/trace directory.
All non-incident traces are stored inside the trace subdirectory. This is the main difference compared with previous releases where critical error information is dumped into the corresponding process trace files instead of incident dumps. Incident dumps are placed in files separated from the normal process trace files starting with Oracle Database 11g. We can also check V$DIAG_INFO view lists all important ADR locations including.

ADR retention policy – automatic purge

A retention policy allows you to specify how long to keep the diagnostic data. ADR incidents are controlled by two different policies:

LONGP_POLICY:
The incident metadata retention policy controls how long the metadata is kept around. This policy has a default setting of one year (default is 8760 = 365 days = 1 year). Here are the components that currently get purged by LONGP_POLICY:

ALERT — files in the ./alert directory
INCIDENT – files in the ./incident/incdir_ directory.
SWEEP — files in the ./sweep directory
STAGE — files in the ./stage directory
HM — files in the ./hm directory and metadata in the HM schema

SHORTP_POLICY
The incident files and dumps retention policy controls how long generated dump files are kept around. This policy has Read more »

Oracle database housekeeping methods – adump purge

Since Oracle Database 11g, all traces, incident dumps and packages, the alert log, Health Monitor reports, core dumps, and more files are stored in the ADR, a file-based Automatic Diagnostic Repository for simplified database diagnostic data management. In spite of that new 11g feature, the housekeeping or purging of those files got not considerably simplified. Unfortunately the new Oracle utility ADRCI can not purge all the files that Oracle database generates in ADR. Thus, you should use the other Unix OS methods and tools to accomplish Oracle 11g database housekeeping. I’ve already described the Unix log rotation mechanism. This time we will talk about Oracle System Audit files and how to purge them regularly.

SYS, SYSDBA or SYSOPER connections to the Oracle database are always audited. Sometimes this can lead to the creation of an excessive number of audit files. When this is considered to be a problem it cannot be solved at the database side and it must be investigated why the ‘client’ applications including Oracle Enterprise Manager (OEM) Components and agents are connecting so frequently as SYSDBA/SYSOPER. So this type of auditing mandatory in the Oracle database and can NOT be turned off. However the amount of audited information depends on AUDIT_SYS_OPERATIONS parameter that allows the addition audit of all statements issued by SYS/SYSDBA/SYSOPER in the same OS audit trail file.  In case the parameter AUDIT_SYS_OPERATIONS=TRUE Oracle audits not only SYS/SYSDBA/SYSOPER connection details but also their SQL operations. In any case the audit files with the name like <sid>_ora_<spid >_<instance#>.aud are created in audit_file_dest location on Unix.

sql*plus> show parameter audit
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest                      string      /opt/app/oracle/admin/orcl/ adump
audit_sys_operations                 boolean     FALSE

I share below one of the methods of purging those audit files on Unix using a simple Unix command based on following: Read more »

Oracle database housekeeping methods – Unix log rotation

Since Oracle Database 11g, all traces, incident dumps and packages, the alert log, Health Monitor reports, core dumps, and more files are stored in the ADR, a file-based Automatic Diagnostic Repository for simplified database diagnostic data management. In spite the housekeeping or purging of those files got not simplified, unfortunately the new Oracle utility ADRCI can not purge all the files that Oracle database generates in ADR. Thus, you should use the other OS methods and tools to accomplish Oracle database housekeeping.

This time I share a method of rotating Oracle database log files using Unix logrotate mechanism. The below example will rotate the Oracle alert.log and listener.log files in the following way:

– Rotation is based on the file size (you can use “M” or “k” for Mb and Kb)
– Unix Logrotate utility creates a copy of the original log file, then truncates it
– The rotated files will be compressed with Unix gzip utility with the following name <logfile>-yyyymmdd.gz
– Only recent 20 rotated log files are kept
– Rotation frequency is default = weekly
– No errors generated if the log file is missing
Read more »

Next Page »

DBMS Blog Updates : Subscribe RSS RSS: Subscribe to Articles · Subscribe to Comments Subscribe RSS Receive site updates via email