برای ساخت این variable باید به شیوه زیر عمل کرد:
اگر بخواهیم فقط یک رکورد در session variable ذخیره بشه، یک variable و یک initialization block درست میکنیم و در initialization block در قسمت کوئری، کوئری زیر رو میزنیم:
select provincecode2 from USER_UNI_COUNT_DIV where user_name=':USER' and flag=0
داشتم فکر می‌کردم که آیا راهی وجود داره که بشه آخرین رکورد از جدول رو بدست آورد. در این مورد مشخص و واضحه که از تعداد رکوردهای موجود در یک جدول بی اطلاع‌ام. فقط می‌خوام کوئری بنویسم که بتونه تمام ستون‌های آخرین رکورد رو بدست بیاره. من سعی کردم از ROWNUM استفاده کنم، اما حدس می‌زنم که شیوه کار اینطور نیست. اگر یک گزارشی ایجاد کنم، می‌خوام که گزارش‌ام بر پایه‌ی کوئری باشه که به سادگی تمام ستون‌های آخرین رکورد رو بدست بیاره.
آیا دستوری وجود داره که بشه باهاش آخرین رکورد از جدول رو بدست آورد؟
با تشکر
حسن
می‌دونی که آخرین رکورد درج شده در جدول میتونه اولین رکورد‌ی باشه که توسط “select * from t” بازگشت داده میشه یا ممکنه صدمی باشه، ممکنه هزارمی باشه، در واقع میتونه هر رکورد‌ای باشد.
یادت باشه رکوردها در هیچ ترتیب خاصی ذخیره و بازگردونی نمیشن.
ولی اگه آخرین رکورد درج شده را می‌خوای، باید یک فیلد timestamp یا sequence ای برای هر رکورد‌ای که درج میشه موقع درج رکورد مشخص کنی اینجوری «آخرین» رکورد رو میتونی داشته باشی یادت باشه این تنها راه است.
یادت باشه تنها راه برای انجام این کار اینه که ستونی داشته باشی که بتونی مرتبش کنی تا «آخرین» رکورد رو پیدا کنی.
ROWID و ROWNUM به دلایل زیر کار نمی‌کنند:
ROWID کار نمیکنه. چون داده‌اش بر پایه‌ی ترکیبی از شماره file/block/slot سرور فعلی است. یادت باشه ما از ROWID ها دوباره استفاده میکنیم، حتی میتونیم تغییرشون بدیم (مثلا با پارتیشن‌بندی جداول). پس ممکنه که Extent شماره‌ی 1 رو در فایل 55 و Extent شماره‌ی 2 رو در فایل 2 داشته باشید. Extent 4 حتی ممکنه در بلاک 555 از فایل 3 باشه، حتی ممکنه Extent 5 در بلاک 2 از فایل 3 باشه. ROWIDها قابل مرتب کردن نیستند.
ROWNUM هم کار نمیکنه چون یک ستون منطقیه(در جدول درج نشده) و با هر SELECT شماره ردیف رکوردهای SELECT مربوط رو برمیگردونه
یک بک‌آپ‌گیری درست و مطمئن باعث میشه که ما یک اطمینان بازیابی داشته باشیم و این اطمینان بازیابی هست که تو سازمانها بیشتر نیاز است. پس بازیابی خیلی اتفاق نمی‌افته و اطمینان به بازیابی خییلی مهمه. شما می‌تونید حتی مانورهاتون رو انجام بدید و ببینید که بازیابی به طور کامل انجام میشه یا نه
این قسمت شروع مقدماتی کارکردن با RMAN هستش که چجوری به محیط خط فرمان RMAN و پنجره EM RMAN متصل بشیم و بتونیم فرمان‌های بک‌آپ‌گیری رو صادر کنیم و بتونیم با محیطش کارکنیم. محیط EM محیط خیلی ساده‌ای است برای کارکردن ولی تو این محیط شما با CONSEPTهای بک‌آپ آشنا نمی‌شید و درکشون نمی‌کنید چون کاملاً گرافیکیه همچنین مشکل TIME ZONE تهران رو داره که توسط محیط EM ساپورت نمیشه
نکته: تو این سری از نوشته‌ها بک‌آپ گیری روی معماری filesystem رو بررسی میکنیم و با معماری ASM کار نداریم
یکی از مهمترین وظایف ادمین‌های دیتابیس تعیین استراتژی بک‌آپ‌ه و در حقیقیت میتوان در ۵ لایه ادمینی دیتابیس را دسته‌بندی کرد: backupman, storageman, securityman, performanceman, clusterman و هر کدوم از اینها نیاز به یه تیم و تخصص بالا داره
تعیین استراتژی دست ادمین دیتابیسه و شما به عنوان ادمین دیتابیس باید تعیین کنید که کدوم استراتژی بیشترین کارایی رو در سازمانتون داره
استراتژی اول
بک‌آپ به صورت Backupset و از طریق Incremental Backupset در ۲ لول (لول ۰ و ۱) توصیه شده که بتونه بهینه‌ترین نوع فضا رو استفاده کنه
نیازسنجی بک‌آپ
برای بک‌آپ نیاز داریم که دیتابیس‌ها رو به archive ببریم بحث آرشیو کردن برای بک‌آپ نیازه
خطر این اتفاق برای ما اینه که اگه فراموش کردیم و بک‌آپ‌امون رو گرفتیم اون بخش‌هایی از دیتا که عملیات غیر loging روش انجام شده قابل خوندن و بازیابی برای ما نخواهد بود و در واقع اصلا دیده نشده. به خاطر همین دیتابیس رو در وضعیت force loging قرار می‌دیم
وقتی دیتابیس در این وضعیت قرار می‌گیره یعنی همه چی به صورت اجباری باید در وضعیت loging قرار بگیره تا هیچ‌چیز از گذر redologها نتونه عبور کنه و هرفرآیند بروزرسانی تو دیتابیس از این گذر عبور کنه
SQL> Alter database force logging
برای تنظیم پایگاه داده در وضعیت ARCHIVE LOG از یوزر sys استفاده میکنیم. برای فهمیدن اینکه دیتابیس ما تو وضعیت آرشیو هست یا نیست از دستور زیذ استفاده میکنیم:
SQL> archive log list
| Archive Mode | Database Log Mode |
| Enabled | Automatic Archival |
| USE_DB_RECOVERY_FILE_DEST | Archive Destination |
| 5161 | Oldest Online Log Sequence |
| 5162 | Next log Sequence To Archive |
| 5163 | Current Log Sequence |
اطلاعاتی که به ما می‌رسه
Database log mode = وضعیت فعال بود لاگ
Automatic archival = وضعیت گرفتن آرشیو به صورت اتوماتیک
Archive destination = یعنی فایلها در فضای پارامتر use_db_recovery_file_dest قرار می‌گیره که همون فضای fra هستش (میشه این مسیر و متغیر رو عوض کرد)
Oldest online log sequence = بحث redo log fileها هستش | شماره قدیمی‌ترین sequence ای که رخ داده
Next log sequence to archive = شماره seq بعدی که رخ میده
Current log sequence = جدیدترین sequnce
اوراکل یه فایلی داره به نام parameter file این فایل برای set کردن پارامترهای شخصی در سیستم است. اوراکل ۲ جور فایل پارامتر داره:
1: system parameter file
2: parameter file
تفاوت بین این ۲ فایل
اوراکل‌های قبلی parameter file فقط بود و شما به صورت آنلاین هیچ تغییری تو سطح پارامترهای سیستمی نمی‌تونستید بدید (نسخه ۸) از نسخه ۹ به بعد system parameter file رو معرفی کرد که شما برخی تنظیمات سیستمی رو می‌تونید به صورت آنلاین انجام بدید (این بهتون کمک میکنه availibility کارتون بالا بره) مثال:
lOG_ARCHIVE_DEST_1='LOCATION=X:\archive
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=eorg'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_FORMAT=archive_%s_%t.%r
LOG_ARCHIVE_MAX_PROCESSES=9
control_file_record_keep_time = 60
lOG_ARCHIVE_DEST_1 = اگه location ندیم از مسیر پیش‌فرضمون استفاده میکنه
VALID_FOR = برای چه حالتی valid است. در اینجا برای تمام حالات و log fileها تنظیم شده است.
DB_UNIQUE_NAME = برای دیدن نام دیتابیس از show parameter db_unique_name استفاده میکنیم.
LOG_ARCHIVE_DEST_STATE_1 = برای اینکه کل این تنظیمات فعال باشه یا نه
LOG_ARCHIVE_FORMAT = فرمتی که برای فایلها درنظر می‌گیریم، این فرمت میتونه با یه prefix ای شروع بشه s به معنی شماره sequnce ای هستش که از redo log fileها خونده میشه(شماره sequnce الزامی و واجب هستش)، t شماره thread هستش و روی دیتابیس‌های کلاستر معنا پیدا میکنه چون ممکنه چندتا دیتابیس دیتابیس داشته باشید که از یک share drive استفاده کنند، r در حقیقت reset log id هستش(برای جلوگیری از duplicate شدن فرآیندهای recovery هستش چون sequnce ریست میشه و با ریست شدن باعث میشه که فایلها duplicate شه پس یه پارامتر اضافه میکنیم تا تعداد دفعات reset شدن رو داشته باشیم و باعث unique شدن فایلهامون بشه)
نکته: تخصیص sequnce از redo log file انجام میشه، درسته sequnce خود redo log file عوض نمیشه اما sequnce ای که داخل redo log file هست داره تغییر میکنه و حتی اگه شما دیتابیس رو روی mode آرشیو هم نبرید این sequnce عوض میشه و شما همیشه seqهای redo log fileهاتون در حال تغییر است. وقتی که شما ۳ تا redo log file دارید وقتی اولی، دومی، سومی پر میشه دیتابیس باید سوییچ کنه روی اولی پس چه مولفه‌ای برای شناسوندن هستش که باید سوییچ انجام بشه؟ یه seq مسلماً به صورت Internal هستش که روی این درج میشه(این seq توی فایل redo ذخیره نمیشه و هر وقت ما بخواهیم این redo رو جایی ذخیره کنیم این seq خودش رو نشون میده) ما برای حفظ ریکاوری‌مون میایم redo log file ها رو که تغییرات دیتابیس هستند رو نگهداری میکنیم.
نکته: برای این که بفهمیم تو حالت force logging هستیم یا نه با viwe ه v$database میتونیم لیست رو بگیریم و هم میتونیم بزنیم Alter database force logging و وقتی باشه میگه من تو مد لاگ‌گیری هستم. دقت کنید اگر loging فعال نباشه ممکنه برخی از دیتای شما نیاد. (این به وضعیت ادمینی بستگی داره ممکنه داده‌هایی که میخواین restore بشه یا نشه)
نکته: Alter database force logging بر روی performance تاثیر زیادی می‌گذارد. وقتی حجم داده‌ها از 10, 15 T می‌گذره این چیزها خودشون رو نشون میدن حتی فرآیندهای بک‌آپ‌گیری ما تاثیر زیادی بر روی سرعت و کارایی دارد مثلاً یک جدول 50T رو با چه استاتژی بک‌آپ بگیریم و کمتر به مشکل بخوریم
v$ = یک dynamic viwe از data dictionary هستش که از طریق view متادیتاهای اوراکل رو خروجی میده
یسری قواعد جامعیتی در بانک‌اطلاعاتی اوراکل وجود داره که شما می‌تونید از اونها در این بانک استفاده کنید کار این قواعد اینه که شما هرچی خواستید رو نتونید به عنوان داده در بانک وارد کنید.
مثال:
CRAETE TABLE T2(ID NUMBER PRIMARY KEY, NAME VARCHAR2(20));
به چند چیز باید توجه کنیم(چون ID به عنوان PRIMARY KEY) تعریف شده):
INSERT INTO T2(ID, NAME) VALUES(1, 'MAHDI');
همونطور که در زیر می‌بینید با یکسان قرار دادن ID پایگاه داده خطایی به ما برمی‌گرداند:
INSERT INTO T2(ID, NAME) VALUES(1, 'EHSAN');
*
ERROR at line 1:
ORA-00001: unique constraint (MGHAFFARI.SYS_C0010911) violated
حالا ID احسان رو می‌ذاریم ۲ و INSERT رو انجام می‌دیم:
INSERT INTO T2(ID, NAME) VALUES(1, 'EHSAN');
*
ERROR at line 1:
ORA-00001: unique constraint (MGHAFFARI.SYS_C0010911) violated
وحالا می‌خوایم ID رو NULL رد کنیم:
INSERT INTO T2(NAME) VALUES('EHSAN');
*
ERROR at line 1:
ORA-01400: cannot insert NULL into (MGHAFFARI.SYS_C0010911) violated
همونطور که می‌بینید نمی‌تونیم مقدار NULL رد کنیم.
بانک اطلاعاتی برای نگهداری داده‌های مختلف نوع‌های مختلفی از فیلد را به شما ارائه می‌کند:
مثال:
CREATE TABLE T1(ID NUMBER(10,10), NAME VARCHAR2(20));
جهت نگهداری اطلاعات عددی که شامل صفر، اعداد مثبت و منفی می‌شود می‌توانید از نوع Number استفاده کنید. این نوع داده ای حداکثر می تواند 38 رقم مخلوط اعشار و صحیح را در خود نگهداری کند.
ID ما که از جنس NUMBER است، میتونه ۲تا پارامتر بگیره اولین پارامتر یعنی ۱۰ رقم صحیح و دومین پارامتر یعنی ۱۰ رقم اعشاری
نکته: اوراکل حداکثر توانایی نگهداری ۳۲ رقم رو داره
جهت نگهداری اطلاعات رشته‌ای با طول متغییر می‌توانید از نوع VARCHAR2 استفاده کنید.
SIZE در این نوع کاراکتر به صورت رقم در جلوی آن مشخص می‌شود.
همانند VARCHAR2 می‌باشد. و جهت نگهداری متون چینی، ژاپنی، پارسی، عربی و... می‌توانید از این نوع داده استفاده نمایید.
جهت نگهداری اطلاعات رشته‌ای با طول ثابت می‌توانید از نوع CHAR استفاده کنید.
CHAR هم SIZE می‌گیره
همانند CHAR می‌باشد. و جهت نگهداری متون چینی، ژاپنی، پارسی، عربی و ... می‌توانید از این نوع داده استفاده نمایید.
CHAR طول ثابت داره یعنی اگه ما داده‌ای در آن ذخیره کنیم که مثلا ۴ حرف باشه در حالتی که سایز وارده به CHAR رو ۲۰ کاراکتر مشخص کرده‌ایم، ۱۶ کاراکتر برای ما خالی رد میشه و حجمی اضافه‌تر از داده ما را ذخیره می‌کند.
اما در VARCHAR و NVARCHAR سایز ما اگر کمتر از مقدار وراد شده باشد به همون میزان کاراکتر وارده سایز جمع می‌شود.
مثال
معمولاً برای داده جنسیت ما از CHAR استفاده میکنیم، به عنوان مثال Female میشه 0 و Male میشه 1 و 2 هم وضعیت مجهول جنسیت رو برای ما مشخص میکنه، در این مورد به جای استفاده از CHAR میتوان از NUMBER هم استفاده کرد.
نکته: برای زمان‌هایی که می‌خواهیم مقادیر TRUE, FALSE در دیتابیس وارد کنیم استفاده از CHAR توصیه می‌شود.
جهت نگهداری اطلاعات تاریخی می‌توانید از نوع DATE استفاده کنید.
نکته: اوراکل تاریخ شمسی رو پشتیبانی میکنه
جهت نگهداری اطلاعات رشته‌ای طولانی می‌توانید از نوع CLOB استفاده کنید.
همانند CLOB بوده و جهت نگهداری متون چینی، ژاپنی، پارسی، عربی، ... می‌توانیدازاین نوع داده استفاده نمایید.
فایل SPFILEORCL.ORA مخزن خود را از مسیر زیر باز کنید:
$Oracle_home/DataBase/product/11.2.0/dbhome_1/database/SPFILEORCL.ORA
با مقداردهی دوباره متغیرهای این فایل میتوان فضای SGA و PGA را تغییر داد. از اونجایی که این فایل یک فایل باینری است تغییر آن ابزار مناسب آن را می‌خواد که آن را در اختیار نداریم.
نکته: از اونجایی که اسم دیتابیس ما ORCL است این فایل به اسم SPFILEORCL نشان داده شده است.
برای تغییر این فایل از اوراکل خواهش میکنیم بی‌خیال SPFILE بشه و از روی SPFILE برای ما یک PFILE ایجاد کند:
CREATE PFILE FROM SPFILE;
زمانی که این دستور را اجرا میکنیم یک فایل جدید در همان مسیر SPFILE برای ما ساخته می‌شود به نام INITorcl.ORA با بازکردن این فیال با یک ادیتور متن خواهید دید که این فایل دیگر یک فایل باینری نیست. برای تغییر فضای SGA و PGA دنبال ۲ متغیر sga_target, pga_aggregate_target بگردید و آنها را مجدد مقداردهی کنید.
در پایگاه‌داده اوراکل میتوان بانک اطلاعاتی را با وضعیت‌های مختلف راه اندازی کرد. برای اینکار باید با کاربر SYS وارد محیط SQLPLUS شد(تنها کاربری که میتونه این کارو انجام بده چون کاربران دیگه role مربوطه رو ندارند). بانک‌اطلاعاتی برای راه اندازی کامل سه مرحله را پشت سر می گذارد.
نکته: گاهی اوقات به هنگام انجام کارهای مربوط به نگهداری و Recovery بانک اطلاعاتی نمی توان بانک اطلاعاتی را برای دسترسی تمام کاربران باز نمود. به همین دلیل باز نمودن بانک اطلاعاتی در این حالت ضروری است. همچنین از حالت NOMOUNT به هنگام ایجاد بانک اطلاعاتی و ایجاد مجدد Control File ها استفاده می شود.
در صورتی که بانک اطلاعاتی قبلاً در حالت NOMOUNT راه اندازی شده باشد، می توان با استفاده از دستور زیر آن را در حالت MOUNT قرار داد:
SQL> ALTER DATABASE MOUNT;
همچنین با استفاده از دستور زیر می توان مستقیماً بانک اطلاعاتی را در حالت MOUNT راه اندازی نمود:
SQL> STARTUP MOUNT;
معمولاً هنگامی که نیاز به Recovery کامل بانک اطلاعاتی ، تغییر نام Data Fileها، تغییر به حالت Archive Log Mode و غیره می باشد، لازم است تا بانک اطلاعاتی را در حالت MOUNT راه اندازی نمود.
SQL> ALTER DATABASE OPEN;
می توان با استفاده از یکی از دستورات زیر مستقیماً بانک اطلاعاتی را در حالت OPEN راه اندازی نمود:
SQL> STARTUP;
SQL> STARTUP OPEN;
به هنگام باز کردن بانک اطلاعاتی، سرور اوراکل ابتدا تمام Data File ها و Redo Log File ها را باز نموده و سپس چک می کند که حتماً بانک اطلاعاتی در حالت سازگار قرار داشته باشد. اگر بانک اطلاعاتی در حالت سازگار نباشد، در این صورت قبل از باز نمودن بانک اطلاعاتی، فرایندهای پس زمینه عملیات Instance Recovery را به طور اتوماتیک انجام می دهند. اگر علاوه بر Instance Recovery نیاز به Media Recovery نیز باشد، اوراکل اعلام می کند که نیاز به Recovery بانک اطلاعاتی می باشد و تا زمانی که شما عملیات Recovery را انجام ندهید بانک اطلاعاتی را باز نخواهد کرد.
نکته: بعد از اجرای STARTUP اول دیتابیس دیگر اجازه اجرای STARTUP را نمی‌دهد(خطاهای زیر) در این حالت برای ادامه مراحل استارت‌کردن اوراکل از Alter در ابتدای دستورات استفاده کنید.
(ORA-01081: cannot start already-running ORACLE - shut it down first)
(SP2-0734: unknown command beginning "startup op..." - rest of line ignore)
نکته: اگر بخواهیم از مراحل پایینتر به مرحله بالاتر برویم فقط با alter می‌توانیم اینکار را انجام دهیم:
alter database open
نکته: اگر هر کدام از حالت‌های استارت را از لولی بالاتر به طور مستقیم برای روشن کردن دیتابیس به کار بگیریم به طور خودکار لول‌های قبلی نیز اجرا می‌شوند. به عنوان مثال وقتی STARTUP OPEN کنیم دیتابیس به طور کامل اجرا می‌شود.
نکته: نمی‌توان از لول‌های بالاتر به لول‌های قبل مستقیم سوییچ کرد(حتی با ALTER) حتماً باید دیتابیس SHUTDOWN شود بعد از ابتدا به آن لول از START رفت.
هر نمونه برای دریافت در خواست و پاسخ دهی به نیاز کاربران از یک شنونده استفاده می‌کند در اوراکل بعد از ایجاد بانک اطلاعاتی یک شنونده به طور خودکار راه اندازی می‌شود. برای اطلاع از نام این شنونده میتوان از دستور زیر استفاده کرد:
LSNRCTL SHOW CURRENT_LISTENER
برای کسب اطلاعات از وضعیت شنونده جاری میتوان از دستور زیر استفاده کرد:
LSNRCTL STATUS
برای متوقف و یا استارت کردن این شنونده می توان از دو دستور زیر استفاده کرد:
نکته: حتماً توجه داشته باشید که برای stop یا start نمودن شنونده حتماً از طریق شل ادمین سیستم اقدام کنید.
LSNRCTL STOP
LSNRCTL START
جهت نصب بانک‌اطلاعاتی اوراکل گام‌های زیر را دنبال کنید:
بعد از دانلود فایلها از سایت شرکت اوراکل ابتدا آنها را از حالت فشرده خارج کنید. (همچنین می‌توانید از پی‌سی‌دنلود اقدام به دانلود فایلها کنید.)
پس از ورود به پوشه برنامه، بر روی فایل setup.exe راست کلیک کنید و با ادمین آن را اجرا کنید. با اجرای این فایل پنجره‌ای مطابق با تصویر زیر نمایش داده می‌شود. کمی صبر کنید تا وارد مرحله بعدی نصب شوید.
س: آیا ساختار کش ساختاری منسجم است؟
ج: بله - ولی به طور دستی قابلیت ویرایش توسط DBA را ندارد مگر با برنامه‌نویسی از طریق SQLJ
نکته: با SQLJ حتی میتوان روش رمزنگاری اوراکل را هم عوض کرد.
س: وقتی تعداد داده‌های جدول در دیتابیس زیاد باشد آیا موقع کوئری گرفتن تمام این جدول به یکباره کش می‌شود؟
ج: اگر تعداد داده‌های جدول شما خیلی زیاد باشد که امکان کش بصورت یکباره وجود نداشته باشد اوراکل جدول را تکه تکه کش می‌کند. و در این صورت سیستم کش اوراکل از بیس رفته است. به طور مثال اگه حدول شما بسیار بزرگ باشد و رم کافی نداشته باشید اوراکل تکه تکه جدول رو درون فضای SGA می‌آورد و روی PGA پردازش را انجام می‌دهد و اگر به داده مورد نظر خود نرسد تکه فعلی را از فضای SGA بیرونن می‌برد و تکه بعدی را وارد فضای SGA می‌کند تا پردازش آن صورت گیرد.
س: زمانی که اوراکل چند جدول را کش کرده است و برای کش کردن جدول جدید دیگر فضای رمی نداریم چه اتفاقی می‌افتد؟
ج: اوراکل جدولی را که کمتر بهش ارجاع شده است را از کش بیرون می‌برد و جدول جدید را کش می‌کند.
س: اگر ما ۱۰ میلیون رکورد داشته باشیم و بخوایم روی این ۱۰ میلیون رکورد کوئری بزنیم اوراکل تا چه مقدار توانایی انجام سریع این کوئری رو داره؟
ج: اگر شما ۱۰ میلیون رکورد داشته باشید و بخواین روی این ۱۰ میلیون رکورد کوئری بزنید و RAM کافی نداشته باشیم نه تنها اوراکل خوب عمل نمیکنه بلکه ضعیف هم عمل نمیکنه (این مطلب در مورد تمام دیتابیس‌ها صادقه، چون شما باید محفظه کش‌ات حداقل اندازه result هات باشه)
به خاطر همین موضوع ما از SI به محیط RAC سوییچ میکنیم چون هرچه قدر هم سرور ما قوی باشه جوابگو SGA نیست چون وقتی دیتای ما که تو هارده نزدیک 20exabyte باشه شما هیچ رمی رو نمی‌تونید روی یک سرور بذارید که فضای SGA بتونه این حجم اطلاعات رو بالا بیاره و کش کنه(البته ۲۰ اگزابایت ما وقتی میاد رو RAM میشه نزدیک ۵ اگزابایت ولی باز ما همچین رمی رو نمی‌تونیم برای یک سرور در حالت SI پیدا کنیم) برای همین ما ورود پیدا میکنیم به محیط RAC که در این محیط ما دیگر یک فضای SGA نداریم و مجموعه‌ای از کلاسترها رو داریم که مثلاً هر کلاستر ۶۴ گیگ RAM داره(حالا وقتی ما صحبت از ۲۰ اگزابایت میکنیم حتماً نیاز به ۱۰۰۰ کلاستر ۶۴ گیگ RAM داریم که بتونیم از اون کش استفاده کنیم)
س: فضای SGA و PGA چقدر است؟
ج: این فضا موقع نصب توسط DBA از درصدی از مقدار رم شما مشخص می‌شود. همچنین بعد از نصب در صورت نیاز به تغییر قابل تغییر است.