داستانهای واقعی: افزایش فضای shared pool

یک RAC سه نود بر روی اوراکل نسخه 12.2 داریم. مدتی بود در وقت های پیک کاری اپلیکیشن، با ویت ایونت gc current block 2-way و ... و با مقدار بالا برخورد میکردم به نحوی که کارکرد اپلیکیشن رو مورد تاثیر خود قرار داده بود. از طرفی تمام موارد مرتبط با GC در کلاستر رو با دقت و وسواس بالا با توجه به آخرین Best Practiceها پیکربندی و بازبینی کرده بودم (به خصوص پارامترهای مرتبط با LMS مانند GCS_SERVER_PROCESSES) و با مانیتورینگ شبکه و سرعت Interconnect هام از سرعت و وضعیت خوب اونها مطمئن بودم همچنین با توجه به مشاهدات محیطی به این نتیجه رسیده بودم که در طول 2 ماه کارکرد اپلیکیشن تنها در انتهای بازه های پیک اپلیکیشن این مشکل دیده میشد پس این موضوع کنجکاوی من رو برای این که بفهمم مشکل کجا بود بیشتر کرد.

تو بررسی هام از طریق Memory Advisor در Enterprise Manager متوجه شدم که در این روزها فضای shared pool به طرز قابل توجهی بالا میره و فضای buffer cache بسیار کوچیک میشه پس با این فرض همه چیز منطقی به نظر میومد. چون با رشد فضای shared pool فضای کافی برای buffer cache نبود.

زمانی که سیستم در وضعیت و پرفورمنس مناسب قرار داشت

 

طولانی شدن زمان های GC CR MULTIBLOCK REQUEST

ما یک RAC سه نود رو نگهداری می‌کنیم. به طور معمول کوئری‌های سنگین ما از نظر زمان اجرا خیلی باهم متفاوت هستند. به این علت که حجم دیتای بیزنس ما زیاد و دارای نوسان زیادی است در دیتای ما واریانسهای طبیعی زیادی وجود داره. با این حال خیلی از بلاکهای این نوسانها تا حدی توی حافظه RAC قرار دارند.

من یکسری تست‌ها انجام دادم که یه رخدادی رو به من نشون میده که میتونم اون رو به عنوان یک مشکل غیر منتظره در وبلاگم ثبت کنم.

تسک ما اجرای یک کوئری با چندین join هستش که باعث ایجاد هش جویان های زیادی در سیستم میشه

مشکل ما این بود که تاخیرهای مرتبط با گرفتن دیتا با Full Table Scan از روی دیسک کمتر از گرفتن دیتا از روی شبکه interconnect بود. در حقیقت به این معنی که همه بلوک ها روی node ای قرار می‌گیرند که از همه دورتر است پس wait های GC CR MULTIBLOCK REQUEST به مقدار زیادی بالا بودند.

میانگین waitهای scattered-read من به طور معمول ۸ میلی ثانیه و میانگین waitهای GC CR MULTIBLOCK REQUEST به طور معمول ۲۱ میلی ثانیه بود.

اگر هرکدام از جدول ها توسط یک کوئری از قبل فراخوانی شده بودند، یا کوئری‌های مشابه در همان روز از دیتابیس گرفته شده باشد و در نتیجه اوراکل محتوای جدول را در نود far-side (دورترین نود - نود ۳) قرار داده باشه اونوقت hash joinهای ما ۴۵ دقیقه طول میکشه و توسط wait ما (GC CR MULTIBLOCK REQUEST) محاصره میشه 

حالا اگه هر نود ما alter system flush buffer cache رو اجرا کنه که در نتیجه اتفاق خواندن از دیسک انجام میشه اونوقت همون کوئری وقتی دوباره اجرا بشه ۵ دقیقه طول میکشه و ایندفعه توسط wait ای به نام scattered/sequential read محاصره میشه

خواننده گرامی قبل از ادامه کار شما باید با Cache Fusion در RAC و مفاهیم Past Image و انواع Waitها در RAC آشنایی داشته باشید. سعی میکنم در مقاله ‌های بعدی به این موضوعات بپردازم.

