Oracle Identity Manager is the leading identity management solution for the past few years.
After Oracle acquired SUN who have it’s own identity management solution a big question was what Oracle is going to do with two  Identity management solutions. Few month ago Oracle announced Oracle Identity Manager 11g Release 2 who is a hybrid between Oracle and Sun identity management solution.

This is the Third in a series of tutorial videos that will show you how to install and configure Oracle Identity Manager 11gR2.

Oracle Identity Manager is the leading identity management solution for the past few years.
After Oracle acquired SUN who have it’s own identity management solution a big question was what Oracle is going to do with two  Identity management solutions. Few month ago Oracle announced Oracle Identity Manager 11g Release 2 who is a hybrid between Oracle and Sun identity management solution.

This is the second in a series of tutorial videos that will show you how to install and configure Oracle Identity Manager 11gR2.

After we have prepared the database for our OIM (Oracle Identity Manager) installation we can now install :

• Java

• Weblogic

• Oracle Identity Manager

• SOA

Oracle Identity Manager is the leading identity management solution for the past few years.
After Oracle acquired SUN who have it’s own identity management solution a big question was what Oracle is going to do with two  Identity management solutions. Few month ago Oracle announced Oracle Identity Manager 11g Release 2 who is a hybrid between Oracle and Sun identity management solution.

This is the first in a series of tutorial videos that will show you how to install and configure Oracle Identity Manager 11gR2.

In order to prevent sensitive data  from reaching non production environments all of the sensitive data should be masked  before the copied environment is accessible.

JumbleDB is a simple to use yet very powerful and complete data masking suite.  JumbleDB is based on a unique, 3-tier approach:

1. Detect -> Automatically locate your sensitive data
2. Protect -> Mask sensitive data using JumbleDB powerful masking engine.
3. Alert -> Scan for sensitive data that have migrated into your already masked environments.

JumbleDB unique data masking project approach reduce total project cost buy simplifying masking process.

Lets see how it works in the following video :

learn more about jumbleDB.

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;