Below is the list of required packages according to the 11gr2 install docs:

binutils-2.17.50.0.6
compat-libstdc++-33-3.2.3
elfutils-libelf-0.125
elfutils-libelf-devel-0.125
elfutils-libelf-devel-static-0.125
gcc-4.1.2
gcc-c++-4.1.2
glibc-2.5-24
glibc-common-2.5
glibc-devel-2.5
glibc-headers-2.5
kernel-headers-2.6.18
ksh-20060214
libaio-0.3.106
libaio-devel-0.3.106
libgcc-4.1.2
libgomp-4.1.2
libstdc++-4.1.2
libstdc++-devel-4.1.2
make-3.81
numactl-devel-0.9.8.i386
sysstat-7.0.2

Here is the list of packages that I installed. Some required packages were already installed. I used the “yum info” command to verify if the package was installed or not.

NOTE: all commands below are ran as root (su -) until “su – oracle”

yum install compat-libstdc++-33
yum install elfutils-libelf-devel
yum install elfutils-libelf-devel-static
yum install gcc (this picked up other required packages (glibc-devel, glibc-headers))
yum install gcc-c++ (this picked up other required package (libstdc++-devel))
yum install ksh
yum install libaio-devel
yum install numactl-devel
yum install sysstat
yum install unixODBC ***for the unixODBC packages, they are not in the required list of packages, but they did come up as a warning in the installer as required. I doubt they are truly necessary, but I appeased the installer.
yum install unixODBC-devel

This will add the minimum installation group that will own the oracle software, create the oracle user, and allow the oracle user to run x sessions locally so you don’t have to login and logout for any of this installation. You may want to add your “normal” user to the oinstall group later.

groupadd oinstall
useradd -s /bin/bash -m -g oinstall oracle
passwd oracle
xhost local:oracle

The next two pieces of work will change various kernel settings and limits to be able to run database instances locally if you desire.

cat >> /etc/profile
#added for oracle
ulimit -S -c unlimited > /dev/null 2>&1

cat >> /etc/sysctl.conf
#added for oracle
fs.suid_dumpable = 1

cat >> /etc/security/limits.conf
oracle              soft    nproc   2047
oracle              hard    nproc   16384
oracle              soft    nofile  1024
oracle              hard    nofile  65536

cat >> /etc/sysctl.conf
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586
net.ipv4.tcp_wmem = 262144 262144 262144
net.ipv4.tcp_rmem = 4194304 4194304 4194304

/sbin/sysctl -p

I disabled SELinux since its not required, and is more difficult to deal with than I care to at this time.

setenforce 0
vi /etc/selinux/config
modify the line "SELINUX=enforcing" to "SELINUX=disabled"

The below directories are the Oracle recommended Optimal Flexible Architecture (besides all the separation of physical devices)

mkdir -p /u01/app/oracle
chown -R oracle:oinstall /u01/app/oracle
chmod -R 775 /u01/app/oracle
mkdir -p /u01/app/oraInventory
chown -R oracle:oinstall /u01/app/oraInventory
chmod -R 775 /u01/app/oraInventory

At this point you should have downloaded the two huge zip files from Oracle’s download page:

mv /home/michael/Downloads/linux_11gR2_database_* /home/oracle/
su - oracle (NOTE: all commands below are ran as oracle)
unzip linux_11gR2_database_1of2.zip
rm linux_11gR2_database_1of2.zip
unzip linux_11gR2_database_2of2.zip
rm linux_11gR2_database_2of2.zip

Here is the where the actual installation begins. You will get a nice GUI for this part.

cd database
./runInstaller

On the successive list of screens, select the following to install the database software without creating a test database.

“Install database software only”
“Single instance database installation”
“Enterprise Edition”
Oracle Base: “/u01/app/oracle”
Software Location: “/u01/app/oracle/product/11.2.0/dbhome_1″
Inventory Directory “/u01/app/oraInventory”
oraInventory Group Name “oinstall”
Database Administrator Group “oinstall”
Database Operator Group “oinstall”

