The script for the demonstration from the tutorial can be downloaded here:seg_demo

Until 11gR2, if you create a table, Oracle database allocates space for initial segment.

The new feature allows you to defer creation of this initial segment until the first row of data is inserted into the table.

In addition to deferring the table’s segment, it also defers the segment creation for LOB columns of the table, indexes created implicitly as part of table creation, and indexes subsequently explicitly created on the table.

By using this feature, large amount of disk space can be saved in case of many unpopulated tables.

A new parameter DEFERRED_SEGMENT_CREATION is created to control the feature. It can be enabled/disabled it at the session or system level (doesn’t require Instance restart).

Alter session set deferred_segment_creation=true;

Alter system set deferred_segment_creation=true;
  

Deferred segment creation is enabled by default. It’s also possible to enable/disable it for a single table by specifying the deferred segment creation clause.

CREATE TABLE.... SEGMENT CREATION IMMEDIATE

CREATE TABLE... SEGMENT CREATION DEFERRED
 

* A table with deferred segment won’t exist in the *_EXTENTS System view before inserting into it data (as no extent is created)
* A new column was added to the *_TABLES,  *_INDEXES and *_LOBS System views – SEGMENT_CREATED, whichindicates whether the initial segment was created or not. Its values are ‘YES’ / ’NO’.

One important note – All segments related to a table are created when the first row is inserted into it. And that, even if they are not used to store data

Following is a short demo that demonstrates the new features.

SQL> @c:\seg_demo
====================================================================
Creating a user for the demonstration and granting it privileges:
====================================================================

SQL> CREATE USER seg_demo identified by seg_demo
User created.
SQL> GRANT RESOURCE , CONNECT TO seg_demo
Grant succeeded.
SQL> GRANT SELECT ON V_$PARAMETER TO seg_demo
Grant succeeded.
SQL> CONNECT seg_demo/seg_demo
Connected.

====================================================================
Displaying relevant parameters
====================================================================

SQL> SHOW PARAMETER def
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
deferred_segment_creation            boolean     TRUE
SQL> SHOW PARAMETER compatible
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
compatible                           string      11.2.0.0.0

=========================================================================================
Creating a table. The table will be created without segments for all its related objects
=========================================================================================

SQL> CREATE TABLE test_seg (id number CONSTRAINT id_pk primary key,
2				email VARCHAR2(50)  CONSTRAINT  email_uk unique,
3				name VARCHAR2(30),
4				data CLOB)
5			lob(data) STORE AS TEST_SEG_DATA_LOB
6			(index test_seg_data_lob_ix)
Table created.

=========================================================================================
Displaying relevant information FROM the System views.
=========================================================================================

SQL> SELECT segment_name ,SEGMENT_TYPE
2	FROM user_segments
3 	WHERE segment_name = 'TEST_SEG'

no rows selected

SQL> SELECT segment_name, extent_id, bytes
2 	FROM user_extents

no rows selected

SQL> SELECT table_name, SEGMENT_CREATED
2 	FROM user_tables

TABLE_NAME                     SEGMENT_CREATED
------------------------------ ---------------
TEST_SEG                       NO

SQL> SELECT table_name, index_name, SEGMENT_CREATED
2 	FROM user_indexes

TABLE_NAME                     INDEX_NAME                     SEGMENT_CREATED
------------------------------ ------------------------------ ---------------
TEST_SEG                       ID_PK                          NO
TEST_SEG                       TEST_SEG_DATA_LOB_IX           NO
TEST_SEG                       EMAIL_UK                       NO

SQL> SELECT  TABLE_NAME ,segment_name, SEGMENT_CREATED
2 	FROM user_lobs

TABLE_NAME                     SEGMENT_NAME         SEGMENT_CREATED
------------------------------ -------------------- ---------------
TEST_SEG                       TEST_SEG_DATA_LOB    NO

=========================================================================================
Inserting the first row to the table.
=========================================================================================

SQL> INSERT INTO TEST_SEG VALUES (1,'Roni@@dbsnaps.com','DBSNAPS','Deferred Segment Creation')

1 row created.

SQL> commit

Commit complete.

=========================================================================================
All the relevant segments will be created.
Displaying relevant information FROM the System views.
=========================================================================================

SQL> SELECT segment_name ,SEGMENT_TYPE
2 FROM user_segments

SEGMENT_NAME         SEGMENT_TYPE
-------------------- ------------------
TEST_SEG             TABLE
TEST_SEG_DATA_LOB_IX LOBINDEX
ID_PK                INDEX
EMAIL_UK             INDEX
TEST_SEG_DATA_LOB    LOBSEGMENT

