مشاوره و پشتیبانی #پایگاه داده #هوش تجاری

۳ مطلب با موضوع «پایگاه‌داده :: Oracle Backup and Recovery» ثبت شده است

عوض کردن DB_NAME دیتابیس با استفاده از NID

یکی از مشکلاتی که ممکنه براتون پیش بیاد اینه که بعد از ساخت دیتابیس جدید بخواین به هر علتی DB_NAME رو به مقداری دیگه تغییر بدید

درسته که تغییر DBID با nid، اثرات غیرقابل برگشتی روی توانایی‌های بک‌آپ و ریکاوری داره، اما تغییر DB_NAME دیتابیس به‌طور چشمگیری پیامدهای کمتری داره، چون:

  1. بک‌آپ‌هایی که قبلاً گرفته شده‌اند را بی‌اعتبار نمی‌کنه
  2. آرشیولاگ‌هایی که قبلاً ساخته شده‌اند را بی‌اعتبار نمی‌کنه
  3. به open کردن پایگاه داده به وسیله‌ی ریست‌لاگ نیازی نداره

خب بیایید db_name پایگاه داده را بدون تغییر dbid دیتابیس تغییر بدیم. (نکته: در هر حال باید حواستان به اثرات احتمالی هم باشه) 

SQL> shutdown immediate;
Database dismounted.
ORACLE instance shut down.

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

بازیابی دیتافایل با آرشیولاگ

فرض کنید دیتافایلی که جدیدا به بانک اضافه شده بنا به دلایلی از بین رفته باشد در این صورت اگر آرشیوها از زمان ایجاد دیتافایل موجود باشند، این امکان وجود دارد که این دیتافایل را بازیابی کرد.

البته همانطور که گفته شد، این کار شرط بسیار سختی دارد:

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

 

در ادامه سناریویی را در همین موضوع شاهد خواهیم بود.

SQL> archive log list;

Database log mode              Archive Mode

SQL> alter tablespace USEF_TBS add datafile '/acfs/test2.dbf' size 10m;

با دستورات زیر جدول جدیدی را که از دیتافایل جدید فضا می گیرد، اضافه می کنیم تا بعد از بازیابی دیتافایل، بررسی کنیم که اطلاعاتی را از دست ندادیم.

 

SQL> create table usef_tbl1  tablespace usef_tbs as select * from dba_tables where 1=2;

SQL>  alter  table usef_tbl1 ALLOCATE EXTENT(DATAFILE '/acfs/test2.dbf'  size 5m);
Table altered.

SQL> insert into usef_tbl1 select * from dba_tables;
2323 rows created.

SQL> commit;

SQL> select count(*) from usef_tbl1;
      2323

در این مرحله دیتافایل را حذف می کنیم و بانک را استارات مجدد می کنیم.

rm –rf   /acfs/test2.dbf

SQL> startup
ORACLE instance started.
Total System Global Area 8351150080 bytes
Fixed Size                  2701528 bytes
Variable Size            7348422440 bytes
Database Buffers          989855744 bytes
Redo Buffers               10170368 bytes
Database mounted.

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/acfs/test2.dbf' 

SQL> alter database datafile  '/acfs/test2.dbf'  offline;
Database altered.

SQL> alter database open;
Database altered.

همانطور که دستور زیر نشان می دهد، جدول ایجاد شده قابل دسترسی نیست.

SQL> select count(*) from usef_tbl1;
ERROR at line 1:
ORA-00376: file 6 cannot be read at this time
ORA-01110: data file 6: ORA-01110: data file 6: '/acfs/test2.dbf' 

SQL> alter database create datafile '/acfs/test2.dbf'  ;
Database altered.

با دستور زیر بازیابی انجام می شود:

SQL> recover datafile  '/acfs/test2.dbf';
Media recovery complete.

SQL> alter database datafile  '/acfs/test2.dbf' ONLINE;
Database altered.
SQL> select count(*) from usef_tbl1;
      2323
۲۵ اسفند ۹۴ ، ۱۱:۰۱ ۰ نظر
مهدی غفاری

بک‌آپ گیری - قسمت اول

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

این قسمت شروع مقدماتی کارکردن با RMAN هستش که چجوری به محیط خط فرمان RMAN و پنجره EM RMAN متصل بشیم و بتونیم فرمان‌های بک‌آپ‌گیری رو صادر کنیم و بتونیم با محیطش کارکنیم. محیط EM محیط خیلی ساده‌ای است برای کارکردن ولی تو این محیط شما با CONSEPTهای بک‌آپ آشنا نمی‌شید و درکشون نمی‌کنید چون کاملاً گرافیکیه همچنین مشکل TIME ZONE تهران رو داره که توسط محیط EM ساپورت نمیشه

نکته:‌ تو این سری از نوشته‌ها بک‌آپ گیری روی معماری filesystem رو بررسی میکنیم و با معماری ASM کار نداریم

یکی از مهمترین وظایف ادمین‌های دیتابیس تعیین استراتژی بک‌آپ‌ه و در حقیقیت می‌توان در ۵ لایه ادمینی دیتابیس را دسته‌بندی کرد: backupman, storageman, securityman, performanceman, clusterman و هر کدوم از اینها نیاز به یه تیم و تخصص بالا داره

تعیین استراتژی دست ادمین دیتابیسه و شما به عنوان ادمین دیتابیس باید تعیین کنید که کدوم استراتژی بیشترین کارایی رو در سازمانتون داره

استراتژی اول:‌ بک‌آپ به صورت Backupset و از طریق Implemental Backupset (بک‌آپ افزایشی) در ۲ لول (لول ۰ و ۱) گفته شده که بتونه بهینه‌ترین نوع فضا رو استفاده کنه

 

نیازسنجی بک‌آپ

برای بک‌آپ نیاز داریم که دیتابیس‌ها رو به archive mode ببریم بحث آرشیو کردن برای بک‌آپ نیازه

  • فعال‌سازی حالت force logging (دیتابیس هر آنچه داخلش به وقوع می‌پیونده، تمام فرآیندهای نوشتن/ خواندن/ بروزشدن/ پاک‌شدن) با فعالسازی تمام این فعالیت‌ها لاگ میشه و از redolog عبور میکنه | ما این امکان رو داریم که فرآیندها رو در دیتابیسمون از redolog عبور ندیم و ارزشش برای ما افزایش کارایی است. مثلاً ‌داریم یک insert خیلی طولانی می‌زنیم و فرصت زیادی هم نداریم پس لاگ کردن رو برمیداریم و از redolog عبور نمیکنه

خطر این اتفاق برای ما اینه که اگه فراموش کردیم و بک‌آپ‌امون رو گرفتیم اون بخش‌هایی از دیتا که عملیات غیر 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 متادیتاهای اوراکل رو خروجی میده

 

 

۲۲ اسفند ۹۴ ، ۱۰:۴۸ ۰ نظر
مهدی غفاری