وجود sp توی application نه توی دیتابیس . آیا ممکن است ؟ [بایگانی]

ali_kolahdoozan

چهارشنبه 05 دی 1386, 20:57 عصر

آیا میشه sp رو توی خود دات نت تعریف کرد . یعنی commandtype از نوع sp باشه ولی اون sp توی sql تعریف نشده باشه و توی خود دات نت باشه . آیا ممکنه ؟ از clr هم نمی خواهم استفاده کنم

رضا عربلو

چهارشنبه 05 دی 1386, 23:53 عصر

sp همانطور که از اسمش پیداست یعنی stored procedure یا همان روال ذخیره شده.
مطمعناً این نام را در سمت سرور به آن داده اند به این معنی که از دید برنامه sp یک روال ذخیره شده در data source می باشد.
حال اگر این sp قرار باشد در سطح برنامه تعریف شئد اسمش می شود query یا همان درخواست که شما به Data Source تان می دهد و او به شما پاسخ می دهد.

AminSobati

پنج شنبه 06 دی 1386, 00:42 صبح

دوست عزیزم یک SP کامپایل میشه قبل از اجرا و فرایندهای پیچیده بسیاری روی اون اتفاق میافته. این عملیات فقط در SQL Server قابل انجامه و محیط Dot NET کوچکترین چیزی از این امور نمیدونه!

ali_kolahdoozan

پنج شنبه 06 دی 1386, 10:41 صبح

اخه یک برنامه از یک شرکت بزرگ دیدم هیچی sp نداشت . گفتم یعنی همش رو توی دات نت نوشتین فرمودند sp ها رو دادیم توی دات نت !!!!!‌ منم با وجود اینکه میدانستم نمیشه شک کردم بالاخره دامنه علم وسیعه گفتم شاید بشه من بلد نباشم . یعنی این شرکت هیچی sp ننوشته و همه رو داده توی خود برنامه و این یعنی گندکاری از نظر من

AminSobati

پنج شنبه 06 دی 1386, 18:29 عصر

احتمالا منظورشون این بوده که تمام Queryها و Logic برنامه از سمت دات نت به SQL Server ارسال و اجرا میشه. از قول من این خبر هیجان انگیز رو بهشون بدین که حجم قابل توجهی از حافظه سرور صرف Planهای تکراری خواهد شد و Recompileها اضافی بار قابل توجهی روی CPU قرار میده! شاید هدفشون اینه که بتونن هروقت خواستن دیتابیس رو عوض کنند و وابستگیی بین نرم افزار و دیتابیس نباشه

ali_kolahdoozan

یک شنبه 09 دی 1386, 18:48 عصر

والا من هم حالا نه این شکل ولی یه چیزهایی توی همین مایه ها بهشون گفتم . فرمودند نه الا بلا اینها همش sp است فقط توی application است منم شاخ در آوردم و شک کردم اما مطمئنم این کار شدنی نیست

ali_kolahdoozan

جمعه 27 اردیبهشت 1387, 15:44 عصر

اين تاپيك قديمي شده . اما يك سوال insert ها و update ها و delete ها هم حتما sp بشوند . آنها كه با plan كاري ندارن

linux

جمعه 27 اردیبهشت 1387, 16:02 عصر

اين تاپيك قديمي شده . اما يك سوال insert ها و update ها و delete ها هم حتما sp بشوند . آنها كه با plan كاري ندارن
اگر یک آپدیت و اینزرت ساده باشه فکر نکم.ولی بعضی وقتها پیش می آید که وقتی یک آپدیت یا اینزرت اتفاق می افته ،تغییرات خاصی باید صورت بگیره که احتیاج به محاسبه و اینکارها داره ، اینها به نظر من sp بشوند بهتر است.

ali_kolahdoozan

جمعه 27 اردیبهشت 1387, 16:29 عصر

نظر ؟ من منبع علمي لازم دارم .

linux

جمعه 27 اردیبهشت 1387, 20:17 عصر

نظر ؟ من منبع علمي لازم دارم .
دیگه منبع موثق تر از من! حالا از شوخی گذشته این تجربه کاری من بوده ولی حتما آقای ثباتی بیشتر می تونه کمک کنه

AminSobati

شنبه 28 اردیبهشت 1387, 00:44 صبح

دستورات SELECT و DELETE و UPDATE شباهت زیادی از این بابت به هم دارند که میبایست Optimize بشن تا در مرحله اجرا، سریعترین روش در پیش گرفته بشه. شاید تعجب کنید بگم اهمیت بهینه بودن وضعیت ایندکسها برای دستور UPDATE حتی از SELECT بالاتره! چون زمانی که شما از WHERE در دستور UPDATE استفاده میکنید، در صورت عدم وجود ایندکس مناسب، کل جدول Lock میشه، Scan روی جدول صورت میگیره تا رکورد حائز شرط update بشه. در تمام مدت Scan این جدول برای SELECTها دست نیافتنی خواهد بود! حالا تصور کنید یک جدول حاوی چند میلیون رکورد چقدر زمان میبره. اما وجود ایندکس کمک میکنه تا از طریق اون، SQL Server براحتی خودش رو به رکوردهایی که میبایست update بشن برسونه و علاوه بر اینکه فقط رکوردهای معدودی Lock میشن، زمان انجام هم بسیار کوتاه تر خواهد بود.
اما دقیق تر اگر به سوال آقای کلاهدوزان بپردازیم، باید عرض کنم به دلیل وجود چنین مکانیزمی، شما میبایست حتی دستورات ویرایشی رو در SP قرار بدین. چون براشون دقیقا Exec Plan بدست میاد. این کار از طرفی باعث مصرف بهینه حافظه سرور شما خواهد شد چرا که با هر بار فراخوانی SP ویرایش، همون Plan قدیمی Re-Use خواهد شد در حالیکه اگر مقادیر رو بصورت مستقیم ارسال کنید، هر بار دستور UPDATE شما باید Compile بشه و یک Plan جدید ازش داخل حافظه Cache بشه

vcldeveloper

شنبه 28 اردیبهشت 1387, 02:49 صبح

امین جان، اگر کوئری ها Prepare شده باشه، آیا اجرای کوئری برای دفعات بعد، فرقی با اجرای SP خواهد داشت؟ چون تا جایی که من دیدم، و در Books Online هم اومده؛ با Prepare کردن یک کوئری، SQL Server یک بار برای اون کوئری Execution Plan کامپایل میکنه و در دفعات بعد از همون Execution Plan استفاده میکنه.

linux

شنبه 28 اردیبهشت 1387, 09:09 صبح

دستورات SELECT و DELETE و UPDATE شباهت زیادی از این بابت به هم دارند که میبایست Optimize بشن تا در مرحله اجرا، سریعترین روش در پیش گرفته بشه. شاید تعجب کنید بگم اهمیت بهینه بودن وضعیت ایندکسها برای دستور UPDATE حتی از SELECT بالاتره! چون زمانی که شما از WHERE در دستور UPDATE استفاده میکنید، در صورت عدم وجود ایندکس مناسب، کل جدول Lock میشه، Scan روی جدول صورت میگیره تا رکورد حائز شرط update بشه. در تمام مدت Scan این جدول برای SELECTها دست نیافتنی خواهد بود! حالا تصور کنید یک جدول حاوی چند میلیون رکورد چقدر زمان میبره. اما وجود ایندکس کمک میکنه تا از طریق اون، SQL Server براحتی خودش رو به رکوردهایی که میبایست update بشن برسونه و علاوه بر اینکه فقط رکوردهای معدودی Lock میشن، زمان انجام هم بسیار کوتاه تر خواهد بود.
اما دقیق تر اگر به سوال آقای کلاهدوزان بپردازیم، باید عرض کنم به دلیل وجود چنین مکانیزمی، شما میبایست حتی دستورات ویرایشی رو در SP قرار بدین. چون براشون دقیقا Exec Plan بدست میاد. این کار از طرفی باعث مصرف بهینه حافظه سرور شما خواهد شد چرا که با هر بار فراخوانی SP ویرایش، همون Plan قدیمی Re-Use خواهد شد در حالیکه اگر مقادیر رو بصورت مستقیم ارسال کنید، هر بار دستور UPDATE شما باید Compile بشه و یک Plan جدید ازش داخل حافظه Cache بشه
پیشنهاد شما این هست که در هر صورت برای Update و insert و select در هر صورت باید sp بسازیم؟ بدون در نظر گرفتن تعداد فیلدها و ...
مثلا برای یک جدولی که 2 تا فیلد داره هم باید این کار را انجام بدهیم؟

