س: آیا ساختار کش ساختاری منسجم است؟
ج: بله - ولی به طور دستی قابلیت ویرایش توسط DBA را ندارد مگر با برنامهنویسی از طریق SQLJ
نکته: با SQLJ حتی میتوان روش رمزنگاری اوراکل را هم عوض کرد.
س: وقتی تعداد دادههای جدول در دیتابیس زیاد باشد آیا موقع کوئری گرفتن تمام این جدول به یکباره کش میشود؟
ج: اگر تعداد دادههای جدول شما خیلی زیاد باشد که امکان کش بصورت یکباره وجود نداشته باشد اوراکل جدول را تکه تکه کش میکند. و در این صورت سیستم کش اوراکل از بیس رفته است. به طور مثال اگه حدول شما بسیار بزرگ باشد و رم کافی نداشته باشید اوراکل تکه تکه جدول رو درون فضای SGA میآورد و روی PGA پردازش را انجام میدهد و اگر به داده مورد نظر خود نرسد تکه فعلی را از فضای SGA بیرونن میبرد و تکه بعدی را وارد فضای SGA میکند تا پردازش آن صورت گیرد.
س: زمانی که اوراکل چند جدول را کش کرده است و برای کش کردن جدول جدید دیگر فضای رمی نداریم چه اتفاقی میافتد؟
ج: اوراکل جدولی را که کمتر بهش ارجاع شده است را از کش بیرون میبرد و جدول جدید را کش میکند.
س: اگر ما ۱۰ میلیون رکورد داشته باشیم و بخوایم روی این ۱۰ میلیون رکورد کوئری بزنیم اوراکل تا چه مقدار توانایی انجام سریع این کوئری رو داره؟
ج: اگر شما ۱۰ میلیون رکورد داشته باشید و بخواین روی این ۱۰ میلیون رکورد کوئری بزنید و RAM کافی نداشته باشیم نه تنها اوراکل خوب عمل نمیکنه بلکه ضعیف هم عمل نمیکنه (این مطلب در مورد تمام دیتابیسها صادقه، چون شما باید محفظه کشات حداقل اندازه result هات باشه)
به خاطر همین موضوع ما از SI به محیط RAC سوییچ میکنیم چون هرچه قدر هم سرور ما قوی باشه جوابگو SGA نیست چون وقتی دیتای ما که تو هارده نزدیک 20exabyte باشه شما هیچ رمی رو نمیتونید روی یک سرور بذارید که فضای SGA بتونه این حجم اطلاعات رو بالا بیاره و کش کنه(البته ۲۰ اگزابایت ما وقتی میاد رو RAM میشه نزدیک ۵ اگزابایت ولی باز ما همچین رمی رو نمیتونیم برای یک سرور در حالت SI پیدا کنیم) برای همین ما ورود پیدا میکنیم به محیط RAC که در این محیط ما دیگر یک فضای SGA نداریم و مجموعهای از کلاسترها رو داریم که مثلاً هر کلاستر ۶۴ گیگ RAM داره(حالا وقتی ما صحبت از ۲۰ اگزابایت میکنیم حتماً نیاز به ۱۰۰۰ کلاستر ۶۴ گیگ RAM داریم که بتونیم از اون کش استفاده کنیم)
س: فضای SGA و PGA چقدر است؟
ج: این فضا موقع نصب توسط DBA از درصدی از مقدار رم شما مشخص میشود. همچنین بعد از نصب در صورت نیاز به تغییر قابل تغییر است.
س: اگر فصای SGA به اندازه حجم جداول نباشد در سرعت بانکاطلاعاتی چه اتفاقی میافتد؟
ج: باعث پایین اومدن سرعت بانکاطلاعاتی میشود.
س: آیا میتوان در دیتابیس دیتاهایی نظیر فایل(عکس، ویدئو و ...) نگهداری کرد؟
ج: اینکار به هیچ عنوان توصیه نمیشود، چون در بهترین حالت باعث OUT OF MEMORY در دیتابیس میشود.
در تجربه ثابت شده این مقدار دیتا در هر رکورد باعث کش بسیار سنگین در اوراکل شده و طبق تجربه این جانب بنده تنها چیزی که در دیتابیس خوابوندم MAP بوده (GIS DIAGRAM-مختصات جغرافیایی و ...) که تازه برای همین موضوع نیز از DATA TYPE مناسب استفاده شده است (پروژه wis international که برای سازمان هواشناسی تعریف شده بود) همچنین حجم تمام این تصاویر را شاید بشه نزدیک ۱۰۰ گیگ تخمین زد و با CLUSTER های سازمان هواشناسی مشکلی ایجاد نمیکرد.
س: اوراکل برای نصب به چه مقدار RAM نیاز دارد؟
ج: خود instance اوراکل بفیر از فضای مورد نیاز SGA و PGA حداقل به ۲ گیگ RAM نیاز دارد.
س: cluster در اوراکل به چه صورت است؟
ج: باید به مفهومی به نام grid در اوراکل رجوع کنیم ولی به طور خلاصه اوراکل یک سرور را به عنوان بخشی از لایه منطقی یک سرور دیگر را بخشی از لایه فیزیکی و به همین ترتیب از هر سرور به عنوان بخشی از بانکاطلاعاتی استفاده میکند.
س: RAC در اوراکل به چه صورت است؟
ج: RAC در اوراکل یعنی بطور مثال ما ۲ تا Instance داریم با یک لایه فیزیکی در حقیقت بحث migration و تداخلات SGA رو محیط RAC حل کرده است.
مدل RAC بر مبنای مدل Grid است.
س: آیا Create a Object در Redo تاثیر دارد و Redo را درگیر میکند؟
ج: در صورتی Create Object در Redo تاثیر دارد که آن Object رفرنس (reference) باشه به یک دیتا (به عنوان مثال name یک جدول باشه رکورد اول جدولی دیگر)
س: تفاوت محیط RAC و Cloud در چیست؟
ج: در محیط RAC نودهای شما ثابت است و کاملاً تعداد کلاسترها و سرورها مشخص است ولی در محیط Cloud تعداد نودها ثابت نیست و به طور مثال میتوان در لحظه نودی را به آن اضافه کرد ولی در محیط RAC بعد از اضافه کردن یک نود باید RAC دوباره کانفیگ شود. ( به طور مثال وقتی در RAC سیستمی را اضافه میکنید باید دیتابیس به مد restrict بره و بعد از اضافه کردن سرور از حالت restrict بیاد بیرون.
س: آیا master node ای برای مدیریت سایر نودها در RAC وجود دارد؟
ج: بله - معمولا gateway اصلی به صورت انتخابی یا از یکی از دیتابیسهای نصب شده بر روی یکی از سرورهای لایه فیزیکی و یا لایه منطقی انتخاب میشود و در حقیقت gateway ما به حالت restric میرود چون ما یک nodeجدید به کلاستر اضافه میکنیم.
س: جدا کردن سرور دیتابیس تا چه قدر ضروری است؟
ج: بسته به اولویتهای پروژه دارد ولی همین قدر که ما دیتابیس را از سمت سرور اپلیکیشنمان جدا کنیم و one node نکردن سرور برای کارهای مختلف اکیداً توصیه میشود.
س: در موقع delete چه اتفاقی در سطح اوراکل میافتد؟
ج: بعد از delete همانند insert اول تغییر روی PGA صورت میگیرد بعد روی Redo یعد از commit از روی دیتافایل پاک میشه بعد تغییرات delete بر روی کش SGA رخ میدهد.
س: آیا حافظه کش به صورت index شده است؟
ج: بله
س: چرا ما distribution رو روی سطح فیزیکی داشته باشیم؟
ج: وقتی حجم دیتابیس بسیار بالا رود به عنوان مثال بشود ۱۰ هگزابایت باید روی لایه فیزیکی distribution کنیم.
س: معماریهای پیشنهادی اوراکل برای بحث ذخیرهسازی اطلاعات چه هستند؟
ج:
- معماری FS یا File System: بدین معنا که شما وقتی دادهای رو داخل اوارکل insert میکنید اوراکل منوط به اینکه دیتافایل روی چه نوع فایلسیستمی نشسته مدل ذخیرهیازی اطلاعات را نیز بر مبنای مدل ذخیرهسازی داده در آن فایلسیتستم میگذارد. یعنی در اصل ذخیرهسازی اطلاعات به سیستمعامل واگذار میشه.
- معماری ASM یا Automatic Storage Management: وفتی توسط این معماری داروی فرمت بشود فقط خود دیتابیس اوراکل قابلیت دسترسی به آن درایو و اطلاعات را دارد و تحت هیچ شرایطی بدون instance اوراکل این اطلاعات قابلیت خوانده شدن ندارند. از لحاط سرعت و عملکرد این فایل سیستم انحصاری بسیار بهتر از باقی فایلسیستمها برای اوراکل کاربرد دارد ولی maintenance دیتابیس در این حالت بسیار سختتر است. در ASM خود اوراکل مدیریت و ذخیرهسازی اطلاعات در هارد را برعهده میگیرد.
س: وظیفه thread بندی در لینوکس به چه صورت در اوراکل پشتیبانی میشود؟
ج: با استفاده از معماریهای dedicated server و shared server در اوراکل شبیهسازی عملیات threadبندی و مدیریت آن توسط اوراکل صورت میگیرد تا فرآیندها از صف اجرا بیرون آیند.
س: چرا ورژنهای مختلف اوراکل برای هر سیتمی به صورت جدا پکیجبندی شدهاند؟
ج: به دلیل اینکه اوراکل در بسیاری از بخشها از کدهای C به صورت native آن سیستمعامل برای دسترسی بیشتر استفاده کرده است.
س: حداقل رم برای نصب اوراکل چقدر است؟
ج: حداقل رم در سیستمی خالی (بدون سرویسها و اپلیکیشنهای اضافی) برای کار با یک دیتابیس ۴ گیگ پیشنهاد میشود.
س: فرق عمده نسخه 12C با 11g در چه مبحثی است؟
ج: 12C معماری Cloud رو پشتیبانی میکند و فرق آن با ورژنها قبل در همین پشتیبانی از محیط cloud است.
س: partitioning را به طور خلاطه توضیح دهید؟
ج: یکی از کاربردهای partitioning بحث تکهتکه کردن table ها هست که به عنوان مثال میتوان هر table را به ۳ قسمت تقسیم کرد و هر datafile در یک آدرس ذخیرهسازی شود.
س: آیا اوراکل فقط به عنوان یک RDBMS یا ORDBMS شناخته میشه؟ آیا امکانات بیشتری هم در اختیار میگذارد؟
ج: بله - بله به عنوان مثال اوراکل ابزارهای خوبی برای بحث امنیت، مدیریت، data mining، warehouse و ... است.
س: آیا اوراکل دارای ابزارهایی برای tuning به صورت داخلی است؟
ج: خیر - اوراکل فقط دارای ابزارهای optimizing است که به صورت پیشنهاداتی برای کارایی بهتر عمل میکنند و عمل tuning را به طور خودکار انجام نمیدهند. به عنوان مثال: یک دستور sql به آن میدهید و تاریخچه و دیاگرامهای مرتبط به آن را مشاهده میکنید تا بعداً با تحلیل درست دست به اقدام برای tuning دیتابیس بزنید.
س: آیا شرکت اوراکل جایگزینی برای ابزارهای Enterprise مثل: SharePoint، Microsoft Project Server، Microsoft Outlook، Microsoft InfoPath به صورت Integrate با دیتابیس خود دارد؟
ج: بله - Orcale ERP، Oracle Portal، ... برای دیدن یک لیست از محصولات اوراکل میتواندی به این لینک از ویکپدیا مراجعه کنید.
س: در مورد Oracle Data Guard توضیح مختصری بیان کنید؟
ج: این تکنولوژی یکی از روشهایی است که ما میتونیم سریعاً با استفاده از اون از قطعیهای پیشبینی نشده جلوگیری کنیم.
در حقیقت به مجموعهی سرور primary و سرور standby و ارتباط بین این ۲ میگن تکنولوژی Data Guard که یک دیتابیس اصلی داره که تراکنشهای کاربران در آن انجام میشه و یک یا چند دیتابیس standby که اطلاعات با دیتابیس اصلی sync میشه. (sync میتونه حالتهای مختلفی رو در بر بگیره)
س: تفاوت Active Data Guard با Data Guard در چیست؟
ج: در تکنولوژی Oracle Data Guard سرور standby تا زمانی که سرور primary باشه عملاً استفادهای نمیشد و فقط sync اطلاعات در آن انجام میگرفت و همیشه در وضعیت Mount بود ولی از ورژن 11g به بعد با اعمال Realtime Apply میتونید وضعیت اوراکل رو روی open بذارید و از اون گزارش بگیرید و یا با RMAN از سرورها بکآپ بگیرید (از طریق سرور stanby) و یا میتونید سرور stanby رو روی وضعیت logical بذارید و بعد روی اون index تعریف کنید و ساختار فیزیکی متفاوتی از سرور primary در stanby ها داشته باشید.
س: Data Guard Broker چیست؟
ج: Data Guard Broker یک چارچوب میدیریتی توزیع شده است که ایجاد، نگهداری و نظارت بر تنظیمات Data Guard رو بر عهده داره.
س: در مورد cloud بیشتر توضیح دهید؟
ج: به عنوان مثال ما ۳ دیتابیس برای سازمانهای مختلف در مکانهای مختلف با دیتاهای مختلف داریم، یکی را به عنوان دیتابیس container انتخاب میکنیم و به این ترتیب center gateway ما همون دیتابیس container امون هست الباقی دیتابیسها دیتابیسهای plugable هستند.
در معماری RAC اگر بار روی یکی از دیتابیسها در سازمانی زیاد شود اولین کسی که از وجود بار باخبر میشود دیتابیس container است بدین ترتیب دیتابیس container یا تحمل بار رو داره یا نداره اگر نداشته باشد بار رو به یک نود دیگه assign میکنه
در معماری Cloud نودهای ما روز به روز میتوانند زیاد شوند و به این ترتیب ما نیازی به تغییر کانفیگها نداریم فقط باید range کلود باهم یکی و تو یک شبکه باشیم و دیتابیسهای دیگه به عنوان دیتابیس plugable برای دیتابیس container ما معرفی شوند.
(دیتابیسهای plugable در حقیقت نودهای ما هستند که به صورت runtime میتونند به شبکه اضافه بشوند و بیرون بیایند.)
س: فرق RAC با Cloud؟
ج: وقتی به معماری Grid در RAC ورود پیدا میکنید center gateway ما اطلاعات نودهای دیگه رو داره(در center gateway آیپی نودهای دیگه رو میدیم و اگر بخوایم نود کم و زیاد کنیم instance center gateway باید پایین و بالا بیاد) ولی در حالت کلود center gateway ما از اطلاعات نودهای دیگه باخبر نیست و در حقیقت بقیه خودشون رو با center gateway تطبیق میدهند.
به عنوان توضیحاتی بیشتر در RAC کل نودهای اتصالی با نود اصلی ۱ دیتابیس محسوب میشوند (به عنوان مثال ۲ تا برای لایه منطقی و یکی برای لایه فیزیکی)
ولی در cloud هر کدوم از نودها یک دیتابیس جدا هستند.
نکته: در این محیطها حتما باید یک container وجود داشته باشد.
نکته: container یا plugable بودن دیتابیس در موقع نصب مشخص میگردد. همچنین container ذاتاً خودش یک plugable هم هست.
نکته: در سقف بار بالا در کلود ممکن است تقسیم بار نیز صورت گیرد و همه بار به یک نود برای پردازش سپرده نشود و همه نودها در امر پردازش شریک باشند و قسمتی را پردازش کنند.
نکته: سرور container معمولاً قویترین سرور بین نودها در این معماریها است.
س: تجربه کلود؟ (۳ تا نود، هر نود ۳۲ گیگ رم)
ج: دیتابیسی که تو بار تراکنش داره از بین میره رو وقتی به کلود وصل میکنید بار آن به سبب اتصال به نودهای دیگه به سرعت و به شدت پایین میآید به قدری که فشار از دیتابیس به طور یکنواخت بین نودها تقسیم میشود.
س: آیا در RAC نیازی به SAN هم هست؟
ج: بسته به نیاز بله
س: اگر سرور container در کلود به هر دلیلی پایین آید چه رخدادی رخ میدهد؟
ج: بار در دیتابیس دیگر تقسیم نمیشود و سرورهای plugable به کار خودشون ادامه میدهند فقط دیگر در شبکه نیستند تا در مواقع لزوم از منابع هم استفاده کنند.
در این حالت دیتابیسها در مد (Single Instance (SI قرار میگیرند.
س: آیا دیتابیس container به صورت center gateway process کلی در کلود عمل میکند؟
ج: خیر - دیتابیس container در کلود به صورت center gateway division process عمل میکند. یعنی center gateway برای برش زدن پردازش در مواقع لزوم
س: وقتی در RAC بعضی نودها از کار بیفتهاند با توجه به توصیف اینکه همه نودها باهم یک دیتابیس را تشکیل دادهاند، آیا دیتابیس از کار میافتد؟
ج: بستگی دارد چه نودهایی از کار بیفتهاند، اگر نودهای instance ای از کار بیفتهاند مشکلی به وجود نمیاد (لایه منطقی) ولی اگه نودهای لایه فیزیکی از کار بیفتهاند دیتابیس پایین میآید.
س: چرا همچنان با در اختیار داشتن تکنولوژی و راهکار Cloud همچنان از RAC استفاده میشود؟
ج: توجه داشته باشید تکنولوژی کلود با اومدن ورژن 12C معرفی شد پس برای استفاده از کلود باید یه این ورژن کوچ کرد، همچنین در خیلی از مواقع و معماریها راهکار کلود به کار نمیآید (مثلا: ۲ سرور داریم میخوایم یک دیتابیس روی این ۲ سرور سوار کنیم، در این حالت تنها میتوان از RAC استفاده کرد.)
س: Tablespace چیست؟
ج: در حقیقت یک فضای برای جدولهاست (اطلاعات جدولها توی Tablespace ها میشینه.) در اصل Tablespace مارو به DataFile ها Map (ارجاع) میدهند. (میتونیم به ازای چند جدول یک Tablespace داشته باشیم یا به ازای هر جدول یک Tablespace داشته باشیم.)
س: آیا اوراکل داری فایل کانفیگ عمومی است؟
ج: بله - فایل INIT.ORA