Oracle DBA Course Oracle DBA Course

Lecture 1: Oracle Architectural Components

Oracle DBA Course (9i, 10g, 11g)

1/49

Copyright  Oracle Corporation, 1998, 2001, 2010. All rights reserved.

Oracle Documentation http://tahiti.oracle.com/

http://www.oracle.com/pls/db112/homepage? remark=tahiti

2/49


Tasks of a Database Administrator 1: Evaluate the Database Server Hardware 2: Install the Oracle Database Software 3: Plan the Database 4: Create and Open the Database 5: Back Up the Database 6: Enroll System Users 7: Implement the Database Design 8: Back Up the Fully Functional Database 9: Tune Database Performance 10: Download and Install Patches 11: Roll Out to Additional Hosts 3/49


Objectives of the lecture

• Overview of Oracle server architecture, identifying main components.

4/49


The Oracle Server Oracle server

Application/ network server

Server 5/49


Users

Oracle server The Oracle server consists of: • Oracle database - physical files that store data • Oracle instance - memory structures and Oracle processes used to access data (from the physical database files)

6/49


Oracle Database An Oracle database consists of operating system files, known as database files, that provide the actual physical storage for database information. The database files are used to ensure that the data is kept consistent and can be recovered in the event of a failure of the instance. Usually there is only accessing a database. Cluster configuration a single database. 7/49

one Oracle instance In the Real Application multiple instances access


Oracle Database Physical Physical Storage Storage Structures Structures Control and redo log files are multiplexed

Control files Parameter file Password file

Data files

Redo log files

Database

8/49


Archived log files

+ Backup files, trace and alert files, audit files, …

Other Key Physical Structures

Parameter file

Password file

9/49

Database


Archived log files

Connecting to a Database Client Client

Connection established

User process

Server process

Server Server Session created Oracle server

User User

10/49 10/49


User Process •• Runs Runs on on the the client client machine machine •• Is Is spawned spawned when when aa tool tool or or an an application application is is invoked invoked •• Runs Runs the the tool tool or or application application (SQL*Plus, (SQL*Plus, Oracle Oracle Enterprise Enterprise Manager, Manager, OracleForms) OracleForms) •• Generates Generates calls calls to to the the Oracle Oracle server server

11/49 11/49


Connection Connection is a communication pathway between a user process and an Oracle Database instance. A communication pathway is established using: 1. available interprocess communication mechanisms (on a computer that runs both the user process and Oracle Database), or 2. network software (when different computers run the database application and Oracle Database, and communicate through a network). 12/49 12/49


Session Session is a specific connection of a user to an Oracle Database instance through a user process. For example, when a user starts SQL*Plus, the user must provide a valid user name and password, and then a session is established for that user. A session lasts from the time the user connects until the time the user disconnects or exits the database application. Multiple sessions can be created and exist concurrently for a single Oracle Database user using the same user name. • For example, a user with the user name/password of SCOTT/TIGER can connect to the same Oracle Database instance several times. 13/49 13/49


Server Process •• Runs Runs on on the the server server machine machine (host) (host) •• Services Services aa single single user user process process in in the the dedicated dedicated server server configuration configuration •• Uses Uses an an exclusive exclusive Program Program Global Global Area Area (PGA) (PGA) •• Processes Processes calls calls generated generated by by the the client client •• Returns Returns results results to to the the client client

14/49 14/49


Oracle Instance Instance SGA

SGA System Global Area Background processes

An An Oracle Oracle instance: instance: •• Is Is aa means means to to access access an an Oracle Oracle database database •• Always Always opens opens one one and and only only one one database database 15/49 15/49


Oracle Memory Structures + Streams Pool in 10g + Result cache in 11g + User Global Area in 11g

16/49 16/49


System Global Area (SGA) Used to store database information that is shared by database processes. It contains data and control information for the Oracle server and is allocated in the virtual memory of the computer where Oracle resides. SHOW SGA; Total System Global Area 36437964 bytes Fixed Size 6543794 bytes Variable Size 19521536 bytes Database Buffers 16777216 bytes Redo Buffers 73728 bytes 17/49 17/49


Dynamic SGA Dynamic SGA implements an infrastructure that allows the SGA configuration to change without shutting down the instance. This then allows the sizes of the database buffer cache, shared pool, and large pool to be changed without shutting down the instance. Conceivably, they could be initially under configured and would grow and shrink depending upon their respective work loads, up to a maximum of SGA_MAX_SIZE. 18/49 18/49


Sizing the SGA The size of the SGA is determined by several initialization parameters, including: DB_CACHE_SIZE: The size of the default cache of database blocks. LOG_BUFFER: The number of bytes allocated for the redo log buffer cache. SHARED_POOL_SIZE: The size in bytes of the area devoted to shared SQL and PL/SQL. LARGE_POOL_SIZE: The size of the large pool; the default is zero. 19/49 19/49