ali_kolahdoozan

شنبه 28 اردیبهشت 1387, 11:55 صبح

باز هم اگر sp باشد بهتر است

ASKaffash

شنبه 28 اردیبهشت 1387, 15:45 عصر

با سلام
دوست عزیز بیشتر اصرار نکنید شرکت مورد بحث در یک کلام خالی بند بوده است امکان ندارد SP در سمت Client باشد یکی ازشعارهای SP جدائی از لایه Application است.

ali_kolahdoozan

شنبه 28 اردیبهشت 1387, 17:57 عصر

بحث دیگه سر اون نیست

حمیدرضاصادقیان

شنبه 28 اردیبهشت 1387, 20:35 عصر

سلام.یعنی امین جان شما پیشنهاد میکنید تاجایی که امکان داره کلا دستوراتی که باید با Sql در ارتباط باشند در قالب sp در بیان.درسته؟
یعنی حتی برای update یا Select های ساده هم اینکارو بکنیم بهتره؟

_alish_

یک شنبه 29 اردیبهشت 1387, 12:51 عصر

آقا ثباتي باز هم از اطلاعات مفيدتان متشكرم ، خواهشا اين بحث رو به نتيجه برسانيد، چون بنظر ميرسه ينده هم تو اين زمينه اشتباه عمليات درج و بروز رساني را با صحبتهاي شما انجام مي دادم.
لطفا بيشتر راهنمايي نماييد.

AminSobati

یک شنبه 29 اردیبهشت 1387, 23:11 عصر

در SQL Server 2005 تمام Queryها (یعنی Select و دستورات ویرایشی(DML)) هم Case Sensitive هستند و هم Space Sensitive. بدلیل اینکه Hash میشن و وقتی یک Query عینا تکرار بشه ولی فقط یک Space اضافه داشته باشه یا کاراکتری تفاوت کنه، مجددا Compile و یک کپی از اون مجددا وارد Cache خواهد شد. اما SP این رو تضمین میکنه که متن Query هیچ تغییری نداره. Query زیر رو در نظر بگیرید:

SELECT * FROM Orders WHERE OrderID=20

اگر این Query هزار بار تکرار بشه و فقط عدد 20 تغییر کنه، هزار کپی در Cache قرار میگیره ولی اگر در SP باشه، فقط یک کپی از خود SP حافظه مورد نیازش رو اشغال خواهد کرد. با Query زیر میتونین محتویات Cache رو ببینین:

SELECT sql,sqlbytes,cacheobjtype FROM master.dbo.syscacheobjects
order by sql

در یک Production Server به احتمال زیاد صدها تکرار از یک Query رو خواهید دید. این موضوع برای Insert هم صادقه و بعنوان جمع بندی بحث: SP دوست شماست و کمک میکنه حافظه SQL Server بهینه استفاده بشه!
برای اینکه بدونید چند مگابایت از حافظه صرف Plan Cache شده:

dbcc memorystatus

به قسمت Procedure Cache رکورد TotalPages رجوع کنید. عددی که میبینید رو ضربدر 8 و تقسیم بر 1024 کنید تا مقدار بر حسب مگابایت بدست بیاد. تعجب نکنید اگر در یک Production Server این عدد حتی بالای یک گیگابایت باشه (به تناسب دانش برنامه نویسهای اون نرم افزار!!)

حمیدرضاصادقیان

دوشنبه 30 اردیبهشت 1387, 00:12 صبح

ممنون استاد ثباتی عزیز.
در کوئری اول که نوشتید در ستون سوم جلوی بعضی از ردیفها نوشته Compiled Plan . منظور اینه که اون دستور sp بوده و کامپایل شده؟ یا یک کوئری بوده؟
فرضا ما یک sp داریم که یک رشته رو میگیره و با استفاده از exec اونو اجرا میکنه.
و ما کوئری خودمون رو از داخل برنامه به اون پاس میدیم . در این حالت ایا با دستور مورد نظر ما مانند یک sp برخورد میشه یا هردفعه اون compile میشه. یعنی اگه دوکوئری مختلف رو درفواصل مختلف به اون sp ارسال کنیم هر دفعه اون compile میشه.یک plan براش ساخته میشه یا از همون plan قبلی که دفعه اول ساخته شده استفاده میکنه.

linux

دوشنبه 30 اردیبهشت 1387, 10:36 صبح

