Re: Tracing?

From: ykhogaly <ykhogaly_at_us.oracle.com>
Date: Fri, 18 Feb 2000 08:31:50 -0700
Message-ID: <88jom3$7n6$1@inet16.us.oracle.com>

Hi,

Widespread use of Oracle Trace can have a number of apparently mysterious side effects including:

Very slow database connect times
Poor Oracle response times
High disk space usage by the file 'process.dat'
Oracle errors attaching to the SGA, such as ORA 7307 or ORA 7337
Protocol errors (such as TNS 12164) errors from SQL*Net
Sessions aborting or hanging when connecting to the instance
Bus errors and/or core dumps from SQLPLUS or SVRMGRL
Trace files being written to the default USER_DUMP_DEST rather than the actual setting of USER_DUMP_DEST
Zero length trace files

Workaround

Two workarounds exist:

If you wish to disable Oracle Trace totally you simply need to remove the '*.dat' configuration files.
If you do wish to disable Oracle Trace for specific processes only you can use the EPC_DISABLED environment variable. Setting this to TRUE will DISABLE tracing.

      Workaround A - No Oracle Trace output required:
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        1. Shut down all 7.3 databases and listeners.

        2. Remove the Oracle Trace files:

            Unix                                                          NT
            ~~~~                                                        ~~
            cd $ORACLE_HOME/otrace/admin       cd orant\otrace73\admin
            rm -f *.dat                                               del

*.dat

Reboot the NT server

      Workaround B - Disable Oracle Trace on specific connections
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        NB: This workaround is not applicable to NT.

        1. Shutdown and remove the trace configuration files as in

Workaround A.

        2. Reinitialise the Oracle Trace files by typing 'otrccref' in
           the otrace/admin directory.

        3. To disable Oracle Trace for a particular session set the
environment
           variable EPC_DISABLED to TRUE.
           Eg: In a Bourne script:
                  EPC_DISABLED=TRUE; export EPC_DISABLED

               In the C-Shell:
                  setenv EPC_DISABLED TRUE

        4. To set EPC_DISABLED=TRUE for SQL*Net connections you can modify
           the 'SID_LIST_listener' clause in the 'listener.ora' file and

add:

                  (ENVS='EPC_DISABLED=TRUE')

           to the SID_DESC for each 7.3 database. Add the entry AFTER the
           (ORACLE_HOME=...) clause.

           Eg:
              SID_LIST_LISTENER=
               (SID_LIST=
                (SID_DESC=
                  (SID_NAME=DB1)
                  (ORACLE_HOME=/oracle/OFA_base/app/oracle/product/7.3.2)
                  (ENVS='EPC_DISABLED=TRUE')
                )
                (SID_DESC=
                  (SID_NAME=DB2)
                  (ORACLE_HOME=/oracle/OFA_base/app/oracle/product/7.3.2)
                  (ENVS='EPC_DISABLED=TRUE')
                )
              )

             By using two listener processes you can have one SQL*Net alias

which allows tracing and another that has tracing disabled.

5. Restart and databases and SQL*Net listeners.

"The Views expressed here are my own and not necessarily those of Oracle Corporation"

"Ms. D.H. Harvey" <qq45_at_liverpool.ac.uk> wrote in message news:88jb5v$dpb$2_at_news.liv.ac.uk...

> SunOS 5.6
>
> Oracle7 Server Release 7.3.4.0.1 - Production
> With the distributed and replication options
> PL/SQL Release 2.3.4.0.0 - Production
>
> In .../otrace/admin files collect.dat, process.dat & regid.dat
> are growing ie some/all of our Oracle7 databases are oracle
> tracing.  Can't tell as these file don't give any clues.
>
> Oracle8 Enterprise Edition Release 8.0.5.0.0 - Production
> PL/SQL Release 8.0.5.0.0 - Production
>
> The .dat files as above exist in .../otrace/admin here but are not
> growing ie not tracing.
>
> Have check oracle_trace_enable parameter for each database and it
> is FALSE for all.
>
> Any pointers as to why O7 tracing and determining on which database/s
> would be much appreciated.
>
> TIA Helen

Received on Fri Feb 18 2000 - 09:31:50 CST