وقتی اوراکل بلوک های درخواست شده رو از نود دور (far-side) به نود نزدیک (near-side) منتقل میکنه با فرض اینکه همه چیز به شکل صحیح پیکربندی شده باشه کلاستر اوراکل از شبکه private استفاده میکنه.

حقیقتاً به نظر من ۲۱ میلی ثانیه خیلی طولانی میاد بیشتر سیستم هایی که من دیدیم یا درباره اونها تحقیق کرده ام خوندن اطلاعاتشون بین ۸ تا ۱۰ میلی ثانیه طول میکشه در کل خوندن بلاک از interconnect باید کمتر از چند میلی ثانیه طول بکشه به عنوان یک اصل کلی این عدد برای سلامت RAC اوراکل بیش از حد مهم و بالاست هستش.

سوالی که برای من پیش میاد اینه که تحت چه شرایطی ممکنه wait یک کوئری با GC CR MULTIBLOCK REQUEST بیشتر از waitهای scattered-read باشه؟ (به عبارت دیگه چرا ممکنه انتقال بلوکها از طریق interconnect بیشتر از انتقال از طریق disk طول بکشه؟)

خب در جواب سوال باید بگم مقایسه بین انتقال اطلاعات در CR global cache بین نودها با خواندن از روی دیسک مثل مقایسه هویج و بادمجون ه.

یادمون باشه تحت خیلی از شرایط ممکنه این مشکل پیش بیاد اول از همه اینکه پیکربندی شبکه برای private امون چیه؟ آیا از اترنت گیگابیت استفاده میکنیم؟ (در کل بهتره از یک شبکه 10G یا Infiniband استفاده کنیم). آیا این شبکه private واقعا private ه یا شخص دیگه ای هم توی شبکه است؟ (در صورت شلوغی این شبکه خود این شبکه ممکنه باعث این چنین مشکلاتی بشه)

اوراکل توصیه میکنه حتما از jumbo frame برای این شبکه استفاده بشه خب با پیگیری های فراوان قبلاً در شبکه ما jumbo frame پیکربندی شده بود و این رخداد به تازگی و بدون تغییر در بیزنس اپلیکیشن رخ داده بود.

خب در ادامه باید بگم اوراکل در انتقال CR Global Cache یک read image واحد درخواست میکنه اونم به خاطر این که یک تراکنش ممکنه یک تغییری در بلوکی که در instance دیگه  وجود داره ایجاد کنه پس ما نیاز به خوندن یک ایمیج واحد داریم

ایمیج برداشته شده از روی دیسک در صورتی که هنوز commit نشده باشه همچنان نیاز داره که با session درخواستی به دیتابیس هماهنگ بشه پس تغییراتی که هنوز commit نشدند باید قبل از اینکه session بتونه ازشون استفاده بکنه rollback بشوند.

در غیر این صورت  ایمیج برداشته شده از روی دیسک یک بلوک current هستش که در این مورد ایمیج همونطور که هست و بوده در اون instance استفاده میشه و در مقیاسه با به دست آوردن ایمیج CR کار کمتری مورد نیازش هست و بار کمتری ایجاد میکنه (چون ایمیج CR باید به صورت منسجم از نودها فراخوانی بشه)

با تمام این توضیحات مشکل رو یا باید در شبکه جستجو میکردم یا در پیکربندی‌های اخیر - با این توضیح که قبلاً چنین مشکلی وجود نداشت و تست‌های انجام شده بر روی شبکه مشکلی رو نشون نمیداد سراغ پارامتر UNDO_RETENTION رفتم

یک توضیحی باید بدم که من برای گرفتن export از یکی از جداولمون که سایز بسیار زیادی داره (بیش از ۳ ترابایت) این پارامتر رو روی ۷ روز تنظیم کرده بودم

خب وقتی به یاد این پارامتر افتادم فهمیدم مشکل کجاست چون همین پارامتر قطعاً در رفتار کلاستر تفاوت ایجاد میکنه - مقدار من برابر ۷ روز بود پس دیتاها توی اینتنس ۱ لود شده و برای مدت طولانی در آینده گرفته میشوند اگه یک کوئری توی اینستنس ۲ اجرا بشه اوراکل ممکنه تصمیم بگیره که نیاز به یک read image منسجم داره ... خب همونطور که میدونید بازسازی مجدد بلاک مقداری زمان میبره به ویژه اگه حجم عظیمی از تغییرات در undo وجود داشته باشند چیزی که گیج کننده بود اینه که تراکنشی که تغییر رو ایجاد کرده باید تا الان وضعیت اش مشخص شده باشه پس به جای بلوک CR باید یک بلوک current درخواست میکرد ولی از اونجایی که بلوک CR به دفعات درخواست شده بود این موضوع نشون میده که تغییرات جداول مرتبط هنوز commit نشده بودند.