SQL> SELECT segment_name, extent_id, bytes
2 	FROM user_extents

SEGMENT_NAME          EXTENT_ID      BYTES
-------------------- ---------- ----------
TEST_SEG                      0      65536
TEST_SEG_DATA_LOB_IX          0      65536
ID_PK                         0      65536
EMAIL_UK                      0      65536
TEST_SEG_DATA_LOB             0      65536
SQL> SELECT table_name, SEGMENT_CREATED
2 	FROM user_tables

TABLE_NAME                     SEGMENT_CREATED
------------------------------ ---------------
TEST_SEG                       YES

SQL> SELECT table_name, index_name, SEGMENT_CREATED
2 	FROM user_indexes
TABLE_NAME                     INDEX_NAME                     SEGMENT_CREATED
------------------------------ ------------------------------ ---------------
TEST_SEG                       ID_PK                          YES
TEST_SEG                       TEST_SEG_DATA_LOB_IX           YES
TEST_SEG                       EMAIL_UK                       YES
SQL> SELECT  TABLE_NAME ,segment_name, SEGMENT_CREATED
2 	FROM user_lobs

TABLE_NAME                     SEGMENT_NAME         SEGMENT_CREATED
------------------------------ -------------------- ---------------
TEST_SEG                       TEST_SEG_DATA_LOB    YES

=========================================================================================
The parameter can be changed in the System/Session level.
Changing the session settings to deferred_segment_creation=FALSE.
=========================================================================================

ALTER SESSION SET deferred_segment_creation=FALSE

Session altered.

=========================================================================================
While this parameter is set to FALSE, tables will be created with all their segments.
=========================================================================================
prompt
SQL> CREATE TABLE test_seg2 (id number CONSTRAINT id2_pk primary key,
2    			name VARCHAR2(30))

Table created.

=========================================================================================
Displaying relevant information FROM the System views.
=========================================================================================

SQL> SELECT segment_name ,SEGMENT_TYPE
2 	FROM user_segments
3 	WHERE segment_name = 'TEST_SEG2'

SEGMENT_NAME         SEGMENT_TYPE
-------------------- ------------------
TEST_SEG2            TABLE
SQL> SELECT segment_name, extent_id, bytes
2 	FROM user_extents
3 	WHERE segment_name = 'TEST_SEG2'

SEGMENT_NAME          EXTENT_ID      BYTES
-------------------- ---------- ----------
TEST_SEG2                     0      65536

SQL> SELECT table_name, SEGMENT_CREATED
2 	FROM user_tables
3 	WHERE table_name = 'TEST_SEG2'

TABLE_NAME                     SEGMENT_CREATED
------------------------------ ---------------
TEST_SEG2                      YES

SQL> SELECT table_name, index_name, SEGMENT_CREATED
2 	FROM user_indexes
3 	WHERE table_name = 'TEST_SEG2'

TABLE_NAME                     INDEX_NAME                     SEGMENT_CREATED
------------------------------ ------------------------------ ---------------
TEST_SEG2                      ID2_PK                         YES

=========================================================================================
In addition, the feature can be enabled/Disabled for a Single table.
While the parameter is set to TRUE, we will disable the deferred segment creation for a single table .
=========================================================================================

ALTER SESSION SET deferred_segment_creation=TRUE

Session altered.

SQL> CREATE TABLE test_seg3 (id number CONSTRAINT id3_pk primary key,
2	    			name VARCHAR2(30))
3				SEGMENT CREATION IMMEDIATE

Table created.

=========================================================================================
Displaying relevant information FROM the System views.
=========================================================================================

SQL> SELECT segment_name ,SEGMENT_TYPE
2 	FROM user_segments
3 	WHERE segment_name = 'TEST_SEG3'

SEGMENT_NAME         SEGMENT_TYPE
-------------------- ------------------
TEST_SEG3            TABLE

SQL> SELECT segment_name, extent_id, bytes
2 	FROM user_extents
3	WHERE segment_name = 'TEST_SEG3'

SEGMENT_NAME          EXTENT_ID      BYTES
-------------------- ---------- ----------
TEST_SEG3                     0      65536

SQL> SELECT table_name, SEGMENT_CREATED
2 	FROM user_tables
3 	WHERE table_name = 'TEST_SEG3'

TABLE_NAME                     SEGMENT_CREATED
------------------------------ ---------------
TEST_SEG3                      YES

SQL> SELECT table_name, index_name, SEGMENT_CREATED
2 	FROM user_indexes
3 	WHERE table_name = 'TEST_SEG3'