A list of prerequisites that are failed will be shown on the screen. The only failed prerequisite I faced was a missing pdksh package, but I already installed the original Korn Shell package “ksh”, so I clicked the “Ignore All” box.

During the install there was one error that popped up about linking:

Error in invoking target ‘agent nmhs’ of makefile ‘/u01/app/oracle/product/11.2.0/dbhome_1/sysman/lib/ins_emagent.mk’

Some information that I gleaned from “http://cn.forums.oracle.com/forums/thread.jspa?threadID=1091616″ regarding this error: Apparently the enterprise manager agent will not run properly until this linking issue is resolved. The fix is below…

vi $ORACLE_HOME/sysman/lib/ins_emagent.mk
Search for the line
$(MK_EMAGENT_NMECTL)
Change it to:
$(MK_EMAGENT_NMECTL) -lnnz11

If at this point, you still have the linking error popup on your screen, you should be able to hit Retry and it should go through. (Can someone confirm this works?) If you ignored the error and finished the installation like I did, you can still do the modification to ins_emagent.mk as above, then manually run “make -f ins_emagent.mk “agent”". Make sure to set the ORACLE_BASE and ORACLE_HOME environment variables before running the make command.

After the install I placed the following lines in the /etc/profile to ensure the ORACLE_* environment variables get set properly after login for any local users:

export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
export PATH=$PATH:$ORACLE_HOME/bin

At this point, I moved some known *.ora files into the $ORACLE_HOME/network/admin directory to skip the tns setup.

From here you should be able to use the oracle client tools to connect to existing databases on your network. Also, I was able to create an 11gR2 database instance locally without any more system changes, besides the normal instructions for creating an instance from the Oracle documentation.

CONFIGURE CHANNEL DEVICE TYPE ‘SBT_TAPE’ PARMS  ‘SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=/u01/app/oracle/sbt)’;

RMAN> backup device type sbt current controlfile;

Starting backup at 08-JUN-10
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=21 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_SBT_TAPE_1: starting piece 1 at 08-JUN-10
channel ORA_SBT_TAPE_1: finished piece 1 at 08-JUN-10
piece handle=17lfnivf_1_1 tag=TAG20100608T140015 comment=API Version 2.0,MMS Version 8.1.3.0
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
Finished backup at 08-JUN-10

When the backup is done, you can see the backup files on disk, along with a binary file “Oracle_Disk_SBT_Catalog” which seems to be a simple index of sorts.

oracle@micweh1-lucid:/u01/app/oracle$ ls -ltr sbt/
total 16396
-rw-r–r– 1 oracle oinstall 8388616 2010-06-08 14:00 17lfnivf_1_1
-rw-r–r– 1 oracle oinstall 8388616 2010-06-08 14:00 c-2019211406-20100608-00
-rw-r–r– 1 oracle oinstall    3204 2010-06-08 14:00 Oracle_Disk_SBT_Catalog

binutils-2.15.92.0.2
compat-libstdc++-33-3.2.3
elfutils-libelf-0.97
elfutils-libelf-devel-0.97
gcc-3.4.6
gcc-c++-3.4.6
glibc-2.3.4-2.41
glibc-common-2.3.4
glibc-devel-2.3.4
glibc-headers-2.3.4
libaio-devel-0.3.105
libaio-0.3.105
libgcc-3.4.6
libstdc++-3.4.6
libstdc++-devel-3.4.6
make-3.80
numactl-0.6.4.i386
pdksh-5.2.14
sysstat-5.0.5
unixODBC-2.2.11
unixODBC-devel-2.2.11

Here is the list of packages that I installed. Some packages from above were already installed, and some were not even available. The ones not available, I just ignored and after extensive testing, all seems to run fine.

NOTE: all commands below are ran as root (sudo su -) until “su – oracle”

apt-get install elfutils
apt-get install libaio1
apt-get install libaio-dev
apt-get install libstdc++6-4.4-dev
apt-get install numactl
apt-get install pdksh
apt-get install sysstat
apt-get install unixODBC-dev
apt-get install unixODBC

This will add the minimum installation group that will own the oracle software, create the oracle user, and allow the oracle user to run x sessions locally so you don’t have to login and logout for any of this installation. You may want to add your “normal” user to the oinstall group later.

groupadd oinstall
useradd -s /bin/bash -m -g oinstall oracle
passwd oracle
xhost local:oracle

The next two pieces of work will change various kernel settings and limits to be able to run database instances locally if you desire.

cp /etc/security/limits.conf /etc/security/limits.conf.bak
cat >> /etc/security/limits.conf
oracle              soft    nproc   2047
oracle              hard    nproc   16384
oracle              soft    nofile  1024
oracle              hard    nofile  65536
<Ctrl-C>

cp /etc/sysctl.conf /etc/sysctl.conf.bak
cat >> /etc/sysctl.conf
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586
net.ipv4.tcp_wmem = 262144 262144 262144
net.ipv4.tcp_rmem = 4194304 4194304 4194304
<Ctrl-C>

/sbin/sysctl -p

The below directories are the Oracle recommended Optimal Flexible Architecture (besides all the separation of physical devices)

mkdir -p /u01/app/oracle
chown -R oracle:oinstall /u01/app/oracle
chmod -R 775 /u01/app/oracle
mkdir -p /u01/app/oraInventory
chown -R oracle:oinstall /u01/app/oraInventory
chmod -R 775 /u01/app/oraInventory

ln -s /usr/bin/awk /bin/awk <-- this was so the root.sh script doesn't fail when trying to find awk

At this point you should have downloaded the two huge zip files from Oracle’s download page:

mv /home/michael/Downloads/linux_11gR2_database_* /home/oracle/
su - oracle
unzip linux_11gR2_database_1of2.zip
rm linux_11gR2_database_1of2.zip
unzip linux_11gR2_database_2of2.zip
rm linux_11gR2_database_2of2.zip

Here is the where the actual installation begins. You will get a nice GUI for this part.

cd database
./runInstaller

On the successive list of screens, select the following to install the database software without creating a test database.

"Install database software only"
"Single instance database installation"
"Enterprise Edition"
Oracle Base: "/u01/app/oracle"
Software Location: "/u01/app/oracle/product/11.2.0/dbhome_1"
Inventory Directory "/u01/app/oraInventory"
oraInventory Group Name "oinstall"
Database Administrator Group "oinstall"
Database Operator Group "oinstall"

A list of prerequisites that are failed will be shown on the screen. I reviewed them and selected “Ignore All” since I verified all the packages were indeed available.
During the install there were a handful of errors about linking such as:
“Error in invoking target ‘idg4odbc’ of makefile ‘/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk’.”
“Error in invoking target ‘idg4odbc’ of makefile ‘/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk’.”
“Error in invoking target ‘install’ of makefile ‘/u01/app/oracle/product/11.2.0/dbhome_1/ctx/lib/ins_ctx.mk’.”
“Error in invoking target ‘all_no_orcl’ of makefile ‘/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk’.
“Error in invoking target ‘utilities’ of makefile ‘/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk’.”

I was able to “Continue” past these errors and complete the installation and creation of database without anymore issues. I read a little bit online about some people having these errors and their GUI tools such as DBCA and Universal Installer not working normally, but I have tested the tools that I use and they seem to be fine.
After the install I placed the following lines in the /etc/profile to ensure the ORACLE_* environment variables get set properly after login for any local users:

export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
export PATH=$PATH:$ORACLE_HOME/bin

At this point, I moved some known *.ora files into the $ORACLE_HOME/network/admin directory to skip the tns setup
From here you should be able to use the oracle client tools to connect to existing databases on your network. Also, I was able to create an 11gR2 database instance locally without any more system changes, besides the normal instructions for creating an instance from the Oracle documentation.

