آشنایی با پروسیجر های ذخیره شده
هر پروسیجر ذخیره ،پرس و جویی است که به جای برنامه ای که در کامپیوتر سرویس گیرنده اجرا می شود ،در sql سرور اکسپرس در یک بانک اطلاعاتی ذخیره می شود. به چه دلیل باید پرس و جو ها را در بانک اطلاعاتی موجود در سرور ذخیره نمود ؟
دو دلیل بسیار خوب وجود دارد :کارایی و مدیریت.
پروسیجر های ذخیره شده چگونه کارایی را افزایش می دهند ؟ به پرس و جو هایی که زیر اجرا کرده اید فکر کنید.به عنوان مثال، پرس و جوی زیر تمام محصولات موجود در جدول production .product که خروش آنها پس از اول ژانویه 2003 بوده است و نمایش می دهد :

Select name, color, listprice, sellstartdata
From production.product
Where sellstartdata > '1/1/2003'
Order by sellstartdata, name

اگر چه این پرس و جو چندان بزرگ به نظر نمی رسد تنها چهار سطر متنی است اما تصور کنید که 5000 کاربر در شبکه در طول روز همین پرس و جو را اجرا کنند.این امر موجب افزایش حجم ترافیک شبکه و در نتیجه موجب شلوغی می شود و یا حتی گلوگاه شلوغی شبکه زمانی پیش می آید که حجم ترافیک بیش از اندازه باشد (قسمتی از داده های ترافیک گم می شوند وباید از نو ارسال شوند که در نتیجه بخشی از داده ها دو مرتبه ارسال شده و همین موجب کندی بیشتر می شود کاربران در این گونه مواقع شاهد کارایی پایین شبکه خواهند بود و شکایات آغاز خواهد شد .)
برای رهایی از ازدحام شبکه و رساندن آن به بالا ترین سرعت می بایست حجم فرامین ارسالی از طریق شبکه را کاهش دهید. یکی از آسان ترین روش ها برای بهبود شرایط ، تبدیل پرس و جو ها به پروسیجر ذخیره شده است.بنابراین ، تنها فرمانی که کاربران از طریق شبکه ارسال خواهند نمود به سطر زیر کاهش می یابد :

EXEC stored-procedure-name

مزیت دیگر پروسیجر های ذخیره شده نسبت به پروسیجر های ویژه ، کامپایل کردن فرامین است.وقتی sql سرور اکسپرس پرس و جویی را کامپایل می کند متن پرس و جو را می خواند .عبارت  joinوwhere   آن را بررسی می کند و سپس پرس و جو را با تمام شاخص های موجود مقایسه می کند تا مشخص شود که عملکرد کدام شاخص (در صورت وجود ) سریعتر خواهد بود sql  سرور اکسپرس پس از یافتن شاخص ،" نقشه اجرا "(مجموعه ای از دستور العمل ها برای اجرای پرس و جو ) را ایجاد و در حافظه ذخیره می کند. پرس و جو ها هر به هنگام اجرا باید کامپایل شوند ،اما پرس و جو های ذخیره شده از قبل کامپایل شده و ذخیره می شوند. در نتیجه پروسیجرهای ذخیره شده ، سریعتر از پرس و جو ها هستند.

توجه

وقتی sql  سرور اکسپرس پرس و جوی ویژه ای را اجرا می کند . تا زمانی که فضای کافی در حافظه باشد ، نقشه اجرای آن در حافظه نگه می دارد ، بنابراین پرس و جو ها نیز ممکن است هر بار هنگام اجرا نیاز به کامپایل شدن نداشته باشند.
پروسیجر های ذخیره ، مزیت دیگری نیز نسبت به پرس و جو ها دارند : حفظ و نگهداری پروسیجرهای ذخیره شده آسان تراست. به عنوان مثال ، اگر نیاز به اعمال برخی تغییرات در یکی از پرس و جو های موجود داشته باشید ، و آن پرس و جو در کامپیوتر کاربران ذخیره شده باشد ، می بایست آن را در یکایک کامپیوترهای مربوطه تغییر دهید. اگر پروسیجر های معادل آن را به طور متمرکز (در سرور) ذخیره کنید ، تغییرات تنها در یکجا (در سرور) اعمال می شوند. این امر موجب صرفه جویی زیادی د ر وقت و حجم کارهایتان می شود.
   علی رغم مزایایی که پروسیجر های ذخیره شده نسبت به پرس و جو ها دارند ، تمام پرس و جو ها را نمی توان با پروسیجر ها جایگزین نمود. اگر کاربران پرس و جو ی ویژه ای را به طور نامرتب و هر چند وقت یکبار اجرا می کنند، نیازی به ایجاد و ذخیره سازی پروسیجرهای معادل آن در سرور نیست ، اما اگر کاربران پرس و جویی را به طور مرتب اجرا می کنند ، می بایست از یک پروسیجر ذخیره شده استفاده نمایید.