TABLE_NAME                     INDEX_NAME                     SEGMENT_CREATED
------------------------------ ------------------------------ ---------------
TEST_SEG3                      ID3_PK                         YES

=========================================================================================
While the parameter is set to FALSE, we will Enable the deferred segment creation for a single table .
=========================================================================================

SQL> ALTER SESSION SET deferred_segment_creation=FALSE

Session altered.

SQL> CREATE TABLE test_seg4 (id number CONSTRAINT id4_pk primary key,
2         			name VARCHAR2(30))
3  	SEGMENT CREATION DEFERRED

Table created.

=========================================================================================
Displaying relevant information FROM the System views.
=========================================================================================

SQL> SELECT segment_name ,SEGMENT_TYPE
2	FROM user_segments
3 	WHERE segment_name = 'TEST_SEG4'

no rows selected

SQL> SELECT segment_name, extent_id, bytes
2 	FROM user_extents
3 	WHERE segment_name = 'TEST_SEG4'

no rows selected

SQL> SELECT table_name, SEGMENT_CREATED
2 FROM user_tables
3 WHERE table_name = 'TEST_SEG4'

TABLE_NAME                     SEGMENT_CREATED
------------------------------ ---------------
TEST_SEG4                      NO

SQL> SELECT table_name, index_name, SEGMENT_CREATED
2 	FROM user_indexes
3 	WHERE table_name = 'TEST_SEG4'

TABLE_NAME                     INDEX_NAME                     SEGMENT_CREATED
------------------------------ ------------------------------ ---------------
TEST_SEG4                      ID4_PK                         NO

=========================================================================================
The END. Dropping the demonstration user
=========================================================================================

SQL> CONNECT / as sysdba

Connected.

DROP USER seg_demo CASCADE

User dropped.

Automatic Parallel Degree

When PARALLEL_DEGREE_POLICY is set to AUTO, automatic parallel degree is enabled. Oracle will evaluate the execution time of the statement, and if it exceeds the value of PARALLEL_MIN_TIME_THRESHOLD parameter (10 seconds by default) Oracle will calculate an automatic degree of parallelism (DOP) for this statement.

Oracle calculates the DOP based on the statement requirements and the load on the server. The DOP can be limited by the parameter PARALLEL_DEGREE_LIMIT:

• CPU (default) – will set the maximum DOP to the value of PARALLEL_THREADS_PER_CPU * CPU_COUNT * # of instances.
• IO  - will limit the DOP according to the I/O of the system (available only after running DBMS_RESOURCE_MANAGER.CALIBRATE_IO).
• Integer value – will limit the DOP to this integer.

When PARALLEL_DEGREE_POLICY is set to LIMITED, Oracle will automatically determine the DOP for the statements. However, statements that are not specified to run in parallel, will run in serial.

Statement Queuing

When a statement is executed, Oracle determines the DOP for this statement. If creating the calculated number of parallel processes will cause the total number of active parallel processes in the system to exceed the PARALLEL_SERVERS_TARGET, this statement will be queued.

The queue of statements is based on the simple “first in first out” mechanism. Once there are enough parallel processes available, the statement will start executing.

Using resource manager, we can set priority in the statement queue, timeout for statements and manage the amount of parallel processes for statements.

In Memory Parallel Execution

When running a parallel operation, the server process is reading the data from the file using direct operation into its PGA. The data blocks are not cached in the SGA and are not read from it. The in memory parallel execution feature enables the server processes to load the blocks to the SGA and read them from the SGA.

If the object is too large to fit in the buffer cache, Oracle will still use direct read.

Disable Automatic Parallel Features

Enabling and disabling the automatic parallel features is made using the PARALLEL_DEGREE_POLICY parameter:

• AUTO – all of the above features are enabled.
• LIMITED – in memory parallel execution and statement queuing will be disabled, the automatic DOP will be enabled only for queries that were set to run in parallel.
• MANUAL – disable all the automatic parallel features and revert parallel behavior to pre-11gR2

When searching for resource-intensive queries, we can use the sys.dm_exec_query_stats and sys.dm_exec_requests.

These dynamic management views already where introduced in SQL server 2005.
In SQL Server 2008 there are a couple of columns added to the sys.dm_exec_query_stats and sys.dm_exec_requests - The query_hash and the query_plan_hash column.

By using these columns we can find and tune similar queries that collectively consume significant system resources, and help determine the aggregate resource usage for similar queries and similar query execution plans.

First let’s look at the following queries:

use AdventureWorks
go
SELECT SOD.ProductID ,
sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
FROM Sales.SalesOrderHeader SOH
JOIN Sales.SalesOrderDetail SOD
   ON SOH.SalesOrderID = SOD.SalesOrderID