I recently noticed this wait event as the top event on my DSS database. A quick search of what exactly this is will lead you to believe that it is an idle event, and shouldn’t warrant any attention. Oracle’s Metalink document 271767.1 “WAITEVENT: “PX Deq Credit: send blkd”" states this is an idle event, and a simple example they provide to reproduce it is to run “select /*+ parallel(sales, 10) +/ * from sales)”. (That typo in the hint is Oracle’s, not mine, I had to leave it for your entertainment purposes). This will cause the QC to become overloaded with messages from the slaves, theoretically 10 would be too many in this case, and the slaves begin waiting on the QC. In this situation, it might be possible to better tune the parallel settings in the database so this doesn’t happen as often.

In this typical case, the worst thing that seems to happen is that you get too many parallel slaves for a query waiting for a time, and once the query is done processing, so the slaves stop waiting, and move on to other sessions/work. So I assume the reason for the nonchalant behavior towards this event is justified in that case, BUT I have found this other case is affecting my database in a far greater fashion, because PX slaves are being occupied for hours at a time, causing other queries degree of parallelism to be downgraded or removed altogether. In a very busy database, this can make a big difference on performance.

Now I am going to show you how to reproduce this, so you can understand better what is happening. First put the below query into a script called pq.sql to monitor the parallel query sessions

col username for a12
col “QC SID” for A6
col “SID” for A6
col “QC/Slave” for A8
col “Req. DOP” for 9999
col “Actual DOP” for 9999
col “Slaveset” for A8
col “Slave INST” for A9
col “QC INST” for A6
set pages 300 lines 300
col wait_event format a30

select
decode(px.qcinst_id,NULL,username,
‘ – ‘||lower(substr(pp.SERVER_NAME,
length(pp.SERVER_NAME)-4,4) ) )”Username”,
decode(px.qcinst_id,NULL, ‘QC’, ‘(Slave)’) “QC/Slave” ,
to_char( px.server_set) “SlaveSet”,
to_char(s.sid) “SID”,
to_char(px.inst_id) “Slave INST”,
decode(sw.state,’WAITING’, ‘WAIT’, ‘NOT WAIT’ ) as STATE,
case  sw.state WHEN ‘WAITING’ THEN substr(sw.event,1,30) ELSE NULL end as wait_event ,
decode(px.qcinst_id, NULL ,to_char(s.sid) ,px.qcsid) “QC SID”,
to_char(px.qcinst_id) “QC INST”,
px.req_degree “Req. DOP”,
px.degree “Actual DOP”
from gv$px_session px,
gv$session s ,
gv$px_process pp,
gv$session_wait sw
where px.sid=s.sid (+)
and px.serial#=s.serial#(+)
and px.inst_id = s.inst_id(+)
and px.sid = pp.sid (+)
and px.serial#=pp.serial#(+)
and sw.sid = s.sid
and sw.inst_id = s.inst_id
order by
decode(px.QCINST_ID,  NULL, px.INST_ID,  px.QCINST_ID),
px.QCSID,
decode(px.SERVER_GROUP, NULL, 0, px.SERVER_GROUP),
px.SERVER_SET,
px.INST_ID
/

Now, using your IDE, ( I am using SQL Developer with the Sql Array Fetch Size set to 50 ) run a sample parallel query, and allow the first results to show up:

select /*+ parallel(bigtable, 4) +*/ * from bigtable;

Now, in another database session, run the pq.sql script to see the issue in action:

SQL> @pq

Username     QC/Slave SlaveSet SID    Slave INS STATE    WAIT_EVENT                     QC SID QC INS Req. DOP Actual DOP

———— ——– ——– —— ——— ——– —————————— —— —— ——– ———-

USER111      QC                515    1         WAIT     SQL*Net message from client    515

- p000      (Slave)  1        510    1         WAIT     PX Deq Credit: send blkd       515    1             4          4

- p001      (Slave)  1        500    1         WAIT     PX Deq Credit: send blkd       515    1             4          4

- p003      (Slave)  1        494    1         WAIT     PX Deq Credit: send blkd       515    1             4          4