به دلیل مزایای کارایی و مدیریتی که  پروسیجر های ذخیره شده دارند،لازم است با روش ایجاد و کاربرد آنها آشنا شوید.

بهینه سازی پروسیجر های ذخیره شده

برای آنکه پروسیجر های ذخیره شده را بهینه کنید ،لازم است بدانید که sql سرور اکسپرس چگونه پرس و جو ها را اجرا می کند. Sql سرور اکسپرس در طی فرایند کامپایل صرفاً محتوای پرس و جو را بررسی می کند تا مشخص شود که به دنبال چه چیزی هستید . به ویژه اینکه بررسی می کند که کدام جداول را با هم مرتبط می کنید و از کدام ستون ها در صورت وجود ، در عبارت where استفاده کرده اید .sql سرور اکسپرس سپس " نقشه اجرا " را طراحی می کند نقشه شاخص ها یی که سریعترین نتایج را بدست می آورند . سپس نقشه اجرا  را در کش پروسیجر ذخیره می کند محلی از RAM که خصوصاً برای این منظور کنار گذاشته شده است. وقتی پروسیجری را مجدداً اجرا می کنید ،SQL  سرور اکسپرس نیاز به طراحی مجدد نقشه اجرا نخواهد داشت ، بلکه صرفاً از نقشه نخست استفاده می کند.
   اگر چه این رویه کارامد است ،اما می تواند مشکلاتی را نیز به همراه داشته باشد . به عنوان نمونه، اگر ساختار بانک اطلاعاتی را از طریق افزودن جدول جدید و با افزودن ستون های جدید به یکی از جداول موجود تغییر دهید ، sql سرور اکسپرس پروسیجر ذخیره شده را جهت منعکس شدن این تغییرات به طور خودکار از نو کامپایل می کند. تنها زمانی که پروسیجر ذخیره شده از نو کامپایل نمی شود ، زمان ایجاد یک شاخص جدید است و در این گونه شرایط باید آن را به طور دستی از نو کامپایل نمایید.
   با استفاده از دو روش می توانید sql سرور اکسپرس را مجاب به کامپایل مجدد پروسیجر های ذخیره شده کنید:
● با استفاده از فرمان WITH  RECOMPILE
● با استفاده از فرمان EXECUTE-WITH RECOMPILE
    
  استفاده از فرمان WITH  RECOMPILE سبب می شود که SQL سرور اکسپرس هر بار هنگام اجرای پروسیجر ذخیره شده ، نقشه اجرا را طراحی کند روش ایجاد پروسیجر ذخیره شده ای که پارامتر های ورودی آن را هر بار هنگام اجرا تغییر می کنند ف به همین صورت است . به عنوان مثال ، برای آنکه uspshow products هر بار هنگام اجرا از نو کامپایل شود از فرامین زیر استفاده کنید:

CREATE PROCEDURE USPSHOWPRODUCTS
   @Data [data time] =
WITH RECOMPILE, EXECUTE AS CALLER
AS
SELECT Name, color, list price, sellstartData
FROM PRODUCTION .PRODUCT
WHERE sellstartdata >@Data
ORDER BY sellstartdata, Name

گزینه WITH  RECOMPILE برای sql سرور اکسپرس مشخص می کند که هر بار هنگام اجرای پروسیجر ذخیره شده ، نقشه اجرای جدیدی ایجاد نماید و آن را در کش ذخیره نکند.
  متاسفانه چنانچه هر چند وقت یکبار نیاز به تغییر نقشه اجرا داشته باشید. این راه حل ممکن است خسته کننده و کند باشد. در این گونه موارد از روش دوم برای کامپایل مجدد استفاده کنید.
 فرمان EXECUTE-WITH RECOMPILE برای sql سرور اکسپرس مشخص می کند که نقشه اجرا را صرفاً در همین اجرا از نو طراحی می کند .(و نه هر بار که پروسیجر اجرا می شود ) اگر از این فرمان استفاده کنید ، فرامین ایجاد پروسیجر پیشین نیاز به تغییر نخواهد داشت. کافی است WITH  RECOMPILE را هنگام اجرای پروسیجر به کار برید:

  EXEC uspshowproducte WITH RECOMPILE

فرمان EXECUTE-WITH RECOMPILE می تواند موجب اجرای سریعتر پروسیجر های ذخیره شده شود. اما تا به حال هیچ گونه اقدامی برای ایمن سازی آنها در مقابل چشمان کنجکاو انجام نداده اید.

جلسات گذشته :

• جلسه اول
• جلسه دوم
• جلسه سوم
• جلسه چهارم
• جلسه پنجم
• جلسه ششم