در اس کیو ال سرور 2016، قابلیت غیر فعال نمودن parameter sniffing در سطح بانک اطلاعاتی مهیا شده است. اما چرا؟

قبل از پاسخگویی به سؤال بالا، به یک سری مقدمات نیاز است:

وقتی یک کوئری به اس کیو ال ارسال می‌شود، چه اتفاقی رخ می‌دهد؟
وقتی یک کوئری ارسال می‌شود، تعدادی از پروسس‌ها بر روی کوئری شروع به فعالیت‌هایی مانند مهیا نمودن داده‌های بازگشتی، یا ذخیره سازی و ... می‌کنند.
 پروسس‌ها به دو دسته زیر تقسیم می‌شوند:

1. پروسس‌هایی که در relational engine رخ می‌دهند
2. پروسس‌هایی که در storage engine رخ می‌دهند

در relational engine، هر کوئری pars شده و سپس بوسیله query optimizer پردازش و پلن اجرایی (execution plan) آن که بفرمت باینری است، ایجاد می‌شود و به storage engine ارسال می‌گردد. در storage engine پروسس‌هایی مانند قفل گذاری، نگهداری ایندکس‌ها و تراکنش‌ها رخ می‌دهد. هنگامیکه اس کیو ال سرور کوئری را دریافت می‌نمایند، آن را بلافاصله به relational engine ارسال می‌کند. سپس نحو (syntax) آن بررسی می‌شود؛ این عمل  query parsing نامیده می‌شود. خروجی عملیات پارسر، یک ساختار درختی (query tree) است. این ساختار درختی مشخص کننده مراحل لازم جهت اجرای کوئری ارائه شده می‌باشد.
اگر یک کوئری شامل DML نباشد (مانند ساخت جدول)، علمیات بهبود برروی آن صورت نخواهد گرفت. ولی در صورتیکه کوئری ارسالی، DML باشد، درخت اشاره شده در بالا به algebrizer فرستاده می‌شود که وظیفه آن تفسیر و بررسی کلیه نام اشیاء، جداول و ستون‌های اشاره شده در متن کوئری است. فرآیند algebrizer بسیار مهم و حیاتی است؛ بدلیل اینکه در کوئری ممکن است اشاره کننده‌هایی به اشیایی باشند که در بانک اطلاعاتی موجود نیست. خروجی algebrizer یک query processor tree باینری است که به بهبود دهنده کوئری ارسال می‌گردد. 

معرفی Query Optimizer (بهبود دهنده پرس و جو)

بهبود دهنده، بهترین مسیر اجرای کوئری را مشخص می‌کند. این بهبود دهنده است که مشخص می‌کند که اطلاعات بوسیله ایندکس دریافت شوند، یا اینکه از چه اتصالی استفاده شود و الی آخر. این تصمیمات براساس محاسبات هزینه‌های (میزان پردازش لازم cpu و I/O) پلن اجرایی صورت خواهد پذیرفت. بهمین دلیل به پلن cost-based نیز شناخته می‌شود.
هنگامیکه کوئری ساده‌ای مانند دریافت اطلاعات از یک جدول، که بر روی آن ایندکس گذاری انجام نشده‌است، ارسال شود، بهبود دهنده بجای مشخص نمودن یک پلن مناسب بهینه، از یک پلن ساده (trivial) استفاده می‌کند. ولی برعکس در صورتیکه کوئری trivial نباشد (یعنی مثلا کوئری به گونه‌ای باشد که از ایندکس‌ها به شکل صحیحی استفاده شده باشند)، بهبود دهنده یک پلن مناسب را براساس اطلاعات آماری مهیا شده در اس کیو ال سرور، تولید و انتخاب می‌نماید.

