Recent Article
All Archives


All topic articles are listed in this page.

Select the articles under each topic and enjoy reading.

Glossary Index
 a    b    c    d    e    f    g    h    i    j    k    l    m   
 n    o    p    q    r    s    t    u    v    w    x    y    z   
ACID Properties
»  Active Sessions
Active Sessions are foreground sessions contributing to DB Time in any given moment.
  • Foreground sessions in a database call
  • Either on CPU, waiting for I/O or Waiting (not idle)
»  Archiver (ARCn) Processes
Archives the standby redo logs applied by the managed recovery process (MRP).
»  ASM Basics
- The smallest unit of storage written to disk is called an "allocation unit" (AU) and is usually 1MB (4MB recommended for Exadata)
- Very simply, ASM is organized around storing files
- Files are divided into pieces called "extents"
- Extent sizes are typically equal to 1 AU, except in 11.1 and 11.2 where it will use variable extent sizes that can be 1, 8, 64 AUs or 1, 4, 16 AUs respectively
- File extent locations are maintained by ASM using file extent maps.
- ASM maintains file metadata in headers on the disks rather than in a data dictionary
- The file extent maps are cached in the RDBMS shared pool; these are consulted when an RDBMS process does I/O
- ASM is very crash resilient since it uses instance / crash recovery similar to a normal RDBMS (similar to using undo and redo logging)
»  Average Active Sessions
AAS = DB Time / Elapsed Time

For example, if your DB Time is 1500 seconds and the elapsed time is 300 seconds then, AAS is 5 seconds
»  Bundle Patches
Are the quarterly patches for Windows and Exadata which include both the quarterly security patches as well as recommended fixes.
»  consistent get
A 'consistent get' is when Oracle gets the data in a block which is consistent with a given point in time, or SCN. Consistent gets are the retrieval of blocks from the buffer cache in "read consistent" mode and may include read asides to UNDO (rollback segments). A query will generally perform "consistent gets." The consistent get is at the heart of Oracle's read consistency mechanism. When blocks are fetched in order to satisfy a query result set, they are fetched in consistent mode. If no block in the buffer cache is consistent to the correct point in time, Oracle will (attempt to) reconstruct that block using the information in the rollback segments. If it fails to do so, that's when a query errors out with the much dreaded, much feared, and much misunderstood ORA-1555 "snapshot too old".
»  consistent gets - examination
'Consistent gets - examination' are a different kind of consistent get that only requires a single latch, saving CPU. The most common use of a consistent get - examination is to read undo blocks for consistent read purposes. If you're doing a query on a couple tables that are mostly cached, but one of them has uncommitted DML against it at the time, you'll do consistent gets for the standard data in the cache, and the query will do consistent gets - examination to read the undo blocks and create read consistent blocks; this doesn't necessarily save CPU unfortunately, because while the consistent gets - examination only acquire one latch, creating the read consistent data block also takes a latch.
»  Critical Patch Update (CPU)
Now refers to the overall release of security fixes each quarter rather than the cumulative database security patch for the quarter. Think of the CPU as the overarching quarterly release and not as a single patch.
»  db block get
A 'db block get' is a current mode get. That is, it's the most up-to-date copy of the data in that block, as it is right now, or currently. There can only be one current copy of a block in the buffer cache at any time. Db block gets generally are used when DML changes data in the database. In that case, row-level locks are implicitly taken on the updated rows. There is also at least one well-known case where a select statement does a db block get, and does not take a lock. That is, when it does a full table scan or fast full index scan, Oracle will read the segment header in current mode (multiple times, the number varies based on Oracle version).
»  db time
Database Time is total time spent by user processes either actively working or actively waiting in a database call.
  • Time spent in the database by foreground sessions
  • Includes CPU Time, I/O Time and Wait time
  • Excludes Idle Wait Time