در SQL Server 2005 تمام Queryها (یعنی Select و دستورات ویرایشی(DML)) هم Case Sensitive هستند و هم Space Sensitive. بدلیل اینکه Hash میشن و وقتی یک Query عینا تکرار بشه ولی فقط یک Space اضافه داشته باشه یا کاراکتری تفاوت کنه، مجددا Compile و یک کپی از اون مجددا وارد Cache خواهد شد. اما SP این رو تضمین میکنه که متن Query هیچ تغییری نداره. Query زیر رو در نظر بگیرید:

SELECT * FROM Orders WHERE OrderID=20

اگر این Query هزار بار تکرار بشه و فقط عدد 20 تغییر کنه، هزار کپی در Cache قرار میگیره ولی اگر در SP باشه، فقط یک کپی از خود SP حافظه مورد نیازش رو اشغال خواهد کرد. با Query زیر میتونین محتویات Cache رو ببینین:

SELECT sql,sqlbytes,cacheobjtype FROM master.dbo.syscacheobjects
order by sql

در یک Production Server به احتمال زیاد صدها تکرار از یک Query رو خواهید دید. این موضوع برای Insert هم صادقه و بعنوان جمع بندی بحث: SP دوست شماست و کمک میکنه حافظه SQL Server بهینه استفاده بشه!
برای اینکه بدونید چند مگابایت از حافظه صرف Plan Cache شده:

dbcc memorystatus

به قسمت Procedure Cache رکورد TotalPages رجوع کنید. عددی که میبینید رو ضربدر 8 و تقسیم بر 1024 کنید تا مقدار بر حسب مگابایت بدست بیاد. تعجب نکنید اگر در یک Production Server این عدد حتی بالای یک گیگابایت باشه (به تناسب دانش برنامه نویسهای اون نرم افزار!!)
ممنون از اطلاعاتی که به ما می دهی می توانی کتابی معرفی کنی که بیشتر بحثش تو این زمینه باشه؟
مقدار قابل قبول برای TotalPages چقدر هست؟

AminSobati

دوشنبه 30 اردیبهشت 1387, 15:22 عصر

ممنون از اطلاعاتی که به ما می دهی می توانی کتابی معرفی کنی که بیشتر بحثش تو این زمینه باشه؟
مقدار قابل قبول برای TotalPages چقدر هست؟
عموما كتابهاي Administration اين اطلاعات رو دارند ولي طبيعيه كه نكات پيشرفته تر در اينترنت و وبلاگ برنامه نويسان خود SQL Server پيدا ميشه.
مقدار TotalPages هيچ Range خاصي نداره. مهم اينه كه Procedure Cache تا جاي ممكن با SPها پر بشه. حالا اگر شما 2000 تا SP داريد و اينها 500 مگابايت فضا اشغال كرده باشند، ايرادي وارد نيست. چون اگر SP نبود حتما چند برابر فضا اشغال ميشد

AminSobati

دوشنبه 30 اردیبهشت 1387, 17:02 عصر

ممنون استاد ثباتی عزیز.
در کوئری اول که نوشتید در ستون سوم جلوی بعضی از ردیفها نوشته Compiled Plan . منظور اینه که اون دستور sp بوده و کامپایل شده؟ یا یک کوئری بوده؟
فرضا ما یک sp داریم که یک رشته رو میگیره و با استفاده از exec اونو اجرا میکنه.
و ما کوئری خودمون رو از داخل برنامه به اون پاس میدیم . در این حالت ایا با دستور مورد نظر ما مانند یک sp برخورد میشه یا هردفعه اون compile میشه. یعنی اگه دوکوئری مختلف رو درفواصل مختلف به اون sp ارسال کنیم هر دفعه اون compile میشه.یک plan براش ساخته میشه یا از همون plan قبلی که دفعه اول ساخته شده استفاده میکنه.

وجود Compiled Plan میتونه هم برای SP باشه هم برای Queryهای مستقیم یا adhoc.
اینکه داخل SP شما Dynamic TSQL اجرا کنین، یعنی از قابلیت اصلی SP استفاده نشده و بازهم Planهای اضافی تولید میشه. مگر اینکه خودتون Query رو به اصطلاح Parameterize کنین و با sp_executesql اجرا کنین. مثال از Parameterize در راهنمای دستور sp_executesql وجود داره.