اطلاعات آماری از ستون‌ها و ایندکس‌ها جمع آوری می‌شود. این اطلاعات شامل نحوه توزیع داده، یکتایی و انتخاب شوندگی است. این اطلاعات توسط یک histogram ارائه می‌شود. اگر اطلاعات آماری برای یک ستون و یا ایندکس وجود داشته باشد، بهبود دهنده از آن‌ها برای محاسبات خود استفاده خواهد کرد. اطلاعات آماری بصورت خودکار برای تمام ایندکس‌ها و یا هر ستونی که بشود بر روی آن‌ها where یا join نوشت، فراهم خواهد شد.
بهبود دهنده با مقایسه پلن‌ها براساس بررسی تفاوت‌های انواع joinها، چیدمان مجدد ترتیب join و بررسی ایندکس‌های مختلف و سایر فعالیت‌های دیگر، پلن مناسب را انتخاب و از آن استفاده می‌کند. در طی هر کدام از فعالیت‌های اشاره شده، زمان اجرای آن‌ها نیز تخمین زده (estimated cost) خواهد شد و در پایان، زمان کل تخمینی بدست خواهد آمد و بهبود دهنده از این زمان برای انتخاب پلن مناسب بهره خواهد برد. باید توجه داشت که این زمان تقریبی است. زمانیکه بهبود دهنده پلن اجرایی انتخاب می‌کند، یک actual plan را ایجاد و در حافظه ذخیره می‌شود؛ بنام plan cache. البته درصورتیکه پلن مشابه و بهینه‌تری وجود نداشته باشد. 

استفاده مجدد از پلن ها

تولید پلن هزینه بر است. به‌همین دلیل اس کیوال سرور اقدام به ذخیره سازی و نگهداری آن‌ها می‌کند تا بتواند از آن‌ها مجددا استفاده نماید؛ البته تا جایی که مقدور باشد. هنگامیکه آن‌ها تولید می‌شوند، در قسمتی از حافظه بنام plan cache ذخیره می‌شوند. به این عمل procedure cache نیز گفته می‌شود.

هنگامیکه کوئری به سرور ارسال می‌شود، بوسیله بهبود دهنده، یک estimated plan ایجاد خواهد شد و قبل از اینکه به storage engine ارسال شود، بهبود دهنده estimated plan را با actual execution planهای موجود در plan cache مقایسه می‌کند. در صورتیکه یک actual plan را مطابق با estimated plan پیدا نماید، از آن مجدد استفاده خواهد کرد. این استفاده مجدد به عدم تحمیل سربار اضافه‌ای به سرور جهت کوئری‌های بزرگ و پیچیده که در زمان واحد، هزاران بار اجرا خواهند شد، منجر می‌شود.
هر پلن فقط یکبار در حافظه ذخیره خواهد شد. ولی در مواقعی با تشخیص بهبود دهنده و هزینه پلن، یک کوئری می‌تواند پلن دیگری نیز داشته باشد. بنابراین پلن دوم نیز با مجموعه عملیاتی متفاوت، جهت اجرای موازی (parallel execution) برای یک کوئری ایجاد و در حافظه ذخیره می‌شود.
پلن‌های اجرایی برای همیشه در حافظه باقی نخواهند ماند. پلن‌های اجرایی دارای طول عمری طبق فرمول حاصل ضرب هزینه، در تعداد دفعات می‌باشند. مثلاً پلنی با هزینه 10 و تعداد دفعات اجرای 5، طول عمر 50 را خواهد داشت. پروسس lazywriter که یک پروسس داخلی است وظیفه آزاد سازی تمام انواع کش‌ها، از جمله پلن کش را دارد. این پروسس در بازه‌های مشخص، تمام اشیاء درون حافظه را بررسی کرده و یک واحد از طول عمر آن‌ها می‌کاهد.
در موارد زیر، یک پلن از حافظه پاک خواهد شد:
1. به حافظه بیشتری نیاز باشد
2. طول عمر پلن صفر شده باشد 

حال فرض کنید شما یک پروسیجر یا یک کوئری پارامتری دارید (پارامتر ورودی: شناسه سفارش یا نال) که کلیه محصولات سفارش داده شده یا محصولات یک سفارش خاص را نمایش می‌دهد. هنگامی که SQL Server optimizer پلن این کوئری را ایجاد می‌کند و یا آن را کامپایل می‌کند، به پارامترهای ورودی این پروسیجر گوش می‌دهد (نال یا یک شناسه سفارش). optimizer بوسیله column statistics از تعداد رکوردهایی که بازگشت داده می‌شود، برآوردی می‌کند (مثلا 40 رکورد). سپس یک پلن مناسب را انتخاب می‌کند و آن را برای اجرا ارسال می‌کند و پلن را ذخیره می‌نماید.
جمله آخر، معمولا باعث ایجاد مشکل می‌شوند.
اگر optimizer تکست کوئری مشابهی را مشاهده نماید، ولی با پارامترهای متفاوت، به کش پلن مراجعه کرده و اگر در آن جا قرار داشت، از آن مجددا استفاده می‌نماید. این استفاده مجدد خوب است؛ اما  درصورتیکه پارامتر ارسالی نال باشد چه اتفاقی رخ می‌دهد؟ جدول سفارشات محصول بسیار حجیم است و متاسفانه از پلنی که برای بازگشت 40 رکورد قبلا ایجاد شده، برای بازگشت این حجم بالای از رکوردها استفاده می‌شود که این کشنده است.
هیچ تضمینی وجود ندارد که از وقوع این اتفاق جلوگیری نمایید؛ اما می‌توانید در هنگام توسعه، پروسیجر را شناسایی و نسبت به رفع آنها اقدام نمایید. ابتدا کش پلن را خالی نمایید و سپس پروسیجر را با مقادیر متفاوت، اجرا نمایید. در صورتیکه پلن‌های متفاوتی مشاهده نمودید، این یک علامت هشدار است و می‌بایست نسبت به رفع آن‌ها اقدام فوری نمایید. 

این مساله یعنی IE دسترسی نمایش Adobe رو بسته. برای رفع آن:
الف) در IE به منوی Tools -> Manage add-ons مراجعه کنید. آیا افزونه‌های Adobe فعال هستند؟
ب) تنظیمات امنیتی IE را در حالت پیش فرض قرار بدید
Tools -> Internet Options -> Security tab -> Reset all zones to default level


ولی در کل پیشنهاد من پیاده سازی روش توضیح داده شده جهت استفاده از Active-X شرکت Adobe در WPF است. یکبار مراحل آن‌را قدم به قدم طی کنید.

سلام ؛ 

در  قسمت قبل با الگوریتم Association Rules که بیشتر برای تحلیل سبد خرید استفاده می‌شد، آشنا شدیم. در این قسمت که قسمت آخر از سری مقالات الگوریتم‌های داده کاوی در SSDT می‌باشد، با الگوریتم‌های Neural Network و Logistic Regression آشنا می‌شویم.

Neural Network (هوش مصنوعی)

مقدمه

روشی کار مغز انسان برای حل مساله‌ای که با آن مواجه می‌شود را درنظر بگیرید. ابتدا حقایق مساله را در چند سطح تحلیل کرده و می‌سنجد. سپس این حقایق، وارد نرون‌های عصبی می‌شوند. این نرون‌های عصبی مانند فیلترهایی که براساس الگوهای معلوم قبلی عمل می‌کنند، شروع به فیلتر کردن حقایق می‌نمایند. درنهایت این موضوع سبب استنتاج می‌گردد که ممکن است منجر به پیدا کردن راه حلی برای مساله شود و یا به عنوان وقایع افزوده‌ای برای از سرگیری مراحل بالا در نرون‌های عصبی دیگر باشد.

توصیف الگوریتم

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

پیچیدگی تحلیل انجام شده توسط این الگوریتم به دو عامل بر می‌گردد:

1. ممکن است یک یا تمام ورودی‌ها به طریقی با یک یا همه‌ی خروجی‌ها مرتبط باشند و الگوریتم باید این موضوع را در آموزش مدل درنظر بگیرد.
2. ممکن است ترکیبات مختلفی از ورودی‌ها به طریقی با خروجی‌ها در ارتباط باشند.
   

دسته بندی اسناد یکی از موضوعاتی است که شبکه‌های عصبی بهتر از الگوریتم‌های دیگر آن را حل می‌کنند. البته اگر سرعت برای ما مهم باشد، می‌توان از الگوریتم Naïve Bayes استفاده کرد. اما درصورتیکه دقت مهم‌تر باشد، آنگاه باید از الگوریتم شبکه‌های عصبی استفاده نمود.

تفسیر مدل

 نتیجه‌ی حاصله از این الگوریتم نسبت به الگوریتم‌های قبلی کاملا متفاوت است. در اینجا دیگر خبری از طرح محتوای مدل و نمودار گرافیکی لایه آموزش نیست. هدف اصلی در اینجا نمایش تاثیر صفت-مقدار، بر ویژگی قابل پیش بینی است. برای مثال جدول زیر در رابطه با تمایل به خرید یا اجاره خانه در رابطه با صفات مختلف می‌باشد. همانطور که مشخص است، دو ستون اول نشان دهنده‌ی جفت صفت-مقدار و دو ستون دوم، صفت مدنظر جهت پیش بینی را نشان می‌دهند. براساس این جدول می‌توان نتیجه گرفت که مهمترین فاکتور در تمایل به خریداری خانه، سن افراد می‌باشد. افرادی که سنی بین 38 تا 54 سال را دارند، بیشترین تمایل را در خرید یک خانه دارند. فاکتورهایی مانند متاهل بودن، سطح تحصیلات فوق دکترا، بازه سنی 33 تا 38  و خانم بودن نیز دارای اهمیت می‌باشند که به ترتیب از درجه اهمیت آن‌ها کم می‌شود. از طرفی بازه سنی 20 تا 28 سال بیشترین تمایل برای اجاره خانه را دارند. همچنین می‌توان گفت که افرادی که مجرد هستند، طلاق گرفته‌اند و یا سطح تحصیلاتشان دبیرستان است، بیشتر تمایل به اجاره خانه دارند تا به خرید آن.

Logistic Regression

همانند الگوریتم شبکه‌های عصبی است؛ با این تفاوت که لایه مخفی‌ای برای تولید ترکیبی از ورودی‌ها ندارد. یعنی سعی در برقراری ارتباط بین ترکیبی از ورودی‌ها و خروجی‌ها نمی‌کند (در واقع همان الگوریتم شبکه‌های عصبی است که پارامتر Hidden Node Ratio آن روی صفر تنظیم شده است). بنابراین سرعت پردازش و آموزش مدل در آن، بالاتر می‌باشد. البته صرف اینکه این الگوریتم دارای پیچیدگی کمتری است نمی‌توان گفت که همیشه ضعیف‌تر از الگوریتم شبکه‌های عصبی است. بلکه حتی در بعضی از مدل‌ها بهتر از الگوریتم شبکه‌های عصبی عمل می‌کند و مانع از باز آموزشی مدل می‌گردد.

به پایان آمد این دفتر، حکایت همچنان باقی است!

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

بعد از مدتی سروکار داشتن با مفاهیم WCF ،Web API ،WCF REST و Web Service برای تهیه یک فریم ورک قوی، به این نتیجه رسیدم که اکثر برنامه نویسان در مقایسه بین مفاهیم یاد شده به مشکل می‌خورند. در این مطلب سعی بر این است که تفاوت‌های اساسی آنها را به‌صورت کلی بیان کنم. 
دانت فریم ورک با بهره‌گیری از این تکنولوژی‌ها، امکاناتی را برای ایجاد HTTP سرویس‌ها، به ما می‌دهد و قبل از بکارگیری لازم است انتخاب کنیم که از کدام تکنولوژی باید استفاده کنیم.

Web Service
1. پایه‌ی آن براساس SOAP است و داده‌ها را در قالب XML به ما می‌دهد.
2. فقط از HTTP پروتکل پشتیبانی می‌کند.
3. متن باز نیست  اما می‌توان از آن در هر کلاینتی که از XML پشتیبانی می‌کند، استفاده کرد.
4. فقط بر روی IIS می‌توان آن‌را هاست کرد.

