۴ مطلب با کلمه‌ی کلیدی «کلاستر اوراکل» ثبت شده است

دستورات کاربردی ابزار Srvctl

Srvctl یک ابزار شناخته شده برای add، remove، relocate و مدیریت سرویسهای crs مختلف یا کامپوننت های RAC است.

1. STOP DATABASE

SYNTAX – srvctl stop database -d db_name [-o stop_options] where stop_options is normal/immediate(default)/transactional/abort

e.g

srvctl stop database -d PRODB -o normal
srvctl stop database -d PRODB -o immediate
srvctl stop database -d PRODB -o transactional
srvctl stop database -d PRODB -o abort

2. START DATABASE
SYNTAX – srvctl start database -d db_name [-o start_options] where start_option is nomount/mount/open(default)

e.g

srvctl start database -d PRODB -o nomount
srvctl start database -d PRODB -o mount
srvctl start database -d PRODB -o open

ادامه مطلب...
۰۲ خرداد ۰۱ ، ۱۶:۰۶ ۰ نظر
مهدی غفاری

داستانهای واقعی: افزایش فضای 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 نشده بودند.

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

۱۷ شهریور ۹۹ ، ۱۹:۵۴ ۲ نظر
مهدی غفاری

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

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

همیشه اینو یادتون باشه اگه 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 تقسیم‌بندی‌ها عوض میشه و به صورت بلاک/بلاک هستش

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

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

ادامه مطلب...
۲۰ ارديبهشت ۹۵ ، ۰۹:۵۳ ۳ نظر
مهدی غفاری