در نهایت با پایین آوردن مقدار این پارامتر به عدد دیفالت (۹۰۰) یا همون ۱۵ دقیقه این مشکل رو حل کردم.

سطح redundancy دیسک گروه‌ها در ASM

سطح redundancy دیسک گروه ها در ASM به سه حالت زیر است:

نوع اول Normal
اطلاعات فایل ما را در دو جا نگهداری می‌کند. یعنی شبیه سناریو RAID 1 می‌باشد. تحمل خرابی یک گروه ۱ دیسک است. اگر یک دیسک از بین برود دیگری وجود دارد. برای راه‌اندازی آن دو تا دیسک و یا دو تا گروه failure نیاز است.

نوع دوم High
اطلاعات فایل را در ۳ جا نگهداری می‌کند. برای این حالت نمونه سناریو RAID ای وجود ندارد. تحمل خرابی ۲ تا دیسک و یا ۲ گروه failure است. اگر یکی از بین برود اطلاعات دو جای دیگر وجود دارد. برای راه اندازی آن ۳ تا دیسک و یا سه تا گروه failure نیاز است.

نوع سوم External
هیچ mirrory برای دیسک ها در ASM وجود ندارد و در صورت لزوم براساس RAID سخت‌افزاری دیسک‌ها سناریوبندی می‌شوند.

مروری اجمالی بر سخت‌افزاری‌های مورد نیاز کلاستر - قسمت دوم

قسمت قبل: مروری اجمالی بر سخت‌افزاری‌های مورد نیاز کلاستر - قسمت اول

همیشه اینو یادتون باشه اگه io خیلی زیادی دارید best practice اینه که نوع OS شما windows / linux نباشه و بهتره از سخت‌افزارهای RACK Oracle/Sun و OS Sun Solaris استفاده کنید همچنین استفاده از IBM AIX و HP-UX هم توصیه میشه

اوراکل توی چند ساله اخیر اومد گفت که دیگه نسخه 11g به بعد رو برای HP-UX نمیده پس بهتره از Oracle Sun Solaris استفاده کنید

یادتون باشه بسته به TPSهاتون (Transaction Per Seconds) باید سرور رو مشخص کنید مثلاً سرورهای dl محدودیت‌هایی از لحاظ آدرس‌دهی و معماری دارند چون Intel بیس‌اند پس در شرایطی که tpsهاتون وحشتناک زیاده (مثلاً در هر ثانیه ۱۰ تا رکورد insert بشه) از dl استفاده نکنید

معمولاً در سازمان‌ها مخلوطی از سرورها با برندهای مختلف رو استفاده می‌کنن مثلاً برای core banking‌ از HP-UX و ماشین‌های IBM و برای سیستم مالی از سرورهای dl و لینوکس استفاده می‌کنن

یادتون باشه برای DBA فرقی نمیکنه نوع سیستم‌عامل چیه و کامل بلد بودن لینوکس برای کار با همه سیستم‌عامل‌ها کفایت میکنه

هارد دیسک

هر هاردی یک صفحه دیسک داره که بهش می‌گیم plate و به خود اون دیسک میگن platter پس ممکنه یک هارد چندین platter داشته باشه

تقسیم‌بندی بالا که به صورت sector و track است بیشتر intel بیسه ولی توی IBM تقسیم‌بندی‌ها عوض میشه و به صورت بلاک/بلاک هستش

به هر قطاع یک سکتور گفته میشه و تمام سکتورها باهم سایزشون یکیه اونهایی که به مرکز نزدیکتراند تراکم بیشتری دارند و اونهایی که به لبه نزدیکتراند تراکم کمتری دارند

همچنین سرعت خوندن اطلاعات در مرکز سریعتره چون چرخش دیسک سریعتره

