The Database as a Networked Server - Implementing Database Security and Auditing - page 69

Figure 3.5

Retrieving network
connection
information in
SQL Server.

In Oracle, the SGA tables and views can be used. As an example, you can
use the following statement to get equivalent information in Oracle 10g:

select machine, terminal, program, logon_time, username from
v$session;

MACHINE TERMINAL PROGRAM LOGON_TIM USERNAME
raven OMS 09-OCT-04 SYSMAN

WORKGROUP\RON-SNYHR85G9DJ RON-SNYHR85G9DJ sqlplusw.exe 19-OCT-04 SYSTEM

raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
raven OMS 08-OCT-04 SYSMAN
WORKGROUP\RAVEN RAVEN emagent.exe 08-OCT-04 DBSNMP
WORKGROUP\RAVEN RAVEN emagent.exe 08-OCT-04 DBSNMP

The record that shows my Query Analyzer connection and my
SQL*Plus connection, respectively, is highlighted in both cases.
I mention these internal tables because in most auditing scenarios you
will not stop with connection information; you will often also want to audit
what was actually done within that session. This will require access to the
actual SQL commands sent as part of these sessions—using views such as
V$SQL in Oracle and commands such as

in SQL
Server. If all you need is connection information, you can usually manage
with built-in traces, monitoring events, or audit events, which are available
in all major database products.
The main issue with internal tables is that they are constantly being
changed. It is therefore fairly simple to get a snapshot of the current state of

dbcc inputbuffer