In a system I'm maintaining there is a Stored Procedure called
dbo.MyStoredProcedure. I didn't create this - it was created by a
developer who has now left. I don't know how the object came by its
"dbo." prefix, but I think he created it in QA.
Anyway, there were some performance issues (it was taking between 4
and 10 seconds to complete) so I copied the SQL into a QA window and
it consistently ran in under 1 second. So I created a new SPROC with
SQL exactly identical to the old one, but without the "dbo." prefix,
and that too runs in <1 second.
Any thoughts?
Edward 6 2930
<te********@hotmail.comwrote in message
news:11**********************@v33g2000cwv.googlegr oups.com...
In a system I'm maintaining there is a Stored Procedure called
dbo.MyStoredProcedure. I didn't create this - it was created by a
developer who has now left. I don't know how the object came by its
"dbo." prefix, but I think he created it in QA.
dbo = database owner.
This is actually fairly common.
So not really sure what you're finding unusual here.
However, that said, you should call all stored procs with the owner
qualifier included.
Example:
stored proc FOO
Created by the sa so it's qualifed as:
dbo.FOO
Now user BAR comes along and calls:
exec FOO
First SQL Server will check to see if there is a stored proc BAR.FOO and try
to execute that. If not, THEN it'll look up dbo.FOO and try to execute
that.
Sounds like what's happening here. (Or something similar.) (note it's even
worse if it's named sp_xxxx).
Not sure why it would take 4-10 seconds, but I suspect that's part of the
issue.
Anyway, there were some performance issues (it was taking between 4
and 10 seconds to complete) so I copied the SQL into a QA window and
it consistently ran in under 1 second. So I created a new SPROC with
SQL exactly identical to the old one, but without the "dbo." prefix,
and that too runs in <1 second.
Any thoughts?
Edward
--
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com te********@hotmail.com wrote:
>
In a system I'm maintaining there is a Stored Procedure called
dbo.MyStoredProcedure. I didn't create this - it was created by a
developer who has now left. I don't know how the object came by its
"dbo." prefix, but I think he created it in QA.
Anyway, there were some performance issues (it was taking between 4
and 10 seconds to complete) so I copied the SQL into a QA window and
it consistently ran in under 1 second. So I created a new SPROC with
SQL exactly identical to the old one, but without the "dbo." prefix,
and that too runs in <1 second.
Any thoughts?
Edward
Maybe all the stored procedure needed was a recompilation. Maybe it had
nothing to do with the dbo prefix.
Please post back if the behavior is consistent (IOW, if performance
degrades if you change it back to the dbo prefix).
Gert-Jan
(te********@hotmail.com) writes:
In a system I'm maintaining there is a Stored Procedure called
dbo.MyStoredProcedure. I didn't create this - it was created by a
developer who has now left. I don't know how the object came by its
"dbo." prefix, but I think he created it in QA.
Anyway, there were some performance issues (it was taking between 4
and 10 seconds to complete) so I copied the SQL into a QA window and
it consistently ran in under 1 second. So I created a new SPROC with
SQL exactly identical to the old one, but without the "dbo." prefix,
and that too runs in <1 second.
Any thoughts?
All stored procedures in a database (and all tables, all views etc)
belongs to a schema, and the full name within the database is
schema.procedure. If you leave out the schema when you create your
procedure, the procedure is created in your default schema. If you are
the database owner the default is "dbo". On SQL 2000, your default
schema is always the same as your user name. But in SQL 2005, owners
and schema are separeate, and all users can have dbo as their default
schema.
In many databases, all objects are in the dbo schema.
It follows from this, that whatever the performance problems with
your procedure due to, it was not the dbo prefix. (Unless you recreated
the procedure in your default schema which have tables that are
namesakes with those in the dbo schema - but are much smaller.)
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se
Books Online for SQL Server 2005 at http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinf...ons/books.mspx
"Gert-Jan Strik" <so***@toomuchspamalready.nlwrote in message
news:45***************@toomuchspamalready.nl...
te********@hotmail.com wrote:
>> In a system I'm maintaining there is a Stored Procedure called dbo.MyStoredProcedure. I didn't create this - it was created by a developer who has now left. I don't know how the object came by its "dbo." prefix, but I think he created it in QA.
Anyway, there were some performance issues (it was taking between 4 and 10 seconds to complete) so I copied the SQL into a QA window and it consistently ran in under 1 second. So I created a new SPROC with SQL exactly identical to the old one, but without the "dbo." prefix, and that too runs in <1 second.
Any thoughts?
Edward
Maybe all the stored procedure needed was a recompilation. Maybe it had
nothing to do with the dbo prefix.
Please post back if the behavior is consistent (IOW, if performance
degrades if you change it back to the dbo prefix).
Duh, didn't even think of recompilation.
--
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
Gert-Jan
On 19 Feb, 22:35, Gert-Jan Strik <s...@toomuchspamalready.nlwrote:
teddysn...@hotmail.com wrote:
In a system I'm maintaining there is a Stored Procedure called
dbo.MyStoredProcedure. I didn't create this - it was created by a
developer who has now left. I don't know how the object came by its
"dbo." prefix, but I think he created it in QA.
Anyway, there were some performance issues (it was taking between 4
and 10 seconds to complete) so I copied the SQL into a QA window and
it consistently ran in under 1 second. So I created a new SPROC with
SQL exactly identical to the old one, but without the "dbo." prefix,
and that too runs in <1 second.
Any thoughts?
Edward
Maybe all the stored procedure needed was a recompilation. Maybe it had
nothing to do with the dbo prefix.
Please post back if the behavior is consistent (IOW, if performance
degrades if you change it back to the dbo prefix).
10/10! I dropped the SPROC, then recreated it identically and it ran
like a greyhound. So all it needed was recompilation. I guess
there's an art to knowing how often/in what circumstances to recompile
SPROCs but I'm a developer, not a DBA so I don't know!
Thanks
Edward
(te********@hotmail.com) writes:
10/10! I dropped the SPROC, then recreated it identically and it ran
like a greyhound. So all it needed was recompilation. I guess
there's an art to knowing how often/in what circumstances to recompile
SPROCs but I'm a developer, not a DBA so I don't know!
You don't even have to drop the procedure, it sufficient to say:
sp_recompile procname
to flush all plans of it out the cache.
Normally, this is not needed, but SQL Server has this feature known as
parameter sniffing. When the optimizer builds the plan on the first
invocation, it looks at the actual parameter values and takes this as
guidance. But if that first invocation is for an untypical value, that
may buy you a plan which is bad for regular input.
This is not the only reason for a this sort of behaviour. It can also
be that the statistics are such that the optimizer's estimates for
two plans are very close, although one of the plans are not good at all.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se
Books Online for SQL Server 2005 at http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinf...ons/books.mspx This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Andreas Lauffer |
last post by:
I changed from Access97 to AccessXP and I have immense performance
problems.
Details:
- Access XP MDB with Jet 4.0 ( no ADP-Project )
- Linked Tables to SQL-Server 2000 over ODBC
I used...
|
by: teddysnips |
last post by:
SQL Server 2000
I have a stored procedure that uses an extended SPROC to send an email
notification to my customers when a document is distributed.
However, the SPROC has an unexpected side...
|
by: Gui Lloyd |
last post by:
I have a problem with performance in IE.
The script above works quite fine when the table has a small number of
elements, but, when the table has 2500 elements, when I click in the
checkbox of the...
|
by: Bob Stearns |
last post by:
When I run the following query with the two sections commented out, the
response time is between 1 an 2 seconds; with the first indicated
section enabled, the response goes up to 15 seconds even...
|
by: Mike L |
last post by:
I tried a sample of code in MSDN magazine, but now I'm stuck. What code has
the best performance to populate a Data Grid with a SP? Below is the code I
have, which might be completing the wrong...
|
by: MR |
last post by:
Why does the string value assigned to the RequestElementName in the
SoapDocumentMethodAttribute get changed?
The value below with a colon is changed to the hex value surrounded by
underscores....
|
by: Bob Stearns |
last post by:
The following query takes 3-5 seconds which seems a bit excessive:
select * from is3.pedigree2
where bhid in
( 322380, 379701, 380901, 394336, 394342, 396039, 400764)
Furthermore, when...
|
by: Bob Stearns |
last post by:
BHID id the (only) primary key, and thus index, of Animals, which is the
only real table involved.
Pedigree2 is the view based on Animals.
runstats on table is3.animals ON ALL COLUMNS AND...
|
by: Looch |
last post by:
Hi All,
I originally wrote a sproc with one of the parameters set as
SqlDBType.nvarchar,8. The parameter in the sproc was defined as 8
cahracters and the column in the table was also set to...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |