|
|
|
|
|
|
| Author |
Message |
Anthony Mandic *nix forums Guru Wannabe
Joined: 05 Jul 2005
Posts: 164
|
Posted: Sun Apr 03, 2005 5:43 am Post subject:
Re: Parallel first time calls to stored proc
|
|
|
CJ wrote:
| Quote: |
I am having a problem with a stored proc which is dropping out of the
procedure cache and thus being re-resolved the first time it is called
after it has dropped out.
|
It sounds like your proc cache is too small.
| Quote: | The problem is that the first time the
stored proc is called, it can be called N times in parallel (ie
through N different sessions). This will cause N copies of the query
plan to be generated and stored in the cache.
|
This is what normally happens. Sprocs are non-reenterant,
so every caller gets their own copy. The dbcc memusage
call reports how many instances of the query plan are
in cache.
| Quote: | I can accept this as it is the way Sybase works, however what is
surprising is that the time for each stored proc to complete is of
O(N). i.e. if it takes 10 seconds for just one call, then it will
take 100 seconds when there are 10 parallel calls. The stored proc is
a read-only proc, so there are no exclusive locks taken out by it.
|
Its irrelevant whether it locks or not, each reresolution requires
the optimiser to reresolve the sproc. This can lead to problems
if the query plan generated by the sproc contains conditionals
and the next caller inherits a plan that is not optimal for
their particular query. This is a known problem.
| Quote: | Has anyone else come across this problem and found a solution?
|
Does your sproc have conditional statelemts in it? How big
is it? Can you break it up?
-am © 2005 |
|
| Back to top |
|
 |
CJ *nix forums beginner
Joined: 01 Apr 2005
Posts: 1
|
Posted: Fri Apr 01, 2005 10:28 am Post subject:
Parallel first time calls to stored proc
|
|
|
I am having a problem with a stored proc which is dropping out of the
procedure cache and thus being re-resolved the first time it is called
after it has dropped out. The problem is that the first time the
stored proc is called, it can be called N times in parallel (ie
through N different sessions). This will cause N copies of the query
plan to be generated and stored in the cache.
I can accept this as it is the way Sybase works, however what is
surprising is that the time for each stored proc to complete is of
O(N). i.e. if it takes 10 seconds for just one call, then it will
take 100 seconds when there are 10 parallel calls. The stored proc is
a read-only proc, so there are no exclusive locks taken out by it.
Has anyone else come across this problem and found a solution?
CJ |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Thu Jan 08, 2009 4:30 am | All times are GMT
|
|
Car Credit | Debt Consolidation | Xecuter 3 Mod Chip | Guitar Lesson | Internet Advertising
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|