respective all!
My database version is Oracle 12.2.
My question is - what if I include
alter session set events '10046 trace name context forever...'
at the top of session but do not include "counterpart"
alter session set events '10046 trace name context off'
at the bottom of session?
Will Oracle terminate tracing automatically when the session ends? And will it terminate tracing in case of erroneous end of the session?
TIA,
Andrew.
Will Oracle terminate tracing automatically when the session ends?
And will it terminate tracing in case of erroneous end of the session?
Yes, of course, since you enabled it for your session only.
BTW, there is special parameter MAX_DUMP_FILE_SIZE that allows you to set max trace file size limit: https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/MAX_DUMP_FILE_SIZE.html
Related
This question already has answers here:
How to kill a running SELECT statement
(6 answers)
Closed 9 years ago.
I have 1000 records on my table,while deleting records using toad, I get a error message as
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
I tried ,
alter system kill session ('214,60347');
but I get invalid for both attributes.In this i declared correct values,
I also tried
alter system kill session ('214,60347#'); as alter system kill session ('sid,serial#');
is first query correct? or are there any other ways to kill session in oracle?
This message means that the transaction was not committed nor rolled back. Event after the error if you are able to do one of both try it.
It would be good to add the "immediate" keyword at the end to force it right away.
ALTER SYSTEM KILL SESSION ('sid,serial#') IMMEDIATE;
ALTER SYSTEM KILL SESSION ('214,60347') IMMEDIATE;
Because killing the session can make a mess try to use the "disconnect" option.
ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE;
Details about it can be found here:
http://www.oracle-base.com/articles/misc/killing-oracle-sessions.php
I have Oracle RAC 10g environment with two nodes.
On connection we set the session TIME_ZONE using ALTER SESSION.
But, on switching the session to another node , RAC lost TIME_SONE settings.
How to keep session parameters upon switching to another RAC node?
Tx
If you're talking about Transparent Application Failover there is probably no easy way to do this:
You must also reexecute any session customizations, in other words,
ALTER SESSION statements, after failover has occurred.
There may be workarounds, depending on how you set the session settings. For example, if all the relevant sessions come from the same application, computer, etc., you can use a logon trigger that sets the same settings. You can find the relevent session using v$session.failed_over = 'YES', and matching other relevant columns in v$session.
Is it possible to alter the session permanently even after i close my oracle sql developer?
An example of the statement that i want to alter:
Alter Session Set Nls_Timestamp_Tz_Format='HH24:MI TZR';
The above statement only allow me to alter the current session and not making it permanently.
Thanks
If you just want to change the default value for SQL Developer, you can do that in the SQL Developer settings. In SQL Developer 3.1 (the same settings exist in earlier versions though the navigation may be slightly different), Tools | Preferences | Database | NLS allows you to specify a Timestamp Format and a Timestamp TZ Format. SQL Developer will then automatically issue the appropriate ALTER SESSION commands for you whenever it creates a new session.
You need to set this in the initialization parameter file to affect the database globally.
Initialization parameters such as Nls_Timestamp_Tz_Format can be set up from three sources:
In a session using the ALTER SESSION SET statement
In client side parameter file init.ora
In server side parameter file spfile
To set default permanently in the db, from the database:-
alter system ... scope=spfile;
then as SYS (so you may need to talk to a DBA), and obviously at an appropriate time! -
shutdown;
startup;
(I know the spfile has been mentioned, but it can all be done from the sqlplus cmdline, at least in 11g.)
We're having issues with a table that is locking up in our system, so we decided to put a tracefile so we can gather more info about it. Here's what we've done:
alter session set tracefile_identifier='10046USERLOGINNR';
alter session set timed_statistics = true;
alter session set statistics_level=all;
alter session set max_dump_file_size = unlimited;
alter session set events '10046 trace name context forever,level 12';
//UPDATE SQL STATEMENTS
alter session set events '10046 trace name context off';
However, and for some reason that we can't identify yet, the trace file 10046USERLOGINNR does not get created.
Anything we're missing?
It looks to me like what you're doing should be working. The things I can think of to check are:
Are you looking in the right place? The trace file should go into the directory indicated by the USER_DUMP_DEST database parameter.
Does the Oracle OS account have write privilege on the directory? If not creation of the trace file will silently fail.
If you're on Windows, you could use Process Explorer to check all the open file handles for oracle.exe after activating tracing. If the file is going to an unexpected location for some reason, you'll find it this way. Presumably there's some way you could check the same thing on other operating systems as well.
Daft theory, but double check the udump_dest_dir setting. Might be getting created somewhere unexpected. (on that, also check bdump for shared server connections).
Is there a tool (that already comes with Oracle) for tracing SQLs that have been executed? In DB2 there is something called an 'event monitor' which I use to track the tables that have been updated. Is there an equivalent tool in Oracle?
I plan to
enable tracing
go on the website (that uses the db) and change an entry
disable tracing
see output file and record which table has been updated.
There is a table I am looking that should be updated when the entry is changed. I do not know what the name of the table is (and there are many tables), and so I need to trace the SQL executed to find out.
I have tried:
ALTER SESSION SET sql_trace = true;
-- go on website and change an entry
ALTER SESSION SET sql_trace = false;
tkprof the_trace_file.trc file.out EXPLAIN=system/manager SYS=no
However when following those steps above, no SQLs were recorded.
Is there a tool that Oracle provides? (I would like to avoid downloading external software)
There is a table I am looking that
should be updated when the entry is
changed. I do not know what the name
of the table is (and there are many
tables), and so I need to trace the
SQL executed to find out.
I'm thinking you are using the word "trace" here with another meaning than what is usually meant in the Oracle world.
You basically hit some button in the app, and by looking at what SQL queries are running, you want to find what table that code was referencing? Did I get it right?
In that case, you could have a look at v$sql, and look at columns SQL_TEXT and SQL_FULLTEXT.
The ALTER SESSION commands work at the session level (ie your current connection).
The website will use a different session (probably from a connection pool).
You can enable tracing for all sessions using the ALTER SYSTEM SET sql_trace = true;
The main reason you didn't get anything in the trace file is because you didn't do anything in the session where trace was enabled.
If you'd have done:
alter system set sql_trace = true;
-- fiddle around with the website
alter system set sql_trace = false;
You'd have gotten one or more trace files, one for each session which had activity while you were fiddling with the website.
The problem is that if the website uses connection pooling, your user activity may have been spread across several connections, and may be intermingled with other concurrent user activity.
Maybe Oracle Audit will help you.
Here is a good explanation: http://www.oracle-base.com/articles/10g/Auditing_10gR2.php
You have to enable audit by setting the parameter AUDIT_TRAIL.
That is at server level. You can audit at client level using a third party sql tracer for OCI:
http://sourceforge.net/projects/ocimonitor/
I find the Enterprise Manager the most useful tool for this. As has already been noted you have to alter the session that the web site is using and not your own. If you set your connection pool limit to 1 connection, you can easily find the session in the enterprise manager and then turn on the tracing. Usually a find the the top queries display in the enterprise manager tells me what queries are taking too long without having to trace anything.