“Optimize for Adhoc Workload” چطور بر Plan Cache تاثیر می‌گذارد

9 دیدگاه

1. 

   میلاد فیروزی

   دی ۲۰, ۱۳۹۴ در ۱۵:۵۱

       بسیار چالب بود

   ممنون

   پاسخ
2. 

   مهدی ربانی ذبیحی

   دی ۲۰, ۱۳۹۴ در ۱۸:۵۵

       بسیار عالی بود ممنون

   پاسخ
3. 

   Hamid J. Fard

   دی ۲۱, ۱۳۹۴ در ۰۷:۱۷

      گزینه Optimize for ad-hoc workloads برای محیط های Data Warehouse است نه برای محیط OLTP. بهتر است برای محیط OLTP برنامه و Query ها یک بار دیگر باز نویسی شوند. البته شما این تعداد Plan Stub دارید به دلیل وجود i.ToString()  است.

   از SQLCommand.Prepare() استفاده کنید تا Query مورد نظر را به صورت پارامترایز تبدیل و به SQL Server ارسال کند.

   پاسخ
   1. 

      مسعود طاهری

      دی ۲۱, ۱۳۹۴ در ۱۰:۰۰

          سلام بر حمید عزیز  و سایر دوستان

      استفاده از این گزینه در سیستم های OLTPی که سورس آن در دسترس نیست و کد نویسی آن برای چندین سال قبل است بسیار مفید است.

      برای مثال App را در نظر بگیرید که با VB6 و یا Delphi نوشته شده است تمامی کوئری ها به صورت ad-hoc داخل سورس نوشته شده متاسفانه این نوع کوئری ها ایراداتی نظیر SQL Injection ، کارایی و… دارند. برای رفع مشکلاتی که تورج عزیز اشاره کرد می توان روی این گزینه هم در سیستم های OLTP حساب باز کرد.

      معمولا در ایران و شاید خیلی از کشورهای دنیا شرکت های بزرگ تمایلی برای بازنویسی برنامه های جدید خود ندارند دلایل 

      1- سیستم دارد کار می کند و نیازی به تغییر اون نیست

      2- هزینه تولید سیستم جدید به مراتب بالا است (در مواردی سیستم اگر بزرگ باد چند ده میلیارد تومان)

      3- اگر App ایردات امنیتی دارد دنبال راه حل جایگزین هستند که این موراد را پوشش دهد. به شرط اینکه هزینه آن از تولید سیستم جدید به مراتب پایین تر باشد (مانند انجام تنظیمات امنیتی در SQL Server ، استفاده از WAF، استفاده از DBF)

      پاسخ
      1. 

         Hamid J. Fard

         دی ۲۱, ۱۳۹۴ در ۱۳:۰۰

            اگر سیستم بزرگی که گفتید از این روش استفاده کرده باشه یعنی اینکه طراحی این سیستم از پایه و اساس اشتباه بوده. البته در محیط OLTP قابلیت Forced Parameterization هم فعال باشد تا تعداد Plan Stub ها به حداقل برسد. در محیط OLTP سرعت پردازش مهمترین اصل است ولی با فعال سازی این گزینه استفاده از پردازنده زیادتر شده و اینکه زمان تراکنش به دلیل عملیات اضافی بالا می رود.

         این گزینه از طرف مایکروسافت برای محیط های DW ارائه شده است.

         به هرحال میل خودتون در مورد استفاده از این قابلیت.
      2. 

         مسعود طاهری

         دی ۲۱, ۱۳۹۴ در ۱۵:۰۱

             بلی حمید جان از سیستم ها تا دلتان بخواهد در ایران وجود دارد و هنوز که هنوز است کار می کند و متاسفانه برای سازمان ها قابل توجیه نیست که هزینه ای برای باز نویسی مجدد آن در نظر بگیرند.

      3. 

         مسعود طاهری

         دی ۲۱, ۱۳۹۴ در ۱۵:۵۱

         در خصوص مصرف CPU هم باید اشاره کنم. همانطور هم که تورج عزیز در مقاله اشاره کرده مصرف CPU به ازای فعال شدن این پارامتر به اون شدتی نیست که دوستان فکر می کنند (مثلا 50 درصد و…) مهمترین حسن این قابلیت مصرف کم حافظه نسبت به زمانی است که کدهای Ad-hoc به شدت در App نوشته شده است. در این حالت می توانیم روی این ویژگی حساب باز کنید. 
      4. 

         Hamid J. Fard

         دی ۲۱, ۱۳۹۴ در ۱۷:۱۸

            مطلع هستم مصرف پردازنده کم است ولی برای تعداد بسیار بالای کوری ها. در بهینه سازی یک مسئله است به این صورت که ممکن از یک دستور  با یک بار اجراء سرعت سیستم را پایین آورد ولی یک دستور با اجراء بسیار زیاد سرعت سیستم را پایین آورد.
4. 

   فرشید علی اکبری

   دی ۲۱, ۱۳۹۴ در ۱۲:۲۹

    سلام

   ممنون از مقاله خوب تون و تشکر از آقای طاهری بابت ارائه مطالب تکمیلی.

   پاسخ