WCF
1. پایه‌ی پیش فرض آن براساس SOAP است و داده‌ها را در قالب XML به ما می‌دهد.
2. تکامل یافته‌ی وب سرویس‌ها است (ASMX) و از پروتکل‌های مختلفی همچون  TCP, HTTP, HTTPS, Named Pipes, MSMQ  پشتیبانی می‌کند.
3. مشکل اصلی WCF در بد قلقی و گسترده بودن تنظیمات آن می‌باشد.
4.  متن باز نیست، اما می‌توان از آن در هر کلاینتی که از XML پشتیبانی می‌کند، استفاده کرد.
5.  بر روی IIS یا برنامه‌ها و یا ویندوز سرویس‌ها، می‌توان آن‌را هاست کرد.

WCF REST
1. برای استفاده از WCF  و WCF REST  باید حتما  webHttpBindings را فعال کرده باشید.
2. از  دستور العملهای HTTP Get و  HTTP  POST با استفاده از ترکیب خصیصه‌های [WebGet] و [WebInvoke] ، پشتیبانی می‌کند.
3. برای فعال کردن سایر دستور العمل‌های  HTTP باید تنظیماتی را در IIS انجام دهید، تا درخواست‌هایی که بر اساس دستورالعمل‌های ویژه‌ی در فایل svc. می‌باشند را قبول کند.
4. ارسال دیتا به آن از طریق پارامتر، با استفاده از  WebGet احتیاج به تنظیماتی دارد و یا  UriTemplate  باید مشخص شود.
5. از  XML, JSON and ATOM  پشتیبانی می‌کند.

Web API
1. یک فریم ورک جدید برای ساختن HTTP سرویس، یک راه ساده و آسان.
2. متن باز است و یک راه ایده آل برای ساخت  REST-ful سرویس‌ها بر روی دات نت فریم ورک.
3. برخلاف  WCF Rest، سرویس‌های آن از ویژگی‌های کامل HTTP مانند ( URIs, request/response headers, caching, versioning various content formats) پشتیبانی می‌کنند.
4. همچنین از ویژگیهای کامل MVC از قبیل routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing به‌سادگی و قوی پشتیبانی می‌کند.
5.  بر روی IIS و یا برنامه‌ها، می‌توان آنرا هاست کرد.
6. یک معماری سبک و مناسب برای دستگاه‌هایی که پهنای باند محدودی دارند، مانند گوشی‌های هوشمند.
7. پاسخها بوسیله  Web API’s MediaTypeFormatter به صورت JSON, XML  فرمت می‌شوند؛ و یا هر فرمتی را که شما می‌خواهید، به‌عنوان MediaTypeFormatter اضافه کنید .

انتخاب بین WCF  یا WEB API
1.انتخاب WCF زمانی مناسب است که شما می‌خواهید یک سرویس را ایجاد کنید که باید از سناریو‌های مختلفی از قبیل پیغام‌های یکطرفه و صف  پیغام‌ها و ارتباطات دو طرفه پشتیبانی کند و یا می‌خواهید یک سرویس را ایجاد کنید که از کانال‌های انتقال سریع استفاده کند؛ از قبیل TCP و  Named Pipes و یا شاید گاهی UDP در  WCF 4.5 و همچنین می‌خواهید از HTTP  پشتیبانی کند؛ وقتی که همه‌ی کانال‌های دیگر انتقال در دسترس نیستند.
2. انتخاب  Web API زمانی مناسب است که شما می‌خواهید یک  resource-oriented سرویس را بر روی HTTP ایجاد کنید. در اینجا می‌توان از ویژگی‌های کامل HTTP  مانند  URIs, request/response headers, caching, versioning, various content formats استفاده کرد و یا می‌خواهید سرویس را در معرض طیف گسترده‌ای از کلاینت‌ها شامل مرورگرها، موبایل‌ها، iphone و تبلت قرار دهید.