یادآوری

رابطه میان user و owner و schema؟

در حقیقت owner همان schema است، schema هم همان user است، یوزر وقتی مالک چیزی است به آن schema یا owner گفته می‌شود.

نکته: در sqlserver یوزر و schema از همدیگه جدان و ما schema جدا بغیر از یوزر هم داریم که به یوزر کاری نداره. در حقیقت دیتابیس یه نوع schema است.

بخش‌بندی DataBase

هر بانک اطلاعاتی شامل دو ساختار فیزیکی و منطقی است. ساختار فیزیکی همان فایل هایی هستند که بر روی هارد دیسک ذخیره می‌شوند (DataBase)، ساختار منطقی نیز دسترسی کاربران را به ساختار فیزیکی مقدور می سازد (DataBase Instance).

در حقیقت اطلاعات در قسمت Physical ذخیره میشه ولی تا لایه Logical بالا نباشه شما از لایه Phusical نمی‌تونید استفاده کنید. واکشی و ریختن اطلاعات از لایه یا بر لایه Phusical نیازمند بالا بودن بایه Logical است.

اگه بخوایم خیلی ساده بیان کنیم لایه Loical روی CPU و RAM شماست و لایه Physical روی هارد دیسک شماست.

برای اینکه بخوایم به هارد دسترسی داشته باشیم حتماً باید از CPU, RAM استفاده کنیم تا بتونیم یه پردازشی رو استارت کنیم.

نکته:در زمانهایی اگر بیان کردیم instance بالاست یا پایینه منظورمون لایه Logical است.

همچنین در نکاهی کلی اگر instance پایین باشه شما نمی‌تونید با دیتابیس در ارتباط باشید حتی اگه لایه Physical وجود داشته باشه.

ساختار فیزیکی DataBase

در حقیقت ساختار فیزیکی DataBase از سه جز اصلی تشکیل شده است:

  • Data Files
  • Redo Log Files
  • Controll Files

Data Files

این فایلها در لایه Physical قرار دارند و اطلاعات جداول ما را ذخیره می‌کنند. DF ها کاملاً قابل لمس و قابل مشاهده‌اند:

ROOT/Oracle/DB/oradata/orcl

فایلهای داخل این مسیر که پسوند DBF دارند، DF های ما هستند. البته باز کردن این فایلها توسط ادیتورهای متن سودی در نمایش اطلاعات درون این فایلها ندارد و هیچ یک از رکوردها قابل نمایش نیست. در حقیقت ما به واسطه لایه Logical به داده‌های خودمون در DF ها دسترسی داریم و به صورت مستقیم قابلیت دسترسی به این فایلها رو نداریم.

همچنین برای پیدا کردن مسیر و نام Data File های اوراکل میتونید از دستور ذیر استفاده کنید:

SELECT * FROM V$DBFILE;

کوچکترین واحد ذخیره سازی اطلاعات در سطح Data File ها Data Block است، زمانی که کاربر اقدام به واکشی اطلاعات می‌کند نمونه بانک اطلاعاتی این بلاک ها را می خواند. اندازه خواندن این بلاک ها به صورت پیش فرض در بانک اطلاعاتی اوراکل 8 کیلو بایت است، این اندازه در سایر بانک های اطلاعاتی و همچنین در بانک اطلاعاتی اوراکل مضربی از 2 می‌باشد.

اندازه 8 کیلوبایت اندازه مناسبی جهت خواندن Data Block است. اما اگر اندازه رکورد های شما در بانک اطلاعاتی بزرگ است اندازه خواندن Data Block باید افزایش پیدا کند و اگر اندازه رکورد های شما کوچک است اندازه Data Block باید کاهش پیدا نماید.

به مجموعه چند Data Block پشت سر هم Extents گویند.

به مجموعه Extents ها Segment گویند.

Segment ها در اصل همان موجودیت‌هایی هستند که در هنگام ایجاد به فضا نیاز دارند، همانند جدول‌ها، دقت داشته باشید که یک جدول می‌تواند بر روی یک یا چند Data File ذخیره شده باشد و هر Data File نیز می تواند اطلاعات چند جدول را در خود ذخیره‌سازی کند.

Data File ها در بانک اطلاعاتی به صورت مستقیم از طریق کاربر مورد استفاده قرار نمی‌گیرند و حتما باید از طریق یک موجودیت منطقی بنام TableSpace مورد استفاده قرار گیرند. هر Data File متعلق به یک TableSpace است.

در Data File ها دو واژه اساسی دیگر نیز وجود دارد:

PCTFREE: فضای خالی بین Data Block ها را PCTFREE می‌گویند. این فضا برای داده هایی در نظر گرفته شده که مقدار آنها NULL است و در آینده مقدار این داده ها تغیر خواهد کرد. این فضا می تواند متغیر باشد، میزان 10% حجم Data Block عدد مناسبی است که می توان به این فضا اختصاص داده شود. در صورتی که این فضا بیشتر در نظر گرفته شود باعث اتلاف فضای دیسک سخت خواهد شد. 10% میزان فضای پیش فرض بانک اطلاعاتی اوراکل برای این قسمت است.


PCTUSED: فضایی است که رکورد ها برای درج به آن نیاز دارند. به طور پیش فرض این فضا در بانک اطلاعاتی اوراکل 20% حجم Data Block است. این بدان معناست که اگر رکوردی بخواهد بر روی بلاک یک Data File درج شود باید 80% از بلاک‌های آن خالی باشد و اگر خالی نباشد بانک اطلاعاتی بلاک جدیدی جهت درج اطلاعات رکورد برای آن در نظر خواهد گرفت.

Controll Files

معمولاً هر بانک‌اطلاعاتی یک CTL داره وظیفه CTL نگه‌داری مسیر ذخیره‌سازی DF ها بر روی هارد دیسک است. در حقیقت instance اوراکل با خوندن از روی این فایل به مسیر DF ها بر روی مدیاهای ذخیره‌سازی مورد استفاده پی می‌برد.

نکته: DF ها می‌تونن تو جاهای مختلف سیستم تو درایوها، پارتیشن‌ها و فولدرهای مختلف نگه‌داری بشن و فقط مسیرشون در CTL برای instance اوراکل وجود داشته باشه.

نکته: تعداد DF ها ربطی به تعداد دیتابیس‌های موجود بر روی بانک‌اطلاعاتی نداره. ممکنه 20 DF برای یک دیتابیس باشه. در حقیقت یک DF میتونه اطلاعات چندین table رو تو خودش ذخیره کنه یک table هم میتونه رو چندتا DF بشینه. البته فیلد رو فقط با partitioning میتونیم جداسازی رو اعمال کنیم.

با استفاده از CTL میشه storage distributed را در اوراکل انجام داد حتی به طوری که DF ها در سرورهای مختلف به صورت جدا باشند.

نکته: ما ۲ نوع distributed تو اوراکل داریم:

  • storage
  • process

