How to determine the name of the trace file to be generated

In many cases we need to find out the name of the latest trace file generated in the USER_DUMP_DEST directory. What we usually do is go to physically to the USER_DUMP_DEST with the operating system browser and sort all the files by date and look for latest files. We can remove this hassle easily if we know what would be the trace file name in advance.

For example issuing,
D:\>sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Jun 10 21:58:15 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> alter database backup controlfile to trace;

Database altered.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
will generated a trace file inside USER_DUMP_DEST. Let's see the location of USER_DUMP_DEST.

If you use Sql*plus then issue,
SQL> show parameter user_dump_dest

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
user_dump_dest string E:\ORACLE\PRODUCT\10.2.0\ADMIN
\ORCL\UDUMP

Querying from v$parameter,
SQL> select value from v$parameter where name='user_dump_dest';

VALUE
-------------------------------------------------------------------
E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP

On windows changes to directory E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP and issue,
E:\oracle\product\10.2.0\admin\orcl\udump>dir /OD

The latest files are for latest trace.

Now it would be quite easy task if we knew the name of the trace file to be generated by ALTER DATABASE command.

In advance we can get the trace file name by,

SQL> set linesize 130
SQL> COL trace_file FOR A60
SQL> SELECT s.sid,
           s.serial#,
           pa.value || '\' || LOWER(SYS_CONTEXT('userenv','instance_name')) ||
           '_ora_' || p.spid || '.trc' AS trace_file
    FROM   v$session s,
           v$process p,
           v$parameter pa
    WHERE  pa.name = 'user_dump_dest'
    AND    s.paddr = p.addr
    AND    s.audsid = SYS_CONTEXT('USERENV', 'SESSIONID');

       SID    SERIAL# TRACE_FILE
---------- ---------- ------------------------------------------------------------
       146         11 E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP\orcl_ora_4968.trc

So the trace file to be generated now will be named as orcl_ora_4968.trc

So now issuing, "alter database backup controlfile to trace" will generate the file named E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP\orcl_ora_4968.trc.

On windows you can issue like this,
SQL> alter database backup controlfile to trace;

Database altered.

SQL> host notepad E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP\orcl_ora_4968.trc
Related Documents
http://arjudba.blogspot.com/2009/04/how-to-tracediagnosis-oracle-data-pump.html

How to hide your server's info

As you may or may not know, by default, your server details are public and anyone with some basic knowledge can easily see them.

For example, let's consider this http://1mum.geek-tools.org. If you check its HTTP headeryou'll see this info:

HTTP/1.1 200 OK
Date: Mon, 08 Jun 2009 16:44:51 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.2.9
X-Pingback: http://1mum.geek-tools.org/xmlrpc.php
Connection: close
Content-Type: text/html; charset=UTF-8


If you use apache web server and if you want to turn this off just edit your Apache VirtualHost definition and add this line:
ServerSignature Off
More info about this can be found here in http://httpd.apache.org/docs/1.3/mod/core.html#serversignature

In order for the changes to be activated you'll have to restart your web server.

Now that you made this change here's the question: will turning off your web server headers be of any help? :-)

The quick answer is yes and no.
Yes: if you sell webhosting it may look better/more secure to your potential customers. It could also save you some SPAM/attacks as some of these malware loving guys use automated tools that read this info

No: most of the attacking tools won't care about the header details as they'll brute force your server anyway.
Besides that, one with a bit more networking knowledge can not only have a fairly good guess of what your OS is but also figure out details like your server's uptime!

The bottom line: if its easy for you to edit your webserver configuration to hide your server's details do it, if not it won't matter much anyway.