JOIN Production.Product P
   ON P.ProductID = SOD.ProductID
WHERE SOH.CustomerID = 520
AND SOD.OrderQty > 10
GROUP BY SOD.ProductID;
go

SELECT SOD.ProductID ,sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
FROM Sales.SalesOrderHeader SOH
JOIN Sales.SalesOrderDetail SOD
   ON SOH.SalesOrderID = SOD.SalesOrderID
JOIN Production.Product P
   ON P.ProductID = SOD.ProductID
WHERE SOH.CustomerID = 523
AND SOD.OrderQty > 10
GROUP BY SOD.ProductID;
go

These queries are only different in the constant value supplied for the CustomerID column; Now let’s look at the Query_Hash values of this both queries:

SELECT st.text AS "Query Text", qs.query_hash AS "Query Hash"
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) st
WHERE st.text ='SELECT SOD.ProductID ,sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount FROM Sales.SalesOrderHeader SOH JOIN Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 520 AND SOD.OrderQty > 10 GROUP BY SOD.ProductID;'
OR st.text = ' SELECT SOD.ProductID ,sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount FROM Sales.SalesOrderHeader SOH JOIN Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 523 AND SOD.OrderQty > 10 GROUP BY SOD.ProductID;'

We can see that although these queries’ text does not exactly match, sql server 2008 identifies these queries as having the same structure and therefore have the same hash values. This gives a significant advantage to help us identifying similar queries. We can for instance use this information to find which queries would benefit from using parameterization to improve performance. For example, let’s change the logic of the queries:

use AdventureWorks
go
SELECT SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
FROM Sales.SalesOrderHeader SOH
JOIN Sales.SalesOrderDetail SOD
   ON SOH.SalesOrderID = SOD.SalesOrderID
JOIN Production.Product P
   on P.ProductID = SOD.ProductID
WHERE SOH.CustomerID = 520
AND SOD.OrderQty > 10
GROUP BY SOD.ProductID;
go
SELECT  SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount
from Sales.SalesOrderHeader SOH
join Sales.SalesOrderDetail SOD
   on SOH.SalesOrderID = SOD.SalesOrderID
Join Production.Product P
   on P.ProductID = SOD.ProductID
where SOH.CustomerID = 523
OR SOD.OrderQty > 10
GROUP BY SOD.ProductID;

go

Now, let’s find out the query hash for these two queries:

SELECT st.text AS "Query Text", qs.query_hash AS "Query Hash"
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text (qs.sql_handle) st
WHERE st.text ='SELECT SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount FROM Sales.SalesOrderHeader SOH JOIN Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 520 AND SOD.OrderQty > 10 GROUP BY SOD.ProductID;'
OR st.text = 'SELECT SOD.ProductID , sum((UnitPrice * OrderQty ) - (UnitPriceDiscount * OrderQty ) ) TotalSaleAmount from Sales.SalesOrderHeader SOH join Sales.SalesOrderDetail SOD    ON SOH.SalesOrderID = SOD.SalesOrderID JOIN Production.Product P    ON P.ProductID = SOD.ProductID WHERE SOH.CustomerID = 523 OR SOD.OrderQty > 10 GROUP BY SOD.ProductID;' 

We see that these 2 queries has different query hashes, so they to do not share the same logic. Now let us examine the query plan hash column, how can we use this column to find performance issues? Consider that you have similar queries like we have seen, but somehow they do not have the same query plan, this sometimes indicates a performance problem; Let’s examine the following example (from SQL 2008 BOL):

USE AdventureWorks;
GO
SET STATISTICS XML ON;

SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name
FROM Production.TransactionHistory T
JOIN Production.Product P
   ON T.ProductID = P.ProductID
WHERE P.ProductID = 1;
GO

SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name
FROM Production.TransactionHistory T
JOIN Production.Product P
   ON T.ProductID = P.ProductID
WHERE P.ProductID = 3;
GO

SET STATISTICS XML OFF;
GO 

If you examine the query’s plan you will see that they are different, although the query hashes are the same because we just changed the value for the ProductID column.

SELECT ST.text AS "Query Text",QS.query_plan_hash ,QP.query_plan
FROM sys.dm_exec_query_stats QS
CROSS APPLY sys.dm_exec_sql_text (QS.sql_handle) ST
CROSS APPLY sys.dm_exec_query_plan(QS.plan_handle) QP
WHERE ST.text = 'SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name FROM Production.TransactionHistory T JOIN Production.Product P ON T.ProductID = P.ProductID WHERE P.ProductID = 1;'
OR ST.text = 'SELECT T.TransactionID, T.TransactionDate, P.ProductID, P.Name FROM Production.TransactionHistory T JOIN Production.Product P    ON T.ProductID = P.ProductID WHERE P.ProductID = 3;'; 

