Create and manage contexts

September 28, 2015, 6:07 pm

≫ Next: ORA-55626: Cannot remove the Flashback Archive's primary tablespace

≪ Previous: Implement fine-grained access control

What is an Application Context?

An application context is a set of name-value pairs that Oracle Database stores in memory. The application context has a label called a namespace, for example, empno_ctx for an application context that retrieves employee IDs. Inside the context are the name-value pairs (an associative array): the name points to a location in memory that holds the value. An application can use the application context to access session information about a user, such as the user ID or other user-specific information, or a client ID, and then securely pass this data to the database. You can then use this information to either permit or prevent the user from accessing data through the application. You can use application contexts to authenticate both database and nondatabase users

The components of the name-value pair are as follows:

Name. Refers to the name of the attribute set that is associated with the value. For example, if the empno_ctx application context retrieves an employee ID from the HR.EMPLOYEES table, it could have a name such as employee_id.
Value. Refers to a value set by the attribute. For example, for the empno_ctx application context, if you wanted to retrieve an employee ID from the HR.EMPLOYEES table, you could create a value called emp_id that sets the value for this ID.

Oracle Database stores the application context values in a secure data cache available in the User Global Area (UGA) or the System (sometimes called "Shared") Global Area (SGA)

Types of Application Contexts

There are three general categories of application contexts:

Database session-based application contexts. This type retrieves data that is stored in the database user session (that is, the UGA) cache. There are three categories of database session-based application contexts:

Initialized locally. Initializes the application context locally, to the session of the user.
Initialized externally. Initializes the application context from an Oracle Call Interface (OCI) application, a job queue process, or a connected user database link.
Initialized globally. Uses attributes and values from a centralized location, such as an LDAP directory.

Global application contexts. This type retrieves data that is stored in the System Global Area (SGA) so that it can be used for applications that use a sessionless model, such as middle-tier applications in a three-tiered architecture. A global application context is useful if the session context must be shared across sessions, for example, through connection pool implementations.
Client session-based application contexts. This type uses Oracle Call Interface functions on the client side to set the user session data, and then to perform the necessary security checks to restrict user access.

Database Session-Based Application Contexts

If you must retrieve session information for database users, use a database session-based application context. This type of application context uses a PL/SQL procedure within Oracle Database to retrieve, set, and secure the data it manages

The database session-based application context is managed entirely within Oracle Database. Oracle Database sets the values, and then when the user exits the session, automatically clears the application context values stored in cache. If the user connection ends abnormally, for example, during a power failure, then the PMON background process cleans up the application context data.You do not need to explicitly clear the application context from cache.

Retrieve session information. To retrieve the user session information, you can use the SYS_CONTEXT SQL function. The SYS_CONTEXT function returns the value of the parameter associated with the context namespace. You can use this function in both SQL and PL/SQL statements. Typically, you will use the built-in USERENV namespace to retrieve the session information of a user.

Set the name-value attributes of the application context you created with CREATE CONTEXT. You can use the DBMS_SESSION.SET_CONTEXT procedure to set the name-value attributes of the application context. The name-value attributes can hold information such as the user ID, IP address, authentication mode, the name of the application, and so on. The values of the attributes you set remain either until you reset them, or until the user ends the session. Note the following:

If the value of the parameter in the namespace already has been set, then SET_CONTEXT overwrites this value.
Be aware that any changes in the context value are reflected immediately and subsequent calls to access the value through the SYS_CONTEXT function will return the most recent value

Be executed by users. After you create the package, the user will need to execute the package when he or she logs on. You can create a logon trigger to execute the package automatically when the user logs on, or you can embed this functionality in your applications. Remember that the application context session values are cleared automatically when the user ends the session, so you do not need to manually remove the session data.

Using SYS_CONTEXT with Database Links

When SQL statements within a user session involve database links, then Oracle Database runs the SYS_CONTEXT SQL function at the host computer of the database link, and then captures the context information there (at the host computer).

If remote PL/SQL procedure calls are run on a database link, then Oracle Database runs any SYS_CONTEXT function inside such a procedure at the destination database of the link. In this case, only externally initialized application contexts are available at the database link destination site. For security reasons, Oracle Database propagates only the externally initialized application context information to the destination site from the initiating database link site

Using DBMS_SESSION.SET_CONTEXT to Set Session Information

DBMS_SESSION.SET_CONTEXT (
  namespace VARCHAR2,
  attribute VARCHAR2,
  value     VARCHAR2,
  username VARCHAR2,
  client_id VARCHAR2);

Demo:

SHAIKDB>select * from dba_context where schema='LOB';

NAMESPACE SCHEMA PACKAGE TYPE

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

EMP LOB EMP_PKG ACCESSED LOCALLY

SHAIKDB>show user

USER is "LOB"

SHAIKDB>drop context emp;

Context dropped.

SHAIKDB>create context emp using emp_pkg;

Context created.

SHAIKDB>create package emp_pkg is

procedure emp_proc;

end;

Package created.

SHAIKDB>create or replace package body emp_pkg is

procedure emp_proc is

id hr.employees.employee_id%type;

lname hr.employees.last_name%type;

income hr.employees.salary%type;

social hr.employees.ssn%type;

begin

select employee_id,last_name,salary,ssn into id,lname,income,social from

hr.employees where first_name=sys_context('USERENV','SESSION_USER');

dbms_session.set_context('emp','employee_id',id);

dbms_session.set_context('emp','fist_name',sys_context('USERENV','SESSION_USER'));

dbms_session.set_context('emp','last_name',lname);

dbms_session.set_context('emp','salary',income);

dbms_session.set_context('emp','ssn',social);

exception

when no_data_found then null;

end;

Package body created.

Insert data into the hr table for user LOB & PFAY:

SHAIKDB>/

Enter value for id: 223

Enter value for fname: LOB

Enter value for lname: LOB

Enter value for name: LOB

Enter value for phone: 5141234567

old 1: insert into hr.employees values (&id,'&fname','&lname','&NAME','&phone',sysdate,'AD_VP',50000,null,null,100,null)

new 1: insert into hr.employees values (223,'LOB','LOB','LOB','5141234567',sysdate,'AD_VP',50000,null,null,100,null)

1 row created.

SHAIKDB>create trigger log_trigger after logon on database

begin

lob.emp_pkg.emp_proc;

end;

Trigger created.

[oracle@collabn1 ~]$ sqlplus pfay/pfay

SQL*Plus: Release 11.2.0.1.0 Production on Mon Sep 28 19:50:08 2015

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, Real Application Clusters, OLAP, Data Mining

and Real Application Testing options

SHAIKDB>select sys_context('USERENV','SESSION_USER') from dual;

SYS_CONTEXT('USERENV','SESSION_USER')

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

PFAY

SHAIKDB>select sys_context('emp','employee_id') from dual;

SYS_CONTEXT('EMP','EMPLOYEE_ID')

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

222

SHAIKDB>select sys_context('emp','first_name') from dual;

SYS_CONTEXT('EMP','FIRST_NAME')

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

PFAY

SHAIKDB>select sys_context('emp','last_name') from dual;

SYS_CONTEXT('EMP','LAST_NAME')

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

PFAY_LAST

SHAIKDB>select sys_context('emp','salary') from dual;

SYS_CONTEXT('EMP','SALARY')

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

50000

SHAIKDB>select sys_context('emp','ssn') from dual;

SYS_CONTEXT('EMP','SSN')

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

SHAIKDB>select sys_context('USERENV','SESSION_USER') from dual;

SYS_CONTEXT('USERENV','SESSION_USER')

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

LOB

Let’s create a trigger to test the context values:

Demo2:

You cannot set the context manually it has to set via package:

SHAIKDB>grant create trigger,create procedure,create any context,create session to pfay;

Grant succeeded.

SHAIKDB>exec dbms_session.set_context('emp1','id',1000);

BEGIN dbms_session.set_context('emp1','id',1000); END;

ERROR at line 1:

ORA-01031: insufficient privileges

ORA-06512: at "SYS.DBMS_SESSION", line 101

ORA-06512: at line 1

SHAIKDB>create context test1 using test_pkg;

Context created.

SHAIKDB>create package test_pkg is

2 procedure test_proc;

3 end;

4 /

Package created.

SHAIKDB>create or replace package body test_pkg is

2 procedure test_proc is

3 begin

4 dbms_session.set_context('test1','id',1000);

5 end;

6 end;

7 /

Package body created.

SHAIKDB>create trigger test1_trigger after logon on schema

2 begin

3 pfay.test_pkg.test_proc;

4 end;

5 /

Trigger created.

Predefined Parameters of Namespace USERENV

