Updating sql tables when joined
Ofcourse without killing that session and re-running it.T1 - May 17, 2002 - am UTC No, think about it -- how could it?How can I know which PL/SQL blocks or SQL statements are being run by him ? It shows everyone logged in and if they are active, what they are doing and how long they've been doing it.As to SQL statemets, I can join v$session.user# with v$sqlarea.parsing_user_id ( am I really right ??? How can I track the execution of those objects and queries (something like V$transaction for entire trasactions) ? If someone is executing PLSQL, what you will see will depend on what the plsql is currently doing. if the plsql is doing lots of PLSQL work -- you'll see that code.say you changed it from using an index to using a full scan (via the stats). For some reason, however, I cannot get it to compile. begin 2 dbms_output.put_line( 'hello' ); 3 end; 4 / 5 / / * ERROR at line 4: ORA-06550: line 4, column 2: PLS-00103: Encountered the symbol "/" The symbol "/" was ignored.It couldn't just start full scanning as it would undoubtably re-read rows it had already processed. Keep getting 'PLS-00103 Encountered the symbol "/"' at line forty, which is the forward slash following the two "end loops" and the "end" statement. sounds like you do (from the cut and paste maybe) November 15, 2002 - pm UTC If a session is currently ACTIVE, this is the number of seconds the statement it is executing has been ACTIVE.If a session is currently INACTIVE, this is how long its been inactive.If timed statistics is TRUE, this number is very accurate.
Any work around to query these views from non sys user.
just knowing that at this instant -- when you run that query -- no one is using the package, that is not useful to you -- as the instant after you run that query the answer will change (and you should not run your process) You NEED to use a serialization device.
Tom, I agree 101% - X$ are "magical", they CAN and WILL change anytime, without warning, and worse, NO READ-CONSISTENCY here - so, in a very busy db, chances are of X$ being "late", not refreshed, or alike.
I had run it about 2 months back and it completed in 3 hours. If a SQL is executing and we do certain changes which will impact the performance of this SQL.
The data has mot increased much but I don't know if the DBA has changed some parameters since then. Can I predict with some certainty how much more time will it take to insert the records. Then is there anyway we can force the executed SQL to read these changes.