مروری اجمالی بر سخت‌افزاری‌های مورد نیاز کلاستر - قسمت اول

دریافت اسلایدها
حجم: 11.7 مگابایت

 

تو این پست میخوایم یک مرور اجمالی بر سخت‌افزاری‌هایی که برای راه اندازی کلاستر نیاز هست داشته باشیم

اینا رو حتما به عنوان یک DBA باید بدونید حتی باید به شرکت یا سازمان کمک کنید و LOM تهیه کنید که تجهیزات رو خریداری کنه

بعد از سخت‌افزار شما باید توپولوژی شبکه‌ی کلاستر رو هم بدونید برای کار عملی حتما لازمه که اینها رو بدونید

ما مدلهای مختلف سرور داریم

به سرورهای زیر ml server میگن که به صورت tower ای هستن

مقدمه‌ای بر High Availability و Oracle Active Data Gurd

تغییر شرکتها و وابستگی روز افزون آنها به راه‌کارهای فناوری اطلاعات

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

نیاز به دسترسی پایدار و سریع

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

افزایش حجم اطلاعات به مرور زمان و اهمیت نگهداری آنها

مورد دومی که موقع پیاده‌سازی راهکارهای فناوری اطلاعات باهاش مواجه هستیم افزایش روز افزون اطلاعات است. اطلاعاتی که حالا سرمایه شرکت‌ها است و اهمیت نگهداری اونها بسیار مهم و قابل توجه است. پس راهکارهای نگهداری اطلاعات روز به روز افزایش پیدا می‌کنند. اما در این نوشته من راهکارهایی که شرکت اوراکل ارائه میده رو بهتون مغرفی می‌کنم ولی قبل از اون بریم سراغ اهمیت حداکثر پایداری

اهمیت حداکثر پایداری

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

هزینه‌های مستقیم: از دست دادن بهره‌وری و درآمد
هزینه‌های غیر مستقیم: لطمه زدن به روابط ذینفعان و مشتریان سازمانی، تبلغات بد و بروز شکایت از سازمان به سازمانهای نظارتی و بالادستی

معمولاً افرادی که سن بالاتری دارند در بعضی مواقع به راهکارهای فناوری اطلاعات اعتراض می‌کنند و این به دلیل اینه که به درستی راهکارهای فناوری‌اطلاعات پیاده‌سازی نشده است.

نصب و راه‌اندازی Oracle Database 12C RAC در ویندوز سرور ۲۰۱۲ با استفاده از VirtualBox

این نوشته درباره چگونگی نصب و پیکربندی Oracle Database 12C RAC در ویندوز سرور ۲۰۱۲ ورژن Standard با استفاده از VirtualBox و بدون فضای ذخیره‌سازی مشترک اضافی به صورت یک پیکربندی کامل است.

مقدمه

یکی از بزرگترین مشکلات به هنگام آزمایش محیط‌های RAC، نیاز آنها به فضای ذخیره‌سازی مشترک است. در یک محیط عملی، فضای ذخیره‌سازی مشترک معمولاً توسط یک دستگاه پیشرفته‌ی NAS یا SAN تامین می‌شود، اما اگر قصد شما تجربه‌ی نصب و استفاده از RAC باشد، هر دوی این گزینه‌ها بسیار بیشتر از آن‌چه باید برای شما خرج برمی‌دارند. راهکار ارزان‌تر، استفاده از یک دیسک فایروایر (FireWire) متصل است تا امکان دسترسی، دیسک‌(های) یکسان برای ماشین‌ها فراهم شود. هر چند که این راهکار هم به پول احتیاج دارد و نیازمند حداقل ۲ سرور است. راهکار سوم، استفاده از مجازی‌سازی برای شبیه‌سازی فضای ذخیره‌سازی مشترک است.

با استفاده از VirtualBox می‌توان چندین ماشین‌مجازی (VM) را بر روی یک سرور اجرا کرد و اجرای هر دو گروه RAC بر روی یک ماشین را ممکن می‌سازد. به علاوه چنین‌کاری شما را در قادر خواهد ساخت دیسک‌های مجازی مشترک راه‌اندازی کنید و بر مشکلات مربوط بر گرانی فضاهای ذخیره‌سازی مشترک فائق بیابید.