Below you can find a query to find similar queries with differnat query plans, in order to find the cost of each distinct query plan,we will use Xquery on the Query Plan Xml Column :

SELECT max([QueryText]) QueryText , max(SimilarQueries.query_plan.value('(//@StatementSubTreeCost)[1]','float')) QueryCost
FROM (SELECT QS1.*,ST.text AS QueryText,QP1.query_plan
      FROM sys.dm_exec_query_stats QS1
      CROSS APPLY sys.dm_exec_sql_text (QS1.sql_handle) ST
      CROSS APPLY sys.dm_exec_query_plan(QS1.plan_handle) QP1
      JOIN sys.dm_exec_query_stats QS2
         ON QS1.query_hash = QS2.query_hash
      WHERE QS1.query_plan_hash <> QS2.query_plan_hash ) as SimilarQueries
GROUP BY SimilarQueries.query_plan_hash
ORDER BY 1 

We can determine that the second query plan is more costly. it will be much nicer if we can get in the same result set the Xml Query Plan itself; this requires some TSQL juggling around, since the XML data type cannot be used in a group by or with an aggregation function.

SELECT QueryText ,QueryCost,QP.query_plan QueryPlan
FROM (select max(QueryText) QueryText ,max(SimilarQueries.query_plan.value('(//@StatementSubTreeCost)[1]','float')) QueryCost ,max(plan_handle) plan_handle
      FROM  (SELECT QS1.*,ST.text AS QueryText,QP1.query_plan
             FROM sys.dm_exec_query_stats QS1
             CROSS APPLY sys.dm_exec_sql_text (QS1.sql_handle) ST
             CROSS APPLY sys.dm_exec_query_plan(QS1.plan_handle) QP1
             JOIN sys.dm_exec_query_stats QS2
                on QS1.query_hash = QS2.query_hash
             WHERE where QS1.query_plan_hash <> QS2.query_plan_hash ) as SimilarQueries
     GROUP BY SimilarQueries.query_plan_hash) SimilarQueriesCost
CROSS APPLY sys.dm_exec_query_plan(plan_handle) QP
ORDER BY 1

In SQL 2008 Management Studio when we will click the Query Plan Xml Column you will immediately get the graphical representation of the query plan, this enables us to examine immediately the execution plan of the costly query plans.

Starting in Oracle 11.1, we have the option to gather statistics without publishing them to the optimizer. When using pending statistics we can allow the optimizer to use these statistics by setting the parameter OPTIMIZER_USE_PENDING_STATISTICS to true. After checking the new statistics we can publish or delete them.

SQL Plan Management (11.1)

SQL Plan Management allows the optimizer to maintain execution plan history for repeating SQL statements. Using this history, the optimizer can prevent plan changes for these SQL statements. The optimizer will save the new plan and will verify that the performance of the new plan is better than the old ones. After the verification, the optimizer can accept the plan and start using it.

Invisible Indexes (11.1)

Invisible indexes are regular indexes that are not used by the optimizer. We can create invisible indexes (or change indexes to be invisible) to verify how a new index or the deletion of an index will change the SQL plans. An index can be set to visible or invisible using the “create index” or “alter index” commands. To allow the optimizer to use invisible indexes, set the OPTIMIZER_USE_INVISIBLE_INDEXES parameter to true.

Real Application Testing (11.1)

Oracle Real Application Testing option contains two components, Database Replay and SQL Performance Analyzer. These features help us to identify performance issues before hardware and software changes.

• Database Replay: Database replay allows us to capture the real workload of the production system and replay it on a test environment. The test environment can have different hardware, Oracle version, parameters, etc. This way we can assess the impact of these changes on our production database.
• SQL Performance Analyzer (SPA): the SPA allows us to identify SQL performance changes between the production and test environments. Using SPA we run the same SQL statements on both environments and see the actual improvement or degradation of these statements in the new environment.

Instance Caging (11.2)

Instance caging in 11.2 allows us to limit the amount of CPUs the instance can use. To use instance caging, we set the CPU_COUNT parameter to the desired amount of CPUs. This feature allows us to have better load sharing when having several instances running on the same server.

Automatic Parallelism (11.2)

Automatic parallelism in 11.2 consists of three features:

• Automatic degree of parallelism: Oracle will decide which statements to run in parallel and the parallel degree
• Statement queuing: long statements that can’t get enough parallel slaves will not be executed in serial, but will be queued until they can get the desired parallel degree
• In memory parallel execution: enables the parallel slaves to use the buffer cache when accessing data blocks, instead of performing direct read from the physical disks.

To fully enable this feature the PARALLEL_DEGREE_POLICY parameter should be set to AUTO. When the parameter is set to LIMITED, only the automatic parallel degree is enabled, and only for queries that we set to run in parallel.

To entirely disable this feature and revert to pre 11.2 behavior, set the PARALLEL_DEGREE_POLICY to MANUAL.

In this log file you can find various messages such as: Database Startup and Shutdown, different ORA errors, log switches, pointers to trace files and dump files and more.

The Alert.log is the first place a DBA will go to look for errors in the database.
As many organizations monitor the Alert.log file for errors and exceptions it would have been nice if we could have entered our own errors and messages into the Alert.log.

Oracle gives us the option to insert a manual record to the Alert.log and/or to the trace files themselves.

The procedure kdswrt in dbms_system package allows us to write own messages in the alert log / trace files or both.
It receives two parameters:

-   A number that indicates where do we want to write our message:

• 1 – Writing to a TRACE file.
• 2 – Writing to the Alert.log file.
• 3 – Writing to both of them.

-   A text string (the message itself).

USAGE:

exec dbms_system.ksdwrt(2, 'ORA-9999: Procedure TEST has ended successfully.);

The entry in the Alert.log will look like the following:

Wed Sep 29 10:00:57 2010
Thread 1 advanced to log sequence 7615 (LGWR switch)
Current log# 1 seq# 7615 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG
Wed Sep 29 11:10:15 2010
ORA-9999: Procedure TEST has ended successfully.
Wed Sep 29 11:10:15 2010
Thread 1 advanced to log sequence 7616 (LGWR switch)
Current log# 2 seq# 7616 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
Wed Sep 29 10:00:57 2010
Thread 1 advanced to log sequence 7615 (LGWR switch)
Current log# 1 seq# 7615 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG

It is a very useful feature, as we can use it in our PL/SQL procedures inside the exception handling section or to indicate the procedure’s progression.
Moreover, it can be used inside Unix/Linux shell scripts – to insert Alert.log messages from various OS scripts.
To see how to run SQL statements from SQLPLUS inside bash scripts, visit our post: oracle-running-sqlplus-from-unix-bash-scripts

In addition, in Oracle 11g and beyond we are able to directly query the Alert.log file with an SQL statement via the table X$DBGALERTEXT.

For Example:

SELECT message_text FROM X$DBGALERTEXT WHERE rownum < 20;

One popular use of virtualization, is creating a MASTER image of one virtual machine and then copy it when necessary.

But, what do we do when we need an Oracle Database on this machine. How can we replicate the machine and work with the database.

Moreover, will the Database itself and the Database Control (Oracle Enterprise Manager) work on the new machine?

Below are the steps to configure the database and the Database control in the new machine.
The following steps were performed on Oracle Database 10g Release 2 (10.2.0.4) 64-bit, on CentOS 5 (64-bit) virtual machine :

Database:

• Change the hostname in the file $ORACLE_HOME/network/admin/listener.ora
  for example:

LISTENER =
   (DESCRIPTION_LIST =
    (DESCRIPTION =
     (ADDRESS = (PROTOCOL = TCP)(HOST = NEW_HOSTNAME)(PORT = 1521))
    )
   )

• Change the hostname in the file $ORACLE_HOME/network/admin/tnsnames.ora
  Please change the hostname in all the relevant entries.
  for example:

 ORCL1 =
   (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = NEW_HOSTNAME)(PORT = 1521))
     (CONNECT_DATA =
     (SERVER = DEDICATED)
     (SERVICE_NAME = orcl1)
    )
   )

Database Control:

Recreating the Database control repository is needed. without it, the Database Control won’t start.
In order to recreate the DB control run following commands:

• Dropping the current DB control’s settings.
  In the <NEW HOSTNAME> please make sure to write the new hostname.

$ emca -deconfig dbcontrol db -repos drop -ORACLE_HOSTNAME <NEW HOSTNAME> -SID <ORACLE_SID> -PORT <Listener's Port> -SYSMAN_PWD <SYSMAN password> -SYS_PWD <SYS password></pre>

Information in regards the different ‘emca’ attributes can be acquire by running ‘emca’ without any attribute from the CMD.

 $ emca -deconfig dbcontrol db -repos drop -ORACLE_HOSTNAME ORCLSERVER -SID orcl1 -PORT 1521 -SYSMAN_PWD **** -SYS_PWD ****