که process distributed توسط مفهومی به اسم (RAC(Real Application Cluster در اوراکل انجام می‌گیرد. (به طور خلاصه این مفهوم به بالا آوردن چند instance بانک‌اطلاعاتی اشاره دارد)

نکته: در حقیقت instance بانک‌اطلاعاتی از DFهای موجود در CTLها استفاده می‌کند و ما به شکل مستقیم دسترسی نداریم پس وقتی instance به DFها دسترسی پیدا می‌کند و data ها را cash می‌کند عملاً سرعت خواندن از دیسک‌ها تاثیر زیادی بر سرعت بانک ندارد.

Redo Log Files

شبیه به محفظه Temp عمل می‌کنه، در بانک اطلاعاتی اوراکل قبل از ورود اطلاعات به Data File ها اطلاعات به صورت موقت در Redo Log File ها ذخیره می‌شود. دقت کنید در بعضی از موارد اطلاعات ممکن است به دلایل مختلف در Data File ها ذخیره نگردند در این شرایط می‌توان از Redo Log File ها جهت استخراج این داده‌ها استفاده کرد.

بیشتر بدانید: شما وقتی داده‌ای را درون جدولی ذخیره می‌کنید در اصل داده‌ها قراره تو Data File ذخیره شوند ولی این اتفاق به طور مستقیم نمی‌افته. وقتی شما در instance اوراکل می‌گید که insert ای انجام شود اطلاعات اول رو Redo ها میشینه و بعدش ۲ حالت پیش میاد یا شما RollBack می‌کنید یا commit می‌کنید، این یعنی شما یا تایید می‌کنید اطلاعات رو Data File بشینه یا تایید نمی‌کنید اگر تایید نکنید اطلاعات دیگه رو Data File نمیشینه ولی اثرات خودش رو روی Redo می‌ذاره.

چرا وجود Redo لازمه: به دلیل اینکه هزینه (CPU) نوشتن اطلاعات بر روی DataFile ها بسیار زیاد است، چون DataFile ها دائماً باز و بسته میشن ولی Redo ها همیشه باز هستن به همین علت سرعت خواندن و نوشتن بر روی Redo ها بسیار بالا است چون به طور دائم بر روی RAM قرار دارند. مثل اینکه یک Runtime buffer داشته باشید چون همیشه این buffer در حال استفاده است و بسته نمیشه.

نکته: تمام اطلاعات ذخیره شده بر روی Redo به صورت باینری است.

نکته: به درج اطلاعات Transaction یا تراکنش گفته میشه، تراکنش ۲ حالت ممکنه براش پیش بیاد یا RollBack میشه یا Commit

نکته: ممکنه یه تراکنش از طرف ما RollBack نشه و خود RDBMS اونو RollBack کنه به عنوان مثال: وقتی که DataFile ها پر بشن و از حجم تعیین شده توسط شما اطلاعات عبور کنه و شما بخواین یه تراکنش انجام بدید در این حالت به طور خودکار تراکنش RollBack میشه. همچنین در صورتی که تراکنش RollBack بشه فقط اثرات خودش رو توی Redo میذاره ولی اگه تراکنش Commit بشه اثرات خودش رو هم روی Redo و هم روی DataFile میذاره.

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

به اینکار Switch Log گفته میشه. برای جلوگیری از این امر می توان بانک اطلاعاتی را در مد ArchiveLog (آرشیو) قرار داد، در این مد اوراکل از اطلاعات Redo Log File ها کپی برداری کرده و باعث می‌شود تا اطلاعات Redo Log File ها از بین نروند. (بعد از پر شدن هر Redo و موقع SwitchLog از Redo قبلی کپی میگیره)

نکته: به طور پیش‌فرض حجم هر Redo در بانک‌اطلاعاتی اوراکل 50MB تعیین شده، ولی قابل تغییر است.

Redoها اطلاعات مهمی را درون خود نگهداری می‌کنند این اطلاعات عبارتند از:

  • تصویر داده‌ها قبل از اجرای تراکنش
  • تصویر داده‌ها بعد از اجرای تراکنش

در واقع کاملترین قسمت اطلاعات در Redo ها ذخیره می‌شود. (شامل همه اطلاعات مث: تصویر رکورد قبل از تراکنش بعد از تراکنش، تاریخ، xid و ...)

برای  Switch کردن بر روی Redo Log File بعدی به صورت دستی‌می توان از دستور ذیر در محیط SQLPLUS استفاده کرد:

ALTER SYSTEM SWICH LOGFILE;

برای بردن بانک اطلاعاتی در مد ARCHIVELOG می‌توان از دستور ذیل استفاده کرد:

ALTER DATABASE ARCHIVELOG;

و برای بردن به مد NOARCHIVELOG از دستور زیر می‌توان استفاده کرد:

ALTER DATABASE NOARCHIVELOG;

برای اطلاع از حالت جاری بانک اطلاعاتی وضعیت NoArchiveLog و یا ArchiveLog میتوانید از دستور ذیر استفاده نمایید.

SELECT LOG_MODE FROM V$DATABASE;

نکته: Redo ها به طرز بسیار وحشتناکی بعد از مدتی سنگین می‌شوند.

نکته: در اوراکل اگه دیتابیستون تو مد آرشیو باشه و شما DataFile هاتون رو از دست بدید شما اطلاعاتتون رو از طریق Redo ها خواهید داشت ولی یک کار هزینه بر است و بهتره همیشه بک‌آپ داشته باشیم.

نکته: از رو تاریخ Redo ها میشه در مد آرشیو میشه تشخیص داد هر Redo چه اطلاعاتی رو درون خودش نگه داشته.

نکته: اوراکل در مد آرشیو کپی‌ها رو در مسیری که موقع نصب مشخص می‌کنید ذخیره می‌کنه.

بیشتر بدانیم: وقتی Database بدون DataFile قرار است کار کند باید بانک‌اطلاعاتی را حتماً بدون DataFile راه‌اندازی کنیم(نیاز به بالا بودن instance صروری است) تا بتوان دیتابیس را ریکاوری کرد.

نکته: تا وقتی اطلاعات به طور صحیح در DataFile موجود نباشد دسترسی به آنها بسیار سخت است.

نکته: فقط log خود دیتابیس بر روی Redo ها موجوده و log بانک‌اطلاعاتی (RDBMS) در اینجا نیست. به عنوان مثال وقتی حمله‌ای به پورت بانک‌اطلاعاتی انجام می‌شود در Redo ها نمی‌توان دنبال log آن گشت.