System Global Area (SGA) SGA memory allocated and tracked in granules by SGA components. A granule is a unit of contiguous virtual memory allocation. The size of a granule depends on the parameter SGA_MAX_SIZE: – 4 MB if estimated SGA size is < 128 MB – 16 MB otherwise

20/49 20/49


The Shared Pool Shared pool Library cache Data dictionary cache

•• Size Size defined defined by by SHARED_POOL_SIZE SHARED_POOL_SIZE •• Library Library cache cache contains contains statement statement text, text, parsed parsed code, code, and and an an execution execution plan plan •• Data Data dictionary dictionary cache cache contains contains table table and and column column definitions definitions and and privileges privileges 21/49 21/49


Resizing The size of Shared Pool can be dynamically resized using ALTER SYSTEM SET. After performance analysis can be adjusted (but the total SGA size cannot exceed SGA_MAX_SIZE): ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

22/49 22/49


Library Cache 1. Stores information about the most recently used SQL and PL/SQL statements: • Enables the sharing of commonly used statements 2.

Consists of two structures: •

Shared SQL area

•

Shared PL/SQL area

3. Has its size determined by the shared pool sizing 23/49 23/49


The library cache consists of two structures: • Shared SQL: The Shared SQL stores and shares the execution plan and parse tree for SQL statements run against the database. The second time that an identical SQL statement is run, it is able to take advantage of the parse information available in the shared SQL to expedite its execution. To ensure that SQL statements use a shared SQL area whenever possible, the text, schema, and bind variables must be exactly the same. • Shared PL/SQL: The shared PL/SQL area stores and shares the most recently executed PL/SQL statements. Parsed and compiled program units and procedures (functions, packages, and triggers) are stored in this 24/49 Copyright  Oracle Corporation, 1998, 2001, 2010. All rights reserved. 24/49 area.

Data Dictionary Cache It is a collection of the most recently used definitions in the database. It includes information about database files, tables, indexes, columns, users, privileges, and other database objects. During the parse phase, the server process looks at the data dictionary for information to resolve object names and validate access. Caching the data dictionary information into memory improves response time on queries. Size is determined by the shared pool sizing. 25/49 25/49


Sizing the Data Dictionary The overall size is dependent on the size of the shared pool size and is managed internally by the database. If the data dictionary cache is too small, then the database has to query the data dictionary tables repeatedly for information needed by the database. These queries are called recursive calls and are slower than the queries that are handled only by the data dictionary cache.

26/49 26/49


Database Buffer Cache

•• Stores Stores the the most most recently recently used used blocks blocks that that have have been been retrieved retrieved from from the the data data files files.. •• DB_BLOCK_SIZE DB_BLOCK_SIZE determines determines the the primary primary block block size size.. 27/49 27/49


Multiple Block Sizes An Oracle database can be created with a standard block size and up to four non-standard block sizes. Nonstandard block sizes can have any power-of-two value between 2 KB and 32 KB.

28/49 28/49


Database Buffer Cache Consists of three independent sub-caches: •

DEFAULT Buffer Pool - DB_CACHE_SIZE

•

KEEP Buffer Pool - DB_KEEP_CACHE_SIZE

•

RECYCLE Buffer Pool - DB_RECYCLE_CACHE_SIZE

Database buffer cache can be dynamically resized to grow or shrink using ALTER SYSTEM ALTER SYSTEM SET DB_CACHE_SIZE = 96M;

29/49 29/49


Types of buffers Unused - available for use because it has never been used or is currently unused. The easiest for the database to use. Clean - used earlier and written to the disk. The database can reuse it. Dirty - changed and has not yet been written to the disk.

30/49 30/49


Access modes of a buffer Free (Unpinned) - contains no data or is free to be overwritten. Pinned - currently being accessed or explicitely retained for future use (e.g. the KEEP buffer pool).

31/49 31/49


Two lists of (pointers to) buffers Write list (dirty buffer list) - buffers that are modified and need to be written to the disk. Least recently used list (LRU) – buffers that have not yet been moved to the Write List. The most recently accessed blocks are always in the front (MRU end, hot end); the least recently accessed blocks, in the end (LRU end, cold end).

32/49 32/49


LRU list 1. The least-used blocks are thrown out of the list when new blocks are accessed and added to the MRU end of the list. • With one exception – when a full table is scanned – the blocks are written to the LRU end of the list. 2. When an Oracle process accesses a buffer, it moves the buffer to the MRU end of the list so that the most frequently accessed data is available in the buffers. 33/49 33/49


