Re: version_count

From: Chuck <skilover_nospam_at_bluebottle.com>
Date: Fri, 04 Apr 2008 18:57:16 GMT
Message-ID: <gSuJj.31$Ah1.5@trnddc08>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

joel garry wrote:
| On Apr 4, 9:38 am, Chuck <skilover_nos..._at_bluebottle.com> wrote:
| Can someone please give me an explanation, or point me to a URL which
| has one, of what v$sqlarea.version_count is all about? I understand it
| has to do with the # of child cursors for a given SQL in the library
| cache, but why would you need more than one cursor? Is that cursor not
| shareable? What would make a cursor not shareable? Does it have to do
| with different execution plans for the same SQL but with different bind
| variables? Or is it simply the # of sessions running the same SQL at he
| same time? TIA

| From the performance manual: "A SQL statement can map to multiple
| cursors, because the objects referred to in the cursor can differ from
| user to user."

That makes sense. Different users with objects of the same name would require different cursors for the same SQL. That's not my case though. It's a peoplesoft database with a single application schema and everyone uses the same objects.

| There's lots of explanations on the web and in books. Here's a good
| start (found by searching for v$sqlarea.version_count on
| asktom.oraclecom)

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:9497064796920
| http://www.freelists.org/archives/oracle-l/03-2004/msg03180.html

| Dan's primer is pretty good summary of 11:
http://www.psoug.org/reference/cursor_sharing.html

| A view exists to tell you why:

|
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/dynviews_2124.htm

I'll check those links too. Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with PCLinuxOS - http://enigmail.mozdev.org

iEYEARECAAYFAkf2egwACgkQzIf+rZpn0oSfGgCfYChqyWCwT9g4/IzVCAZtoSKy 3roAoJOEc9hx7AGKj3+fBsOBiaoovUOi
=bCj0
-----END PGP SIGNATURE----- Received on Fri Apr 04 2008 - 13:57:16 CDT

Original text of this message