مانیتورینگ پایگاه داده DB2 for zOS

مقدمه

DB2  تحت z/OS یک پایگاه داده‌ی رابطه ای است که در سخت افزار مین فریم (Mainframe) از شرکت IBM  استقرار می ‌یابد و برای ثبت و بازیابی حجم بالای اطلاعات‌ مورد استفاده قرار می ‌گیرد. شرکت IBM این پایگاه داده را با همین نام برای سیستم عامل‌های ویندوز و لینوکس (به اختصار LUW) ارائه کرده است که بررسی شاخص‌های مرتبط با آن در اینجا انجام شده است، اما برای محیط‌های با تراکنش‌های بالا، استفاده از سخت افزار مین فریم توصیه می ‌شود. به همین دلیل بسیاری از بانک‌های مطرح دنیا و بانک‌های دولتی ایران به علت نیاز به پایداری و توان پردازشی بالا از مین فریم و پایگاه داده DB2  تحت z/OS‌ استفاده می کنند. در حال حاضر DB2  جزو لاینفک سیستم‌های بانکی (Core Banking) بسیاری از بانک های دولتی ایران می ‌باشد و برای راه اندازی و نگهداری آن با چالش‌هایی مانند ابزارها و دانش مانیتورینگ روبرو هستند.

در این مقاله به برخی از شاخص‌های مهم و تأثیرگذار در مانیتورینگ پایگاه داده DB2  تحت z/OS پرداخته می‌شود.(بررسی پایگاه داده DB2 for LUW در مقاله‌ی دیگری انجام شده است، برای خواندن آن مقاله بر روی این لینک کلیک کنید) پیش از پرداختن به این موضوع باید اشاره شود که پایگاه‌ داده‌ی DB2‌ در محیط z/OS می ‌تواند با پیکربندی‌های متفاوتی استقرار یابد و  Distributed Data Facility (DDF) یکی از سرویس‌های دیتابیس DB2 تحت z/OS می باشد که به منظور ارتباط برنامه های کاربردی با درایورهای JDBC و ODBC مورد استفاده قرار می گیرد و فرض می شود این سرویس برای مانیتورینگ در حالت استارت است.

دسترس‌پذیری پایگاه‌داده

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

در کنار شاخص دسترس‌پذیری زمان پاسخ پایگاه داده به یک درخواست مشخص در طول زمان نیز بسیار مهم است. در حال حاضر این دو شاخص به صورت دوره‌ایی توسط پلتفرم معین از پایگاه داده‌ی DB2‌ استخراج می ‌شود.

آمار Threadها 

یکی از پارامترهای مهم در اتصال از طریق DDF، آمار Threadها می ‌باشد. این آمار در سیستم عامل z/OS با استفاده از دستور Display DDF Detail‌ استخراج می ‌شود. خروجی این دستور در حالت پیش‌فرض به صورت شکل زیر است

مواردی که در این شکل با رنگ قرمز مشخص شده است جزء شاخص‌های مهم می ‌باشند. در این شکل اطلاعات کاملی از آمار Threadها و ارتباطات ارایه شده است که در حال حاضر سامانه معین بسیاری از این پارامترها را در قالب شاخص‌ها دریافت و ذخیره می ‌نماید تا راهبر در زمان‌های مختلف بتواند تحلیل درستی از وضعیت پایگاه داده داشته باشد. 

در صورتی که مقدار STATUS=STOPDQ باشد نشان از بسته بودن پورت DDF است. در این حالت هیچ برنامه ای از طریقDDF امکان اتصال به دیتابیس را ندارد. مقدار نرمال برای اتصال به صورت STATUS=STARTD می باشد. بهتر است برای بررسی انواع حالت به کتاب DB2 Messages مراجعه شود.

یکی از مهمترین این پارامترها پارامتر ADBAT می ‌باشد. مطابق تعریف در این لینک شاخص ADBAT شامل تعداد Threadهای فعال و Threadهای Disconnect شده می ‌باشد. البته مقدار پارامتر DT در تحلیل این پارامتر مهم است. Threadها وظیفه اجرای دستورات و عملیات‌هایی که توسط کلاینت‌ها و برنامه‌ها به پایگاه داده زده شده است را دارند. بنابراین ممکن است تا هزاران ارتباط به پایگاه داده زده شده باشد و Threadها وظیفه دارند تا به هر ارتباط سرویس‌دهی کنند. 

