I would like to start monitoring our system closely as to see who and at what time did a user run a query.
Currently, on the tables from HIST DB, we are able to see the query Texts, username, date, time, and client IP. But what we are more interested in is to see the client host machine name.
When we run a query requesting client hostname, the output comes as unknown.
Below is the query that we are running to get our required information:
SELECT *
FROM NZ_QUERY_HISTORY
Is there anything else that we can look at or implement for us to be able to see client machine name.
FYI: When we run: show session all; we do infact see the client host machine.
We did our own view on top of the query history database when we started using netezza a few years ago, and it does not include the DNS name (hostname) of the client. I guess we left it out because it is empty most of the time. Another guess is that our DNS setup doesn’t not allow reverse DNS lookups for all IP addresses from the netezza host.
Instead we rely on:
the clien IP address and netezza username
the username&ip address on the client machine
In total that is quite powerfull
Furthermore we add a bit if ‘pre sql’ to the connection configuration of the client tools we use (sas, powercenter, business objects, etc) and add as much info as we can to the 4 ‘client_application_*’ variables. See here for syntax: https://www.ibm.com/support/knowledgecenter/en/SSULQD_7.2.1/com.ibm.nz.dbu.doc/r_dbuser_set.html
For powercenter we add the workflow,session and other -names...
I'm writing an insert into a linked server table that includes the IP the of the local server. When SSMS into the server and exec the SP, it provides the correct information into the Linked table.
When the SQL Agent runs the job for itself its returning 'NULL' and inserting Null into the remote table instead of the local IP. I'm sure this is because there is no "local" IP being used as it is using its only ports ect.
Specifically talking about the Connectionproperty('local_net_address)
set #vcLocalIP= convert (varchar,CONNECTIONPROPERTY('local_net_address'))
Any Help or Ideas on this would be greatly appreciated. Just trying to craft this SP so it can be put on different servers and all return the relevant information with as little "manual" intervention as possible.
I have a linked server where I can clearly see all the databases and tables, so I know the server is properly linked. However, when I try to execute a query, it says invalid object name, at the linked server's table.
The linked server is aliased as TCS, therefore, my query takes that table as
FROM [TCS].dbo.table as b
I have also tried including the database name also as FROM [TCS\db1].dbo.table.
What am I missing here?
Try including the DB name like so:
FROM [TCS].db1.dbo.table as b
I don't think you can specify the DB using a slash.
I would also check to make sure your security settings for the linked server are allowing your account to connect. This article touches on how to do that.
either:
the user (used for the link) doesn't have access to the table; Grant access;
the default DB on the server doesn't have the table. You have to change it to the relevant one or included in the db in the name: [TCS].DATABASE.dbo.table as b;
I have two Sysbase servers , server1 and server2 . I have a stored procedure declared and running on server1. In that SP i want to access table from server2. How can i do that? Also my both instances are running in a UNIX box
You can do that, read more about "Proxy tables" at Sybase Infocenter (search for: create proxy_table statement) Afaik, there has to be remote server declared as well. I think it's documented well.
First, create a 'Remote Server' in the database that has the stored procedure.
You will need to tell it what the 'Server Type' is and how to connect (ODBC, for instance), then in the connection information, you can simply put the DSN name.
Now, you can create proxy tables to reference tables in your other server.
Try using the four part name. See here: http://www.dbforums.com/sybase/1001475-call-sql-server-stored-proc-sybase.html
We have a system with an Oracle backend to which we have access (though possibly not administrative access) and a front end to which we do not have the source code. The database is quite large and not easily understood - we have no documentation. I'm also not particularly knowledgable about Oracle in general.
One aspect of the front end queries the database for a particular set of data and displays it. We have a need to determine what query is being made so that we can replicate and automate it without the front end (e.g. by generating a csv file periodically).
What methods would you use to determine the SQL required to retrieve this set of data?
Currently I'm leaning towards the use of an EeePC, Wireshark and a hub (installing Wireshark on the client machines may not be possible), but I'm curious to hear any other ideas and whether anyone can think of any pitfalls with this particular approach.
Clearly there are many methods. The one that I find easiest is:
(1) Connect to the database as SYS or SYSTEM
(2) Query V$SESSION to identify the database session you are interested in.
Record the SID and SERIAL# values.
(3) Execute the following commands to activate tracing for the session:
exec sys.dbms_system.set_bool_param_in_session( *sid*, *serial#*, 'timed_statistics', true )
exec sys.dbms_system.set_int_param_in_session( *sid*, *serial#*, 'max_dump_file_size', 2000000000 )
exec sys.dbms_system.set_ev( *sid*, *serial#*, 10046, 5, '' )
(4) Perform some actions in the client app
(5) Either terminate the database session (e.g. by closing the client) or deactivate tracing ( exec sys.dbms_system.set_ev( sid, serial#, 10046, 0, '' ) )
(6) Locate the udump folder on the database server. There will be a trace file for the database session showing the statements executed and the bind values used in each execution.
This method does not require any access to the client machine, which could be a benefit. It does require access to the database server, which may be problematic if you're not the DBA and they don't let you onto the machine. Also, identifying the proper session to trace can be difficult if you have many clients or if the client application opens more than one session.
Start with querying Oracle system views like V$SQL, v$sqlarea and
v$sqltext.
Which version of Oracle? If it is 10+ and if you have administrative access (sysdba), then you can relatively easy find executed queries through Oracle enterprise manager.
For older versions, you'll need access to views that tuinstoel mentioned in his answer.
Same data you can get through TOAD for oracle which is quite capable piece of software, but expensive.
Wireshark is indeed a good idea, it has Oracle support and nicely displays the whole conversation.
A packet sniffer like Wireshark is especially interesting if you don't have admin' access to the database server but you have access to the network (for instance because there is port mirroring on the Ethernet switch).
I have used these instructions successfully several times:
http://www.orafaq.com/wiki/SQL_Trace#Tracing_a_SQL_session
"though possibly not administrative access". Someone should have administrative access, probably whoever is responsible for backups. At the very least, I expect you'd have a user with root/Administrator access to the machine on which the oracle database is running. Administrator should be able to login with a
"SQLPLUS / AS SYSDBA" syntax which will give full access (which can be quite dangerous). root could 'su' to the oracle user and do the same.
If you really can't get admin access then as an alternative to wireshark, if your front-end connects to the database through an Oracle client, look for the file sqlnet.ora. You can set trace_level_client, trace_file_client and trace_directory_client and get it to log the Oracle network traffic between the client and database server.
However it is possible that the client will call a stored procedure and retrieve the data as output parameters or a ref cursor, which means you may not see the query being executed through that mechanism. If so, you will need admin access to the db server, and trace as per Dave Costa's answer
A quick and dirty way to do this, if you can catch the SQL statement(s) in the act, is to run this in SQL*Plus:-
set verify off lines 140 head on pagesize 300
column sql_text format a65
column username format a12
column osuser format a15
break on username on sid on osuser
select S.USERNAME, s.sid, s.osuser,sql_text
from v$sqltext_with_newlines t,V$SESSION s
where t.address =s.sql_address
and t.hash_value = s.sql_hash_value
order by s.sid,t.piece
/
You need access those v$ views for this to work. Generally that means connecting as system.