You can get an overview of all available OLE DB Drivers in the “Data Link Properties” application which is delivered together with the Microsoft operating system.
But the application itself is rather cumbersome to find…

We tell you have to find the “Data Link Properties” window.

First of all, create a new “Universal Data Link” file in a location of your choice. Let’s name it test.udl
Don’t worry, you do not need to fill in any information inside the file, just leave it empty.

Notice how the icon is changed, the associated program is “Microsoft Data Link”.

Next, you need to double click on the file, and this will open up the “Data Link Properties” Window.

Next, you can choose the correct OLE DB Provider and go to the All tab page to change the properties you want.

EXP-00056: ORACLE error 6550 encountered
ORA-06550: line 1, column 41:
PLS-00302: component 'SET_NO_OUTLINES' must be declared
ORA-06550: line 1, column 15:
PL/SQL: Statement ignored
EXP-00000: Export terminated unsuccessfully

You are probably using another version of the export tool than the version of the database.

For instance, you use the Oracle 10g export tool to export a schema from an Oracle 9i database.



The export tool of Oracle contain some version specific code.

In this case, the export tool is executing a procedure at connect time (set_no_outlines) which does not exist on an Oracle 9i database.



It is good practice to keep the version of the Oracle client tools and database in sync.



This problem will disappear if you use the Oracle 9i version of the export tool.

In order to startup an Oracle database, one need to have either an Oracle password file or rely on Operating system authentication.

If the init.ora parameter remote_login_passwordfile is set to either exclusive or shared, Oracle will search for a password file to do the authentication.

Default Location of the Password File

The default location for an Oracle password file is the %ORACLE_HOME%/database on Windows and $ORACLE_HOME/dbs on Unix flavours.

On windows, the filename should be: PWD%ORACLE_SID%.ora

On Unix, the filename should be: orapw$ORACLE_SID

Command to create a password file

You can use the orapwd command to create a new password file.

Usage: orapwd file=<fname> password=<password> entries=<users> force=<y/n> nosysdba=<y/n>

  where
    file - name of password file (mand),
    password - password for SYS (mand),
    entries - maximum number of distinct DBA,
    force - whether to overwrite existing file (opt),
    nosysdba - whether to shut out the SYSDBA logon (opt for Database Vault only).
  There are no spaces around the equal-to (=) character.

If you want to create a new password file, make sure the database is closed, else the password file will be overwritten at next startup.

Check users in a password file

You can query the v$pwfile_users data dictionary view in order to know which users are in the password file including the gratned privileges.

SQL> select * from v$pwfile_users;

USERNAME                       SYSDB SYSOP
------------------------------ ----- -----
SYS                            TRUE  TRUE

• 1: Write the message to a trace file
• 2: Write the message to the alert.log file
• 3: Write the message to both a trace file and the alert.log file

For example, your application can write something to the alert.log file whenever a critical condition is encountered.

In order to write something to the alert.log, we need to provide 2 as the first parameter.

SQL> exec dbms_system.ksdwrt(2, '[YOURAPP] A Critical error was detected in module: INIT');

PL/SQL procedure successfully completed.

Now, if we check the alert.log file, we can see the message:

SQL> select value from v$parameter where name='background_dump_dest';

VALUE
--------------------------------------------------------------------------------
/u01/app/oracle/product/10.2.0/rdbms/log

SQL> select name from v$database;

NAME
---------------------------
ORA10G

SQL> host tail /u01/app/oracle/product/10.2.0/rdbms/log/alert_ORA10G.log
Mon Jun 15 21:57:47 2009
[YOURAPP] A Critical error was detected in module: INIT

Starting from Oracle 11g, you can query the X$DBGALERTEXT internal view to check the alert.log from within Oracle.

alert<ORACLE_SID>.log

on Windows, or

alert_<ORACLE_SID>.log

On Unix/Linux


The alert.log file normally is in the $ORACLE_BASE/<ORACLE_SID>/bdump location, or since Oracle 11g in the database specific location in the diagnostic_dest.



If the database is running, you can issue following select to be able to identify the location of the background_dump_dest:

SQL> select value from v$parameter where name='background_dump_dest';

VALUE
--------------------------------------------------------------------------------
/oracle/diag/diag/rdbms/ora11g/ORA11G/trace

To find the location of the diagnostic_dest, one can use the following select:

SQL> select value from v$parameter where name='diagnostic_dest';

VALUE
--------------------------------------------------------------------------------
/oracle/diag/

In order to know the current ORACLE_SID, you can use following select:

SQL> select name from v$database;

NAME
---------------------------
ORA11G

In our example, because we are on Linux, the name of the alert.log file will be:

/oracle/diag/diag/rdbms/ora11g/ORA11G/trace/alert_ORA11G.log

select value from v$parameter where name='audit_trail'

Value can have a number of different possibilites:

• none or false: auditing is not enabled
• OS: audit records are written to your operating system
• db or true / db, extended: audit trail records are written to the SYS.AUD$ table in your database. Under normal circumstances, this table exists in the SYSTEM tablespace.
• xml / xml, extended: audit trail records are written to XML OS files.

If you want to enable auditing, the value should not be NONE or FALSE.



You change the value either in the init<ORACLE_SID>.ora file if you are using a pfile, or in the spfile using following command:

SQL> alter system set audit_trail=DB scope=spfile;

System altered.

You need to bounce (stop and restart) the database in order to let the parameter become active.



Now, if you want to enable auditing when users connect, use following statement to enable session logon (creation) auditing:

SQL> audit create session;

Audit succeeded.

If you want to disable a certain audit action, you can use the NOAUDIT statement:

SQL> noaudit create session;

Noaudit succeeded.

Now, you can use the dba_audit_trail or any other audit table to check for audit records:

-- select all invalid logon sessions for a certain user ordered by last logon attempt
select * from dba_audit_session where username='username' and returncode != 0 order by timestamp desc;

If you want to know to what operating system file location audit files are written, you can run following query:

SQL> select value from v$parameter where name='audit_file_dest';

VALUE
--------------------------------------------------------------------------------
/u01/app/oracle/product/10.2.0/rdbms/audit

To check the tablespace the AUD$ table belongs to, use following select:

SQL> select tablespace_name from dba_tables where owner='SYS' and table_name='AUD$';

TABLESPACE_NAME
------------------------------
SYSTEM

1. Enable trace at the beginning of your session
2. Enable trace of a running session

1. Enable tracing at the begin of your session

To enable tracing for a particular session we will need to set the Oracle event 10046.

This event contains a level which can be combined using a logical OR relation to mix different trace functions.

This is what the different levels are used for:

As said before we can combine the different levels to enable combination’s of tracing.

A level of 12 means that we will trace bind variables as well as wait events. When setting the level to a value other than zero, level 1 will also be activated. So setting the level to 12 also enables tracing for parse, execute, fetch,… operations.

– To enable tracing

alter session set events '10046 trace name context forever, level 12'

--To stop tracing of the current session
alter session set events '10046 trace name context off'

Enable trace of a running session

In order to enable tracing for a running application, one can use the dbms_system package.

