Showing posts with label value. Show all posts
Showing posts with label value. Show all posts

Friday, March 23, 2012

Introduction to Auditing

A database’s audit trail is stored in the SYS.AUD$ table:

SQL> desc sys.aud$
Name                       Null?    Type
-------------------------- -------- ------------------
SESSIONID                  NOT NULL NUMBER
ENTRYID                    NOT NULL NUMBER
STATEMENT                  NOT NULL NUMBER
TIMESTAMP#                 NOT NULL DATE
USERID                              VARCHAR2(30)
USERHOST                            VARCHAR2(128)
TERMINAL                            VARCHAR2(255)
ACTION#                    NOT NULL NUMBER
RETURNCODE                 NOT NULL NUMBER
OBJ$CREATOR                         VARCHAR2(30)
OBJ$NAME                            VARCHAR2(128)
AUTH$PRIVILEGES                     VARCHAR2(16)
AUTH$GRANTEE                        VARCHAR2(30)
NEW$OWNER                           VARCHAR2(30)
NEW$NAME                            VARCHAR2(128)
SES$ACTIONS                         VARCHAR2(19)
SES$TID                             NUMBER
LOGOFF$LREAD                        NUMBER
LOGOFF$PREAD                        NUMBER
LOGOFF$LWRITE                       NUMBER
LOGOFF$DEAD                         NUMBER
LOGOFF$TIME                         DATE
COMMENT$TEXT                        VARCHAR2(4000)
CLIENTID                            VARCHAR2(64)
SPARE1                              VARCHAR2(255)
SPARE2                              NUMBER
OBJ$LABEL                           RAW(255)
SES$LABEL                           RAW(255)
PRIV$USED                           NUMBER
SESSIONCPU                          NUMBER
 
SQL>
 
You can tell Oracle what to monitor using the AUDIT command. The example below will record when the SYSTEM user connects to the database:
 
SQL> audit create session by system;
 
Audit succeeded.
 
SQL>
 
This database currently has auditing turned off i.e the audit_trail initialisation parameter is set to NONE:
 
SQL> l
  1  select value from v$parameter
  2* where name = 'audit_trail'
SQL> /
 
VALUE
------------------------------
NONE
 
SQL>
 
So subsequent logins by SYSTEM will not be recorded in SYS.AUD$:
 
SQL> conn system/manager
Connected.
SQL> select count(*) from sys.aud$
  2  /
 
  COUNT(*)
----------
         0
 
SQL>
 
In versions up to and including Oracle 11, you cannot turn auditing on while a database is open:
 
SQL> alter system set audit_trail = true;
alter system set audit_trail = true
                 *
ERROR at line 1:
ORA-02095: specified initialization parameter cannot
be modified
 
SQL>
 
You have to alter the pfile or spfile as appropriate and bounce the database. Once audit_trail is set to true, auditing will start working and a row will appear in SYS.AUD$ after SYSTEM has connected to the database:
 
SQL> select value from v$parameter
  2  where name = 'audit_trail'
  3  /
 
VALUE
------------------------------
TRUE
 
SQL> conn system/manager
Connected.
SQL> select count(*) from sys.aud$
  2  /
 
  COUNT(*)
----------
         1
 
SQL>
 
You can query records in SYS.AUD$ in the normal way. The TIMESTAMP# column has the logon time and a PRIV$USED of 5 stands for CREATE SESSION:
 
SQL> l
  1* select userid, timestamp#, priv$used from sys.aud$
SQL> /
 
USERID     TIMESTAMP#  PRIV$USED
---------- ---------- ----------
SYSTEM     21-MAR-12           5
 
SQL>
 
Various views record the auditing which you have asked Oracle to do in your database. The audit request we made above is stored in DBA_PRIV_AUDIT_OPTS:
 
SQL> select user_name, privilege
  2  from dba_priv_audit_opts
  3  /
 
USER_NAME            PRIVILEGE
-------------------- --------------------
SYSTEM               CREATE SESSION
 
SQL>
 
You can stop an audit request with the NOAUDIT command:
 
SQL> noaudit create session by system
  2  /
 
Noaudit succeeded.
 
SQL>
 
Once you have done this, the relevant entry disappears from DBA_PRIV_AUDIT_OPTS:
 
SQL> select user_name, privilege
  2  from dba_priv_audit_opts
  3  /
 
no rows selected
 
SQL>
 
And connections by SYSTEM will no longer be recorded in SYS.AUD$:
 
SQL> select count(*) from sys.aud$
  2  /
 
  COUNT(*)
----------
         1
 
SQL> conn system/manager
Connected.
SQL> select count(*) from sys.aud$
  2  /
 
  COUNT(*)
----------
         1
 
SQL>
 
Unlike other objects owned by SYS, you are allowed to delete rows from SYS.AUD$.
 
SQL> delete sys.aud$
  2  /
 
1 row deleted.
 
SQL>
 
However, you should check first that it does not contain rows produced by your colleagues with separate audit requests!

Friday, December 30, 2011

Hidden Parameters

Oracle has several hidden initialisation parameters. These have names which begin with an underscore. You can see them using the following query, which I ran on an Oracle 9 database:
 