»  Fetch Archive Log (FAL) Client
Pulls archived redo log files from the primary site. Initiates transfer of archived redo logs when it detects a gap sequence.
»  Fast Application Notification (FAN)
FAN is simply a series of published events by ONS. ONS publishes events as a RAC service, including UP and DOWN events in case of falure.
FAN is built into Oracle's integrated client protocols, such as JDBC, ODP.NET and OCI so that programs written to connect to make cluster-wide decisions.
For example, several programs can be run against a two node RAC cluster, including batch processes.
The batch applications can be programmed to respond to a FAN DOWN event so that if a node fails, the batch process pauses until the node comes back online.
Another feature, Fast Connection Failure (FCF), allows clients to respond to FAN events with quick failover to other nodes in the event of an outage.
»  Latching
As to latching, and how it relates, well, consider that the block buffers are in the SGA, which is shared memory. To avoid corruption, latches are used to serialize access to many linked lists and data structures that point to the buffers as well as the buffers themselves. It is safe to say that each consistent get introduces serialization to the system, and by tuning SQL to use more efficient access paths, you can get the same answer to the same query but do less consistent gets. This not only consumes less CPU, it also can significantly reduce latching which reduces serialization and makes your system more scalable.
»  Logical Standby Process (LSP)
The LSP applies the redo records from archived redo logs to the logical standby database.
The Oracle database log miner engine is used by the logical standby process for the SQL apply operations. Using the log miner engine, the LSP process recreates the SQL statements from redo logs that have been executed on the primary database.
These statements are then applied to the standby database to keep it current with the primary database.
»  Latest Patchsets
Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets (Doc ID 1454618.1)
»  Managed Recovery Process (MRP)
Applies archive redo log information to the standby database.
»  MGMTD - GIMR database
The GIMR primarily stores historical Cluster Health Monitor metric data. It runs as a container database on a single node of the RAC cluster.
»  Nodeapps
Virtual IP (VIP)
Oracle Net Listener
Global Services Daemon (GSD):
  • The Global Services Daemon (GSD) runs on each node with one GSD process per node.
  • The GSD coordinates with the cluster manager to receive requests from clients such as the DBCA, EM, and the SRVCTL utility to execute administrative job tasks such as instance startup or shutdown.
  • The GSD is not an Oracle instance background process and is therefore not started with the Oracle instance.
Oracle Notification Service (ONS)
Note: Nodeapp services that run on each node can be relocated to other nodes through the virtual IP.
»  Patch Set Updates (PSU)
Are the same cumulative patches that include both the security fixes and priority fixes. The key with PSUs is they are minor version upgrades (e.g., to Once a PSU is applied, only PSUs can be applied in future quarters until the database is upgraded to a new base version.
»  Remote File Server (RFS)
Receives archived and/or standby redo logs from the primary database.
The Remote File Server (RFS) process receives the redo data and writes it to a Standby Redo Log (SRL). RFS sends an acknowledgement back to the production database that the redo has been received and written to disk. When the production database receives this acknowledgement, it acknowledges the commit to the client application and processes the next transaction.
»  Response Time
Response time is the time it takes to get a response from the database for a query that a client sends to the database.
Response time is simply the sum of two components

response time = processing time + wait time
»  Security Patch Update (SPU)
Terminology is introduced in the October 2012 Critical Patch Update as the term for the quarterly security patch. SPU patches are the same as previous CPU patches, just a new name. For the database, SPUs can not be applied once PSUs have been applied until the database is upgraded to a new base version.
»  Wait Event: SQL*Net break/reset to client
Def: The server sends a break or reset message to the client. The session running on the server waits for a reply from the client.
Wait Time: The actual time it takes for the break or reset message to return from the client
Solution: Check for errors in sql statement
»  Wait Event: SQL*Net break/reset to dblink
Def: The server sends a break or reset message to the client. The session running on the server waits for a reply from the client.
Wait Time: The actual time it takes for the break or reset message to return from the client
Solution: Check for errors in sql statement sent
»  Wait Event: SQL*Net more data from client
Def: The server is waiting on the client to send more data to its client shadow process, in an already initiated operation
Solution: Usually OK, reduce data transferred, possible Network problems.
»  Wait Event: SQL*Net more data to client
That normally indicates that you have a very long string or LOB that is bigger than the packet size so the server is waiting for the rest of the packets to arrive to combine them.
»  Wait Event: SQL*Net more data from dblink
Def: The foreground process is expecting more data from a data base link.
Wait Time: The total time it takes to read the data from the database link (including the waiting time for the data to arrive)
Solution: Reduce data transfer, check net response