Join sql_address from v$session to address from v$sqlarea .
Regards,
Denny
Quoting [EMAIL PROTECTED]:
I'm suffering from a senior moment.
The question is at the every bottom.
SQL select sql_text from v$sqlarea sa where buffer_gets 1
SQL_TEXT
Hi Larry,
I am attending. Wonder who else on the list is attending.
Regards,
Denny
Quoting Larry Elkins [EMAIL PROTECTED]:
Listers,
Just curious if anyone from the list will be going to the HOTSOS
Symposium
in Dallas on 2/9 thru 2/12? It sounds like it should be pretty good,
but
That's what I thought too. But the results of testing are somewhat different.
Maybe it's evaluated within the PL/SQL engine and does not require a context
switch to the SQL engine.
Platform : Sun Solaris 2.6
Oracle : 8.1.7.4 (32 bit)
DEV:43#14739-23049@dual1
DEV:43#14739-23049declare
2
Hi Scott,
I wouldn't worry about the hit ratios. Have you tried to find badly
performing SQL. The chances are the execution plan may have changed for some of
the frequently used SQL. When you doubled the block size, did you halve the
db_file_multiblock_read_count ? The optimizer may be
I don't think administering usernames should be the DBAs responsibilty. There
are better things to do than create/manage hundreds of users.
But there are applications (for instance Siebel) which require you to create
individual logins for each user. We have handled that by creating a
The DBA usually does not get to decide how the application is developed in
most of the cases. We have to manage what's out there. There are some products
which use one login for all users and manage security within the application.
If the applications is web enabled, the changes are the
Hi,
How did you identify this is the statement which is causing the problem ? Did
you check v$latch_children for the library cache children ? I would assume if
it's one single SQL, then the contention will be on one child latch and not
distributed across all the library cache latches. If this
If a common login is used (which is the case with most applications),
dbms_application_info can be used to set the actual username in either the
module or action. As long as the application is not using dbms_application_info
to set both, you should be able to get the info from v$session.
