Ancora sbagliato a iniziare il nome di una procedura memorizzata dall'utente con sp_?

Uno dei miei colleghi ha chiamato una procedura memorizzata nel nostro database SQL Server 2008 R2 sp_something. Quando ho visto questo, ho subito pensato: "È SBAGLIATO!" e ho iniziato a cercare nei miei segnalibri questo articolo online che spiega perché è sbagliato, così ho potuto fornire una spiegazione al mio collega.

Nell'articolo (di Brian Moran ) viene spiegato che assegnando alla procedura memorizzata un prefisso sp_ , SQL Server esamina il database master per un piano compilato. Poiché sp_sprocnon si trova lì, SQL Server ricompilerà la procedura (e per questo richiede un blocco di compilazione esclusivo, causando problemi di prestazioni).

Il seguente esempio è riportato nell'articolo per mostrare la differenza tra due procedure:

USE tempdb;
GO

CREATE PROCEDURE dbo.Select1 AS SELECT 1;
GO

CREATE PROCEDURE dbo.sp_Select1 AS SELECT 1;
GO

EXEC dbo.sp_Select1;
GO

EXEC dbo.Select1;
GO

Eseguire questo, quindi aprire il Profiler (aggiungere l' SP:CacheMissevento Stored Procedures -> ) ed eseguire nuovamente le stored procedure. Dovresti vedere una differenza tra le due stored procedure: la sp_Select1stored procedure genererà un SP:CacheMissevento in più rispetto alla Select1stored procedure (l'articolo fa riferimento a SQL Server 7.0 e SQL Server 2000 ).

Quando eseguo l'esempio nel mio ambiente SQL Server 2008 R2, ottengo la stessa quantità di SP:CacheMisseventi per entrambe le procedure (sia in tempdb che in un altro database di test).

Quindi mi chiedo:

• Posso aver fatto qualcosa di sbagliato nell'esecuzione dell'esempio?
• sproc sp_somethingL'adagium " non nominare un utente " è ancora valido nelle versioni più recenti di SQL Server?
• In tal caso, esiste un buon esempio che mostra la sua validità in SQL Server 2008 R2?

Grazie mille per i tuoi pensieri su questo!

MODIFICARE

Ho trovato Creazione di stored procedure (Motore di database) su msdn per SQL Server 2008 R2, che risponde alla mia seconda domanda:

Si consiglia di non creare alcuna procedura memorizzata utilizzando sp_ come prefisso. SQL Server utilizza il prefisso sp_ per designare le stored procedure di sistema. Il nome scelto potrebbe essere in conflitto con alcune future procedure di sistema. [...]

Non viene menzionato nulla in merito ai problemi di prestazioni causati dall'utilizzo del sp_prefisso. Mi piacerebbe sapere se è ancora così o se lo hanno risolto dopo SQL Server 2000.

È abbastanza facile metterti alla prova. Creiamo due procedure molto semplici:

CREATE PROCEDURE dbo.sp_mystuff
AS
  SELECT 'x';
GO
CREATE PROCEDURE dbo.mystuff
AS
  SELECT 'x';
GO

Ora costruiamo un wrapper che li esegua più volte, con e senza il prefisso dello schema:

CREATE PROCEDURE dbo.wrapper_sp1
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC sp_mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_1
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_sp2
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC dbo.sp_mystuff;
      SET @i += 1;
    END
END
GO
CREATE PROCEDURE dbo.wrapper_2
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @i INT = 1;
    WHILE @i <= 1000
    BEGIN
      EXEC dbo.mystuff;
      SET @i += 1;
    END
END
GO

risultati:

conclusioni:

• l'utilizzo del prefisso sp_ è più lento
• tralasciando il prefisso dello schema è più lento

La domanda più importante: perché si vuole utilizzare il prefisso sp_? Che cosa i vostri collaboratori si aspettano di guadagnare dal farlo? Ciò non dovrebbe riguardare la necessità di dimostrare che ciò è peggio, ma dovrebbe giustificare l'aggiunta dello stesso prefisso di tre lettere a ogni singola procedura memorizzata nel sistema. Non riesco a vedere il vantaggio.

Inoltre ho eseguito alcuni test piuttosto estesi di questo modello nel seguente post di blog:

http://www.sqlperformance.com/2012/10/t-sql-queries/sp_prefix

Si consiglia di non creare alcuna procedura memorizzata utilizzando sp_ come prefisso. SQL Server utilizza il prefisso sp_ per designare le stored procedure di sistema. Il nome scelto potrebbe essere in conflitto con alcune future procedure di sistema. [...]

Non viene menzionato nulla in merito ai problemi di prestazioni causati dall'utilizzo del prefisso sp_. Mi piacerebbe sapere se è ancora così o se lo hanno risolto dopo SQL Server 2000.

Come mostra il semplice commento di Martin Smith - sì, se si dispone di una procedura memorizzata con un sp_prefisso - l'esecutore di query di SQL Server controllerà sempremaster prima nel database se esiste una procedura memorizzata (contrassegnata come procedura memorizzata dal sistema) con quel nome.

E se esiste, quella procedura memorizzata dal sistema dal masterdatabase prevale sempre e verrà eseguita al posto della tua.

Quindi sì - è ancora valido: non usare il sp_prefisso.

Un test migliore è quello di scrivere una query che richiede un'ottimizzazione completa poiché è probabilmente un riflesso migliore di ciò che sta facendo il proc che stai scrivendo. Ho racchiuso la seguente query in un SP, ripetuto il test e ottenuto gli stessi risultati.

select * from Person.BusinessEntity b
inner join Person.BusinessEntityAddress ba on b.BusinessEntityID = ba.BusinessEntityID
inner join Person.Address a on ba.AddressID = a.AddressID

Ho avuto lo stesso numero di eventi cache mancati e hit in entrambi i casi e in entrambi i casi il piano è stato aggiunto alla cache. Ho anche eseguito entrambi i processi più volte e non vi era alcuna differenza costante nel tempo della CPU o nel tempo trascorso riportato da dm_exec_query_stats.

L'altra preoccupazione è che dal momento che "sp_" procs può essere eseguito dal master, è possibile ottenere una copia del proc che è stato eseguito nel master invece del DB in cui si sta lavorando, ma un test rapido mostrerà che non è il caso. Tuttavia, se proc viene eliminato dal DB in cui si sta lavorando ed esiste una copia nel master, verrà eseguito il che potrebbe essere un problema se si tratta di una versione precedente. Se questa è una preoccupazione non userei "sp_" per nominare il proc.

Credo che il problema abbia a che fare quando non si specifica il nome completo dell'oggetto. Pertanto, "EXEC sp_something" controllerà prima il master, ma "EXEC dbname.dbo.sp_something" non andrà mai prima al master.

La lezione, se ricordo, è di usare sempre il nome completo.