STARTED EMCA at Jun 17, 2010 7:54:31 PM EM Configuration Assistant, Version 11.2.0.0.2   Production Copyright (c) 2003, 2005, Oracle.  All rights reserved.
Do you wish to continue? [yes(Y)/no(N)]: y

Jun 17, 2010 7:54:49 PM oracle.sysman.emcp.EMConfig   perform
INFO: This operation is being logged at   /u01/app/oracle/cfgtoollogs/emca/orcl/emca_2010_06_17_19_54_31.log.

Jun 17, 2010 7:54:50 PM   oracle.sysman.emcp.EMDBPreConfig performDeconfiguration
WARNING: EM is not configured for this database. No   EM-specific actions can be performed.
Jun 17, 2010 7:54:50 PM   oracle.sysman.emcp.ParamsManager checkListenerStatusForDBControl WARNING: Error initializing SQL connection. SQL   operations cannot be performed

Jun 17, 2010 7:54:50 PM oracle.sysman.emcp.EMReposConfig   invoke INFO: Dropping the EM repository (this may take a   while) ...

Jun 17, 2010 7:54:50 PM   oracle.sysman.emcp.EMReposConfig invoke INFO: Repository successfully dropped Enterprise Manager configuration completed
successfully FINISHED EMCA at Jun 17, 2010 7:54:50 PM 

• Recreating the DB control’s repository.
  In the <NEW HOSTNAME> please make sure to write the new hostname.

$emca -config dbcontrol db -ORACLE_HOSTNAME <NEW HOSTNAME> -SID <ORACLE_SID> -PORT <Listener's  Port> -SYS_PWD <SYSMAN password> -SYSMAN_PWD <SYSMAN  password> -DBSNMP_PWD <DBSNMP password>

After this step the Database Control’s repository will be recreated and you will able to connect the Database control’s URL.

$ emca -config dbcontrol db -ORACLE_HOSTNAME ORCLSERVER -SID orcl1 -PORT 1521 -SYS_PWD **** -SYSMAN_PWD **** -DBSNMP_PWD ****
STARTED EMCA at Jun 17, 2010 8:04:27 PM

EM Configuration Assistant, Version 11.2.0.0.2   Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.
Enter the following information:
Email address for notifications (optional):
Outgoing Mail (SMTP) server for notifications (optional):
-----------------------------------------------------------------
You have specified the following settings

Database ORACLE_HOME ................   /u01/app/oracle/product/11.2.0/db_1

Local hostname ................ <HOSTNAME>

Listener ORACLE_HOME ................   /u01/app/oracle/product/11.2.0/db_1

Listener port number ................ 1521

Database SID ................ orcl1

Email address for notifications ...............

Outgoing Mail (SMTP) server for notifications   ...............

-----------------------------------------------------------------

Do you wish to continue? [yes(Y)/no(N)]: y

Jun 17, 2010 8:04:44 PM oracle.sysman.emcp.EMConfig   perform
INFO: This operation is being logged at   /u01/app/oracle/cfgtoollogs/emca/orcl2/emca_2010_06_17_20_04_27.log          .

Jun 17, 2010 8:04:45 PM   oracle.sysman.emcp.EMReposConfig uploadConfigDataToRepository
INFO: Uploading configuration data to EM repository   (this may take a while) ...

Jun 17, 2010 8:05:43 PM   oracle.sysman.emcp.EMReposConfig invoke
INFO: Uploaded configuration data successfully

Jun 17, 2010 8:05:44 PM   oracle.sysman.emcp.util.DBControlUtil configureSoftwareLib
INFO: Software library is already configured.

Jun 17, 2010 8:05:44 PM   oracle.sysman.emcp.util.DBControlUtil configureSoftwareLib
INFO:    EM_SWLIB_STAGE_LOC (value) will be ignored.

Jun 17, 2010 8:05:44 PM   oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
INFO: Deploying   Provisioning archives ...

Jun 17, 2010 8:06:09 PM   oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
INFO: Provisioning archives deployed successfully.

Jun 17, 2010 8:06:09 PM   oracle.sysman.emcp.util.DBControlUtil secureDBConsole
INFO: Securing Database Control (this may take a   while) ...

Jun 17, 2010 8:06:34 PM   oracle.sysman.emcp.util.DBControlUtil secureDBConsole
INFO: Database Control secured successfully.

Jun 17, 2010 8:06:34 PM   oracle.sysman.emcp.util.DBControlUtil startOMS
INFO: Starting Database Control (this may take a   while) ...

Jun 17, 2010 8:07:28 PM oracle.sysman.emcp.EMDBPostConfig   performConfiguration
INFO: Database Control started successfully

Jun 17, 2010 8:07:28 PM   oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: >>>>>>>>>>>   The Database Control URL is https://HOSTNAME:1158/em   <<<<<<<<<<<

Jun 17, 2010 8:07:36 PM   oracle.sysman.emcp.EMDBPostConfig invoke
WARNING:
************************  WARNING    ************************
Management Repository has been placed in secure mode   wherein Enterprise Manager data will be encrypted.  The encryption key has been placed in the   file: /u01/app/oracle/product/11.2.0/db_1/HOSTNAME_orcl2/sysman/config/emkey.ora.   Please ensure this file is backed up as   the encrypted data will become unusable if this file is lost.
***********************************************************

Enterprise Manager configuration completed   successfully

FINISHED EMCA at Jun 17, 2010 8:07:36 PM

Known Issues:

In case no new hostname is provided in the attribute ‘–ORACLE_HOSTNAME’ of the emca command, the utility will use the old hostname and the drop/create operation will fail.

For more information in regards to Drop, Create And Recreate DB Control, please refer to Metalink note: 278100.1

A server process is waiting on “db file sequential read” wait event after it performs a single block I/O operation and it is waiting for the operating system to complete it.

A single block I/O operation occurs when a server process request a single block for the operating system. This happens during operations such as index unique or range scans, table access by rowid, etc.

Seeing this wait event in the top wait events is expected and doesn’t mean that something is wrong. Remember, users are working and reading indexes or table blocks from the disk is common. However, if we see that this event is very high and consuming unreasonable time, we need to check our SQL statement, they might need tuning, or might have unnecessary hints such as the “index” hint.

To read about analyzing wait events in an AWR report, see my post analyzing oracle awr reports – top 5 events.

A server process is waiting on “db file scattered read” wait event after it performs a multiblock I/O operation and it is waiting for the operating system to complete it.

A multiblock I/O operation occurs when the server process asks for a “chunk” of blocks and not for a single block. The amount of blocks in the “chunk” is determined by the DB_FILE_MULTIBLOCK_READ_COUNT initialization parameter. For example, if the database block size is 8k and DB_FILE_MULTIBLOCK_READ_COUNT is 8, a single multiblock I/O operation will read 8 blocks, which is 64KB of data. The maximum size of a multiblock I/O operation is determined by the operating system and storage.

When talking about performance, there are several things we need to remember:

• A server process can perform multiblock I/O operations only in certain cases like full table scans and fast full index scans. It is important to remember that multiblock I/O and DB_FILE_MULTIBLOCK_READ_COUNT are irrelevant to other operations such as index  range/unique scans.
• Setting the DB_FILE_MULTIBLOCK_READ_COUNT to a high value will result in less I/O operations (as long as it is not exceeding the operating system and storage limitation).
• Setting the DB_FILE_MULTIBLOCK_READ_COUNT to a high value can also result in unwanted full table scans, since a higher value lowers the optimizer cost of full table scans.
• Starting in 10gR2, Oracle will determine the best value for the DB_FILE_MULTIBLOCK_READ_COUNT parameter if it is not set. If the parameter is set, Oracle will not automatically set its value.

To read about analyzing wait events in an AWR report, see my post analyzing oracle awr reports – top 5 events.

From Oracle documentation:
“Wait events are statistics that are incremented by a server process or thread to indicate that it had to wait for an event to complete before being able to continue processing.”

For example, wait events can be related to I/O, locks, memory allocation, etc.

The top events tell us what the server processes wait for the most. Eliminating these wait events will definately reduce execution time, since server processes will not have to wait this time for other operations to complete.

There are many wait event in Oracle databases, this is a list of some important and common wait events:

• buffer busy waits
• free buffer waits
• db file scattered read
• db file sequential read
• enqueue waits
• log buffer space
• log file sync

To identify a performance problem we will check the time spent on each wait event and the average wait time. These numbers can be very different for different wait events, I/O wait events will probably have a low average, while waiting on locking related wait events can take a long time. Don’t forget to compare the wait time to the AWR report time period, waiting on I/O for an hour may be reasonable if the AWR report was generated on 6 hours period, but may indicate a problem on a 10 minutes report (the waiting time can exceed the total report time, since it is cumulative for all server processes).

The best way to find performance problems is to compare the wait events and the time spent on them to an AWR report from a time period in which the database worked fine. So try to save reports as a baseline for future reference.

In the next posts we’ll go deeper into analyzing the rest of the AWR report.