SQL> l
  1  select ksppinm
  2  from   SYS.X$KSPPI
  3* where  substr(KSPPINM,1,1) = '_'
SQL> /
 
 
KSPPINM
-------------------------------------------------------
_trace_files_public
_latch_recovery_alignment
_spin_count
_latch_miss_stat_sid
_max_sleep_holding_latch
_max_exponential_sleep
_use_vector_post
_latch_class_0
_latch_class_1
_latch_class_2
_latch_class_3
 
Etc.
 
KSPPINM
-------------------------------------------------------
_xsolapi_sql_use_bind_variables
_xsolapi_sql_prepare_stmt_cache_size
_xsolapi_sql_result_set_cache_size
_xsolapi_debug_output
_xsolapi_cursor_use_row_cache
_xsolapi_cursor_max_rows_to_cache_per_req
_xsolapi_cursor_max_time_for_partial_cache
_xsolapi_source_trace
 
613 rows selected.
 
SQL>
 
What does it mean when we say they are hidden?  We can see the answer by comparison with an ordinary parameter e.g. sql_trace:
 
SQL> l
  1  select name, value, isdefault
  2  from v$parameter
  3* where name = 'sql_trace'
SQL> /
 
NAME       VALUE      ISDEFAULT
---------- ---------- ---------
sql_trace  FALSE      TRUE
 
SQL>
 
In this case, sql_trace is set to its default value of FALSE but it still has an entry in V$PARAMETER. A hidden parameter, on the other hand, does not have an entry in V$PARAMETER:
 
  1  select name, value, isdefault
  2  from v$parameter
  3* where name = '_trace_files_public'
SQL> /
 
no rows selected
 
SQL>
 
... unless it has been set on purpose. The query below was run on a different Oracle 9 database, which had _trace_files_public set in its parameter file:
 
SQL> l
  1  select name, value, isdefault
  2  from v$parameter
  3* where name = '_trace_files_public'
SQL> /
 
NAME                 VALUE      ISDEFAULT
-------------------- ---------- ---------
_trace_files_public  TRUE       FALSE
 
SQL>
 
Documentation for hidden parameters is not freely available. Oracle will tell you when to implement them, usually when they are replying to a service request. Advice from Oracle to implement a hidden parameter relates to a given database running on a specific Oracle version. I went to an 11g release 2 seminar run by Oracle recently. They discussed upgrade policy there and said that hidden parameters should be removed before an upgrade.

Wednesday, December 28, 2011

CPU_COUNT

According to Oracle’s own documentation for 10g release 1:
 
On most platforms, Oracle automatically sets the value of CPU_COUNT to the number of CPUs available to your Oracle instance. Do not change the value of CPU_COUNT.
 
The following test was done on an Oracle 9 database running on Tru64:
 
Tru64 > psrinfo -n
number of processors on system = 1
Tru64 > psrinfo -v
Status of processor 0 as of: 12/02/11 15:19:04
  Processor has been on-line since 02/19/2011 17:29:11
  The alpha EV6.7 (21264A) processor operates at 618 MHz,
  has a cache size of 2097152 bytes,
  and has an alpha internal floating point processor.
 
Tru64 > sqlplus '/ as sysdba'
 
SQL*Plus: Release 9.2.0.5.0 - Production on Fri Dec 2 15:19:28 2011
 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
 
SQL> col value format a10
SQL> col isdefault format a9
SQL> select value, isdefault from v$parameter
  2  where name = 'cpu_count'
  3  /
 
VALUE      ISDEFAULT
---------- ---------
1          TRUE
 
SQL>
 
The following test was done on an Oracle 9 database running on Linux:
 
Linux > cat /proc/cpuinfo | grep -i 'processor' | wc -l
2
Linux > sqlplus '/ as sysdba'
 
SQL*Plus: Release 9.2.0.4.0 - Production on Fri Dec 2 15:40:12 2011
 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
 
SQL> col value format a10
SQL> col isdefault format a9
SQL> select value, isdefault from v$parameter
  2  where name = 'cpu_count'
  3  /
 
VALUE      ISDEFAULT
---------- ---------
2          TRUE
 
SQL>
 
The following test was done on an Oracle 10 database running on Solaris:
 
Solaris > psrinfo -p -v
The physical processor has 2 virtual processors (0 16)
  UltraSPARC-IV+ (portid 0 impl 0x19 ver 0x22 clock 1500 MHz)
The physical processor has 2 virtual processors (2 18)
  UltraSPARC-IV+ (portid 2 impl 0x19 ver 0x22 clock 1500 MHz)
Solaris > sqlplus / as sysdba
 
SQL*Plus: Release 10.2.0.3.0 - Production on Fri Dec 2 15:52:40 2011
 
Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
 
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
 
SQL> col isdefault format a9
SQL> col value format a5
SQL> select value, isdefault from v$parameter
  2  where name = 'cpu_count'
  3  /
 
VALUE ISDEFAULT
----- ---------
4     TRUE
 
SQL>
 
So it looks as if it works as intended. I went to an Oracle seminar recently, where they said that cpu_count works differently in 11g release 2. Once I have investigated, I will cover this in a future post.