September 1, 2009 - 3pm Central time zone
Reviewer: A reader
Thanks!! for great explanation Sir
One more doubt since we have SARS and SRS for sorting which define which part goes where i.e. (a
bit in UGA and a bit in PGA ) who about Hash/Bitmap Join? it is also partially located in UGA (SGA)
and partially located in PGA for shared server?
Is the same parameter SARS and SRS define the location during Hash/bitmap join?
Many Thanks
Regard's
Followup September 1, 2009 - 6pm Central time zone:
stop going down the manual path - just use automatic pga memory management - seriously...
those without the retained are in the UGA in the SGA
September 2, 2009 - 11am Central time zone
Reviewer: A reader
Thanks Sir for quick reply
<quote>
those without the retained are in the UGA in the SGA
<quote>
So you mean to say hash_area_size is in UGA(i.e. SGA Large pool)
but as per below
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10837399101938
you said that
<quote>
Now, there are some operations -- like a hash join for example -- that prevent migration.
It used to be that these operations were not permitted via shared server -- but now they
are.
If anything remains in the PGA after a call -- that session will be non-migratable, we
need THAT specific shared server. If the remaining bits of data are safely in the UGA,
that'll be in the SGA and we can migrate.
It is for that reason for example that PGA_AGGREGATE_TARGET is *not* used with shared
server in 9i with shared server, sort_area_size/hash_area_size are, regardless of the
workarea size policy setting.
<quote>
So I am confuse could you please clarify in this regard?
Millions Thanks.
Followup September 2, 2009 - 12pm Central time zone:
exactly, the as per below:
It used to be that these operations were not permitted via shared server --
but now they are.
lends evidence to the placement of the hash area, if it were in the pga, we could NOT use shared server.
IT USED TO BE (past tense) that shared server could not use a hash join - because it was pga based.
It is no longer true (current) hence the data must be available in a place that a migrated session (something you get with shared server all of the time) can have access to - the UGA, in the SGA.
And in 9i, the first release of automatic memory management, shared server was not supported - it uses the sort/hash/bitmap area sizes.
However, you are in 10g, whereby automatic memory management is fully supported
and hence, you should not be using manual.
September 2, 2009 - 1pm Central time zone
Reviewer: A reader
Thanks Tom thats clarify my confusion
Shared servers x Connections
September 2, 2011 - 12pm Central time zone
Reviewer: Sam from Colombia
Tom,
We have a client that have faced a lot of problems, due to the number
of new conections opened by PHP, at an interval of 40 minutes, 2600 new conections
were opened and closed.
After we talk with thier DBA, He told us that they didn't got the "ORA-01000:
maximum open cursors exceeded tips". He also told that the main problem is the large
number of new conections opened and closed in a short period of time.
We have about 500 clients using the same application with Oracle and it's the
first time that we heard about this kind of problem.
We dont belive its hardware problem, their server is extremely good, here is
some parameters:
db_cache_size 4000M
db_file_multiblock_read_count 32
java_pool_size 160M
large_pool_size 32M
log_buffer 46756864
open_cursors 2000
parallel_max_servers 480
parallel_min_servers 0
pga_aggregate_target 1G
sga_max_size 8000M
shared_pool_size 944M
sort_area_retained_size 0
sort_area_size 65536
Our client is using Oracle 10g R2 on red hat enterprise
Do you think we can solve this problem using Oracle Shared Servers, or it will
just "mask the real problem"?
Do you have any ideia of what should be checked?
Best Regards,
Gustavo
Followup September 3, 2011 - 11am Central time zone:
You need DRCP - database resident connection pooling, a new 11gr2 feature.
shared server might help offset to a small degree the login cost - but not nearly as well as DRCP
About PHP and opening/closing connections
September 3, 2011 - 4pm Central time zone
Reviewer: Stew Ashton from Paris, France
Just to add to Tom's reply:
If the problem is just having too many connections to the database, DRCP is the complete answer.
If the problem is opening and closing too many connections in a short period of time, you also need the PHP program to use "persistent connections" to the database.
Shared Server Connection
September 16, 2011 - 3pm Central time zone
Reviewer: Gustavo from Brazil
Tom,
Thanks for the reply.
But the client wont change the database version.
We have the database server and the application server, on a local connection,
where all users access the system through the internet connection from the company.
The idea to solve our problem, is to bring the application server to the company where
users will connect locally on the application, but the application server and the database
server will have to "talk" on the internet connection.
1 - ) Oracle client and server has something, where i can compress the data between
the application server and database server?
2 - ) In your opinion, is this a good idea?
Regards,
Gustavo
Followup September 16, 2011 - 4pm Central time zone:
1) we already do compression of the data stream - and compression of the data stream will not affect logon latency nor will it help the ora-1000 (which is a BUG in the client application by the way... it is leaking cursors....)
fixing the network will do nothing to solve the issue of the login problem.
I don't know why you are asking about compression to fix a login problem?
|