-- to enable tracing for another sid, serial# pair
sys.dbms_system.set_ev( sid, serial#, 10046, 12, '');

-- to disable tracing.
sys.dbms_system.set_ev( sid, serial#, 10046, 0, '');

Alternatively, to just enable a level 1 trace:

-- to enable tracing for another sid, serial# pair
sys.dbms_system.set_sql_trace_in_session(sid, serial#, true);
-- to disable tracing.
sys.dbms_system.set_sql_trace_in_session(sid, serial#, false);

When your application require frequent tracing for a particular setting, one might think about including an option into the application which – when enabled – just starts tracing the session.

Alternatively, you can create a schema logon trigger which enables tracing when a user logs on to the schema.

The dbms_stats.gather_system_stats packaged procedure can be used during a certain interval to measure the actual I/O and CPU usage during a workload, typically a days work.

SQL> exec dbms_stats.gather_system_stats('START')

PL/SQL procedure successfully completed.

SQL> -- days processing

SQL> exec dbms_stats.gather_system_stats('STOP')

PL/SQL procedure successfully completed.

Now, when you gathered workload CPU statistics, one can query the sys.aux_stats$ data dictionary table to see the actual values that will be used when generating your Sql plan:

select sname, pname, pval1
from sys.aux_stats$;

SNAME       	PNAME      PVAL1
-------------	---------  -------
SYSSTATS_INFO   STATUS
SYSSTATS_INFO   DSTART
SYSSTATS_INFO   DSTOP
SYSSTATS_INFO   FLAGS	    1
SYSSTATS_MAIN   CPUSPEEDNW  502.005
SYSSTATS_MAIN   IOSEEKTIM   10
SYSSTATS_MAIN   IOTFRSPEED  4096
SYSSTATS_MAIN   SREADTIM    7.618
SYSSTATS_MAIN   MREADTIM    14.348
SYSSTATS_MAIN   CPUSPEED    507
SYSSTATS_MAIN   MBRC 	    6
SYSSTATS_MAIN 	MAXTHR      32768
SYSSTATS_MAIN 	SLAVETHR      

13 rows selected.

CPUSPEEDNW, IOSEEKTIM, and IOTFRSPEED are noworkload statistics;

SREADTIM, MREADTIM, CPUSPEED, MBRC, MAXTHR, and SLAVETHR represent workload statistics.



When you have both workload and noworkload statistics, the optimizer will use workload statistics.

• SREADTIM – single block read time (msec): the average time Oracle takes to read a single block
• MREADTIM – multiblock read time (msec): the average time taken to read sequentially
• MBRC – multiblock read count: the average amount of blocks read during multiblock sequential reads. This value is used instead of the db_ multiblock_read_count parameter during query optimization to compute costs for table and fast full index scans
• MAXTHR – maximum I/O system throughput: is captured only if the database runs parallel queries
• SLAVETHR – maximum slave I/O throughput: is captured only if the database runs parallel queries

• nomount phase: during this phase, the initialization file is read
• mount phase: during this phase, the controlfile file is read
• open phase: during this phase, the datafiles and redolog files are checked for consistency and opened

nomount phase

During the nomount phase, the Oracle initialization file is read. If it is found, the memory structures are created and the Oracle processes are started.

The memory area and startup of the processes are done using the ‘startup nomount’ command.

SQL> conn / as sysdba
Connected to an idle instance.

SQL> startup nomount
ORACLE instance started.

Total System Global Area  171966464 bytes
Fixed Size                  2082496 bytes
Variable Size             113248576 bytes
Database Buffers           50331648 bytes
Redo Buffers                6303744 bytes

We can check the v$instance view to check if the instance was started successfully and check the status of the instance

SQL> select instance_name, status from v$instance;

INSTANCE_NAME STATUS
------------- ----------------------
ORA11G        STARTED

Because we only have read the initialization file, we cannot check the status of the database.

To be able to check the database, we need to mount the database.

SQL> select * from v$database;
select * from v$database
              *
ERROR at line 1:
ORA-01507: database not mounted

mount phase

During the mount phase, the controlfile(s) are checked for availability and read.

The controlfile contain information about the database, such as the database name and the number and location of the datafiles.

The database is mounted using the ‘alter database mount’ command.

SQL> alter database mount;

Database altered.

Should there be a problem with (one of the) controlfile(s), you will get an error.

In order to mount a database, all controlfiles should be available and accessible.

SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00205: error in identifying control file, check alert log for more info

You need to check the alert.log file in order to rectify the problem.

You can use following query to check what controlfiles are needed to mount the database.

SQL> select value from v$parameter where name='control_files';

VALUE
--------------------------------------------------------------------------------
/u01/app/oracle/product/10.2.0/dbs/cntrlORA11G.dbf

Now you can check the status of the database using the v$database view:

SQL> select name, open_mode from v$database;

NAME      OPEN_MODE
--------- ----------
ORA11G    MOUNTED

In order to use the database, we need to open the database.

open phase

During the open phase, the datafiles and redolog files are check for consistency and opened.

When the database is open, you can also access the data dictionary views. Because the data dictionary views are stored in datafiles, you can only query the views when the database is open.

SQL> select count(*) from dba_users;
select count(*) from dba_users
                     *
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only

In order to open the database, we issue the ‘alter database open’ command.

SQL> alter database open;

Database altered.


[SEVERE] - My Oracle Support Username/Email Address Not Specified


In order to fix this problem, make sure you set following response file parameter to TRUE:


DECLINE_SECURITY_UPDATES=true

By default, this parameter is empty and defaults to FALSE, meaning that Oracle tries to download new security updates from My Oracle Support.
This means that you need to provide the correct credentials, or just skip this by setting the parameter to TRUE.