After getting another cup of coffee and rereading the text of the package
body, it is not free_unused_user_memory that references the
close_cached_open_cursors parameter, but the ability to alter the session
with this parameter is there. And what do you know, you can still alter the
session that way even though the parameter is now obsolete(actually it is
just hidden now(ie _close_cached_open_cursors )). Now this makes me even
more curious as to why the alertlog has entries saying this is an obsolete
parameter when I can execute it from sqlplus fine. Sigh, one of these weeks
I am going to go to bed.:-)
--
Dave A
"Dave A" <dave_and_vanna_at_hotmail.com> wrote in message
news:suhvp7faohf15e_at_corp.supernews.com...
> Hi all,
>
> I love Oracle as it keeps me employed, but with this upgrade from 7.3.4 to
> 8.1.6.2, I have not been getting a lot of sleep :-)
> The latest weirdness I have found (going to metalink shortly) is that the
> alert log contains many messages about close_cached_open_cursors specifies
> an obsolete parameter.
>
> First, I said "OK, that's nice".
> Then I got to wondering, what exactly was giving the alter session
command.
> I queried dba_source and found only one package that had this parameter
> specified in one of it's procedures. That package is dbms_session and the
> procedure is free_unused_user_memory.
> This entry in the alert log is always around 6:30 am and I can't seem to
> track down what would be going on at the time to call this procedure(yet).
>
> I verified that the create date for the package is the same as the
date/time
> of the upgrade so I don't believe this is a case of an older version of
the
> package being around. I have also verified in all 8.1.6.2 installations
> that the procedure references this parameter.
>
> The problem here is that this procedure is used to return unneeded memory
> from user sessions to the OS. Since the way Oracle is doing it obviously
> isn't working, what is? Since the alert log entries only occur at 6:30am
I
> have to assume that Oracle has other ways of doing this and that more than
> likely it is an application that is calling the procedure, but still, this
> seems like a bug to me. Anyone have any wisdom to add on this?
>
> --
> Dave A
>
>
>
>
Received on Sat Oct 14 2000 - 20:31:45 CDT