When an Oracle process requests data • It searches the data in the buffer cache – if it finds, we get cache hit. • If not – cache miss – data need to be copied from disk to the buffer. • The server process searches (from the LRU end) until it finds a free buffer or until it has searched a threshold limit of buffers. It moves encountered dirty buffers to the write list. If it does not find a free buffer – DBWn writes some buffers from write list to disk – making available free buffers for the server process. 34/49 34/49


Database smart fflash lash cache enabled (*) DBWn can write the body of a clean buffer to the flash cache, enabling reuse of its in-memory buffer. The database keeps the buffer header in an LRU list in main memory to track the state and location of the buffer body in the flash cache. If this buffer is needed later, then the database can read it from the flash cache instead of from magnetic disk. (*) Currently available only in Solaris and Oracle Enterprise Linux. 35/49 35/49


Buffer Touch Count The frequency of access of buffers on the LRU list - instead of constantly shuffling buffers on the LRU list. When a buffer gets pinned, the database determines when its touch count was last incremented. If the count was incremented over three seconds ago, then the count is incremented. If a buffer is on the cold end of the LRU, but its touch count is high, then the buffer moves to the hot end. If the touch count is low, then the buffer ages out of the cache. 36/49 36/49


Redo Log Buffer Cache

•• Size Size defined defined by by LOG_BUFFER LOG_BUFFER •• Records Records changes changes made made through through the the instance instance •• Used Used sequentially sequentially •• Circular Circular buffer buffer 37/49 37/49


Redo Log Buffer Cache • The redo log buffer cache records all changes made to the database data blocks. •

Its primary purpose is recovery.

• Changes recorded within are called redo entries. • Redo entries contain information to reconstruct or redo changes.

38/49 38/49


Res ult cache (11g) Result The result cache buffers query results. If a query is run that already has results in the result cache, the database returns results from the result cache instead of rerunning the query. This speeds up the execution of frequently run queries. The database automatically invalidates a cached result whenever a transaction modifies the data or metadata of any of the database objects used to construct that cached result. 39/49 39/49


Result cache (11g)

Users can annotate a query or query fragment with a result cache hint to indicate that results are to be stored in the SQL query result cache. You can set the RESULT_CACHE_MODE initialization parameter to control whether the SQL query result cache is used for all queries (when possible), or only for queries that are annotated. 40/49 40/49


PL/SQL Function Result Cache A PL/SQL function may depend on several parameters. In some cases, the SQL statements in the function body access data (for example, the catalog of wares in a shopping application) that changes very infrequently compared to the frequency of calling the function. The look-up key for the cache is the combination of actual arguments with which the function is invoked. When a particular invocation of the result-cached function is a cache hit, then the function body is not executed; instead, the cached value is returned immediately. 41/49 41/49


Large Pool The large pool is an optional area of memory in the SGA configured only in a shared server environment. It relieves the burden placed on the shared pool. This configured memory area is used for session memory (UGA – User Global Area), I/O slaves, and backup and restore operations. Unlike the shared pool, the large pool does not use an LRU list. Sized by LARGE_POOL_SIZE ALTER SYSTEM SET LARGE_POOL_SIZE = 64M; 42/49 42/49


Java Pool The Java pool services the parsing requirements for Java commands. Required if installing and using Java. It is sized by the JAVA_POOL_SIZE parameter. In Oracle9i, the default size of the Java Pool is 24M.

43/49 43/49


Streams Pool (10g) Oracle Streams enables information sharing. Using Oracle Streams, each unit of shared information is called a message, and you can share these messages in a stream. The stream can propagate information within a database or from one database to another. The stream routes specified information to specified destinations. Used for distributed databases, applications and data warehouses. The size of the Streams Pool starts at zero. The pool size grows dynamically as needed. 44/49 44/49


Program Global Area (PGA) •• Not Not shared shared Contains: Contains:

Server process

PGA

•• Sort Sort area area

Memory region that contains data and control –– Sort Sort area area size size can can grow grow information for a single depending depending on on the the need. need. server process or a single •• Session Session information information background process. The PGA is allocated when a •• Cursor state Cursor state process is created and •• Stack Stack space space deallocated when the process is terminated. SORT_AREA_SIZE SORT_AREA_SIZE

45/49 45/49


PGA The total memory used by all individual PGAs is known as the total instance PGA memory, and the collection of individual PGAs is referred to as the total instance PGA, or just instance PGA. With Oracle Enterprise Manager Database Control, you set the size of the instance PGA, not individual PGAs.

46/49 46/49


User Global Area (UGA) 1. UGA contains session variables e.g. logon information, values of package variables. 2. When using a dedicated server connection, the UGA is stored in the PGA. 3. When using a shared server connection, the UGA is stored in the Large Pool of the SGA enabling any shared server process access to it.

47/49 47/49


Summary 1

48/49 48/49


Summary 2

Fixed SGA – internal area for communication between processes 49/49 49/49