Parameter	Return Value
ACTION	Identifies the position in the module (application name) and is set through the DBMS_APPLICATION_INFO package or OCI.
AUDITED_CURSORID	Returns the cursor ID of the SQL that triggered the audit. This parameter is not valid in a fine-grained auditing environment. If you specify it in such an environment, then Oracle Database always returns NULL.
AUTHENTICATED_IDENTITY	Returns the identity used in authentication. In the list that follows, the type of user is followed by the value returned: Kerberos-authenticated enterprise user: kerberos principal name Kerberos-authenticated external user : kerberos principal name; same as the schema name SSL-authenticated enterprise user: the DN in the user's PKI certificate SSL-authenticated external user: the DN in the user's PKI certificate Password-authenticated enterprise user: nickname; same as the login name Password-authenticated database user: the database username; same as the schema name OS-authenticated external user: the external operating system user name Radius/DCE-authenticated external user: the schema name Proxy with DN : Oracle Internet Directory DN of the client Proxy with certificate: certificate DN of the client Proxy with username: database user name if client is a local database user; nickname if client is an enterprise user. SYSDBA/SYSOPER using Password File: login name SYSDBA/SYSOPER using OS authentication: operating system user name
AUTHENTICATION_DATA	Data being used to authenticate the login user. For X.503 certificate authenticated sessions, this field returns the context of the certificate in HEX2 format. Note: You can change the return value of the AUTHENTICATION_DATA attribute using the length parameter of the syntax. Values of up to 4000 are accepted. This is the only attribute of USERENV for which Oracle Database implements such a change.
AUTHENTICATION_METHOD	Returns the method of authentication. In the list that follows, the type of user is followed by the method returned: Password-authenticated enterprise user, local database user, or SYSDBA/SYSOPER using Password File; proxy with username using password: PASSWORD Kerberos-authenticated enterprise or external user: KERBEROS SSL-authenticated enterprise or external user: SSL Radius-authenticated external user: RADIUS OS-authenticated external user or SYSDBA/SYSOPER: OS DCE-authenticated external user: DCE Proxy with certificate, DN, or username without using password: NONE Background process (job queue slave process): JOB You can use IDENTIFICATION_TYPE to distinguish between external and enterprise users when the authentication method is Password, Kerberos, or SSL.
BG_JOB_ID	Job ID of the current session if it was established by an Oracle Database background process. Null if the session was not established by a background process.
CLIENT_IDENTIFIER	Returns an identifier that is set by the application through the DBMS_SESSION.SET_IDENTIFIER procedure, the OCI attribute OCI_ATTR_CLIENT_IDENTIFIER, or the Java class Oracle.jdbc.OracleConnection.setClientIdentifier. This attribute is used by various database components to identify lightweight application users who authenticate as the same database user.
CLIENT_INFO	Returns up to 64 bytes of user session information that can be stored by an application using the DBMS_APPLICATION_INFO package.
CURRENT_BIND	The bind variables for fine-grained auditing.
CURRENT_EDITION_ID	The identifier of the current edition.
CURRENT_EDITION_NAME	The name of the current edition.
CURRENT_SCHEMA	The name of the currently active default schema. This value may change during the duration of a session through use of an ALTER SESSION SET CURRENT_SCHEMA statement. This may also change during the duration of a session to reflect the owner of any active definer's rights object. When used directly in the body of a view definition, this returns the default schema used when executing the cursor that is using the view; it does not respect views used in the cursor as being definer's rights. Note: Oracle recommends against issuing the SQL statement ALTER SESSION SET CURRENT_SCHEMA from within a stored PL/SQL unit.
CURRENT_SCHEMAID	Identifier of the currently active default schema.
CURRENT_SQL CURRENT_SQLn	CURRENT_SQL returns the first 4K bytes of the current SQL that triggered the fine-grained auditing event. The CURRENT_SQLn attributes return subsequent 4K-byte increments, where n can be an integer from 1 to 7, inclusive. CURRENT_SQL1 returns bytes 4K to 8K; CURRENT_SQL2 returns bytes 8K to 12K, and so forth. You can specify these attributes only inside the event handler for the fine-grained auditing feature.
CURRENT_SQL_LENGTH	The length of the current SQL statement that triggers fine-grained audit or row-level security (RLS) policy functions or event handlers. Valid only inside the function or event handler.
CURRENT_USER	The name of the database user whose privileges are currently active. This may change during the duration of a session to reflect the owner of any active definer's rights object. When no definer's rights object is active, CURRENT_USER returns the same value as SESSION_USER. When used directly in the body of a view definition, this returns the user that is executing the cursor that is using the view; it does not respect views used in the cursor as being definer's rights.
CURRENT_USERID	The identifier of the database user whose privileges are currently active.
DATABASE_ROLE	The database role using the SYS_CONTEXT function with the USERENV namespace. The role is one of the following: PRIMARY, PHYSICAL STANDBY, LOGICAL STANDBY, SNAPSHOT STANDBY.
DB_DOMAIN	Domain of the database as specified in the DB_DOMAIN initialization parameter.
DB_NAME	Name of the database as specified in the DB_NAME initialization parameter.
DB_UNIQUE_NAME	Name of the database as specified in the DB_UNIQUE_NAME initialization parameter.
ENTRYID	The current audit entry number. The audit entryid sequence is shared between fine-grained audit records and regular audit records. You cannot use this attribute in distributed SQL statements. The correct auditing entry identifier can be seen only through an audit handler for standard or fine-grained audit.
ENTERPRISE_IDENTITY	Returns the user's enterprise-wide identity: For enterprise users: the Oracle Internet Directory DN. For external users: the external identity (Kerberos principal name, Radius and DCE schema names, OS user name, Certificate DN). For local users and SYSDBA/SYSOPER logins: NULL. The value of the attribute differs by proxy method: For a proxy with DN: the Oracle Internet Directory DN of the client For a proxy with certificate: the certificate DN of the client for external users; the Oracle Internet Directory DN for global users For a proxy with username: the Oracle Internet Directory DN if the client is an enterprise users; NULL if the client is a local database user.
FG_JOB_ID	Job ID of the current session if it was established by a client foreground process. Null if the session was not established by a foreground process.
GLOBAL_CONTEXT_MEMORY	Returns the number being used in the System Global Area by the globally accessed context.
GLOBAL_UID	Returns the global user ID from Oracle Internet Directory for Enterprise User Security (EUS) logins; returns null for all other logins.
HOST	Name of the host machine from which the client has connected.
IDENTIFICATION_TYPE	Returns the way the user's schema was created in the database. Specifically, it reflects the IDENTIFIED clause in the CREATE/ALTER USER syntax. In the list that follows, the syntax used during schema creation is followed by the identification type returned: IDENTIFIED BY password: LOCAL IDENTIFIED EXTERNALLY: EXTERNAL IDENTIFIED GLOBALLY: GLOBAL SHARED IDENTIFIED GLOBALLY AS DN: GLOBAL PRIVATE
INSTANCE	The instance identification number of the current instance.
INSTANCE_NAME	The name of the instance.
IP_ADDRESS	IP address of the machine from which the client is connected. If the client and server are on the same machine and the connection uses IPv6 addressing, then ::1 is returned.
ISDBA	Returns TRUE if the user has been authenticated as having DBA privileges either through the operating system or through a password file.
LANG	The abbreviated name for the language, a shorter form than the existing 'LANGUAGE' parameter.
LANGUAGE	The language and territory currently used by your session, along with the database character set, in this form: language_territory.characterset
MODULE	The application name (module) set through the DBMS_APPLICATION_INFO package or OCI.
NETWORK_PROTOCOL	Network protocol being used for communication, as specified in the 'PROTOCOL=protocol' portion of the connect string.
NLS_CALENDAR	The current calendar of the current session.
NLS_CURRENCY	The currency of the current session.
NLS_DATE_FORMAT	The date format for the session.
NLS_DATE_LANGUAGE	The language used for expressing dates.
NLS_SORT	BINARY or the linguistic sort basis.
NLS_TERRITORY	The territory of the current session.
OS_USER	Operating system user name of the client process that initiated the database session.
POLICY_INVOKER	The invoker of row-level security (RLS) policy functions.
PROXY_ENTERPRISE_IDENTITY	Returns the Oracle Internet Directory DN when the proxy user is an enterprise user.
PROXY_GLOBAL_UID	Returns the global user ID from Oracle Internet Directory for Enterprise User Security (EUS) proxy users; returns NULL for all other proxy users.
PROXY_USER	Name of the database user who opened the current session on behalf of SESSION_USER.
PROXY_USERID	Identifier of the database user who opened the current session on behalf of SESSION_USER.
SERVER_HOST	The host name of the machine on which the instance is running.
SERVICE_NAME	The name of the service to which a given session is connected.
SESSION_EDITION_ID	The identifier of the session edition.
SESSION_EDITION_NAME	The name of the session edition.
SESSION_USER	The name of the database user at logon. For enterprise users, returns the schema. For other users, returns the database user name. This value remains the same throughout the duration of the session.
SESSION_USERID	The identifier of the database user at logon.
SESSIONID	The auditing session identifier. You cannot use this attribute in distributed SQL statements.
SID	The session ID.
STATEMENTID	The auditing statement identifier. STATEMENTID represents the number of SQL statements audited in a given session. You cannot use this attribute in distributed SQL statements. The correct auditing statement identifier can be seen only through an audit handler for standard or fine-grained audit.
TERMINAL	The operating system identifier for the client of the current session. In distributed SQL statements, this attribute returns the identifier for your local session. In a distributed environment, this is supported only for remote SELECT statements, not for remote INSERT, UPDATE, or DELETE operations. (The return length of this parameter may vary by operating system.)

Data Dictionary Views That Display Information about Application Contexts

View	Description
ALL_CONTEXT	Describes all context namespaces in the current session for which attributes and values were specified using the DBMS_SESSION.SET_CONTEXT procedure. It lists the namespace and its associated schema and PL/SQL package.
ALL_POLICY_CONTEXTS	Describes the driving contexts defined for the synonyms, tables, and views accessible to the current user. (A driving context is a context used in a Virtual Private Database policy.)
DBA_CONTEXT	Provides all context namespace information in the database. Its columns are the same as those in the ALL_CONTEXT view, except that it includes the TYPE column. The TYPE column describes how the application context is accessed or initialized.
DBA_POLICY_CONTEXTS	Describes all driving contexts in the database that were added by the DBMS_RLS.ADD_POLICY_CONTEXT procedure. Its columns are the same as those in ALL_POLICY_CONTEXTS.
SESSION_CONTEXT	Describes the context attributes and their values set for the current session.
USER_POLICY_CONTEXTS	Describes the driving contexts defined for the synonyms, tables, and views owned by the current user. Its columns (except for OBJECT_OWNER) are the same as those in ALL_POLICY_CONTEXTS.
V$CONTEXT	Lists set attributes in the current session. Users do not have access to this view unless you grant the user the SELECT privilege on it.
V$SESSION	Lists detailed information about each current session. Users do not have access to this view unless you grant the user the SELECT privilege on it

Documentation:

Oracle® Database Security Guide 11g Release 2 (11.2) → Part Number E10574-02 → 6 Using Application Contexts to Retrieve User Information

SYS_CONTEXT → Oracle® Database SQL Language Reference 11g Release 2 (11.2) → Part Number E10592-02

↧

ORA-55626: Cannot remove the Flashback Archive's primary tablespace

September 28, 2015, 6:59 pm

≫ Next: Administer flashback data archive and schema evolution

≪ Previous: Create and manage contexts

Trying to remove tablespace from the default flashback archive but it throws an error until I delete the whole flashback archive:

ORA-55626: Cannot remove the Flashback Archive's primary tablespace

SHAIKDB>create flashback archive flash_days tablespace tbs2 quota 100m retention 10 day;

Flashback archive created.

SHAIKDB>alter flashback archive flash_days set default;

Flashback archive altered.

SHAIKDB>alter flashback archive flash_days add tablespace tbs3;

Flashback archive altered.

SHAIKDB>col FLASHBACK_ARCHIVE_NAME for a20

SHAIKDB>select * from dba_flashback_archive_ts;

FLASHBACK_ARCHIVE_NA FLASHBACK_ARCHIVE# TABLESPACE_NAME QUOTA_IN_MB

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

FLASH_ARCH_DEFAULT 1 TBS1 1024

FLASH_DAYS 2 TBS2 100

FLASH_MONTHS 3 TBS3 1024

FLASH_DAYS 2 TBS3 10240

fix:-

Delete the dman archive itself:

SHAIKDB>alter flashback archive flash_days remove tablespace tbs2;
alter flashback archive flash_days remove tablespace tbs2
                                                     *
ERROR at line 1:
ORA-55626: Cannot remove the Flashback Archive's primary tablespace

SHAIKDB>drop flashback archive flash_days;

Flashback archive dropped.

SHAIKDB>select * from dba_flashback_archive_ts;

FLASHBACK_ARCHIVE_NA FLASHBACK_ARCHIVE# TABLESPACE_NAME            QUOTA_IN_MB
-------------------- ------------------ ------------------------------ ----------------------------------------
FLASH_ARCH_DEFAULT              1 TBS1                   1024
FLASH_MONTHS                  3 TBS3                   1024

↧

Administer flashback data archive and schema evolution

September 29, 2015, 4:55 pm

≫ Next: How to Add a user in Grid control

≪ Previous: ORA-55626: Cannot remove the Flashback Archive's primary tablespace

Using Flashback Data Archive (Oracle Total Recall)

A Flashback Data Archive provides the ability to track and store transactional changes to a table over its lifetime. A Flashback Data Archive is useful for compliance with record stage policies and audit reports

You can specify a default Flashback Data Archive for the system. A Flashback Data Archive is configured with retention time. Data archived in the Flashback Data Archive is retained for the retention time.

Conditions for Data Archive:

You have the FLASHBACK ARCHIVE object privilege on the Flashback Data Archive that you want to use for that table.
The table is neither nested, clustered, temporary, remote, or external.
The table contains neither LONG nor nested columns.

To disable:

FLASHBACK ARCHIVE ADMINISTER system privilege or
As SYSDBA

Creating a Flashback Data Archive

Creating a default Flashback Data Archive that uses up to 1 G of tablespace tbs1, whose data are retained for 100 years:

SHAIKDB>create flashback archive default flash_arch_default tablespace tbs1 quota 1g retention 100 year;

Flashback archive created.

SHAIKDB>create flashback archive flash_days tablespace tbs2 quota 100m retention 10 day;

Flashback archive created.

SHAIKDB>alter flashback archive flash_days set default;

Flashback archive altered.

SHAIKDB>create flashback archive flash_months tablespace tbs3 quota 1g retention 1 month;

Flashback archive created.

Add space:

SHAIKDB>alter flashback archive flash_days add tablespace tbs3;

Flashback archive altered.

SHAIKDB>alter flashback archive flash_days modify retention 45 day;

Flashback archive altered.

SHAIKDB>alter flashback archive flash_days modify tablespace tbs3 quota 10g;

Flashback archive altered.

SHAIKDB>col FLASHBACK_ARCHIVE_NAME for a20

SHAIKDB>select * from dba_flashback_archive_ts;

FLASHBACK_ARCHIVE_NA FLASHBACK_ARCHIVE# TABLESPACE_NAME QUOTA_IN_MB

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

FLASH_ARCH_DEFAULT 1 TBS1 1024

FLASH_DAYS 2 TBS2 100

FLASH_MONTHS 3 TBS3 1024

FLASH_DAYS 2 TBS3 10240

SHAIKDB>select * from dba_flashback_Archive;

