Zaten önbelleğinde kullanılabilir değilse, kullanıcı bir saklı yordamın yürütüldüğünde, SQL Server yordamı yükler ve a query plan derler. Derlenmiş planı önbelleğe kaydedilir ve planı geçersiz kılmak ve bir recompilation zorlamak için bazı eylemler oluşana kadar saklı yordamın sonraki Arayanların tarafından yeniden kullanılabilir. Aşağıdaki eylemlerden bir saklı yordamın planın recompilation neden olabilir:
- WITH YENIDEN yan tümcesi ya da EXECUTE CREATE PROCEDURE deyimi içinde kullanın.
- Şema ekleme veya kısıtlamaları, varsayılanlar veya kuralları bırakarak da dahil olmak üzere başvurulan nesnelerin herhangi değiştirir.
- Bu yordam tarafından başvurulan bir tablo için sp_recompile çalıştırıyor.
- (Geçici veritabanı işlemleri yapıyorsanız) yordamını veya nesnelerin herhangi birini içeren bir veritabanını geri yükleme yordamı başvuruyor.
- Yeterli sunucu etkinliğini önbelleğinden eskime plan neden.
Bir saklı yordamın recompiling için tüm bu nedenle önceki sürümleri var ve yordamın yürütmeye başlamadan önce yeniden derlemek plan neden oldu. SQL Server 7. 0'de yeni bir davranış başlanan bir saklı yordam çalıştırılırken yeniden derlemek neden olabilir. Iyileştirici en olası plan için bir yordam içinde belirli her deyim her zaman vardır, bu yeni davranışı sağlar. Aşağıdaki olay bir saklı yordam, bir çalışma zamanı recompilation neden olabilir:
- Saklı yordam tarafından başvurulan bir tabloya veri değişikliklerini yeterli yüzdesi.
- Yordam, veri tanımlama dili (DDL) ve veri düzenleme dili (DML) işlemleri interleaves.
- Yordamın bazı geçici tablo işlemlerini gerçekleştirir.
Her biri bu nedenler daha ayrıntılı bu makalede ele alınmıştır.
Bazı durumlarda, saklı yordam recompiling maliyetini birden çok yararı, özellikle büyük yordamlar için bunu türetilmiş var. Derlenmiş bir recompilation tetiklendiğinde
tüm toplu veya yordamını çekirdekler, Not çok önemlidir. Bu, performansın düşmesine yordamını veya toplu iş boyutunu doğrudan orantılı oldu?u anlam?na gelir. Bu konu hakkında daha fazla bilgi için SQL Server Books Online'da "Transact-SQL ipuçları" konusuna bakın.
Bu makaledeki bilgiler aşağıdaki çalışma zamanı saklı yordam yeniden nedenini tanımlayan üzerinde odaklanır ve bunları engellemek için kullanabileceğiniz yöntemler anlatılmaktadır.
En iyi yöntem
Sahibe iyisidir bir yordam çalıştırdığınızda saklı yordam adları nitelendirin. Bu, daha iyi netlik ve varolan yürütme planının geçerli kullanıcı tarafından daha kolay yeniden kullanılmasını sağlar. Olmayan bir kullanıcı
pubs veritabanındaki Veritabanı sahibi (dbo) (Bu örnekte
myProc olarak adlandırılır) dbo olduğu saklı yordam çalıştırılır, örneğin, aşağıdaki ifadeyi kullanın:
yerine bu:
bu tekniği karışıklığı bir kodlama ve Bakım açısından'den farklı sahipler yordamla olası diğer sürümleri hakkında ortadan kaldırır ve ayrıca SQL Server'ın özel yordam için yürütme planı daha doğrudan erişim sağlar.
Sahip adı uygun değil, SQL Server derleme kodunu girer ve bir DERLEME yordamı kilitlendiğinde edinme. Ancak, sonuçta bunu yeni bir plan (başka bir nedenle geçerli varsayarak) gerekli olduğunu belirler, böylece bu planı nitelik yetersizliği yüzünden bu noktada yeniden DEĞIL. Ancak, DERLEME kilit ilgili yordamı alma fazladan bir adım engelleme Çekişme ciddi durumlarda neden olabilir. Q263889 için başvuru BILGI: SQL engelleme nedeniyle bu durum hakkında daha fazla bilgi için [[DERLEME]] kilitler.
Owner.procedure yordam çağrısıyla, sahibine nitelemek, çakışması azaltılır; böylece, derleme kilidi almak gerekmez.
Tanımlama ve sorunları çözme
Önceden yapmadıysanız, Microsoft Knowledge sisteminizin performansını çözümlemek amacıyla Base'de Profiler verilerini yakalama hakkındaki ayrıntılar için aşağıdaki makaleye başvurun:
224587
(http://support.microsoft.com/kb/224587/
)
NASıL YAPıLıR: SQL Server'da Uygulama performansı sorunlarını giderme
Profiler verileri görüntüleme
SQL Server Profiler oluşmasını recompiles numarasını izlemek için kullanabileceğiniz
SP:recompile olay içerir. Saklı yordam çalıştırılırken yeniden derler her
SP:recompile olayı oluşur.
- <a1>Grup</a1> olay sınıfı tarafından Profiler izlemesi
- Dosya menüsünde Özellikler ' i tıklatın.
- Veri sütunları) sekmesinde YUKARı düğmesini metin ve Event ClassGrup başlığı altında Olay sınıfı ile ilk taşımak için kullanın. Diğer Grup başlığının altındaki tüm sütunları olarak kaldırmak için AŞAĞı düğmesini kullanın.
- Tamam ' ı tıklatın.
SP:recompile olayların sayısını denetleyin.
Tek tek oluşumları ayrıntılarını görmek için SP:recompile grubu genişletebilirsiniz. Olayın metin sütunu derlenmiş çekirdekler saklı yordamın adını gösterir. Birden çok yordamlar recompiles neden, yinelenme sayısına'ya sıralanır. Çok sayıda SP:recompile olayları ve yüksek CPU kullanımı yaşıyorsanız, en yüksek sayısını recompiles sahip yordamlar çözme üzerinde odaklanın. Sistem işlem KIMLIĞI (SPID) not alın ve başlangıç saati belli bir örneği için SP:recompile olayın procedure(s) depolanan ve aşağıdaki adımları izleyin.
SP:recompile olay görmezsiniz, ancak performans sorunu yaşamaya devam ediyorsanız, Microsoft Knowledge Base'de aşağıdaki makaleye bakın: 224587
(http://support.microsoft.com/kb/224587/
)
NASıL YAPıLıR: SQL Server'da Uygulama performansı sorunlarını giderme
- Ifade recompile olayı harekete belirleme
- Dosya menüsünde Özellikler ' i tıklatın.
- Veri sütunları) sekmesinde, diğer Grup başlığının altındaki tüm sütunları olarak kaldırmak için AŞAĞı düğmesini kullanın.
- Tüm olayları dışında olaylar) sekmesinde, kaldırmak SP: Başlangıç, SP: StmtStarting, SP:recompile, ve SP: Tamamlanan. SP: StmtStarting olayının yakalama, SP: StmtCompleted yerine kullanabilirsiniz, ancak yapmak böylece aramak için gereken bilgi miktarı ikiye katlar, çünkü her ikisi de dahil etmeyin.
- Belirlediğiniz bir saklı yordamın recompilation incelemek için belirli bir örneği, belirli SPID ve zaman dilimi, oluşum süzgeçleri sekmesini kullanarak görüntülemek verileri sınırlayabilirsiniz.
- Tamam ' ı tıklatın.
SP:recompile olay doğrudan SP:StmtStarted olay recompilation neden saklı yordamın deyiminin ardından yükseltilecektir. Recompile olay bittikten sonra yeni oluşturulan planla ifade yürütülüyor gösteren SP:StmtStarted olay, bir yineleme görürsünüz.
Aşağıdaki örneği inceleyin:
use pubs
go
drop procedure RecompProc
go
create procedure RecompProc as
create table #t (a int)
select * from #t
go
exec RecompProc
Query Analyzer'da bu kod yürütme ve yukarıdaki olaylar bir Profiler izlemesinde görüntüleyin, aşağıdaki işlem sırasını görürsünüz:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | RecompProc |
| SP: StmtStarting | Tablo # t (bir int) oluşturma |
| SP: StmtStarting | seçin * # t gelen |
| SP:recompile | RecompProc |
| SP: StmtStarting | seçin * # t gelen |
| SP: tamamlandı | RecompProc |
Hemen ifade recompilation neden olduğunu anlarsınız:
Çünkü, önce ve SP:recompile olayından sonra görünür.
Yalnızca SP: StmtCompleted olayının ancak SP: StmtStarting olayının yakalanan, önce aşağıdaki gibi bir neden deyimi doğrudan SP:recompile gösterir:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | RecompProc |
| SP:recompile | RecompProc |
| SP: StmtCompleted | seçin * # t gelen |
| SP: tamamlandı | RecompProc |
SP: StmtCompleted olayının için önce SP:recompile olay artırılıyor Bkz: "seçin * # t'den" the recompilation neden ekstresi. Sonra yeni sorgu planı için recompile oluşturulan deyimi kadar tamamlanamıyor olarak bu, anlamlıdır. Bu makaledeki örneklerde tüm diğer SP: StmtStarting olayının kullanın. Yalnızca SP: StmtCompleted olayının yakaladığınız yalnızca ifadenin SP:recompile görüntülemek üzere yukarıda açıklandığı gibi unutmayın.
Birden çok kez bu belirli saklı yordamı çalıştırmak için SQL Server, bu yordam için varolan bir planı yeniden kullanacaksanız unutmayın. Yalnızca recompile olay yordamı ilk işlemin yürütülmesi görürsünüz veya bırakma ve bu yordamın her defasında yeniden oluşturmanız, komut dosyasını yürütün. Bu özel durumda recompilation nedeni bu makalenin "Yeniden Due to Aralaması veri tanımlama dili (DDL) ve veri düzenleme dili (DML) işlemi" bölümünde açıklanan; kolayca hangi deyimi recompilation neden olduğunu belirlemek nasıl göstermek üzere yalnızca bir örnek.
Için satır değişiklikler nedeniyle yeniden
Özgün Sorgu planını oluşturulduğu tarihten bir saklı yordam tarafından başvurulan bir tabloya veri yeterli yüzdesi değiştirildiyse, SQL Server saklı yordamın en güncel istatistiksel verilerini temel alan bir plan olduğundan emin olmak için yeniden derleyin. Örnek olarak, saklı yordamını dikkate alın:
drop procedure RowModifications
go
create procedure RowModifications as
-- assume SomeTable exists with the same definition as #t,
-- and has over 1000 rows
create table #t (a int, b char(10))
select * from #t
insert #t select * from SomeTable
select count(*) from #t where a = 37
go
exec RowModifications
exec RowModifications
RowModifications yordamın ikinci yürütme için Profil Oluşturucusu'ndaki aşağıdaki olaylar görüntülenir:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | RowModifications |
| SP: StmtStarting | Tablo # t (int, b char(10)) oluşturma |
| SP: StmtStarting | seçin * # t gelen |
| SP: StmtStarting | # t Seç'i yerleştirin * SomeTable gelen |
| SP: StmtStarting | # t Count(*) seçin; burada bir 37 = |
| SP:recompile | RowModifications |
| Otomatik UpdateStats | C |
| SP: StmtStarting | # t Count(*) seçin; burada bir 37 = |
| SP: tamamlandı | RowModifications |
Not: Ilk çalıştırma da
SP:recompile olayı gösterecektir "seçin * # t'den" ifadesi. Bu özel durumda recompilation nedeni, bu makalenin "Yeniden Due to Aralaması veri tanımlama dili (DDL) ve veri düzenleme dili (DML) işlemi" bölümünde açıklanmıştır. Bu örnekte, yordamı yürütülen her açışınızda, çünkü yukarıda gösterilen
SP:recompile üzerinde odaklanır.
Bu örnekte, "# t count(*) seçin; burada bir tablo oluşturulduğundan bu yana, 37" nedenler yüzünden, satır sayısını değişiklik yordamın bir recompilation =.
Otomatik UpdateStats olay varlığını recompilation satır değişiklikler olduğunu onaylar.
Metin sütunu, sütun için istatistikler değişiklik gösterir.
Satır sayısı, t # tablo oluşturulduğunda sıfırdır. Plan için özgün "seçin * # t'den" "sayısı (*) seçin." sorgu planı yanı sıra, bu satır sayımından geliştirilmiştir. Ancak, "count(*) seçin" yürütülmeden önce 1.000 yeni satırlar # t tabloya eklenir. Yeterli miktarda veri değiştirilmiş olduğundan, iyileştirici deyimi için en etkin plan'yi seçer emin olmak için bu yordamı yeniden derler. Bu recompilation, her yürütülmesi bir saklı yordamın 1.000 satır ekleme her zaman olarak önemli yeterli recompilation erişmediğini görüntülenecek nedeniyle ortaya çıkar.
SQL Server bir plan derlenmiş çekirdekler olup olmadığını belirlemek için kullandığı algoritma Microsoft Knowledge Base'de aşağıdaki makalede açıklanan otomatik güncelleştirme istatistikleri için kullanılan aynı algoritma şudur:
195565
(http://support.microsoft.com/kb/195565/EN-US/
)
BILGI: SQL Server 7.0 ve SQL Server 2000 Autostats nasıl çalışır
Yukarıdaki örnekte, saklı yordam recompilation fark bir performans etkisi yoktur kadar küçüktür. Ancak birden çok yeniden kaynaklanan benzer etkinlikler gerçekleştirir büyük bir saklı yordam, bir performans düşüşü görebilirsiniz.
Yeniden satır değişiklikler yüzünden counteract için aşağıdaki yöntemleri bulunmaktadır:
- Sp_executesql kullanma deyimini yürütün.
Bu tercih edilen yöntemdir. Ifadeleri sp_executesql saklı yordamını kullanarak yürütülen saklı yordamın planının bir parçası derlenir. Bu nedenle, ifade yürütürken, SQL Server yeni bir çalışma zamanında oluşturmak veya varolan bir planı önbelleğinde için kullanmak üzere boş olacaktır. Her iki durumda, arama saklı yordam için plan etkilenmez ve derlenmiş çekirdekler gerekmez.
EXECUTE deyimi aynı etkiyi; ancak bu önerilmez. EXECUTE kullanarak bildirimi için sorgunun parameterization izin vermediğinden sp_executesql kullanma olarak etkin değildir.
Yukarıda verilen RowModifications yordamı sp_executesql gibi kullanmak için yazılabilir:
drop procedure RowModifications2
go
create procedure RowModifications2 as
set nocount on
-- assume SomeTable exists with the same definition as #t,
-- and has over 1000 rows
create table #t (a int, b char(10))
select * from #t
insert #t select * from SomeTable
exec sp_executesql N'select count(*) from #t where a = @a',
N'@a int', @a = 37
go
exec RowModifications2
exec RowModifications2
Ikinci yürütülmesini RowModifications2 yordamı için aşağıdaki olayları Profiler görürsünüz:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | RowModifications2 |
| SP: StmtStarting | Tablo # t (int, b char(10)) oluşturma |
| SP: StmtStarting | seçin * # t gelen |
| SP: StmtStarting | # t Seç'i yerleştirin * SomeTable gelen |
| SP: StmtStarting | exec sp_executesql N'select count(*) # t gelen burada bir = bir ', n'@a int ', @ bir 37 = |
| SP: başlatılıyor | |
| SP: StmtStarting | # t Count(*) seçin; burada bir = bir |
| Otomatik UpdateStats | C |
| SP: StmtStarting | # t Count(*) seçin; burada bir = bir |
| SP: tamamlandı | |
| SP: tamamlandı | RowModifications2 |
RowModifications2 yordamın SP:recompile olay olduğuna dikkat edin. Tam vardır SP: Başlangıç için SP: Tamamlanan sütun için bir içerik ve Otomatik UpdateStats olay sp_executesql olaylarını arayın. Bu çağrı, saklı yordam bağlamı dışında olduğundan, ancak RowModifications2 yordamı bu derlenmiş çekirdekler gerekmez.
Sp_executesql depolanan yordamı kullanma ile ilgili daha fazla bilgi için "sp_executesql (T-SQL)" ve SQL Server Books Online'da "sp_executesql kullanma" konularına bakın. - Sub-Procedures yeniden neden olan bir ifadeyi çalıştırmak için kullanın.
Bu durumda, ifade, hala bir recompilation neden olabilir, ancak büyük arama saklı yordamın recompiling yerine, yalnızca küçük sub-procedure derlemeniz. - TUTMA PLANLA seçeneğini kullanın.
Geçici tablolara olabilen, bazı durumlarda, varsayılan recompilation algoritması ' daha sıkı yeniden ilgili özel kurallar vardır. PLANLA TUTMAK kullanabileceğiniz geçici tablo eşik geri varsayılan algoritmasına yetkilere ılımlı hale getirme çözümünü seçeneği. Daha fazla bilgi için bu makalenin "Önleme Recompilation tarafından using TUTMAK PLANLA seçeneği" bölümüne bakın.
Not: Oldukça Basitleştirilmiş bir satır değişiklikler nedeniyle, derlenmiş çekirdekler bir yordamı örneği
RowModifications yordamdır. Bu örnek ilgili bir aşağıdaki uyarılar gözden geçirin:
- Bu örnek, geçici bir tablo kullanır, ancak bu durum kalıcı tablolara başvuran depolanmış yordamlar hakkında bilgi için geçerlidir. Başvurulan tablodaki verileri yeterli miktarda bir sorgu planını oluşturulan bu yana değiştirilmiş, saklı yordam derlenmiş çekirdekler. "Önleme Recompilation tarafından using TUTMAK PLANLA seçeneğini" tanımlanan recompilation amaçları için farklılıkları nasıl geçici tablo olarak kabul edilir, bu makalenin bölümü.
- Yukarıdaki iki yordam, bir ilk çalıştırma geçici tablo # t ' bir recompilation de ilk select neden. "Yeniden Due to Aralaması veri tanımlama dili (DDL) ve veri denetleme dili (DML) operasyonlar" Bu recompilation nedenleri açıklanır, bu makalenin bölümü.
- Bir "count(*) # t ' seçin" ifadesi, basit yerine bu örnekte kullanılan "seçin * # t'den" ifadesi. Aşırı yeniden önlemek için <a0></a0>, SQL Server "Önemsiz planları" recompiling dikkate almaz (örneğin, bir seçin * bir tablodan) satır değişiklikler yüzünden.
Veri tanımlama dili (DDL) ve <a1>Dil</a1> (DML) işlem veri denetleme Aralaması vadesi için yeniden
Derlenmiş DDL işlemleri, bir yordam veya bir toplu iş içinde gerçekleştirilir, ilk olan sonraki DML karşılaştığında yordam veya bir toplu iş çekirdekler DDL ilgili tablo etkileyen bir işlem.
Aşağıdaki örnek, depolanan yordamı göz önünde bulundurun:
drop procedure Interleave
go
create procedure Interleave as
-- DDL
create table t1 (a int)
-- DML
select * from t1
-- DDL
create index idx_t1 on t1(a)
-- DML
select * from t1
-- DDL
create table t2 (a int)
-- DML
select * from t2
go
exec Interleave
Query Analyzer'da bu kod yürütme ve yukarıdaki olaylar bir Profiler izlemesinde görüntüleyin, aşağıdaki işlem sırasını görürsünüz:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | Aralığı |
| SP: StmtStarting | Tablo t1 oluşturun (bir int) |
| SP: StmtStarting | seçin * gelen t1 |
| SP:recompile | Aralığı |
| SP: StmtStarting | seçin * gelen t1 |
| SP: StmtStarting | Dizin idx_t1 t1(a) üzerinde oluşturun... |
| SP: StmtStarting | seçin * gelen t1 |
| SP:recompile | Aralığı |
| SP: StmtStarting | seçin * gelen t1 |
| SP: StmtStarting | Tablo t2 oluşturun (bir int) |
| SP: StmtStarting | seçin * gelen t2 |
| SP:recompile | Aralığı |
| SP: StmtStarting | seçin * gelen t2 |
| SP: tamamlandı | Aralığı |
Derlenmiş bu durumda, saklı yordam üç kez çalıştırılırken çekirdekler. Bu neden olacağını anlamak için <a0></a0>, en iyi duruma getiricisi, bu saklı yordam için plan nasıl geliştirir göz önünde bulundurun:
- Yordamın ilk derleme sırasında t2 ve tabloları t1 yok. Bu nedenle, bu tablolara başvuran sorgular için hiçbir planı oluşturulabilir. Yürütme zaman oluşturulmalıdır.
- Yordamın ilk kez çalışır gibi ilk adım, tablo t1 oluşturmaktır. Bir seçin--tablo t1 için yok bir plan yoktur gelen sonraki adımdır. Derlenmiş bu nedenle, yordamın bu noktada SELECT deyimi için bir plan geliştirmek için çekirdekler. Bir planı t1 alınan geçerli seçme yanı sıra, t1 gelen seçme dizin oluşturulduktan sonra oluşturulur. T2 hala henüz olmadığından hiçbir planı seçme t2 gelen oluşturulabilir.
- Sonraki adım, t1 üzerinde bir dizin oluşturmaktır. Başka bir seçme t1 üzerinde gerçekleştirilir, aşağıdaki, bir ilk recompile planından hangi şimdi vardır. Derlenmiş t1 şemasını, o planı oluşturulan bu yana değiştirilmiş olduğundan, ancak, yordamı yeniden t1 seçme için yeni bir plan oluşturmak için çekirdekler gerekir. Ve t2 hala olmadığından hiçbir planı seçme t gelen için oluşturulabilir.
- Sonra tablo t2 oluşturulur ve select t2 gelen yürütülür. Hiçbir planı bildirimini varolduğundan, yordamın son bir kez derlenmiş çekirdekler.
Bu yeniden her yürütülmesi bir saklı yordamın oluşur. Yeniden azaltmak için <a0></a0>, tüm DDL yapmak için bu yordamı değiştirme işlemleri, aşağıdaki gösterildiği gibi DML işlemi tarafından izlenen:
drop procedure NoInterleave
go
create procedure NoInterleave as
-- All DDL first
create table t1 (a int)
create index idx_t1 on t1(a)
create table t2 (a int)
-- Then DML
select * from t1
select * from t1
select * from t2
go
exec NoInterleave
exec NoInterleave
Ilk yürütülmesini
NoInterleave yordamı aşağıdaki olaylar Profiler'da gösterir:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | NoInterleave |
| SP: StmtStarting | Tablo t1 oluşturun (bir int) |
| SP: StmtStarting | Dizin idx_t1 t1(a) üzerinde oluşturun... |
| SP: StmtStarting | Tablo t2 oluşturun (bir int) |
| SP: StmtStarting | seçin * gelen t1 |
| SP:recompile | NoInterleave |
| SP: StmtStarting | seçin * gelen t1 |
| SP: StmtStarting | seçin * gelen t1 |
| SP: StmtStarting | seçin * gelen t2 |
| SP: tamamlandı | NoInterleave |
Bu durumda tüm DDL) deyimleri yapılır en fazla ön. En iyi duruma getiricisi, bu yordamın gibi derlendiğinden:
- Yordamın ilk derleme sırasında t2 ve tabloları t1 yok. Bu nedenle, bu tablolara başvuran sorgular için hiçbir planı oluşturulabilir. Yürütme zaman oluşturulmalıdır.
- Yordamı gerçekleştiren adımlardan DDL'YI olan tablolar t1 ve t2 yanı sıra, dizin üzerinde t1 oluşturma işlemleri.
- Ilk select t1'den sonraki adımdır. Olduğundan hiçbir planı bu SELECT deyimi için kullanılabilir, yordamın derlenmiş çekirdekler. Tüm nesneleri mevcut olduğundan planları için tüm yordamı bir SELECT ifadelerine şu anda oluşturulur.
- Oluşturulan planları'nı kullanarak, yordamın geri kalanını yürütür. Başvurulan nesne için hiçbir değişiklik olduğundan yordamın bir sonraki yeniden derlemek için gerek yoktur.
Not: Sorgu planı ve önbellek var ve yapmak, ikinci ve sonraki yürütmeler olun herhangi bir yeniden hiç sonuç yok. Tüm DDL) deyimleri yordamın en başında yer olduğundan emin olmak için oluşturmak, değiştirmek veya Tablo bırakma yordamlar değiştirilmesi.
Için bazı geçici tablo işlemi nedeniyle yeniden
Geçici tablolara saklı yordamdaki kullanılması, saklı yordamı yürütülen her derlenmiş çekirdekler yordamına neden olabilir.
Bunu önlemek için <a0></a0>, saklı yordam bunu aşağıdaki koşulları karşıladığından şekilde değiştirin:
- Geçici bir tablonun adını içeren tüm ifadeleri aynı saklı yordam ve değil çağıran veya çağrılan saklı yordam veya EXECUTE kullanarak yürütülen bir dize oluşturulan geçici tabloya başvuruda deyimi veya sp_executesql saklı yordamını.
- Geçici bir tablonun adını içeren tüm ifadeleri sözdizimsel olarak saklı yordam veya tetikleyiciyi sonra geçici bir tablo görüntülenir.
- Geçici bir tablo, bir SELECT deyimi başvuru yok BILDIRMEK CURSOR ifadeleri vardır.
- Herhangi bir geçici tablonun adını içeren tüm deyimleri için geçici bir tabloya başvuran herhangi bir DROP TABLE deyimi koyun.
DROP TABLE deyimi, saklı bir yordam için oluşturulan geçici tablolar için gerekli değildir. Tablolar, yordamı tamamlandığında otomatik olarak bırakılır. - Geçici tablo oluşturma hiçbir ifadeleri (gibi CREATE TABLE veya SELECT... INTO) gibi Eğer Akış denetimi deyimi içinde görünen... ELSE veya WHILE.
<a0>Sakla</a0> PLAN seçeneğini kullanarak Recompilation önleme
Geçici tablo kullanım içinde saklı yordamlar, sorgu en iyi duruma getiricisi için belirli karmaşıklık tanıtır. Satır sayısı ve istatistik bilgilerini tabloların, saklı yordamın yürütülmesinin yaşam süresi önemli ölçüde değişebilir. Iyileştirici geçici tablolar ile ilgili tüm durumlarda iyi bir plan kullanmasını sağlamak için <a0></a0>, özel bir algoritma ile yeniden daha ısrarlı olarak geliştirilmiştir. Derlenmiş bir depolanmış yordamla oluşturulan geçici bir tablo birden çok altı kez değişmişse, sonraki deyimi geçici tablo başvurduğunda yordamı çekirdekler, algoritmayı belirtir.
Aşağıdaki örneği inceleyin:
drop procedure useKeepPlan
go
create procedure useKeepPlan as
create table #t (a int, b char(3))
select * from #t
-- Make greater than 6 changes to #t
insert #t values (1, 'abc')
insert #t values (2, 'abc')
insert #t values (3, 'abc')
insert #t values (4, 'abc')
insert #t values (5, 'abc')
insert #t values (6, 'abc')
insert #t values (7, 'abc')
-- Now reference #t
select count(*) from #t
--option (KEEP PLAN)
go
exec useKeepPlan
exec useKeepPlan
böyle bir durumda, ikinci gerçekleştirilmesi için Profil Oluşturucusu'ndaki aşağıdaki olaylar görüntülenir:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | useKeepPlan |
| SP: StmtStarting | Tablo # t (bir int) oluşturma |
| SP: StmtStarting | Yedi - deyimlerini ekleyin... |
| SP: StmtStarting | Count(*) # t1 seçin... |
| SP:recompile | useKeepPlan |
| SP: StmtStarting | Count(*) # t1 seçin... |
| SP: tamamlandı | useKeepPlan |
Yordam için geçici tablo # t yedi değiştikten sonra oluşan seçin, derlenmiş çekirdekler.
Bu ısrarlı recompilation, burada bu başvuru raporu için en uygun sorgu planlamasını değişiklikleri geçici tablo veri dağıtımını önemli ölçüde etkileyebilir durumlarda yararlıdır. Ancak, geçici tablolara sık sık değişiklik yordamlar büyük olması durumunda, ancak önemli bir şekilde yeniden genel performansı yavaş neden olabilir. Bu durum için SELECT deyimi TUTMAK PLANLA seçeneği kullanılmaya başlandı.
TUTMA PLANLA geçici tablolara yordamın içinde birden fazla altı değişiklikleri nedeniyle, saklı yordam yeniden ortadan kaldırır ve yukarıda bu makalenin "Yeniden Due to satır değişiklikler" bölümünde açıklanan satır değişiklikler yüzünden recompilation standart algoritması geri döner. TUTMA PLANLA yeniden tamamen engellemez, bu yalnızca geçici tablolara yordamda başvurulan birden fazla altı değişikliklerden neden engeller. Yukarıdaki örnekte, saklı yordamdaki "(CANLı PLAN) seçeneği" satırından açıklamayı kaldırırsanız
SP:recompile olay oluşturulmaz.
Yukarıdaki kodu "(CANLı PLAN) seçeneği" satırında açıklamayı kaldırmak ve çalıştırmak, Profil Oluşturucusu'ndaki aşağıdaki olaylar görürsünüz:
Bu tabloyu kapaBu tabloyu aç
| Olay sınıfı | Metin |
|---|
| SP: başlatılıyor | useKeepPlan |
| SP: StmtStarting | Tablo # t (bir int) oluşturma |
| SP: StmtStarting | Yedi - deyimlerini ekleyin... |
| SP: StmtStarting | # t1 seçeneğinden Count(*) seçin (TUTMAK PLANLA) |
| SP: tamamlandı | useKeepPlan |
SP:recompile olay olduğuna dikkat edin.
Saklı yordam çalıştırılma ekstreleri belirli için nedeniyle yeniden SET
Aşağıdaki beş SET seçenekleri ON varsayılan olarak ayarlanır:
- ansi_defaults
- ansi_nulls
- ansi_padding
- ansi_warnings
- concat_null_yields_null
Derlenmiş bu seçeneklerden herhangi birini KAPALı ayarlamak için SET deyimi yürütme, her çalıştırır saklı yordamın çekirdekler. Bunun nedeni, bu seçenekleri değiştirmek, recompilation tetikleyen sorgu sonucu etkileyebilecek olur.
Aşağıdaki örnek kodu dikkate alın:
Use pubs
drop procedure test_recompile
go
create procedure test_recompile as
Set ANSI_DEFAULTS OFF
Select au_lname, au_fname, au_id from authors
where au_lname like 'L%'
--Option (Keep Plan)
Go
böyle bir durumda, SQL Profiler, her bir saklı yordamın yürütülmesi için aşağıdaki olaylar görüntülenir:
+---------------------------------------------------+
| Event Class | Text |
+---------------------------------------------------+
| SP:Starting | test_recompile |
+---------------------------------------------------+
| SP:StmtStarting | Set ANSI_DEFAULTS OFF |
+---------------------------------------------------+
| SP:StmtStarting | select au_lname, au_fname, au_id|
+---------------------------------------------------+
| SP:Recompile | test_recompile |
+---------------------------------------------------+
| SP:StmtStarting | select au_lname, au_fname, au_id|
+---------------------------------------------------+
| SP:Completed | test_recompile |
+---------------------------------------------------+
SET</a0> seçeneği, yukarıda listelenen beş seçeneklerden herhangi biri ile değiştirmek için aynı sonuçları gösterilir. Ayrıca koruma planı burada seçeneğiyle SET ekstresindeki recompilation neden olduğu için recompilation önlemek için yardımcı olmaz.
The recompilation önlemek için önerilen yol herhangi biri, bu beş SET deyimi saklı bir yordam değil kullanmaktır. Ek bilgi için Microsoft Knowledge Base'de aşağıdaki makaleye bakın:
294942
(http://support.microsoft.com/kb/294942/EN-US/
)
SORUN: SET CONCAT_NULL_YIELDS_NULL neden yordamlar recompile için depolanan
Ancak, the SET çalışan önerilmez olarak bağlantı seçeneği saklı yordamı aynı değere sıfırlamak için bir ifade olarak bunu yapmayı recompile, kurtulabilirsiniz:
Set ANSI_DEFAULTS OFF
exec test_recompile
The SQL Profiler izlemesi daha fazla olay SP:recompile gösterir.
Aşağıdaki tabloda bazı yaygın SET deyimleri ve saklı yordamdaki SET deyimini değiştirmeden bir recompile olup olmamasına neden listeler:
Bu tabloyu kapaBu tabloyu aç
| Set Ekstresi | Yeniden derle |
| Set quoted_ıdentıfıer | Hayır |
| Set arıthabort | EVET |
| Set ansı_null_dflt_off | EVET |
| Set ansi_defaults | EVET |
| Set ansi_warnings | EVET |
| Set ansi_padding | EVET |
| Set concat_null_yields_null | EVET |
| Set numeric_roundabort | Hayır |
| Set nocount | Hayır |
| Set rowcount | Hayır |
| Set xact_abort | Hayır |
| Set implicit_transactions | Hayır |
| Set arithignore | Hayır |
| Set lock_timeout | Hayır |
| Set fmtonly | Hayır |
Başvurular
308737
(http://support.microsoft.com/kb/308737/EN-US/
)
INF: nasıl Recompilation SP:recompile bir olay, nedenini belirleyin
SQL Server'ı kullanma hakkında bilgi için Profiler, SQL Server Books Online'da bakın.