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).
Related
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
I have an Oracle instance with 8 users/schemas already but since late last week I am unable to create any new users on that instance. When I run the create user script it just keeps running....
This is a development box and I have full access to it. I am not a DBA so how do I troubleshoot to find out what the issue could be? and what could the issue be?
Here is the create user script:
create user usr_ARCHIVE identified by usr_ARCHIVEpw
default tablespace USERS
temporary tablespace TEMP
profile DEFAULT
quota UNLIMITED on USERS;
Please have a look at the user tablespace to see whether it has enough free space or not. I have faced similar issues in the past.
It's probably waiting or trying to obtain a lock. To determine what is going on you need to enable tracing. Before executing the create user statement, execute the following command:
alter session set events '10046 trace name context forever, level 12';
This will create a trace file in the trace directory. By default this is the same directory where the alert.log file is stored. Analyze the trace file and especially check for the lines that start with WAIT.
The problem was with another 10G TNSListener that was running. Once the 10G TNSListener was stopped and 11G Listener restarted the issue was resolved.
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.)
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.
I seem to be seeing a lot of messages like this in my log:
Trigger DEV."MBR_TRG" was disabled before the load.
Trigger DEV."MBR_TRG" was re-enabled by another process.
SQL*Loader-951: Error calling once/load initialization
ORA-00604: error occurred at recursive SQL level 1
ORA-00054: resource busy and acquire with NOWAIT specified
This is on my local dev machine, so there shouldn't be anything else trying to insert into these tables. How can I track down the cause of this? And is there any way to prevent the triggers from being re-enabled (at least to see if I get an error anywhere in my script)?
If this is your local dev machine you can drop the trigger and recreate it later.
Or you can change the trigger code to something that will not mess with your data but will only log execution so you can see when it was enabled.
It looks like the type of trigger can have an impact on how sqlloader deals with the trigger. As far as tracking the cause I would try a DDL trigger
I was seeing these errors in direct path loads. The problem was not 'another process' as the error message suggested, but lack of the proper permissions for the user to disable the trigger. You must have permission to alter the table AND the trigger. Which means you must own the table, or have alter permission on the table, or have alter any table permission. Also, you must own the trigger, or have alter any trigger permission.