OWNER_NAME FLASHBACK_ARCHIVE_NA FLASHBACK_ARCHIVE# RETENTION_IN_DAYS CREATE_TIME LAST_PURGE_TIME STATUS

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

SYS FLASH_ARCH_DEFAULT 1 36500 28-SEP-15 09.24.57.000000000 PM 28-SEP-15 09.24.57.000000000 PM

SYS FLASH_DAYS 2 45 28-SEP-15 09.29.39.000000000 PM 28-SEP-15 09.29.39.000000000 PM DEFAULT

SYS FLASH_MONTHS 3 30 28-SEP-15 09.30.28.000000000 PM 28-SEP-15 09.30.28.000000000 PM

undo_management string AUTO

SHAIKDB>alter flashback archive flash_months add tablespace tbs2;

Flashback archive altered.

SHAIKDB>alter flashback archive flash_months remove tablespace tbs3;

alter flashback archive flash_months remove tablespace tbs3

ERROR at line 1:

ORA-55626: Cannot remove the Flashback Archive's primary tablespace

If it is not the default tablespace that you created the archive with then you can remove the tablespace using the remove command from flashback archive.

SHAIKDB>alter flashback archive flash_months remove tablespace tbs2;

Flashback archive altered.

SHAIKDB>alter flashback archive flash_months set default;

Flashback archive altered.

SHAIKDB>create user flash identified by flash default tablespace tbs1;

User created.

SHAIKDB>grant create session,create table to flash;

Grant succeeded.

SHAIKDB>grant flashback archive on flash_months to flash;

Grant succeeded.

SHAIKDB>grant flashback archive on flash_arch_default to flash;

Grant succeeded.

SHAIKDB>alter user flash quota unlimited on tbs1;

User altered.

SHAIKDB>alter user flash quota unlimited on tbs2;

User altered.

SHAIKDB>alter user flash quota unlimited on tbs3;

User altered.

Create table flash and store the historical data in the default Flashback Data Archive:

SHAIKDB>show user

USER is "FLASH"

SHAIKDB>create table flash1 (id number,name varchar2(10)) flashback archive;

Table created.

SHAIKDB>begin

for i in 1..100 loop

insert into flash1 values(i,'LOVE');

commit;

end loop;

end;

PL/SQL procedure successfully completed.

SHAIKDB>select * from flash1 where rownum <=10;

ID NAME

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

1 LOVE

2 LOVE

3 LOVE

4 LOVE

5 LOVE

6 LOVE

7 LOVE

8 LOVE

9 LOVE

10 LOVE

10 rows selected.

SHAIKDB>col ARCHIVE_TABLE_NAME for a20

SHAIKDB>col OWNER_NAME for a15

SHAIKDB>col table_name for a10

SHAIKDB>select * from dba_flashback_archive_tables;

TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NA ARCHIVE_TABLE_NAME STATUS

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

FLASH1 FLASH FLASH_MONTHS SYS_FBA_HIST_74868 ENABLED

SHAIKDB>show user

USER is "SYS"

SHAIKDB>create flashback archive flash_days tablespace tbs2 quota 1g retention 1 day;

Flashback archive created.

SHAIKDB>grant flashback archive on flash_days to flash;

Grant succeeded.

Create table flash2 and store the historical data in the default_flash_arch Flashback Data Archive:

SHAIKDB>create table flash2 (id number,name2 varchar2(10)) flashback archive flash_days;

Table created.

SHAIKDB>begin

for i in 1..100 loop

insert into flash2 values(i,'FLASH2');

commit;

end loop;

end;

/ 2 3 4 5 6 7

PL/SQL procedure successfully completed.

SHAIKDB>select * from flash2 where rownum <=10;

ID NAME2

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

1 FLASH2

2 FLASH2

3 FLASH2

4 FLASH2

5 FLASH2

6 FLASH2

7 FLASH2

8 FLASH2

9 FLASH2

10 FLASH2

10 rows selected.

SHAIKDB>select * from dba_flashback_archive_tables;

TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NA ARCHIVE_TABLE_NAME STATUS

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

FLASH1 FLASH FLASH_MONTHS SYS_FBA_HIST_74868 ENABLED

FLASH2 FLASH FLASH_DAYS SYS_FBA_HIST_74878 ENABLED

SHAIKDB>alter table flash1 no flashback archive;

alter table flash1 no flashback archive

ERROR at line 1:

ORA-55620: No privilege to use Flashback Archive

SHAIKDB>show user

USER is "SYS"

or grant flashback archive administer privilege to manage the flashback archives.

SHAIKDB>alter table flash.flash1 no flashback archive;

Table altered.

SHAIKDB>select * from dba_flashback_archive_tables;

TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NA ARCHIVE_TABLE_NAME STATUS

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

FLASH2 FLASH FLASH_DAYS SYS_FBA_HIST_74878 ENABLED

SHAIKDB>alter table flash1 flashback archive flash_days;

Table altered

TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NA ARCHIVE_TABLE_NAME STATUS

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

FLASH1 FLASH FLASH_DAYS SYS_FBA_HIST_74868 ENABLED

FLASH2 FLASH FLASH_DAYS SYS_FBA_HIST_74878 ENABLED

SHAIKDB>alter flashback archive flash_days modify retention 7 day;

Flashback archive altered.

19:20:19 SHAIKDB>alter session set nls_date_format='mm/dd/yyyy hh24:mi:ss';

Session altered.

19:20:40 SHAIKDB>select sysdate from dual;

SYSDATE

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

09/29/2015 19:20:47

SHAIKDB>insert into flash1 select * from flash2;

200 rows created.

SHAIKDB>commit;

Commit complete.

SHAIKDB>insert into flash2 select * from flash1;

300 rows created.

SHAIKDB>commit;

Commit complete.

19:20:47 SHAIKDB>select count(*) from flash1;

COUNT(*)

----------

300

19:29:54 SHAIKDB>select count(*) from flash1 as of timestamp to_timestamp('09-29-2015 10:00:00','mm-dd-yyyy hh24:mi:ss');

COUNT(*)

----------

100

19:32:11 SHAIKDB>select count(*) from flash1 as of timestamp to_timestamp('09-29-2015 19:30:00','mm-dd-yyyy hh24:mi:ss');

COUNT(*)

----------

300

19:47:18 SHAIKDB>select distinct name from flash1;

NAME

----------

FLASH2

LOVE

19:47:25 SHAIKDB>delete flash1 where name='LOVE';

200 rows deleted.

19:47:45 SHAIKDB>commit;

Commit complete.

19:47:48 SHAIKDB>select count(*) from flash1;

COUNT(*)

----------

100

19:47:54 SHAIKDB>select count(*) from flash1 as of timestamp ( systimestamp - interval '5' minute);

COUNT(*)

----------

300

19:48:44 SHAIKDB>select count(*) from flash1 as of timestamp ( systimestamp - interval '1' hour);

COUNT(*)

----------

100

Lets get the data back:

19:48:55 SHAIKDB>select count(*) from flash1 as of timestamp ( systimestamp - interval '10' minute) where name='LOVE';

COUNT(*)

----------

200

19:50:44 SHAIKDB>insert into flash1 select * from flash1 as of timestamp(systimestamp - interval '10' minute) where name='LOVE';

200 rows created.

19:51:21 SHAIKDB>commit;

Commit complete.

19:51:23 SHAIKDB>select count(*) from flash1;

COUNT(*)

----------

300

If you must use unsupported DDL statements on a table enabled for Flashback Data Archive, use the DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA procedure to disassociate the base table from its Flashback Data Archive. To reassociate the Flashback Data Archive with the base table afterward, use the DBMS_FLASHBACK_ARCHIVE.REASSOCIATE_FBA procedure.

View	Description
*_FLASHBACK_ARCHIVE	Displays information about Flashback Data Archive files.
*_FLASHBACK_ARCHIVE_TS	Displays tablespaces of Flashback Data Archive files.
*_FLASHBACK_ARCHIVE_TABLES	Displays information about tables that are enabled for Data Flashback Archive files.

Documentation:

Oracle® Database Advanced Application Developer's Guide 11g Release 2 (11.2) → 12 Using Oracle Flashback Technology → Using Flashback Data Archive (Oracle Total Recall)

↧

How to Add a user in Grid control

September 30, 2015, 7:16 pm

≫ Next: Administer Resource Manager

≪ Previous: Administer flashback data archive and schema evolution

How to Add a user in Grid control.
Login as a super user sysman/sys/system

Click on Setup

Click on Administartors

Fill in the details for the new user --> RESMGR

↧

Administer Resource Manager

October 4, 2015, 3:17 pm

≫ Next: Administer Resource Manager using dbconsole:

≪ Previous: How to Add a user in Grid control

Oracle Database Resource Manager (the Resource Manager) enables you to optimize resource allocation among the many concurrent database sessions.

Resource consumer group

A group of sessions that are grouped together based on resource requirements. The Resource Manager allocates resources to resource consumer groups, not to individual sessions.

Resource plan

A container for directives that specify how resources are allocated to resource consumer groups. You specify how the database allocates resources by activating a specific resource plan.

Resource plan directive

Associates a resource consumer group with a particular plan and specifies how resources are to be allocated to that resource consumer group.

Resource Consumer Groups

A resource consumer group (consumer group) is a collection of user sessions that are grouped together based on their processing needs. When a session is created, it is automatically mapped to a consumer group based on mapping rules that you set up. As a database administrator (DBA), you can manually switch a session to a different consumer group. Similarly, an application can run a PL/SQL package procedure that switches its session to a particular consumer group.

Because the Resource Manager allocates resources (such as CPU) only to consumer groups, when a session becomes a member of a consumer group, its resource allocation is then determined by the allocation for the consumer group. By default, each session in a consumer group shares the resources allocated to that group with other sessions in the group in a round robin fashion.

There are three special consumer groups that are always present in the data dictionary. They cannot be modified or deleted. They are:

SYS_GROUP
This is the initial consumer group for all sessions created by user accounts SYS or SYSTEM. This initial consumer group can be overridden by session-to–consumer group mapping rules.
DEFAULT_CONSUMER_GROUP
This is the initial consumer group for all sessions started by user accounts other than SYS and SYSTEM. This initial consumer group can be overridden by session-to–consumer group mapping rules. DEFAULT_CONSUMER_GROUP cannot be named in a resource plan directive.
OTHER_GROUPS
This group applies collectively to all sessions that belong to a consumer group that is not part of the currently active plan, including sessions that belong to DEFAULT_CONSUMER_GROUP. OTHER_GROUPS must have a resource plan directive specified in every plan. It cannot be explicitly assigned to sessions through mapping rules.

Procedure	Description
GRANT_SYSTEM_PRIVILEGE	Grants the ADMINISTER_RESOURCE_MANAGER system privilege to a user or role.
REVOKE_SYSTEM_PRIVILEGE	Revokes the ADMINISTER_RESOURCE_MANAGER system privilege from a user or role.

The following PL/SQL block grants the administrative privilege to user SCOTT, but does not grant SCOTT the ADMIN option. Therefore, RESMGR can execute all of the procedures in the DBMS_RESOURCE_MANAGER package, but SCOTT cannot use the GRANT_SYSTEM_PRIVILEGE procedure to grant the administrative privilege to others.

BEGIN
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE(
  GRANTEE_NAME   => 'RSMGR,
  PRIVILEGE_NAME => 'ADMINISTER_RESOURCE_MANAGER',
  ADMIN_OPTION   => FALSE);
END;
/

The following PL/SQL block creates a simple resource plan with two user-specified consumer groups:

SHAIKDB>select plan,GROUP_OR_SUBPLAN,CPU_P1,CPU_P2,CPU_P3,mgmt_p1,mgmt_p2,mgmt_p3 from dba_rsrc_plan_directives where plan like '%SIMPLE%' order by 2;

PLAN GROUP_OR_SUBPLAN CPU_P1 CPU_P2 CPU_P3 MGMT_P1 MGMT_P2 MGMT_P3

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

MY_SIMPLE_PLAN MY_SIMPLE_GROUP1 0 80 0 0 80 0

MY_SIMPLE_PLAN MY_SIMPLE_GROUP2 0 20 0 0 20 0

MY_SIMPLE_PLAN OTHER_GROUPS 0 0 100 0 0 100

