Hello
For SS2K
I have read some articles before :
For public users other than dbo executing a dbo-owned stored procedure
without the dbo. qualifier, the first time lookup from the Procedure
Cache will fail resulting in a compile lock something like that. And a
CacheMiss should appear in the Profiler trace. And then ultimately the
cached plan was found once the ambiguous object name had been
resolved. (No actual re-compile) And I should see the ExecTextHit
following the CacheMiss.
However my testing is showing NO CacheMiss when I exec following in
QueryAnalyzer using userlogin other than dbo. Always showing CacheHit
or ExecTextHit
exec testproc
My question is that Is there any CacheMiss and compile lock for very
short time if I do not qualify the <dbo.> for executing SPs. Or has
this internal data structure been revised. The snapshot on
sysprocesses table won't show compile lock for such a short-time
locking. How do I prove if there is any small performance overhead ?
TIA
Norman Leung
For SS2K
I have read some articles before :
For public users other than dbo executing a dbo-owned stored procedure
without the dbo. qualifier, the first time lookup from the Procedure
Cache will fail resulting in a compile lock something like that. And a
CacheMiss should appear in the Profiler trace. And then ultimately the
cached plan was found once the ambiguous object name had been
resolved. (No actual re-compile) And I should see the ExecTextHit
following the CacheMiss.
However my testing is showing NO CacheMiss when I exec following in
QueryAnalyzer using userlogin other than dbo. Always showing CacheHit
or ExecTextHit
exec testproc
My question is that Is there any CacheMiss and compile lock for very
short time if I do not qualify the <dbo.> for executing SPs. Or has
this internal data structure been revised. The snapshot on
sysprocesses table won't show compile lock for such a short-time
locking. How do I prove if there is any small performance overhead ?
TIA
Norman Leung