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

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.

1. High concurrency of active sessions
2. Queries using a lot of disk time such as full table scans
3. Long duration locks on rows
4. Hardware failure such as disks defect

Another reason could be because there is a very CPU intensive query that is effecting the performance of the entire database.

This post will demonstrate how to determine which process is taking the most CPU in the system and how to retrieve the SQL statement it is currently running in the database.

** This post applies to Unix/Linux and Oracle 10g, 11g

In order to reach are goal we have to do the following things:

1. Determine which process is consuming the most CPU in the system – we can use the TOP Linux/Unix command.
2. Finding out the query this process is running – we can prepare a script in advance to help us.

Let’s begin with the preparations – preparing the script that will display the actual activity of the session within the database. The script will be a shell script that incorporates an SQL script within (you can find out more on this topic here oracle-running-sqlplus-from-unix-bash-scripts/). The script receives an argument which is the Linux/Unix process ID of the process we want to examine. I usually put such scripts in a folder that is part of my $PATH such as ~/bin (or /home/oracle/bin).

Create a run-able script in Linux:

touch /home/oracle/bin/oraproc
chmod +x /home/oracle/bin/oraproc
vi /home/oracle/bin/oraproc

In this file write the a copy of the following snippet

#!/bin/bash
if [ $# -ne 1 ];then
	echo "Usage: oraproc <Unix Process ID>"
	exit
fi

unix_pid=$1

sqlplus -s -l / as sysdba <<EOF
set head off feed off time off timing off
set serveroutput on lines 10000
DECLARE
	stmt VARCHAR2(32000) := '';
	report BOOLEAN := TRUE;
	SPACECHAR CONSTANT CHAR(1) := ' ';
	TABLEN CONSTANT NUMBER(2) := 10;
BEGIN
	dbms_output.enable(99999);
	FOR rec IN (
		SELECT  s.sid, s.username, s.osuser, s.machine,
				nvl(s.module, s.program) prog, s.event, t.sql_text
		FROM    v\$process p
		JOIN    v\$session s ON s.paddr = p.addr
		LEFT JOIN v\$sqltext_with_newlines t
				ON	t.address = s.sql_address
				AND	t.hash_value = s.sql_hash_value
		WHERE   p.spid = ${unix_pid}
		ORDER BY t.piece ) LOOP

		stmt := stmt || rec.SQL_TEXT;
		IF report THEN
			DBMS_OUTPUT.PUT_LINE(RPAD('SID:', TABLEN, spacechar) || rec.sid);
			DBMS_OUTPUT.PUT_LINE(RPAD('USERNAME:', TABLEN, spacechar) || rec.username);
			DBMS_OUTPUT.PUT_LINE(RPAD('OSUSER:', TABLEN, spacechar) || rec.osuser);
			DBMS_OUTPUT.PUT_LINE(RPAD('MACHINE:', TABLEN, spacechar) || rec.machine);
			DBMS_OUTPUT.PUT_LINE(RPAD('PROGRAM:', TABLEN, spacechar) || rec.prog);
			DBMS_OUTPUT.PUT_LINE(RPAD('EVENT:', TABLEN, spacechar) || rec.event);
			DBMS_OUTPUT.PUT_LINE('---------------------------------------');
			report := FALSE;
		END IF;
	END LOOP;
	IF NOT report THEN
		IF LENGTH(stmt) > 0 THEN
			DBMS_OUTPUT.PUT_LINE(stmt);
		ELSE
			DBMS_OUTPUT.PUT_LINE('No current running statement');
		END IF;
	ELSE
		DBMS_OUTPUT.PUT_LINE('Unix PID ${unix_pid} not found');
	END IF;
END;
/
EXIT
EOF

Now let’s see this script at work. I have written a PL/SQL anonymous block that uses a lot of CPU. It looks like this:

declare
	start_date date;
	end_time date;
	dum number;
begin
	start_date := sysdate;
	end_time := sysdate + 1/24/60; -- minute
	while end_time > sysdate loop
		dum := 0;
		for i in 1..10000 loop
			dum := dum + 1;
		end loop;
	end loop;
	dbms_output.put_line (start_date || ' ' || end_time);
end;
/

This script runs for a minute in a loop so it uses CPU very intensively. I run it from one session and run the TOP command from another session like this:

Notice that we see the process ID 9530 takes 98% CPU time.

We use this PID as an argument to our script by calling it from shell like this:

$ oraproc 9530

This will display the actual statement this process is currently running in the database (with some additional info I like to add). It looks like this:

$ oraproc 9503
SID:      1
USERNAME: DEMO
OSUSER:   oracle
MACHINE:  ora2
PROGRAM:  SQL Developer
EVENT:    SQL*Net message from client
---------------------------------------
declare
	start_date date;
	end_time date;
	dum number;
begin
	start_date := sysdate;
	end_time := sysdate + 1/24/60; -- minute
	while end_time > sysdate loop
		dum := 0;
		for i in 1..10000 loop
			dum := dum + 1;
		end loop;
	end loop;
	dbms_output.put_line (start_date || ' ' || end_time);
end;

Good luck.

1. Developers are not granted the alter system / alter user privileges.
2. When creating users for developers the DBA can add a prefix to the name (DEV_USER1, DEV_JOHN, DEV_RACHEL …).
3. Developers do not share the same username.
4. Multiple developers can run from the same client using different usernames to login to Oracle.
5. A developer can run from multiple client machines – in this case he/she will want to kill sessions opened only from one specific client machine

Tested on:

1. Oracle 10g
2. Oracle 10g RAC
3. Oracle 11g
4. Oracle 11g RAC

Now, I will display the setup code, followed by an explanation: Create owner for the procedure (schema)

create user killer identified by killer;
grant alter system to killer;
grant select on v_$session, gv_$session to killer;
alter user killer account lock;

Create the procedure

create or replace PROCEDURE killer.KILL_MY_CLIENTS AUTHID DEFINER AS
   job_no number;
   user_prefix varchar(20);
   domain_name varchar(20);
   num_of_kills number := 0;
   BACKSLASH constant char(1) := chr(92);
begin
   user_prefix := 'DEV';       -- All my developer username prefixed with DEV
                               -- (DEV_USER1, DEV_USER2, DEV_MIKE, DEV_JOHN ...)
   domain_name := 'WORKGROUP'; -- We work in a workgroup.
                               -- Once we work in a windows domain this variable should
                               -- hold the domain name

   for REC in
       (SELECT SID, SERIAL#, INST_ID, MODULE,
               SYS_CONTEXT('USERENV', 'INSTANCE') MY_INST_ID
        from gv$session s
        where s.username like user_prefix || '%'                  -- precaution
          and s.username = sys_context('USERENV', 'SESSION_USER') -- only my username
          and not (S.SID = SYS_CONTEXT('USERENV', 'SID')          -- excluding my session
          and INST_ID = SYS_CONTEXT('USERENV', 'INSTANCE'))
          and replace(upper(machine), domain_name || BACKSLASH, '')     -- my machine
                 = replace(upper(sys_context('USERENV', 'HOST')), domain_name || BACKSLASH, '')
          and s.module not in ('SQL*Plus', 'SQL Developer')       -- not sqlplus
                                                                  -- nor sql developer
          and s.module not like 'sqlplus@%'
          and S.LOGON_TIME < sysdate-(1/24/60/60)                 -- logged-on more
                                                                  -- than a second
        ORDER BY inst_id asc
       ) LOOP
      if rec.inst_id = rec.my_inst_id then
         ---------------------------------------------------------------------------
         -- kill local sessions immediately
         ---------------------------------------------------------------------------
         dbms_output.put('LOCAL SID ' || rec.sid || '(' || rec.module || ')');
         execute immediate 'alter system kill session ''' || rec.sid || ', ' ||
                            rec.serial# || '''' ;
         dbms_output.put_line('. killed locally ' || job_no);
      ELSE
         ---------------------------------------------------------------------------
         -- kill remote sessions (for RAC) as a job
         ---------------------------------------------------------------------------
         DBMS_OUTPUT.PUT('REMOTE SID ' || REC.SID || ' on instance ' || REC.INST_ID  ||
                         '(' || rec.module || ')');
         DBMS_JOB.SUBMIT (
                 job => job_no,
                 what => 'execute immediate ''alter system kill session ''''' || rec.sid ||', ' ||
                          rec.serial# || ''''''';',
                 INSTANCE => rec.inst_id);
         dbms_output.put_line('. killed with job ' || job_no);
         COMMIT;
      end if;
      num_of_kills := num_of_kills + 1;
   end loop;
   dbms_output.put_line ('number of killed sessions: ' || num_of_kills);
end kill_my_clients;

Make procedure available to all

create public synonym kill_my_clients for killer.kill_my_clients;
grant execute on killer.kill_my_clients to public;
alter user killer account lock;

Use it: login as the developer from client machine to any application that can run statements like SQL*Plus

exec kill_my_clients

Explanation: The commands in the first section create a user called “killer”. This user is the owner of the procedure described in the next section. Notice that this user is very powerful because it can kill any user with the permission “alter system”. That is why we must limit access to it so it is locked. The grants on v_$session and gv_$session must be done by sys or other user with admin options on these views. The second section is the procedure itself. It should be compiled under “killer” (as the code demonstrates). Here is an explanation of this procedure:

1. Identify all sessions running from the developer’s machine from his/hers username except for the session running this query in the current node and remote RAC nodes.
   1. If the session is on the same instance of the current connection – kill it immediately.
   2. If the session is on a different RAC node – kill it by submitting a job on that node.

   There are 2 variables that I usually change when I deploy this procedure in an environment:

   • USER_PREFIX – I try naming all the developer users with a prefix such as DEV_USER1, DEV_USER2, DEV_MIKE, DEV_JOHN … I use this prefix as a measure of precaution – I don’t want my procedure to kill any users not beginning with this prefix. This way if my developer is running this procedure from user sys or system by mistake it will do no harm.
   • DOMAIN_NAME – when working with windows clients sometimes the application is prefixed with the domain name (such as SQL Developer) and sometimes not (such as SQL*Plus). This variable will become crucial to identifying sessions opened from the developer’s machine.
2. Execute kill command on the local instance.
3. Execute kill command on all remote instances of RAC by submitting jobs with instance affinity.

Another factor I take into account is that I don’t want to kill connections from SQL*Plus or from SQL Developer. If you are working with other programs such as PL/SQL Developer or Toad you might want to include them in the where clause as well.

The third section demonstrates how to use this mechanism: You just have to login as the developer from the client machine to any application that can run statements like SQL*Plus and execute the procedure (you do not have to use the owner’s name in the call because you have declared a public synonym for it).

Enjoy 

• Pro-actively safeguard application data stored in the Oracle database—Restrict access by unauthorized database users – even privileged users – by using powerful access controls built into the Oracle database.
• Address regulatory requirements—Implement separation-of-duty and other real-time preventive controls.
• Restrict ad-hoc access to application data— Prevent application-bypass with multi-factor policies that are enforced in the database for high security and performance.
• Deploy with confidence—Use certified default policies for Oracle E-Business Suite, Oracle PeopleSoft, and Oracle Siebel CRM applications.

Such fragmentation reduces the efficiency of scaning opreations like full table scans of index scans. Before oracle 10g one should have used “MOVE TABLE” in order to solve this problem.

Oracle 10g inturduced us with new online feature, shrink table.

In order to use the shrink command we need to enable row movment:

alter table <Table_Name> enable row movement;
--Then we can use shrink table command:
alter table <Table_Name> shrink space;

Shrink opration does the following :

Segment data is compacted
High-water mark (HWM) is adjusted to an appropriate location

SELECT *
FROM (
       SELECT a.*, rownum rnum
       FROM ( /* PUT YOUR MAIN QUERY */) a
       WHERE rownum <= :UPPERBUOND
     )
WHERE rnum >= :LOWERBOUND

There are two ways to handle this problem:

1. There is a system privilege called “connect through”. Let’s say we have the user called “master” and we wish to connect as “app”. We will grant the privilege using the following syntax:

Alter user app grant connect through master;

After granting this privilege, the user “master” can connect as the user “app” without the password of “app” user.

To connect as “app” user, use the following syntax:

sqlplus master[app]/pwd@db

Note that the password given is the password of “master” user. But in this sqlplus session we are connected as “app” user.

2. If we can allow ourselves to change the password, but don’t want to change it permanently, there is a way to change the password back.

The DBA_USERS table contains the PASSWORD column. This column contains the encrypted password of the user.
Follow these steps to change the user’s password:

1. Get the encrypted password of the user from DBA_USERS table and save it.
2. Change the password by using the “alter user <user> identified by <pwd>” command.

Perform the following step to change the password back:

1. Use the “alter user <user> identified by values <encrypted_password>” command.

Use the encrypted password you have and pay attention to the “values” keyword in the command, it specifies that the password given in the command is already encrypted.

Transaction log files are copied from the production SQL server, and then restoring them onto a standby server. But this is not all. The key feature of log shipping is that is will automatically backup transaction logs throughout the day (for whatever interval you specify) and automatically restore them on the standby server. This in effect keeps the two SQL Servers in “synch”. Should the production server fail, all you have to do is point the users to the new server, and you are all set. Well, its not really that easy, but it comes close if you put enough effort into your log shipping setup.