MY_SIMPLE_PLAN SYS_GROUP 100 0 0 100 0 0

SHAIKDB>begin

2 dbms_resource_manager.create_simple_plan(simple_plan=>'MY_SIMPLE_PLAN',

3 CONSUMER_GROUP1=>'MY_SIMPLE_GROUP1',GROUP1_PERCENT=>80,

4 CONSUMER_GROUP2=>'MY_SIMPLE_GROUP2',GROUP2_PERCENT=>20);

5 END;

6 /

PL/SQL procedure successfully completed.

Consumer Group	Level 1	Level 2	Level 3
SYS_GROUP	100%	-	-
MYGROUP1	-	80%	-
MYGROUP2	-	20%	-
OTHER_GROUPS	-	-	100%

A complex resource plan is any resource plan that is not created with the DBMS_RESOURCE_MANAGER.CREATE_SIMPLE_PLAN procedure.

for a more complex resource plan, you must create the plan, with its directives and consumer groups, in a staging area called the pending area, and then validate the plan before storing it in the data dictionary.

Step 1: Create a pending area.

Step 2: Create, modify, or delete consumer groups.

Step 3: Create the resource plan.

Step 4: Create resource plan directives.

Step 5: Validate the pending area.

Step 6: Submit the pending area.

Pending Area

The pending area is a staging area where you can create a new resource plan, update an existing plan, or delete a plan without affecting currently running applications. When you create a pending area, the database initializes it and then copies existing plans into the pending area so that they can be updated

SHAIKDB>exec dbms_resource_manager.create_pending_area();

PL/SQL procedure successfully completed.

Creating a Resource Consumer Group

The following PL/SQL block creates a consumer group called OLTP with the default (ROUND-ROBIN) method of allocating resources to sessions in the group:

SHAIKDB>exec dbms_resource_manager.create_consumer_group('CRITICAL','Group for Critical Apps');

PL/SQL procedure successfully completed.

Available Procedures under Resource_manager:

Subprogram	Description
CALIBRATE_IO Procedure	Calibrates the I/O capabilities of storage
CLEAR_PENDING_AREA Procedure	Clears the work area for the resource manager
CREATE_CATEGORY Procedure	Creates a new resource consumer group category
CREATE_CONSUMER_GROUP Procedure	Creates entries which define resource consumer groups
CREATE_PENDING_AREA Procedure	Creates a work area for changes to resource manager objects
CREATE_PLAN Procedure	Creates entries which define resource plans
CREATE_PLAN_DIRECTIVE Procedure	Creates resource plan directives
CREATE_SIMPLE_PLAN Procedure	Creates a single-level resource plan containing up to eight consumer groups in one step
DELETE_CATEGORY Procedure	Deletes an existing resource consumer group category
DELETE_CONSUMER_GROUP Procedure	Deletes entries which define resource consumer groups
DELETE_PLAN Procedure	Deletes the specified plan as well as all the plan directives it refers to
DELETE_PLAN_CASCADE Procedure	Deletes the specified plan as well as all its descendants (plan directives, subplans, consumer groups)
DELETE_PLAN_DIRECTIVE Procedure	Deletes resource plan directives
SET_CONSUMER_GROUP_MAPPING Procedure	Adds, deletes, or modifies entries for the login and run-time attribute mappings
SET_CONSUMER_GROUP_MAPPING_PRI Procedure	Creates the session attribute mapping priority list
SET_INITIAL_CONSUMER_GROUP Procedure	Assigns the initial resource consumer group for a user (Caution: Deprecated Subprogram)
SUBMIT_PENDING_AREA Procedure	Submits pending changes for the resource manager
SWITCH_CONSUMER_GROUP_FOR_SESS Procedure	Changes the resource consumer group of a specific session
SWITCH_CONSUMER_GROUP_FOR_USER Procedure	Changes the resource consumer group for all sessions with a given user name
SWITCH_PLAN Procedure	Sets the current resource manager plan
UPDATE_CATEGORY Procedure	Updates an existing resource consumer group category
UPDATE_CONSUMER_GROUP Procedure	Updates entries which define resource consumer groups
UPDATE_PLAN Procedure	Updates entries which define resource plans
UPDATE_PLAN_DIRECTIVE Procedure	Updates resource plan directives
VALIDATE_PENDING_AREA Procedure	Validates pending changes for the resource manager

Creating a Resource Plan

Parameter	Description
PLAN	Name to assign to the plan.
COMMENT	Any descriptive comment.
CPU_MTH	Deprecated. Use MGMT_MTH.
ACTIVE_SESS_POOL_MTH	Active session pool resource allocation method. ACTIVE_SESS_POOL_ABSOLUTE is the default and only method available.
PARALLEL_DEGREE_LIMIT_MTH	Resource allocation method for specifying a limit on the degree of parallelism of any operation. PARALLEL_DEGREE_LIMIT_ABSOLUTE is the default and only method available.
QUEUEING_MTH	Queuing resource allocation method. Controls the order in which queued inactive sessions are removed from the queue and added to the active session pool. FIFO_TIMEOUT is the default and only method available.
MGMT_MTH	Resource allocation method for specifying how much CPU each consumer group or subplan gets. 'EMPHASIS', the default method, is for single-level or multilevel plans that use percentages to specify how CPU is distributed among consumer groups. 'RATIO' is for single-level plans that use ratios to specify how CPU is distributed.
SUB_PLAN	If TRUE, the plan cannot be used as the top plan; it can be used as a subplan only. Default is FALSE.

The following shows resource plan options:

PLAN	Name of the resource plan to which the directive belongs.
GROUP_OR_SUBPLAN	Name of the consumer group or subplan to which to allocate resources.
COMMENT	Any comment.
CPU_P1	Deprecated. Use MGMT_P1.
CPU_P2	Deprecated. Use MGMT_P2.
CPU_P3	Deprecated. Use MGMT_P3.
CPU_P4	Deprecated. Use MGMT_P4.
CPU_P5	Deprecated. Use MGMT_P5.
CPU_P6	Deprecated. Use MGMT_P6.
CPU_P7	Deprecated. Use MGMT_P7.
CPU_P8	Deprecated. Use MGMT_P8.
ACTIVE_SESS_POOL_P1	Specifies the maximum number of concurrently active sessions for a consumer group. Other sessions await execution in an inactive session queue. Default is UNLIMITED.
QUEUEING_P1	Specifies time (in seconds) after which a session in an inactive session queue (waiting for execution) times out and the call is aborted. Default is UNLIMITED.
PARALLEL_DEGREE_LIMIT_P1	Specifies a limit on the degree of parallelism for any operation. Default is UNLIMITED.
SWITCH_GROUP	Specifies the consumer group to which a session is switched if switch criteria are met. If the group name is 'CANCEL_SQL', then the current call is canceled when switch criteria are met. If the group name is 'KILL_SESSION', then the session is killed when switch criteria are met. Default is NULL. If the group name is 'CANCEL_SQL', the SWITCH_FOR_CALL parameter is always set to TRUE, overriding the user-specified setting.
SWITCH_TIME	Specifies the time (in CPU seconds) that a call can execute before an action is taken. Default is UNLIMITED. The action is specified by SWITCH_GROUP.
SWITCH_ESTIMATE	If TRUE, the database estimates the execution time of each call, and if estimated execution time exceeds SWITCH_TIME, the session is switched to the SWITCH_GROUP before beginning the call. Default is FALSE. The execution time estimate is obtained from the optimizer. The accuracy of the estimate is dependent on many factors, especially the quality of the optimizer statistics. In general, you should expect statistics to be no more accurate than ± 10 minutes.
MAX_EST_EXEC_TIME	Specifies the maximum execution time (in CPU seconds) allowed for a call. If the optimizer estimates that a call will take longer than MAX_EST_EXEC_TIME, the call is not allowed to proceed and ORA-07455 is issued. If the optimizer does not provide an estimate, this directive has no effect. Default is UNLIMITED. The accuracy of the estimate is dependent on many factors, especially the quality of the optimizer statistics. In general, you should expect statistics to be no more accurate than ± 10 minutes.
UNDO_POOL	Sets a maximum in kilobytes (K) on the total amount of undo for uncommitted transactions that can be generated by a consumer group. Default is UNLIMITED.
MAX_IDLE_TIME	Indicates the maximum session idle time, in seconds. Default is NULL, which implies unlimited.
MAX_IDLE_BLOCKER_TIME	Indicates the maximum session idle time of a blocking session, in seconds. Default is NULL, which implies unlimited.
SWITCH_TIME_IN_CALL	Deprecated. Use SWITCH_FOR_CALL.
MGMT_P1	For a plan with the MGMT_MTH parameter set to EMPHASIS, specifies the CPU percentage to allocate at the first level. For MGMT_MTH set to RATIO, specifies the weight of CPU usage. Default is NULL for all MGMT_Pn parameters.
MGMT_P2	For EMPHASIS, specifies CPU percentage to allocate at the second level. Not applicable for RATIO.
MGMT_P3	For EMPHASIS, specifies CPU percentage to allocate at the third level. Not applicable for RATIO.
MGMT_P4	For EMPHASIS, specifies CPU percentage to allocate at the fourth level. Not applicable for RATIO.
MGMT_P5	For EMPHASIS, specifies CPU percentage to allocate at the fifth level. Not applicable for RATIO.
MGMT_P6	For EMPHASIS, specifies CPU percentage to allocate at the sixth level. Not applicable for RATIO.
MGMT_P7	For EMPHASIS, specifies CPU percentage to allocate at the seventh level. Not applicable for RATIO.
MGMT_P8	For EMPHASIS, specifies CPU percentage to allocate at the eighth level. Not applicable for RATIO.
SWITCH_IO_MEGABYTES	Specifies the number of megabytes of I/O that a session can transfer (read and write) before an action is taken. Default is UNLIMITED. The action is specified by SWITCH_GROUP.
SWITCH_IO_REQS	Specifies the number of I/O requests that a session can execute before an action is taken. Default is UNLIMITED. The action is specified by SWITCH_GROUP.
SWITCH_FOR_CALL	If TRUE, a session that was automatically switched to another consumer group (according to SWITCH_TIME, SWITCH_IO_MEGABYTES, or SWITCH_IO_REQS) is returned to its original consumer group when the top level call completes. Default is NULL.
MAX_UTILIZATION_LIMIT	Absolute maximum CPU utilization percentage permitted for the consumer group. This value overrides any level allocations for CPU (MGMT_P1 through MGMT_P8), and also imposes a limit on total CPU utilization when unused allocations are redistributed. You can specify this attribute and leave MGMT_P1 through MGMT_P8 NULL. You cannot specify this attribute for a subplan.

Validating the Pending Area:

The following PL/SQL block validates the pending area.

BEGIN
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
END;
/

Submitting the Pending Area:

The following PL/SQL block submits the pending area:

BEGIN
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

Clearing the Pending Area

There is also a procedure for clearing the pending area at any time. This PL/SQL block causes all of your changes to be cleared from the pending area and deactivates the pending area:

BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
END;
/

Switching a Single Session

The SWITCH_CONSUMER_GROUP_FOR_SESS procedure causes the specified session to immediately be moved into the specified resource consumer group. In effect, this procedure can raise or lower priority of the session.

The following PL/SQL block switches a specific session to a new consumer group. The session identifier (SID) is 17, the session serial number (SERIAL#) is 12345, and the new consumer group is the HIGH_PRIORITY consumer group.

BEGIN
DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_SESS ('17', '12345',
'HIGH_PRIORITY');
END;
/

Switching All Sessions for a User

The SWITCH_CONSUMER_GROUP_FOR_USER procedure changes the resource consumer group for all sessions pertaining to the specified user name. The following PL/SQL block switches all sessions that belong to user SCOTT to the LOW_GROUP consumer group:

BEGIN
DBMS_RESOURCE_MANAGER.SWITCH_CONSUMER_GROUP_FOR_USER ('SCOTT',
'LOW_GROUP');
END;
/

Disabling the Resource Manager

To disable the Resource Manager, complete the following steps:

Issue the following SQL statement:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = '';

The following statement in a text initialization parameter file activates the Resource Manager upon database startup and sets the top plan as mydb_plan.

RESOURCE_MANAGER_PLAN = mydb_plan

You can also activate or deactivate the Resource Manager, or change the current top plan, using the DBMS_RESOURCE_MANAGER.SWITCH_PLAN package procedure or the ALTER SYSTEM statement.

The following SQL statement sets the top plan to mydb_plan, and activates the Resource Manager if it is not already active:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'mydb_plan';

Deleting a Plan

The DELETE_PLAN procedure deletes the specified plan as well as all the plan directives associated with it. The pending area must be created first, and then submitted after the plan is deleted.

The following PL/SQL block deletes the great_bread plan and its directives.

BEGIN
DBMS_RESOURCE_MANAGER.DELETE_PLAN(PLAN => 'SIMPLE');
END;
/

Updating a Resource Plan Directive

Use the UPDATE_PLAN_DIRECTIVE procedure to update plan directives. The pending area must be created first, and then submitted after the resource plan directive is updated. If you do not specify an argument for the UPDATE_PLAN_DIRECTIVE procedure, its corresponding parameter in the directive remains unchanged.

The following example adds a comment to a directive:

BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE(
        PLAN             => 'SIMPLE_PLAN1',
        GROUP_OR_SUBPLAN => 'MYGROUP1',
        NEW_COMMENT      => 'Higher priority'
       );
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

To clear (nullify) a comment, pass a null string (''). To clear (zero or nullify) any numeric directive parameter, set its new value to -1:

BEGIN
DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE(
        PLAN                  => 'SIMPLE_PLAN1',
        GROUP_OR_SUBPLAN      => 'MYGROUP1',
        NEW_MAX_EST_EXEC_TIME => -1
       );
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

SELECT * FROM DBA_RSRC_CONSUMER_GROUP_PRIVS;

SELECT PLAN,STATUS, COMMENTS FROM DBA_RSRC_PLANS;

SQL> SELECT SID,SERIAL#,USERNAME,RESOURCE_CONSUMER_GROUP FROM V$SESSION;

SELECT NAME, IS_TOP_PLAN FROM V$RSRC_PLAN;

View	Description
DBA_RSRC_CONSUMER_GROUP_PRIVS USER_RSRC_CONSUMER_GROUP_PRIVS	DBA view lists all resource consumer groups and the users and roles to which they have been granted. USER view lists all resource consumer groups granted to the user.
DBA_RSRC_CONSUMER_GROUPS	Lists all resource consumer groups that exist in the database.
DBA_RSRC_MANAGER_SYSTEM_PRIVS USER_RSRC_MANAGER_SYSTEM_PRIVS	DBA view lists all users and roles that have been granted Resource Manager system privileges. USER view lists all the users that are granted system privileges for the DBMS_RESOURCE_MANAGER package.
DBA_RSRC_PLAN_DIRECTIVES	Lists all resource plan directives that exist in the database.
DBA_RSRC_PLANS	Lists all resource plans that exist in the database.
DBA_RSRC_GROUP_MAPPINGS	Lists all of the various mapping pairs for all of the session attributes.
DBA_RSRC_MAPPING_PRIORITY	Lists the current mapping priority of each attribute.
DBA_HIST_RSRC_PLAN	Displays historical information about resource plan activation. This view contains AWR snapshots of V$RSRC_PLAN_HISTORY.
DBA_HIST_RSRC_CONSUMER_GROUP	Displays historical statistical information about consumer groups. This view contains AWR snapshots of V$RSRC_CONS_GROUP_HISTORY.
DBA_USERS USERS_USERS	DBA view contains information about all users of the database. It contains the initial resource consumer group for each user. USER view contains information about the current user. It contains the current user's initial resource consumer group.
V$ACTIVE_SESS_POOL_MTH	Displays all available active session pool resource allocation methods.
V$PARALLEL_DEGREE_LIMIT_MTH	Displays all available parallel degree limit resource allocation methods.
V$QUEUEING_MTH	Displays all available queuing resource allocation methods.
V$RSRC_CONS_GROUP_HISTORY	For each entry in the view V$RSRC_PLAN_HISTORY, contains an entry for each consumer group in the plan showing the cumulative statistics for the consumer group.
V$RSRC_CONSUMER_GROUP	Displays information about active resource consumer groups. This view can be used for tuning.
V$RSRC_CONSUMER_GROUP_CPU_MTH	Displays all available CPU resource allocation methods for resource consumer groups.
V$RSRCMGRMETRIC	Displays a history of resources consumed and cumulative CPU wait time (due to resource management) per consumer group for the past minute.
V$RSRCMGRMETRIC_HISTORY	Displays a history of resources consumed and cumulative CPU wait time (due to resource management) per consumer group for the past hour on a minute-by-minute basis. If a new resource plan is enabled, the history is cleared.
V$RSRC_PLAN	Displays the names of all currently active resource plans.
V$RSRC_PLAN_CPU_MTH	Displays all available CPU resource allocation methods for resource plans.
V$RSRC_PLAN_HISTORY	Shows when Resource Manager plans were enabled or disabled on the instance. It helps you understand how resources were shared among the consumer groups over time.
V$RSRC_SESSION_INFO	Displays Resource Manager statistics for each session. Shows how the session has been affected by the Resource Manager. Can be used for tuning.
V$SESSION	Lists session information for each current session. Specifically, lists the name of the resource consumer group of each current session.

Demo:

SHAIKDB>create user resmgr identified by resmgr default tablespace tbs1 temporary tablespace temp;

User created.

SHAIKDB>grant create session,create table,select any table,create procedure,create trigger to resmgr;

Grant succeeded.

SHAIKDB>SELECT GRANTEE,PRIVILEGE FROM DBA_RSRC_MANAGER_SYSTEM_PRIVS;

GRANTEE PRIVILEGE

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

SYS ADMINISTER RESOURCE MANAGER

DBA ADMINISTER RESOURCE MANAGER

EXP_FULL_DATABASE ADMINISTER RESOURCE MANAGER

IMP_FULL_DATABASE ADMINISTER RESOURCE MANAGER

APPQOSSYS ADMINISTER RESOURCE MANAGER

SHAIKDB>BEGIN DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SYSTEM_PRIVILEGE('RESMGR','ADMINISTER_RESOURCE_MANAGER',FALSE);

END;

PL/SQL procedure successfully completed.

USERNAME PRIVILEGE ADM

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

RESMGR ADMINISTER RESOURCE MANAGER NO

RESMGR CREATE TRIGGER NO

RESMGR SELECT ANY TABLE NO

RESMGR CREATE PROCEDURE NO

RESMGR CREATE SESSION NO

RESMGR CREATE TABLE NO

6 rows selected.

Granting the RESOURCE_MANAGER_ADMIN privilege using GRID Control:

Delete the plans:

SHAIKDB>EXEC DBMS_RESOURCE_MANAGER.DELETE_CONSUMER_GROUP('CRITICAL');

PL/SQL procedure successfully completed.

If the pending area is not active:

SHAIKDB>EXEC DBMS_RESOURCE_MANAGER.DELETE_PLAN('MY_SIMPLE_PLAN');

BEGIN DBMS_RESOURCE_MANAGER.DELETE_PLAN('MY_SIMPLE_PLAN'); END;

ERROR at line 1:

ORA-29371: pending area is not active

ORA-06512: at "SYS.DBMS_RMIN", line 105

ORA-06512: at "SYS.DBMS_RESOURCE_MANAGER", line 180

ORA-06512: at line 1

Create the pending Area:

SHAIKDB>BEGIN

DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

END;

/ 2 3 4

PL/SQL procedure successfully completed.

Delete the PLAN:

SHAIKDB>select plan,GROUP_OR_SUBPLAN,CPU_P1,CPU_P2,CPU_P3,mgmt_p1,mgmt_p2,mgmt_p3 from dba_rsrc_plan_directives where plan like '%SIMPLE%' order by 2;

PLAN GROUP_OR_SUBPLAN CPU_P1 CPU_P2 CPU_P3 MGMT_P1 MGMT_P2 MGMT_P3

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

MY_SIMPLE_PLAN MY_SIMPLE_GROUP1 0 80 0 0 80 0

MY_SIMPLE_PLAN MY_SIMPLE_GROUP2 0 20 0 0 20 0

MY_SIMPLE_PLAN OTHER_GROUPS 0 0 100 0 0 100

MY_SIMPLE_PLAN SYS_GROUP 100 0 0 100 0 0

SHAIKDB>exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SHAIKDB>EXEC DBMS_RESOURCE_MANAGER.DELETE_PLAN('MY_SIMPLE_PLAN');

PL/SQL procedure successfully completed.

SHAIKDB>EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SHAIKDB>show errors

No errors.

SHAIKDB>exec dbms_resource_manager.submit_pending_Area();

PL/SQL procedure successfully completed.

SHAIKDB>select plan,GROUP_OR_SUBPLAN,CPU_P1,CPU_P2,CPU_P3,mgmt_p1,mgmt_p2,mgmt_p3 from dba_rsrc_plan_directives where plan like '%SIMPLE%' order by 2;

no rows selected

SHAIKDB>

DEMO-2:

Creating:
Pending area
Create consumer groups CRITICAL,MEDIUM,LOW
Create PLAN - CRITICAL
Create PLAN directives
Validate PLAN
Submit PLAN.

SHAIKDB>select plan,GROUP_OR_SUBPLAN,CPU_P1,CPU_P2,CPU_P3,mgmt_p1,mgmt_p2,mgmt_p3 from dba_rsrc_plan_directives where plan=’CRITICAL_PLAN’ order by 2;

no rows selected

SHAIKDB>exec dbms_resource_manager.create_pending_area();

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_consumer_group('CRITICAL','Group for Critical Apps');

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_plan('CRITICAL_PLAN','Plan fr critical queries');

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_plan_directive(PLAN=>'CRITICAL_PLAN',GROUP_OR_SUBPLAN=>'CRITICAL',COMMENT=>'Allocate 60% CPU',MGMT_P1=>60);

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_consumer_group('MEDIUM','Medium critical Apps');

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_consumer_group('LOW','Low critical Apps');

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_plan_directive(PLAN=>'CRITICAL_PLAN',GROUP_OR_SUBPLAN=>'MEDIUM', COMMENT=>'ALLOCATE CPU 20%',MGMT_P1=>20,PARALLEL_DEGREE_LIMIT_P1=>2,ACTIVE_SESS_POOL_P1=>2);

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_plan_directive(PLAN=>'CRITICAL_PLAN',GROUP_OR_SUBPLAN=>'LOW', COMMENT=>'Allocate 10% CPU',MGMT_P1=>10,PARALLEL_DEGREE_LIMIT_P1=>1,ACTIVE_SESS_POOL_P1=>1);

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.create_plan_directive(PLAN=>'CRITICAL_PLAN',GROUP_OR_SUBPLAN=>'OTHER_GROUPS',COMMENT=>'ALLOCATE CPU 10% FOR OTHER GROUPS',MGMT_P1=>10);

PL/SQL procedure successfully completed.

SHAIKDB>EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

PL/SQL procedure successfully completed.

SHAIKDB>SHOW ERRORS

No errors.

SHAIKDB>EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA

PL/SQL procedure successfully completed.

SHAIKDB>select plan,GROUP_OR_SUBPLAN,CPU_P1,CPU_P2,CPU_P3,mgmt_p1,mgmt_p2,mgmt_p3 from dba_rsrc_plan_directives where plan='CRITICAL_PLAN' order by 3 desc;

PLAN GROUP_OR_SUBPLAN CPU_P1 CPU_P2 CPU_P3 MGMT_P1 MGMT_P2 MGMT_P3

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

CRITICAL_PLAN CRITICAL 60 0 0 60 0 0

CRITICAL_PLAN MEDIUM 20 0 0 20 0 0

CRITICAL_PLAN LOW 10 0 0 10 0 0

CRITICAL_PLAN OTHER_GROUPS 10 0 0 10 0 0

Assign consumer groups to USERS:

SHAIKDB>create user test1 identified by test1 default tablespace tbs1 temporary tablespace temp;

User created.

SHAIKDB>grant create session to test1;

Grant succeeded.

SHAIKDB>grant select any table to test1;

Grant succeeded.

SHAIKDB>select username,account_status,INITIAL_RSRC_CONSUMER_GROUP from dba_users where username='TEST1';

USERNAME ACCOUNT_STATUS INITIAL_RSRC_CONSUMER_GROUP

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

TEST1 OPEN DEFAULT_CONSUMER_GROUP

SHAIKDB>exec dbms_resource_manager_privs.grant_switch_consumer_group(grantee_name=>'TEST1',consumer_group=>'LOW',grant_option=>TRUE);

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_resource_manager.set_initial_consumer_group(user=>'TEST1',consumer_group=>'LOW');

PL/SQL procedure successfully completed.

SHAIKDB>SELECT * FROM DBA_RSRC_CONSUMER_GROUP_PRIVS;

GRANTEE GRANTED_GROUP GRA INI

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

PUBLIC DEFAULT_CONSUMER_GROUP YES YES

SYSTEM SYS_GROUP NO YES

TEST1 LOW YES YES

PUBLIC LOW_GROUP NO NO

SHAIKDB>select username,account_status,INITIAL_RSRC_CONSUMER_GROUP from dba_users where username='TEST1';

USERNAME ACCOUNT_STATUS INITIAL_RSRC_CONSUMER_GROUP

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

TEST1 OPEN LOW

SHAIKDB>SELECT SID,SERIAL#,USERNAME,RESOURCE_CONSUMER_GROUP FROM V$SESSION where username='TEST1';

no rows selected

SHAIKDB>/

SID SERIAL# USERNAME RESOURCE_CONSUMER_GROUP

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

50 2546 TEST1 OTHER_GROUPS

SHAIKDB>/

SWITCHING CONSUMER_GROUPS:

SHAIKDB>exec dbms_resource_manager.switch_consumer_group_for_sess('50','2546','MEDIUM');

PL/SQL procedure successfully completed.

SHAIKDB>SELECT SID,SERIAL#,USERNAME,RESOURCE_CONSUMER_GROUP FROM V$SESSION where username='TEST1';

SID SERIAL# USERNAME RESOURCE_CONSUMER_GROUP

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

50 2546 TEST1 MEDIUM

SHAIKDB>exec dbms_resource_manager.switch_consumer_group_for_user('TEST1','CRITICAL');

PL/SQL procedure successfully completed.

SHAIKDB>SELECT SID,SERIAL#,USERNAME,RESOURCE_CONSUMER_GROUP FROM V$SESSION where username='TEST1';

SID SERIAL# USERNAME RESOURCE_CONSUMER_GROUP

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

50 2546 TEST1 CRITICAL

Revoking Switch Privileges

SHAIKDB>exec dbms_resource_manager_privs.revoke_switch_consumer_group(revokee_name=>'TEST1',consumer_group=>'LOW');

PL/SQL procedure successfully completed.

Documentation:

Oracle® Database PL/SQL Packages and Types Reference --> 116 DBMS_RESOURCE_MANAGER

Oracle® Database Administrator's Guide 11g Release 2 (11.2) -->

26 Managing Resource Allocation with Oracle Database Resource Manager

↧

Administer Resource Manager using dbconsole:

October 4, 2015, 6:27 pm

≫ Next: Result Cache:

≪ Previous: Administer Resource Manager

Administer Resource Manager using dbconsole:

[oracle@collabn1 ~]$ emctl status dbconsole

Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0

http://collabn1.shaiksameer:5501/em/console/aboutApplication

Oracle Enterprise Manager 11g is running.

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

Logs are generated in directory /u01/app/oracle/product/11.2.0.2/SHAIKPROD/collabn1_SHAIKDB/sysman/log

Go to Server → Resource Manager

Delete a PLAN:

Click Plans:

Create Consumer Group:

Go to Server → Resource Manager → Consumer Group:

Delete consumer Group “MEDIUM”

Create Consumer Groups:

Create Groups “LOW” & “MEDIUM”

Create CRITICAL_PLAN & Add the Consumer Groups “CRITICAL”,”MEDIUM”,”LOW” to “CRITICAL_PLAN”

Go to Server → Resource Manager → Plans → Create

Modify CPU %:

Change Parallelism Settings:

Change Session details:

Click “OK”

Summary:

Modify the PLAN to different CPU level:

Assign the consumer groups to the users TEST1 & TEST2:

Before Assignments:

SHAIKDB>SELECT SID,SERIAL#,USERNAME,RESOURCE_CONSUMER_GROUP FROM V$SESSION where username in ('TEST1','TEST2');

no rows selected

SHAIKDB>/

SID SERIAL# USERNAME RESOURCE_CONSUMER_GROUP

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

38 2646 TEST1 OTHER_GROUPS

65 4887 TEST2 OTHER_GROUPS

Map consumer groups to Users:

Regroup/Prioritize the groups for Oracle OS User:

Add consumer group CRITICAL to TEST1:

Add consumer group MIDDLE to TEST2:

Activate the PLAN → CRITICAL_PLAN

SHAIKDB>SELECT SID,SERIAL#,USERNAME,RESOURCE_CONSUMER_GROUP FROM V$SESSION where username in ('TEST1','TEST2');

       SID    SERIAL# USERNAME                 RESOURCE_CONSUMER_GROUP
---------- ---------- ------------------------------ --------------------------------
    38    2646 TEST1                 CRITICAL
    65    4887 TEST2                 MEDIUM

Documentation:

Oracle® Database PL/SQL Packages and Types Reference --> 116 DBMS_RESOURCE_MANAGER

Oracle® Database Administrator's Guide 11g Release 2 (11.2) -->

26 Managing Resource Allocation with Oracle Database Resource Manager

↧

Result Cache:

October 4, 2015, 7:33 pm

≫ Next: Use multi column statistics

≪ Previous: Administer Resource Manager using dbconsole:

Result Cache:

A result cache is an area of memory, either in the SGA or client application memory, that stores the result of a database query or query block for reuse. The cached rows are shared across statements and sessions unless they become stale.

Managing the Server Result Cache

The server result cache is a memory pool within the shared pool. This pool contains a SQL query result cache, which stores results of SQL queries, and a PL/SQL function result cache, which stores values returned by PL/SQL functions.

How the Server Result Cache Works

When a query executes, the database looks in the cache memory to determine whether the result exists in the cache. If the result exists, then the database retrieves the result from memory instead of executing the query. If the result is not cached, then the database executes the query, returns the result as output, and stores the result in the result cache.

When users execute queries and functions repeatedly, the database retrieves rows from the cache, decreasing response time. Cached results become invalid when data in dependent database objects is modified.

Server Result Cache Initialization Parameters

The following database initialization parameters control the server result cache:

RESULT_CACHE_MAX_SIZE

This parameter sets the memory allocated to the server result cache. The server result cache is enabled unless you set this parameter to 0, in which case the cache is disabled.

RESULT_CACHE_MAX_RESULT

This parameter sets the maximum amount of server result cache memory that can be used for for a single result. The default is 5%, but you can specify any percentage value between 1 and 100. You can set this parameter at the system or session level.

RESULT_CACHE_REMOTE_EXPIRATION

This parameter specifies the expiration time for a result in the server result cache that depends on remote database objects. The default value is 0 minutes, which implies that results using remote objects should not be cached.

Managing Server Result Cache Memory with Initialization Parameters

By default, on database startup, Oracle Database allocates memory to the server result cache in the shared pool. The memory size allocated depends on the memory size of the shared pool and the memory management system. The database uses the following algorithm:

When using the MEMORY_TARGET initialization parameter to specify the memory allocation, Oracle Database allocates 0.25% of MEMORY_TARGET to the result cache.
When you set the size of the shared pool using the SGA_TARGET initialization parameter, Oracle Database allocates 0.50% of SGA_TARGET to the result cache.
If you specify the size of the shared pool using the SHARED_POOL_SIZE initialization parameter, then Oracle Database allocates 1% of the shared pool size to the result cache.

The size of the server result cache grows until reaching the maximum size. Query results larger than the available space in the cache are not cached. The database employs an LRU algorithm to age out cached results, but does not otherwise automatically release memory from the server result cache.

Purge RESULT CACHE:

You can use the DBMS_RESULT_CACHE.FLUSH procedure to purge memory.

Oracle Database will not allocate more than 75% of the shared pool to the server result cache.

RESULT CACHE Report:

SHAIKDB>SET SERVEROUTPUT ON

SHAIKDB>EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT

R e s u l t C a c h e M e m o r y R e p o r t

[Parameters]

Block Size = 1K bytes

Maximum Cache Size = 1760K bytes (1760 blocks)

Maximum Result Size = 88K bytes (88 blocks)

[Memory]

Total Memory = 10696 bytes [0.005% of the Shared Pool]

... Fixed Memory = 10696 bytes [0.005% of the Shared Pool]

... Dynamic Memory = 0 bytes [0.000% of the Shared Pool]

PL/SQL procedure successfully completed.

Client Result Cache Initialization Parameters

Initialization Parameter	Description
CLIENT_RESULT_CACHE_SIZE	Sets the maximum size of the client result cache for each client process. To enable the client result cache, set the size to 32768 bytes or greater. A lesser value, including the default of 0, disables the client result cache. Note: If the CLIENT_RESULT_CACHE_SIZE setting disables the client cache, then a client node cannot enable it. If the CLIENT_RESULT_CACHE_SIZE setting enables the client cache, however, then a client node can override the setting. For example, a client node can disable client result caching or increase the size of its cache.
CLIENT_RESULT_CACHE_LAG	Specifies the amount of lag time for the client result cache. If the OCI application performs no database calls for a period of time, then the client cache lag setting forces the next statement execution call to check for validations. If the OCI application accesses the database infrequently, then setting this parameter to a low value results in more round trips from the OCI client to the database to keep the client result cache synchronized with the database. The client cache lag is specified in milliseconds, with a default value of 3000 (3 seconds).
COMPATIBLE	Specifies the release with which Oracle must maintain compatibility. For the client result cache to be enabled, this parameter must be set to 11.0.0.0 or higher. For client caching on views, this parameter must be set to 11.2.0.0.0 or higher.

Result Cache Mode

The result cache mode is a database setting that determines which queries are eligible to store result sets in the client and server result caches.

Value	Default	Description
MANUAL	Yes	Query results can only be stored in the result cache by using a query hint or table annotation. This is the recommended value.
FORCE	No	All results are stored in the result cache. If a query result is not in the cache, then the database executes the query and stores the result in the cache. Subsequent executions of the same statement, including the result cache hint, retrieve data from the cache. Sessions uses these results if possible. To exclude query results from the cache, you must use the /+ NO_RESULT_CACHE / query hint. Note: FORCE mode is not recommended because the database and clients attempt to cache all queries, which can create significant performance and latching overhead.

Result cache hints at the application level to control caching behavior. The SQL result cache hints take precedence over the result cache mode and result cache table annotations.

Demo:

SHAIKDB>show parameter result

NAME TYPE VALUE

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

client_result_cache_lag big integer 3000

client_result_cache_size big integer 0

result_cache_max_result integer 5

result_cache_max_size big integer 1760K

result_cache_mode string MANUAL

result_cache_remote_expiration integer 0

SHAIKDB>select name,type,status,object_no,row_count from v$result_cache_objects;

no rows selected

SHAIKDB>select count(*) from result2;

COUNT(*)

----------

227328

SHAIKDB>desc result2;

Name Null? Type

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

EMPLOYEE_ID NUMBER(6)

FIRST_NAME VARCHAR2(20)

LAST_NAME NOT NULL VARCHAR2(25)

EMAIL NOT NULL VARCHAR2(25)

PHONE_NUMBER VARCHAR2(20)

HIRE_DATE NOT NULL DATE

JOB_ID NOT NULL VARCHAR2(10)

SALARY NUMBER(8,2)

COMMISSION_PCT NUMBER(2,2)

MANAGER_ID NUMBER(6)

DEPARTMENT_ID NUMBER(4)

SSN NUMBER(9)

SHAIKDB>set timing on time on

22:08:07 SHAIKDB>

22:08:54 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

2048

Elapsed: 00:00:00.02

22:09:41 SHAIKDB>set echo on

22:10:10 SHAIKDB>set autot on exp

22:10:22 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

2048

Elapsed: 00:00:00.00

Execution Plan

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

Plan hash value: 3939577969

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

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

| 0 | SELECT STATEMENT | | 1 | 13 | 651 (1)| 00:00:08 |

| 2 | SORT AGGREGATE | | 1 | 13 | | |

|* 3 | TABLE ACCESS FULL| RESULT2 | 2086 | 27118 | 651 (1)| 00:00:08 |

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

Predicate Information (identified by operation id):

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

3 - filter("EMPLOYEE_ID"=100)

Result Cache Information (identified by operation id):

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

1 - column-count=1; dependencies=(TEST2.RESULT2); attributes=(single-row); name="select /*+ resul

t_cache result2 */ count(*) from result2 where employee_id=100"

Note

-----

- dynamic sampling used for this statement (level=2)

SHAIKDB>set linesize 600

SHAIKDB>col name for a50

SHAIKDB>select name,type,status,object_no,row_count from v$result_cache_objects;

NAME TYPE STATUS OBJECT_NO ROW_COUNT

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

TEST2.RESULT2 Dependency Published 78641 0

select /*+ result_cache result2 */ count(*) from r Result Published 0 1

esult2 where employee_id=100

22:10:26 SHAIKDB>set autot off

22:14:31 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

2048

Elapsed: 00:00:00.00

SHAIKDB>alter system flush buffer_cache;

System altered.

22:14:39 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

2048

Elapsed: 00:00:00.01

22:15:45 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

2048

Elapsed: 00:00:00.00

22:15:45 SHAIKDB>insert into result2 select * from hr.employees where employee_id=100;

1 row created.

Elapsed: 00:00:00.02

22:17:06 SHAIKDB>commit;

Commit complete.

Elapsed: 00:00:00.00

22:17:09 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

2049

Elapsed: 00:00:00.03

22:17:16 SHAIKDB>set autot on exp

22:17:34 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

2049

Elapsed: 00:00:00.00

Execution Plan

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

Plan hash value: 3939577969

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

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

| 0 | SELECT STATEMENT | | 1 | 13 | 651 (1)| 00:00:08 |

| 2 | SORT AGGREGATE | | 1 | 13 | | |

|* 3 | TABLE ACCESS FULL| RESULT2 | 2086 | 27118 | 651 (1)| 00:00:08 |

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

Predicate Information (identified by operation id):

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

3 - filter("EMPLOYEE_ID"=100)

Result Cache Information (identified by operation id):

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

1 - column-count=1; dependencies=(TEST2.RESULT2); attributes=(single-row); name="select /*+ resul

t_cache result2 */ count(*) from result2 where employee_id=100"

Note

-----

- dynamic sampling used for this statement (level=2)

22:26:41 SHAIKDB>delete result2 where employee_id=100 and rownum <=500;

500 rows deleted.

Elapsed: 00:00:00.03

SHAIKDB>select name,type,status,object_no,row_count from v$result_cache_objects;

NAME TYPE STATUS OBJECT_NO ROW_COUNT

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

TEST2.RESULT2 Dependency Published 78641 0

select /*+ result_cache result2 */ count(*) from r Result Published 0 1

esult2 where employee_id=100

select /*+ result_cache result2 */ count(*) from r Result Invalid 0 1

esult2 where employee_id=100

22:28:34 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

1549

Elapsed: 00:00:00.05

SHAIKDB>set serveroutput on

SHAIKDB>exec dbms_result_cache.memory_report(detailed=>true);

R e s u l t C a c h e M e m o r y R e p o r t

[Parameters]

Block Size = 1K bytes

Maximum Cache Size = 1760K bytes (1760 blocks)

Maximum Result Size = 88K bytes (88 blocks)

[Memory]

Total Memory = 174752 bytes [0.082% of the Shared Pool]

... Fixed Memory = 10696 bytes [0.005% of the Shared Pool]

....... Memory Mgr = 200 bytes

....... Bloom Fltr = 2K bytes

....... Cache Mgr = 5552 bytes

....... State Objs = 2896 bytes

... Dynamic Memory = 164056 bytes [0.077% of the Shared Pool]

....... Overhead = 131288 bytes

........... Hash Table = 64K bytes (4K buckets)

........... Chunk Ptrs = 24K bytes (3K slots)

........... Chunk Maps = 12K bytes

........... Miscellaneous = 28888 bytes

....... Cache Memory = 32K bytes (32 blocks)

........... Unused Memory = 29 blocks

........... Used Memory = 3 blocks

............... Dependencies = 1 blocks (1 count)

............... Results = 2 blocks

................... SQL = 1 blocks (1 count)

................... Invalid = 1 blocks (1 count)

PL/SQL procedure successfully completed.

SHAIKDB> exec dbms_result_cache.flush;

PL/SQL procedure successfully completed.

SHAIKDB>select name,type,status,object_no,row_count from v$result_cache_objects;

no rows selected

22:31:51 SHAIKDB>select /*+ result_cache result2 */ count(*) from result2 where employee_id=100;

COUNT(*)

----------

1549

Elapsed: 00:00:00.01

22:32:29 SHAIKDB>/

COUNT(*)

----------

1549

Elapsed: 00:00:00.00

Dictionary Views:

View/Table	Description
V$RESULT_CACHE_STATISTICS	Lists various server result cache settings and memory usage statistics.
V$RESULT_CACHE_MEMORY	Lists all the memory blocks in the server result cache and their corresponding statistics.
V$RESULT_CACHE_OBJECTS	Lists all the objects whose results are in the server result cache along with their attributes.
V$RESULT_CACHE_DEPENDENCY	Lists the dependency details between the results in the server cache and dependencies among these results.
CLIENT_RESULT_CACHE_STATS$	Stores cache settings and memory usage statistics for the client result caches obtained from the OCI client processes. This statistics table has entries for each client process that is using result caching. After the client processes terminate, the database removes their entries from this table. The client table lists information similar to V$RESULT_CACHE_STATISTICS.
DBA_TABLES, USER_TABLES, ALL_TABLES	Includes a RESULT_CACHE column that shows the result cache mode annotation for the table. If the table has not been annotated, then this column shows DEFAULT. This column applies to both server and client result caching.

Documentation:

Oracle® Database Performance Tuning Guide 11g Release 2 (11.2)--> 7.6 Managing the Server and Client Result Caches

↧

Use multi column statistics

October 5, 2015, 8:24 pm

≫ Next: How to install go on MAC

≪ Previous: Result Cache:

Using multi column statistics

MultiColumn Statistics

When multiple columns from a single table are used together in the where clause of a query (multiple single column predicates), the relationship between the columns can strongly affect the combined selectivity for the column group.

By default, Oracle creates column groups for a table, based on the workload analysis, similar to how it is done for histograms.

You can also create column groups manually by using the DBMS_STATS package. You can use this package to create a column group, get the name of a column group, or delete a column group from a table.

**** The optimizer will only use MultiColumn statistics with equality predicates *****

Creating a Column Group

Use the create_extended_statistics function to create a column group. The create_extended_statistics function returns the system-generated name of the newly created column group

Parameter	Description
owner	Schema owner. NULL indicates current schema.
tab_name	Name of the table to which the column group is being added.
extension	Columns in the column group.

Getting a Column Group

Use the show_extended_stats_name function to obtain the name of the column group for a given set of columns

Parameter	Description
owner	Schema owner. NULL indicates current schema.
tab_name	Name of the table to which the column group belongs.
extension	Name of the column group.

Dropping a Column Group

Use the drop_extended_stats function to delete a column group from a table.

Parameter	Description
owner	Schema owner. NULL indicates current schema.
tab_name	Name of the table to which the column group belongs.
extension	Name of the column group to be deleted.

Gathering Statistics on Column Groups

The METHOD_OPT argument of the DBMS_STATS package enables you to gather statistics on column groups. If you set the value of this argument to FOR ALL COLUMNS SIZE AUTO, the optimizer will gather statistics on all the existing column groups. To collect statistics on a new column group, specify the group using FOR COLUMNS. The column group will be automatically created as part of statistic gathering.

DBMS_STATS package "DBMS_STATS.SEED_COL_USAGE" is used to identify candidate columns for Extended Statistics. This procedure generates candidates for extended statistics when a representative dataload is being played in database.

A second procedure DBMS_STATS.CREATE_EXTENDED_STATS() can be used to define the relationship between the columns that have been identified.

DBMS_STATS.SEED_COL_USAGE can be executed few times in peak load. This will identify all the columns which need Extended Statistics.

DEMO:

====

SHAIKDB>create table ext_columns as select * from dba_tables;

Table created.

SHAIKDB>select count(*) from ext_columns;

COUNT(*)

----------

2795

SHAIKDB>select count(*),segment_created from dba_tables group by segment_created;

COUNT(*) SEG

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

826 NO

1900 YES

70 N/A

SHAIKDB>exec dbms_stats.gather_table_stats('test1','ext_columns');

PL/SQL procedure successfully completed.

SHAIKDB>exec dbms_stats.gather_index_stats('test1','ext_columns_idx');

PL/SQL procedure successfully completed.

SHAIKDB>set autot on exp

SHAIKDB>select count(*) from ext_columns where num_rows=0 and dropped='YES';

COUNT(*)

----------

Execution Plan

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

Plan hash value: 1088373390

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

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

| 0 | SELECT STATEMENT | | 1 | 6 | 4 (0)| 00:00:01 |

| 1 | SORT AGGREGATE | | 1 | 6 | | |

|* 2 | TABLE ACCESS BY INDEX ROWID| EXT_COLUMNS | 1 | 6 | 4 (0)| 00:00:01 |

|* 3 | INDEX RANGE SCAN | EXT_COLUMNS_IDX | 7 | | 1 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

2 - filter("DROPPED"='YES')

3 - access("NUM_ROWS"=0)

SHAIKDB>select count(*) from ext_columns where num_rows=0 and dropped='NO';

COUNT(*)

----------

1704

Execution Plan

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

Plan hash value: 1088373390

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

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

| 0 | SELECT STATEMENT | | 1 | 6 | 4 (0)| 00:00:01 |

| 1 | SORT AGGREGATE | | 1 | 6 | | |

|* 2 | TABLE ACCESS BY INDEX ROWID| EXT_COLUMNS | 7 | 42 | 4 (0)| 00:00:01 |

|* 3 | INDEX RANGE SCAN | EXT_COLUMNS_IDX | 7 | | 1 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

2 - filter("DROPPED"='NO')

3 - access("NUM_ROWS"=0)

In the above plan it shows the number of rows that matches the criteria is 7 for index_range_Scan and for the select statement “2”

In reality the selective count is far more greater than that.

SHAIKDB>select count(*) from ext_columns where num_rows=0 and dropped='NO';

COUNT(*)

----------

1704

SHAIKDB>select count(*) from ext_columns where num_rows=0 and dropped='YES';

COUNT(*)

----------

SHAIKDB>select count(*) from ext_columns where num_rows=0;

COUNT(*)

----------

1704

Above NUM_ROWS and DROPPED columns are related.

SHAIKDB>Select dbms_stats.create_extended_stats('TEST1','EXT_COLUMNS','(NUM_ROWS,DROPPED)') FROM DUAL;

DBMS_STATS.CREATE_EXTENDED_STATS('TEST1','EXT_COLUMNS','(NUM_ROWS,DROPPED)')

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

SYS_STUEXUYKWMBP9B#CB$NYP#P8I5

SHAIKDB>col EXTENSION_NAME for a30

SHAIKDB>col EXTENSION for a30

SHAIKDB>/

SHAIKDB>SELECT extension_name, extension FROM dba_stat_extensions WHERE table_name = 'EXT_COLUMNS';

EXTENSION_NAME EXTENSION

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

SYS_STUEXUYKWMBP9B#CB$NYP#P8I5 ("NUM_ROWS","DROPPED")

After the extension creation it shows the ROWS as 7.

SHAIKDB>set autot on exp

SHAIKDB>select count(*) from ext_columns where num_rows=0 and dropped='NO';

COUNT(*)

----------

1704

Execution Plan

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

Plan hash value: 1088373390

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

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

| 0 | SELECT STATEMENT | | 1 | 6 | 4 (0)| 00:00:01 |

| 1 | SORT AGGREGATE | | 1 | 6 | | |

|* 2 | TABLE ACCESS BY INDEX ROWID| EXT_COLUMNS | 7 | 42 | 4 (0)| 00:00:01 |

|* 3 | INDEX RANGE SCAN | EXT_COLUMNS_IDX | 7 | | 1 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

2 - filter("DROPPED"='NO')

3 - access("NUM_ROWS"=0)

Gather the stats now.

SHAIKDB>exec dbms_stats.gather_table_stats('test1','ext_columns');

PL/SQL procedure successfully completed.

SHAIKDB>select count(*) from ext_columns where num_rows=0 and dropped='NO';

COUNT(*)

----------

1704

Execution Plan

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

Plan hash value: 3344132040

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

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

| 0 | SELECT STATEMENT | | 1 | 6 | 31 (0)| 00:00:01 |

| 1 | SORT AGGREGATE | | 1 | 6 | | |

|* 2 | TABLE ACCESS FULL| EXT_COLUMNS | 1660 | 9960 | 31 (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

2 - filter("NUM_ROWS"=0 AND "DROPPED"='NO')

Reflects the correct number of rows.

Documentation:

Oracle® Database Performance Tuning Guide

11g Release 2 (11.2)

Part Number E16638-06

Chapter 13 Managing Optimizer Statistics

Section 13.3.1.5 Extended Statistics

http://docs.oracle.com/cd/E29505_01/server.1111/e16638/stats.htm#PFGRF94725

Oracle® Database PL/SQL Packages and Types Reference

11g Release 2 (11.2)

Part Number E25788-04

Chater 141 DBMS_STATS

Extended Statistics

http://www.oracle86.com/11gr2/appdev.112/e25788/d_stats.htm#BABDGGEE

↧

How to install go on MAC

October 8, 2015, 10:44 am

≫ Next: Gather statistics on a specific table without invalidating cursors:

≪ Previous: Use multi column statistics

How to install

on MAC

Download

Download it from → https://golang.org/dl/

Pick the OS.

Download the package

Open the downloaded package:

Click “Continue”

Select “all users” → Click “Continue”

Click “Instal”

Enter “Password” → Click “Instal Software”

Wait for the install to complete

Summary:

That’s it you are done.

Package Details:

The package installs the Go distribution under /usr/local/go.

shaiks@MAC$ls -lrt /usr/local/go/

total 168

drwxr-xr-x 7 root wheel 238 Sep 8 21:31 pkg

drwxr-xr-x 15 root wheel 510 Sep 8 21:31 misc

drwxr-xr-x 3 root wheel 102 Sep 8 21:31 lib

-rw-r--r-- 1 root wheel 1150 Sep 8 21:31 favicon.ico

drwxr-xr-x 39 root wheel 1326 Sep 8 21:31 doc

drwxr-xr-x 4 root wheel 136 Sep 8 21:31 blog

drwxr-xr-x 5 root wheel 170 Sep 8 21:31 bin

drwxr-xr-x 11 root wheel 374 Sep 8 21:31 api

-rw-r--r-- 1 root wheel 7 Sep 8 21:31 VERSION

-rw-r--r-- 1 root wheel 1519 Sep 8 21:31 README.md

-rw-r--r-- 1 root wheel 1303 Sep 8 21:31 PATENTS

-rw-r--r-- 1 root wheel 1479 Sep 8 21:31 LICENSE

-rw-r--r-- 1 root wheel 28953 Sep 8 21:31 CONTRIBUTORS

-rw-r--r-- 1 root wheel 1107 Sep 8 21:31 CONTRIBUTING.md

-rw-r--r-- 1 root wheel 21146 Sep 8 21:31 AUTHORS

drwxr-xr-x 234 root wheel 7956 Sep 8 21:32 test

drwxr-xr-x 63 root wheel 2142 Sep 8 21:32 src

-rw-r--r-- 1 root wheel 26 Sep 8 21:32 robots.txt

The package should put the /usr/local/go/bin directory in your PATH environment variable. You may need to restart any open Terminal sessions for the change to take effect.

shaiks@MAC$echo $PATH

/usr/local/git/current/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/go/bin

Create Project Workspace:

shaiks@MAC$mkdir $HOME/mygo

shaiks@MAC$echo "export GOPATH=$HOME/mygo">> ~/.profile

shaiks@MAC$echo "export GOBIN=$GOPATH/bin">> ~/.profile

shaiks@MAC$cat .profile | grep GO

export GOPATH=/Users/shaiksameer/mygo

export GOBIN=$GOPATH/bin

Test go:

shaiks@MAC$pwd

/Users/shaiksameer/mygo

shaiks@MAC$mkdir -p src/hello

shaiks@MAC$pwd

/Users/shaiksameer/mygo/src

Create a sample program

shaiks@MAC$vi /Users/shaiksameer/mygo/src/hello/hello.go

package main

import "fmt"

func main() {
fmt.Printf("hello, world\n")
}

shaiks@MAC$cd ..

shaiks@MAC$go install src/hello/hello.go

It creates a bin directory and executable file called “hello” under bin directory.

Execute the little program from the bin dir:

shaiks@MAC$./bin/hello

hello, world

Or Use compile & run in single command.

shaiks@MAC$go run src/hello/hello.go

Hey!

Mr. Sameer Shaik

Resources:

https://www.youtube.com/watch?v=XCsL89YtqCs

↧

Gather statistics on a specific table without invalidating cursors:

October 13, 2015, 6:02 pm

≫ Next: TNS-12508: TNS:listener could not resolve the COMMAND given

≪ Previous: How to install go on MAC

Gather statistics on a specific table without invalidating cursors:

no_invalidae

Does not invalidate the dependent cursors if set to TRUE. The procedure invalidates the dependent cursors immediately if set to FALSE. Use DBMS_STATS.AUTO_INVALIDATE. to have Oracle decide when to invalidate dependent cursors. This is the default. The default can be changed using the SET_DATABASE_PREFS Procedure, SET_GLOBAL_PREFS Procedure, SET_SCHEMA_PREFS Procedure and SET_TABLE_PREFS Procedure.

SHAIKDB>select parsing_schema_name,sql_id,invalidations from v$sql where parsing_schema_name='TEST1';

PARSING_SCHEMA_NAME SQL_ID INVALIDATIONS

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

TEST1 g4y6nw3tts7cc 0

TEST1 cf19zu91tn7mj 0

TEST1 dyk4dprp70d74 0

TEST1 gpp46471wp37k 0

TEST1 5qgz1p0cut7mx 0

TEST1 g3f3cw3zy5aat 0

TEST1 fkh6yuk3jpayv 0

TEST1 c0j6cx9kzjf7g 0

TEST1 g93x9gquu9t13 0

TEST1 99qa3zyarxvms 0

TEST1 g72kdvcacxvtf 0

TEST1 8wfgaknkskb14 0

TEST1 d6vwqbw6r2ffk 0

TEST1 cw6vxf0kbz3v1 0

TEST1 7hys3h7ysgf9m 0

15 rows selected.

SHAIKDB>select PARSING_SCHEMA_NAME,sql_id,sql_text,invalidations from v$sql where PARSING_SCHEMA_NAME='TEST1' and upper(sql_text) like '%EXT_COLUMNS%';

PARSING_SC SQL_ID SQL_TEXT INVALIDATIONS

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

TEST1 0kmkdmr78n6rj select PARSING_SCHEMA_NAME,sql_id,sql_text,invalidations from v$sql where PARSIN 0

G_SCHEMA_NAME='TEST1' and upper(sql_text) like 'EXT_COLUMNS'

TEST1 8bnh5pqv9t49q select PARSING_SCHEMA_NAME,sql_id,sql_text,invalidations from v$sql where PARSIN 0

G_SCHEMA_NAME='TEST1' and sql_text like 'EXT_COLUMNS'

TEST1 fkh6yuk3jpayv select /*+ no_parallel_index(t, "EXT_COLUMNS_IDX") dbms_stats cursor_sharing_exa 0

ct use_weak_name_resl dynamic_sampling(0) no_monitoring no_substrb_pad no_expan

d index(t,"EXT_COLUMNS_IDX") */ count(*) as nrw,count(distinct sys_op_lbid(78734

,'L',t.rowid)) as nlb,null as ndk,sys_op_countchg(substrb(t.rowid,1,15),1) as cl

f from "TEST1"."EXT_COLUMNS" t where "NUM_ROWS" is not null

TEST1 g93x9gquu9t13 select min(minbkt),maxbkt,substrb(dump(min(val),16,0,32),1,120) minval,substrb(d 0

ump(max(val),16,0,32),1,120) maxval,sum(rep) sumrep, sum(repsq) sumrepsq, max(re

p) maxrep, count(*) bktndv, sum(case when rep=1 then 1 else 0 end) unqrep from (

select val,min(bkt) minbkt, max(bkt) maxbkt, count(val) rep, count(val)*count(va

l) repsq from (select /*+ no_parallel(t) no_parallel_index(t) dbms_stats cursor_

sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring no_substrb_pa

d */"NUM_ROWS" val, ntile(254) over (order by "NUM_ROWS") bkt from "TEST1"."EXT

_COLUMNS" t where "NUM_ROWS" is not null) group by val) group by maxbkt order b

y maxbkt

TEST1 9tu5t6fm8f34k select PARSING_SCHEMA_NAME,sql_id,sql_text,invalidations from v$sql where PARSIN 0

G_SCHEMA_NAME='TEST1' and upper(sql_text) like '%EXT_COLUMNS%'

TEST1 29188am21rjc4 select * from ext_columns where num_rows=0 0

6 rows selected.

SHAIKDB>exec dbms_stats.gather_table_stats('TEST1','EXT_COLUMNS',NO_INVALIDATE=>TRUE);

PL/SQL procedure successfully completed.

SHAIKDB>select PARSING_SCHEMA_NAME,sql_id,sql_text,invalidations from v$sql where PARSING_SCHEMA_NAME='TEST1' and upper(sql_text) like '%EXT_COLUMNS%';

PARSING_SC SQL_ID SQL_TEXT INVALIDATIONS

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

TEST1 0kmkdmr78n6rj select PARSING_SCHEMA_NAME,sql_id,sql_text,invalidations from v$sql where PARSIN 0

G_SCHEMA_NAME='TEST1' and upper(sql_text) like 'EXT_COLUMNS'

TEST1 d78xb1kzg8h3u select * from ext_columns where segment_created='NO' 0

TEST1 8bnh5pqv9t49q select PARSING_SCHEMA_NAME,sql_id,sql_text,invalidations from v$sql where PARSIN 0

G_SCHEMA_NAME='TEST1' and sql_text like 'EXT_COLUMNS'

TEST1 fvxzppp6dda2d BEGIN dbms_stats.gather_table_stats('TEST1','EXT_COLUMNS',NO_INVALIDATE=>TRUE); 0

END;

TEST1 fkh6yuk3jpayv select /*+ no_parallel_index(t, "EXT_COLUMNS_IDX") dbms_stats cursor_sharing_exa 0

ct use_weak_name_resl dynamic_sampling(0) no_monitoring no_substrb_pad no_expan

d index(t,"EXT_COLUMNS_IDX") */ count(*) as nrw,count(distinct sys_op_lbid(78734

,'L',t.rowid)) as nlb,null as ndk,sys_op_countchg(substrb(t.rowid,1,15),1) as cl

f from "TEST1"."EXT_COLUMNS" t where "NUM_ROWS" is not null

TEST1 fa216vary5rhd select substrb(dump(val,16,0,32),1,120) ep, cnt from (select /*+ no_parallel(t) 0

no_parallel_index(t) dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_

sampling(0) no_monitoring no_substrb_pad */max("SEGMENT_CREATED") val,count(*) c

nt from "TEST1"."EXT_COLUMNS" t where "SEGMENT_CREATED" is not null group by

nlssort("SEGMENT_CREATED", 'NLS_SORT = binary')) order by nlssort(val,'NLS_SORT

= binary')