AUTOUPGRADE Tool

Steps in Autoupgrade to 19c are as below :

Preparation
Analyse
Deploy

STEP1 : PREPARATION

. upgr
java -jar $OH19/rdbms/admin/autoupgrade.jar -create_sample_file config

Sample Config : /home/oracle/scripts/sample_config.cfg

Remove :
dbname, start_time, upgrade_node and target_version

Update :
global.autoupg_log_dir=/home/oracle/logs
upg1.source_home=/u01/app/oracle/product/11.2.0.4
upg1.target_home=/u01/app/oracle/product/19
upg1.sid=UPGR
upg1.log_dir=/home/oracle/logs
upg1.restoration=no

STEP2 : ANALYZE

. upgr
java -jar $OH19/rdbms/admin/autoupgrade.jar -config /home/oracle/scripts/UPGR.cfg -mode analyze

STEP 3 : DEPLOY

java -jar $OH19/rdbms/admin/autoupgrade.jar -config /home/oracle/scripts/UPGR.cfg -mode deploy

Job Logs Locations
———————————–
Logs Base: /home/oracle/upg_logs/UPGR
Job logs: /home/oracle/upg_logs/UPGR/101
Stage logs: /home/oracle/upg_logs/UPGR/101/prefixups
TimeZone: /home/oracle/upg_logs/UPGR/temp

There is another utilitily I will share details on it soon.

Mandatory Background Processes

Mandatory background processes are present in all typical database configurations.

These processes run by default in a read/write database instance started with

a minimally configured initialization parameter file. A read-only database instance

disables some of these processes.

This section describes the following mandatory background processes:

• Process Monitor Process (PMON) Group

• Process Manager (PMAN)

• Listener Registration Process (LREG)

• System Monitor Process (SMON)

• Database Writer Process (DBW)

• Log Writer Process (LGWR)

• Checkpoint Process (CKPT)

• Manageability Monitor Processes (MMON and MMNL)

• Recoverer Process (RECO)

Process Monitor Process (PMON) Group

The PMON group includes PMON, Cleanup Main Process (CLMN), and Cleanup

Helper Processes (CLnn). These processes are responsible for the monitoring and

cleanup of other processes.

The PMON group oversees cleanup of the buffer cache and the release of resources

used by a client process. For example, the PMON group is responsible for resetting

the status of the active transaction table, releasing locks that are no longer required,

and removing the process ID of terminated processes from the list of active processes.

The database must ensure that resources held by terminated processes are released

so they are usable by other processes. Otherwise, process may end up blocked or

stuck in contention.

Process Monitor Process (PMON)

The process monitor (PMON) detects the termination of other background

processes. If a server or dispatcher process terminates abnormally, then the PMON

group is responsible for performing process recovery. Process termination can have

multiple causes, including operating system kill commands or ALTER SYSTEM KILL

SESSION statements.

Cleanup Main Process (CLMN)

PMON delegates cleanup work to the cleanup main process (CLMN). The task of

detecting abnormal termination remains with PMON.

CLMN periodically performs cleanup of terminated processes, terminated sessions,

transactions, network connections, idle sessions, detached transactions, and detached

network connections that have exceeded their idle timeout.


Cleanup Helper Processes (CLnn)

CLMN delegates cleanup work to the CLnn helper processes.

The CLnn processes assist in the cleanup of terminated processes and sessions. The

number of helper processes is proportional to the amount of cleanup work to be done

and the current efficiency of cleanup.

A cleanup process can become blocked, which prevents it from proceeding to clean up

other processes. Also, if multiple processes require cleanup, then cleanup time can be

significant. For these reasons, Oracle Database can use multiple helper processes in

parallel to perform cleanup, thus alleviating slow performance.

The V$CLEANUP_PROCESS and V$DEAD_CLEANUP views contain metadata about CLMN

cleanup. The V$CLEANUP_PROCESS view contains one row for every cleanup process.

For example, if V$CLEANUP_PROCESS.STATE is BUSY, then the process is currently

engaged in cleanup.

Database Flash Cache Memory

Oracle’s Database Smart Flash Cache
Over many years the performance of spinning disk-based storage devices has not improved significantly. That situation has changed dramatically thanks to flash-based storage devices. Oracle Database Smart Flash Cache feature leverages this I/O breakthrough offered by flash-based storage devices.

Oracle’s Database Smart Flash Cache feature is supported only on Oracle Linux and Oracle Solaris operating systems.

Oracle’s Database Smart Flash Cache functions as a secondary cache, which means that it stores clean (unmodified) database blocks that have been evicted from the SGA buffer cache to make room for other blocks. If a block selected for eviction has been modified, the dirty block is first written to disk by one of the database writer (DBWR) processes, then it is written to the Database Smart Flash Cache. Blocks can later be retrieved from the Database Smart Flash Cache and returned to the SGA as required.

If a block cannot be found either in the SGA buffer cache or the Database Smart Flash Cache, it will be retrieved from disk.

When to Configure Database Smart Flash Cache ?

Consider adding Database Smart Flash Cache when all of the following conditions are true:

  • Your database is running on the Solaris or Oracle Linux operating systems. Database Smart Flash Cache is supported on these operating systems only.
  • The Buffer Pool Advisory section of your Automatic Workload Repository (AWR) report or STATSPACK report indicates that doubling the size of the buffer cache would be beneficial.
  • db file sequential read is a top wait event.
  • You have spare CPU.


Database Smart Flash Cache Initialization Parameters

DB_FLASH_CACHE_FILE
DB_FLASH_CACHE_SIZE

You can query the V$FLASHFILESTAT view to determine the cumulative latency and read counts of each file and compute the average latency.

REFERENCE : https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/managing-memory.html#GUID-DD34BE6F-4EDE-482D-8F75-7D786F2701AB