- p002      (Slave)  1        507    1         WAIT     PX Deq Credit: send blkd       515    1             4          4

I have found that bind variables find their way into the redo logs as a side effect of the AWR collecting sql statements along with their bind values. They are also freely available in the AWR tables if they are captured.

Using the test case Oracle documented here… http://www.oracle.com/technology/obe/10gr2_db_vmware/security/tde/tde.htm

This test case shows that when using TDE to encrypt a column, the redo logs are definitely protected for the DML on the target table. The example shows the insert statement “insert into cust_payment_info values (‘Mike’, ‘Anderson’, 10004, ’4929889576357400′,’YES’);” actually gets mined out as “insert into “OE”.”cust_payment_info”(“FIRST_NAME”,”LAST_NAME”,”ORDER_NUMBER”,”CREDIT_CARD_NUMBER”,”ACTIVE_CARD”) values (‘Mike’, ‘Anderson’, 10004, ‘Unsupported Type’,'YES’);”. This shows that the encrypted column CREDIT_CARD_NUMBER actually gets mined out as ‘Unsupported Type’ so you are protected there…

In the case that I observed this, we use our own encryption function that uses dbms_crypto package, not TDE. So we won’t see the ‘Unsupported Type’, which gets placed by TDE internal mechanisms, but we will see the value as it has been encrypted, so this is acceptable for us…

But, where I have found you are not protected is the insert into the SYS.WRH$_SQLSTAT table which is part of the Automated Workload Repository data gathering actually has the literal bind value ’4929889576357400′ stored in hexadecimal format in the BIND_DATA column. This occurred when the sql statement used above “insert into cust_payment_info…” got parsed and placed into v$sql and eventually moved into Active Session History, then finally moved into the AWR into the SYS.WRH$_SQLSTAT table. You may want to run this query on your database for entertainment purposes to see what I am talking about: select dbms_sqltune.extract_bind(bind_data, 1).value_string from sys.wrh$_sqlstat where bind_data is not null; The view definition for DBA_HIST_SQLBIND will give you some information on how easy the hexadecimal data is to translate into your real data.

If by using logminer, you mine out inserts into the SYS.WRH$_SQLSTAT, you will see inserts like below:
“insert into “SYS”.”WRH$_SQLSTAT”(…,”BIND_DATA”,”FLAG”) values (…HEXTORAW(‘beda0a2003004a4232dd000408c0021603c2191a’),NULL);”
I removed most of the columns and literal values but chose to show you the remaining hex value that is inserted into the BIND_DATA column. This is where you would be able to get the card information that was originally inserted into the CREDIT_CARD_NUMBER column. A simple call to the dbms_sqltune.extract_bind procedure will give you the literal card number value. (Note: the hex above is not for this exact statement, and won’t return the card number in the test, but can be reproduced).

So, no matter if you encrypt a data column using TDE, or by encrypting it using another method before inserting, I have found this BIND_DATA is still in the AWR table and consequently in the redo logs. Since the BIND_DATA appears to be a simple hexadecimal conversion of some sort, it does not meet PCI encryption standards.
When I first presented this to Oracle in a Service Request, their recommendations to workaround this problem were to turn off AWR altogether, disabling bind capturing only, or to disable logging of peeked binds. All of these workarounds could be drastic changes on a production database system, so we needed a fix for this bug, which Oracle did provide. Oracle has provided us “Patch 9065026: BIND_DATA LACKS CONTROL AT SINGLE-SQL LEVEL” to control single sql statements that we know will have sensitive bind values.

The patch readme does not include instructions on how to use it, so I have provided a test case below that Oracle gave to me.

connect scott/tiger

set serveroutput on

declare

bindvar varchar2(20);

retval varchar2(20);

stmt varchar2(100);

bind_data varchar2(100);

hint varchar2(100);

stored_stmt varchar2(100);

begin

bindvar := ‘TURNER’;

stmt := ‘select ‘||

‘ ename from emp where ename = :b1′;

execute immediate stmt into retval using bindvar;

select sql_text, dbms_sqltune.extract_bind(bind_data,1).value_string

into stored_stmt, bind_data from v$sql where sql_text = stmt;

dbms_output.put_line(‘statement: ‘||stored_stmt);

dbms_output.put_line(‘bind_data: ‘||nvl(bind_data,’Empty!’));

end;

/

statement: select ename from emp where ename = :b1

bind_data: TURNER

declare

bindvar varchar2(20);

retval varchar2(20);

stmt varchar2(100);

bind_data varchar2(100);

hint varchar2(100);

stored_stmt varchar2(100);

begin

hint := ‘ /*+ OPT_PARAM(”_cursor_bind_capture_area_size”, 0) */ ‘;

bindvar := ‘TURNER’;

stmt := ‘select ‘||

hint||

‘ ename from emp where ename = :b1′;

execute immediate stmt into retval using bindvar;

select sql_text, dbms_sqltune.extract_bind(bind_data,1).value_string

into stored_stmt, bind_data from v$sql where sql_text = stmt;

dbms_output.put_line(‘statement: ‘||stored_stmt);

dbms_output.put_line(‘bind_data: ‘||nvl(bind_data,’Empty!’));

end;

/

statement: select /*+ OPT_PARAM(‘_cursor_bind_capture_area_size’, 0) */ ename

from emp where ename = :b1
bind_data: Empty!

BEGIN
sys.dbms_scheduler.disable( ‘”OWNER”.”JOB_NAME”‘ );
sys.dbms_scheduler.set_attribute( name => ‘”OWNER”.”JOB_NAME”‘, attribute => ‘start_date’, value => to_timestamp_tz(’2009-10-03 US/Eastern’, ‘YYYY-MM-DD TZR’));
sys.dbms_scheduler.enable( ‘”OWNER”.”JOB_NAME”‘ );
END;
/

Note the code will not work while the job is running. When the interval is applied for future job runs, they will run at the proper time.

When you create scheduler jobs using sys.dbms_scheduler.create_job(), pass in the parameter of start_date using a specific timezone, such as “start_date => to_timestamp_tz('2009-11-03 00:00:00 US/Eastern', 'YYYY-MM-DD HH24:MI:SS TZR')” or “start_date => systimestamp at time zone 'US/Eastern'“, unless of course you desire your jobs to follow a specific GMT offset, then use the alternate syntax such as “start_date => to_timestamp_tz('2009-11-02 16:40:00 -5:00', 'YYYY-MM-DD HH24:MI:SS TZH:TZM')” or “start_date => systimestamp at time zone '-5:00'“.

alter table unique_test add constraint uk_unique_test unique (num);
select index_name, uniqueness from user_indexes where table_name = 'UNIQUE_TEST';
INDEX_NAME UNIQUENESS
—————————— ———
UK_UNIQUE_TEST UNIQUE

select constraint_name, constraint_type, index_name from user_constraints where table_name = 'UNIQUE_TEST';
CONSTRAINT_NAME C INDEX_NAME
—————————— – ——————————
UK_UNIQUE_TEST U UK_UNIQUE_TEST

If there is a preexisting index that can be used, the database will create the unique constraint, and tell it to use the existing index without creating a new one unnecessarily. Look at the INDEX_NAME column of the DBA_CONSTRAINTS view to see which index the constraint is using. The preexisting index does not have to be unique.

create index i_unique_test on unique_test(num);
alter table unique_test add constraint uk_unique_test unique (num);
select index_name, uniqueness from user_indexes where table_name = 'UNIQUE_TEST';
INDEX_NAME UNIQUENESS
—————————— ———
I_UNIQUE_TEST NONUNIQUE

select constraint_name, constraint_type, index_name from user_constraints where table_name = 'UNIQUE_TEST';
CONSTRAINT_NAME C INDEX_NAME
—————————— – ——————————
UK_UNIQUE_TEST U I_UNIQUE_TEST

You can have a unique index on a table without a unique constraint. This unique index still seems to perform the same duties as a unique constraint will, even claiming that you have violated a unique constraint, not a unique index.

create unique index unique1 on unique_test(num);
select index_name, uniqueness from user_indexes where table_name = 'UNIQUE_TEST';
INDEX_NAME UNIQUENESS
—————————— ———
UNIQUE1 UNIQUE

select constraint_name, constraint_type, index_name from user_constraints where table_name = 'UNIQUE_TEST';
no rows selected

insert into unique_test values (1);
insert into unique_test values (1)
*
ERROR at line 1:
ORA-00001: unique constraint (MICHAEL.UNIQUE1) violated

The first step to identifying where these failed login attempts were coming from is to turn on Oracle database auditing. Make sure the audit_trail database parameter is set. In its simplest form set AUDIT_TRAIL=DB. There are other auditing options that can be used, and can be researched at Oracle’s documentation website (tahiti.oracle.com).

Next, turn on auditing on the CREATE SESSION action. This can be set for all users or for specific users. I chose to just audit my username since it was the one in question.

SQL> audit create session by michael;

Now, every attempt to create a session by the user michael will be audited and placed in the sys.aud$ table. This table can hold a lot more auditing information than just sessions, and because of this reason, it can be very hard to query for a specific set of records. When looking at audited sessions, it is easier to use the DBA_AUDIT_SESSION view which gives you just the information necessary for researching sessions.

To find out where my failed login attempts were coming from, I ran the sql query below to see all of my login attempts, failed or successful.

select os_username, username, userhost, timestamp, returncode
from dba_audit_session
where username = 'MICHAEL'
order by timestamp;

os_username, username, userhost, timestamp, returncode
oracle    MICHAEL    db08    26-AUG-09 10.07.23    28000
oracle    MICHAEL    db08    26-AUG-09 10.12.23    28000
oracle    MICHAEL    db08    26-AUG-09 10.17.23    1017

Any records that have a returncode > 0 are failed login attempts. I can see in the first two audited records that the returncode of 28000 is for a locked account. At that point, after 10.12, I altered my user account and unlocked it. The next failed login attempt that came in got a returncode of 1017, which is an invalid password error. Until I decided to fix this problem, at this point after I unlocked my account, there would be 10 records with a returncode of 1017, then all subsequent attempts would be 28000. This is because my user profile has the FAILED_LOGIN_ATTEMPTS set to 10.

Note here that the userhost of ‘db08′ is the database host in this scenario. This fact was strange to me because I knew that I had no processes of any kind on the database host that would access the database with my username, or so I thought. This database was recently refreshed from a production instance, so I knew my password had been recently changed, and was the reason for the failed logins, so I decided to change my password back to the old password to see if the failed login attempts stopped. At this point, I saw a sucessful connection to the database from the same userhost, as evidenced by the returncode of 0.

oracle    MICHAEL    db08    26-AUG-09 10.22.23    0

I then queried v$session for my username and found the session that was established. From there, I determined by looking at the program and module columns the session was coming from the process “emagent@db08 (TNS V1-V3)”. The emagent process is used by grid control to access the database for various reasons. I knew that this wasn’t me logging into the database through OEM though, because the userhost is the host for the OEM instance, and the os_username is not recorded as evidenced by the below record.

(null)    MICHAEL    dbps07    26-AUG-09 11.03.48    0

So what was emagent doing with my old username and password every five minutes? I determined that oem was attempting to run a user defined metric that I created with my old password.

Takeaways:

1. I got to thinking why the failure of the user defined metric wasn’t more evident to me, which is because the user defined metric was for business specific rules that check business data to make sure things are going “normal”. But this metric is always in a critical state in our development database, because the “normal” business doesn’t take place and isn’t being replicated in any way. In our production database user defined metrics, we use a special database login that does not have any password expiration rules so this will not become an issue in other environments. Now I am off to change our development user defined metrics to use that login instead of mine.
2. If you see failed login attempts coming from your database host, and it isn’t immediately evident what is causing them, check your OEM for user defined metrics that may be running against the database.