استفاده از Execution Plan

[aliasghar]

سلام
نمیدونم چرا من این قسمت را هی چی نوفهمم؟:گیج:
راستش هرچی بیشتر دنبال این مطلب میرم گیج تر میشم برای همین عکس یک دستور Select از فانکشنی را که در برنامه ساختم اینجا می گذارم تا به نسبت اون من را راهنمایی کنین
http://www.barnamenevis.org/forum/attachment.php?attachmentid=2866&stc=1&d=1142433816
لطفا اول عکس را ببیند و بعد به من بگین :
1) این Plan چی را میرسونه ؟ طراحی جدول ، ایندکس و Function من خوبه یا نه؟
2)Estimate row size یعنی چه؟ خوبه یا بده؟ چوری باید بهینه بشه؟
3)I/O Cost یعنی چه؟ خوبه یا بده؟ چوری باید بهینه بشه؟
4)Cpu Costیعنی چه؟ خوبه یا بده؟ چوری باید بهینه بشه؟
5)Cost یعنی چه؟ خوبه یا بده؟ چوری باید بهینه بشه؟ (100% یعنی چه؟ خوبه یا بده؟)
6)Subtree Cost یعنی چه؟ 0.0376 چی را می رسونه؟

فکر کنم جواب این سوالها اندازه یک کتاب بشه پس اگر اینطوره یک کتاب هم به من معرفی کنید که به زبون ساده این مطالب را توضیح داده باشه

شرمنده از این همه پر رو یی

[AminSobati]

با توجه به اینکه Plan از نتیجه یک تابع بدست اومده و محتویات تابع دیده نمیشه، نباید در مورد وضعیت ایندکسها و سایر مسائل نظر داد.
برای Tune کردن یک Query، شما تقریبا نیاز به دانستن پارامترهایی که در عکس میبینین نخواهید داشت. یک روش ساده و البته مطمئن اینه که ببینید آیا الگوریتم های بهینه در Plan وجود دارند یا نه. یعنی شکل Iconها گویای همه چیزه. اینکه چه Iconهایی خوب و یا بد هستند کاملا بستگی به هر Query داره. یعنی نمیشه براش یک فرمول "همیشه صحیح" ارائه کرد.
من مطالعه این کتاب رو توصیه میکنم:
Microsoft SQL Server 2000 Performance Optimization and Tuning Handbook
باز در مورد پارامترها، حالتهایی پیش میاد که مثلا Estimated Row Count مورد توجه قرار میگیره. این آیتم نشون میده از هر قسمت کار، تقریبا چند رکورد به عنوان خروجی بدست اومده. و یا Number of Exucutes مشخص کننده اینه که این بخش از کار، چند بار تکرار شده.

[rabinhood_tehran]

من دارم تو این زمینه یه مقال مینویسم . میروسونم به دستتون

[aliasghar]

از هر دوی شما متشکرم

[aliasghar]

راستی در plan زیر اغلب شلکها یک cost میزنه این cost یعنی هزینه یا ارزش؟
هر چی بیشتر بشه بهتره یا کمتر باشه

[AminSobati]

نه هزینه($) نه ارزش! بلکه یعنی چقدر از CPU یا Disk استفاده شده. طبیعتا هر چه کمتر بهتر!

[aliasghar]

ببخشید
من برای اینکه بتونم این Plan را درک کنم از یک select که چند جدول را به هم لینک کرده بودم استفاده کردم و هربار ایندکسهای جداول را عوض کردم
چیزی که من فهمیدم این بود که Cost روی جداول موجود در select بطوری تقسِم می شد
که جمع cost همه جداول میشد 99
ولی هر چه ایندکسها را عوض کردم یا برداشتم یا .... نتونستم مقدار را برای تمام جداول موجود در select کمتر از 99 کنم

درسته؟ یا میشه اون را کم و زیاد کرد

[AminSobati]

علی اصغر جان حالا متوجه شدم کدوم Cost رو میفرمایید، چون Cost در قسمتهای مختلف یک Plan وجود داره...
این Cost نشون میده هر قسمت از Query، چند درصد از کل بار پردازش رو به عهده داشته. لذا طبیعیه که جمعشون باید همیشه بشه 100. اگر عدد 99 بدست میارین، حتما بعضی آیتمها Costشون برابر با صفر بوده. این یک درصد باقیمانده، بین صفرها پخش شده.
Cost کمک زیادی در کشف علت کندی یک Query میکنه.

[aliasghar]

آقا امین ممنون
حالا اگه اجازه بدین یک سوال دیگه:
من از همین سایت یک تابع تبدیل تاریخ میلادی به شمسی در sql پیدا کردم و از اون برای نمایش فیلد تاریخم به صورت فارسی استفاده میکنم

این تابع در server اجرا میشه
می خواهم بدونم مقدار سرباری را که این تابع برای سرور ایجاد میکنه چقدره و کلاً این تبدیل تاریخ توی سرور انجام بشه بهتره یا در کلاینت ها و هنگام نمایش داده ها؟

ممنون

[AminSobati]

اینکه تابع چقدر بار ایجاد میکنه، برمیگرده به حجم اطلاعات شما. اما از اونجاییکه من طرفدار حتی کوچکترین قدم در جهت افزایش Performance هستم، توصیه میکنم شما یک فیلد به جدول اضافه کنید و موقع Insert تاریخ میلادی، تاریخ شمسی رو هم محاسبه کنید و در این فیلد جدید نگهداری کنید (طبیعتا موقع Update هم باید به روز بشه). حالا هنگام Query، شما محاسبه اضافی برای تبدیل تاریخ نخواهید داشت.

[aliasghar]

امین جان :
از پاسخ شما متشکرم
دیگه آخرای سال هست ، امیدوارم که شما و تمامی دیگر اعضای سایت سال خوب و خوشی داشته باشید. با بهترین موفقیت ها و خلاصه بهترین آروزها برای همه

کتاب tuning performance را گیر آوردم میرم مطالعه کنم و اگه سوالی پیش اومد دوباره مزاحم میشم

ممنون