تعداد کل Threadهای مجاز را می ‌توان در پارامتر MDBAT  یافت که در ZPARM قابل تنظیم می‌باشد. بنابراین حداکثر تعداد Threadها معادل MDBAT است و ADBAT‌ نمی ‌تواند بالاتر از آن باشد. بهتر است آمار نرمال ADBAT در زمان های عادی استخراج شود و مورد پایش قرارگیرد. کاهش کمتر از مقدار نرمال نشان از عدم اتصال برنامه ها و یا کم شدن کاربران می‌باشد و افزایش بیش از نرمال نشان از عدم پاسخ گویی دیتابیس در زمان مناسب به درخواست‌ها می باشد. با مشاهده کاهش و یا افزایش آمار کانکشن‌ها نسبت به مقدار نرمال بهتر است به بررسی ریشه اصلی مشکل که می تواند عوامل بیرونی و درونی دیتابیس باشد، پرداخته شود.

آمار لحظه‌ایی Threadهای  Disconnect شده نیز در پارامتری با عنوان DSCDBAT ارایه می ‌شود. با این توضیحات اختلاف ADBAT و DSCDBAT پارامتر مهمی خواهد بود. با توجه به اینکه تعداد کل Threadهای فعال اعم از فعال و Disconnect شده در ADBAT قرار دارد لذا به هر میزان که این اختلاف بالاتر رود نشان‌دهنده‌ی آزاد نشدن Threadها و درگیر بودن Threadها خواهد بود. بنابراین در صورتیکه مقدار ADBAT به MDBAT(یعنی سقف تردها نزدیک باشد) و مقدار اختلاف ADBAT‌ و DSCDBAT‌ نیز به ADBAT نزدیک باشد(یعنی مقدار DSCDBATها مقدار ناچیزی باشند) در این صورت نشان‌دهنده‌ی عدم آزاد سازی تردها و مشغول بودن آنها می ‌باشد. که در این حالت نیاز به بررسی علت مشغول بودن Threadها می ‌باشد.

در شرایطی که اختلاف ADBAT و DSCDBAT افزایش یابد( با فرض نزدیک بودن ADBAT به MDBAT) پایگاه داده به ارتباطات جدید پاسخی نمی‌دهد و عملا درخواست‌ها در صفی در DDF قرار می ‌گیرند. مقدار این صف در پارامتری به نام QUEDBAT منعکس می ‌شود. البته پارامتر QUEDBAT به صورت افزایشی است و از زمان روشن بودن ماژول DDF مقدار آن اضافه می‌شود. 

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

نکته‌ایی که باید به آن اشاره شود این است که افزایش ADBAT‌ به تنهایی نمی ‌تواند نشانگر نامطلوب بودن شرایط باشد بلکه در صورتیکه این افزایش همراه با کاهش تعداد DSDBAT ها باشد پس از مدتی ممکن است صفی از درخواست‌ها در DDF به وجود بیایید. بنابراین در معین شاخصی مجزا با عنوان «اختلاف ADBAT و DSCDBAT‌» ایجاد شده است که می ‌تواند مبنایی برای بررسی وضعیت کلی پایگاه داده از نظر وضعیت Threadها باشد.

در انتهای این بخش باید اشاره شود که ممکن است پیکربندی پایگاه داده‌ی DB2 به گونه‌ایی باشد که چندین عضو یا Member داشته باشد. در این حالت اطلاعات DDF همه‌ی اعضاء استخراج و شاخص‌های اشاره شده هم به ازای هر Member و هم به ازای کل پایگاه داده محاسبه می ‌شود.

وضعیت لاگ (LOG)

DB2  تمام وقایع مرتبط با ذخیره اطلاعات را در فایلهای لاگ (Log Files) ذخیره می‌کند. ذخیره اطلاعات و تخلیه (Offload) به موقع و آرشیو نمودن آنها در کارایی DB2 بسیار اثر گذار است. بطور خلاصه DB2  معمولا سه جفت لاگ فایل دارد که بصورت چرخشی اطلاعات را در لاگ فایل نوشته و تخلیه می‌کند. بطوریکه بعد از پرشدن هر فایل مطابق مکانیزم داخلی اطلاعات آن در فایل‌های دیگری تحت عنوان فایل‌های آرشیو ذخیره می‌شوند و داده های آنها خالی شده و آماده ذخیره در سیکل بعدی می شوند. بنابراین مانیتور کردن آنها بصورت مستمر و حصول اطمینان از خالی بودن آنها لازم است. 

ممکن است در مواقعی DB2 در نوشتن فایل‌های لاگ و یا ذخیره آنها در فایل‌های آرشیو به خاطر مشکلات IO دچار کندی شدید می‌شود به همین دلیل مانیتورینگ فایل‌های لاگ دارای اهمیت است. برای دیدن وضعیت لاگها از دستور DISPLAY LOG استفاده می شود. نتیجه اجرای این دستور حاوی میزان خالی بودن و نام فایل‌های در حال نوشته شدن می ‌باشد. در پلتفرم معین تعداد کل لاگ‌های فعال و تعداد Offloadهای انجام نشده از پایگاه داده استخراج می ‌شود. بنابراین چنانچه تعداد Offloadهای انجام نشده افزایش پیدا کند به آن معنی است که پایگاه داده در آرشیو کردن فایل‌های لاگ دچار مشکل شده است و باید مورد بررسی قرار گیرد.

با ارسال دستور  DISPLAY LOG اطلاعات زیر دریافت می شود:

لیست پایگاه داده‌ها (DATABASE) و وضعیت فضای جدول‌ها (TABLESPACE):

یکی از موارد مهم در DB2 وضعیت فضای جدول‌ها در پایگاه داده ها می ‌باشد. دستور DISPLAY DATABASE(dbname) SPACENAM(*) RESTRICT از دستورات کاربردی است که وضعیت فضای جدول‌ها را نشان می ‌دهد و در صورتی که وضعیت خاص و غیر عادی داشته باشد با نشان دادن وضعیت آن می ‌توان مشکل را برطرف کرد. پاسخ مطلوب این است که هیچ فضای جدولی در پاسخ نباشد در این صورت کلیه فضای جدول‌های پایگاه داده ی مذکور در وضعیت عادی هستند. 

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

موارد اشاره شده برخی از شاخص های مهم و تأثیر گذار در عملکرد پایگاه‌ داده‌ی DB2‌ تحت Z می ‌باشد که مانیتورینگ آنها می ‌تواند بیانگر وضعیت کلی سلامت این پایگاه داده باشد و به اپراتور در شناخت مشکلات کمک نماید. بررسی زمانی این شاخص‌ها بسیار حائز اهمیت بوده و با توجه به اینکه این پایگاه داده در سازمان‌های بزرگ با کلاینت‌ها و برنامه‌های مختلف و متنوع به کار می ‌رود، اطلاع از زمان مشکل در پایگاه داده می ‌تواند در یافتن ریشه‌ی مشکل کمک نماید. 

توصیه می ‌شود شاخص‌های این پایگاه‌ داده در کنار شاخص‌های سلامت سیستم عامل z/OS مانیتور شود. در حال حاضر پلتفرم معین امکان مانیتورینگ این سیستم عامل را نیز از طریق اینترفیس استاندارد RMF دارد که جزییات شاخص‌های آن در این لینک وجود دارد. لذا با مانیتورینگ سیستم عامل در کنار شاخص‌های سلامت پایگاه داده می ‌توان از عملکرد صحیح این پایگاه داده‌ی مهم اطمینان حاصل کرد. در صورت نیاز به اطلاع از کلیه‌ی شاخص‌های مانیتور شده‌ی پایگاه‌داده  DB2 For zOS را می ‌توانید از این لینک ملاحظه نمایید.