ডাউনটাইম হ্রাস করা এবং ডাটাবেসের প্রাপ্যতা বৃদ্ধি করা অপরিহার্য উদ্দেশ্য যা প্রতিটি ব্যবসা অর্জন করতে চায়। ডাটাবেস অ্যাডমিনিস্ট্রেটর (DBAs) সবসময় নতুন উপায় খুঁজছেন যে কোনো ডেটা ফাইল বা সম্পূর্ণ ডাটাবেস দুর্নীতি ব্যর্থতার ক্ষেত্রে দ্রুত পুনরুদ্ধারের সমাধান প্রদান করার জন্য। সংস্করণ 10g দিয়ে শুরু করে, Oracle® রিকভারি ম্যানেজার (RMAN) IncrementalMerge Backups (IMB) নামে একটি বৈশিষ্ট্য অফার করে, যা পুনরুদ্ধারের সময় কমানোর জন্য একটি সমাধান প্রদান করে, বিশেষ করে খুব বড় ডেটাবেসের জন্য (VLDB)।
পরিচয়
যদি এটি সঠিক বিকল্পগুলির সাথে কনফিগার করা হয়, IMB বৈশিষ্ট্যটি উল্লেখযোগ্যভাবে ডেটাবেস পুনরুদ্ধারের সময় হ্রাস করতে পারে। ব্যাপকভাবে ব্যবহৃত না হলেও, এই বৈশিষ্ট্যটি একটি VLDB-এর জন্য একটি আদর্শ ব্যাকআপ পদ্ধতি। ডেটা ফাইলের ইমেজ কপি তৈরি করা হয়, এবং তারপরে ইনক্রিমেন্টাল ব্যাকআপ প্রয়োগ করা হয়, যা প্রতিটি ব্যাকআপ অপারেশনের পরে ইমেজ কপিগুলিকে এগিয়ে নিয়ে যায়।
এই পোস্টটি IMB ব্যবহার করার জন্য কিছু বিবেচ্য বিষয় তুলে ধরে, প্রক্রিয়াটি ব্যাখ্যা করার জন্য নমুনা কোড প্রদান করে এবং বেশ কিছু পুনরুদ্ধারের পরিস্থিতি দেখায়।
বিবেচনা
একটি ইমেজ কপি ব্যাকআপ কৌশল ব্যবহার করার আগে, নিম্নলিখিত বিবেচনাগুলি মনে রাখবেন:
-
ব্লক চেঞ্জ ট্র্যাকিং (BCT) ডাটাবেসে সক্রিয় থাকতে হবে।
-
ডাটাবেসের ইমেজ কপি সংরক্ষণ করার জন্য আপনার কাছে একই পরিমাণ ডিস্ক স্পেস থাকতে হবে যেভাবে ডাটাবেস ডেটা ফাইলগুলি আসলে ব্যবহার করছে।
-
পয়েন্ট-ইন-টাইম রিকভারি (PITR) এর জন্য, আপনার অবশ্যই ন্যূনতম একটি সম্পূর্ণ ব্যাকআপ থাকতে হবে, এবং ডাটাবেস পুনরুদ্ধার সম্পূর্ণ না হওয়া পর্যন্ত আপনাকে লগ সংরক্ষণ করতে হবে৷
-
ইনপুট এবং আউটপুট (I/O) পরিপ্রেক্ষিতে ডাটাবেসের চিত্র কপিগুলি একই ধরণের স্টোরেজে থাকা উচিত যাতে ডাটাবেস কপিতে স্যুইচ করার সময় কর্মক্ষমতা প্রভাবিত না হয়।
নিম্নলিখিত চিত্রটি একটি ক্রমবর্ধমান আপডেট ব্যাকআপ দেখায়:
নমুনা কোড
একটি দৈনিক চিত্র কপি নিতে এবং ক্রমবর্ধমান আপডেট করতে নিম্নলিখিত কোডটি চালান:
run
{
allocate channel c1 device type disk format ‘/home/oracle/backup/%U’;
recover copy of database with tag ‘IMG_COPY’;
backup incremental level 1 for recover of copy with tag ‘IMG_COPY’ database;
release channel c1;
}
প্রথম এক্সিকিউশনে, recover copy of database কমান্ড কিছুই করে না। backup incremental কমান্ড একটি নতুন ইনক্রিমেন্টাল level 0 তৈরি করে ব্যাকআপট্যাগ করা IMG_COPY কারণ এটি এই ট্যাগ দিয়ে তৈরি করা প্রথম ব্যাকআপ।
দ্বিতীয় এক্সিকিউশনে, recover copy of database কমান্ড কিছুই করে না যতক্ষণ না এটি INC 1 খুঁজে পায় ব্যাকআপ backup incremental কমান্ড INC 1 তৈরি করে ব্যাকআপ।
তৃতীয় এবং পরবর্তী মৃত্যুদণ্ডে, recover command সর্বশেষ উপলব্ধ INC 1 প্রয়োগ করে বিদ্যমান ইমেজ কপি ব্যাকআপ. backup command পরবর্তী INC 1 তৈরি করে ব্যাকআপ।
পুনরুদ্ধারের পরিস্থিতি
নিম্নলিখিত ব্যবহারের কেসগুলি ব্যাখ্যা করে যে কীভাবে ইনক্রিমেন্টাল মার্জ ব্যাকআপগুলি উদাসীন পুনরুদ্ধারের পরিস্থিতিতে সহায়তা করে৷
কেস 1:নষ্ট, মুছে ফেলা বা ওভাররাইট করা ডেটা ফাইল
পরীক্ষার জন্য একটি টেবিল তৈরি করুন, যেমনটি নিম্নলিখিত কোডে দেখানো হয়েছে, এবং চিত্রের অনুলিপি নিতে পূর্ববর্তী স্ক্রিপ্টটি ব্যবহার করুন৷
SQL> create table ImgCpyTab tablespace tbs2 as select * from dba_objects;
Table created.
FILE_NAME FILE_ID TABLESPACE_NAME
————————- ——————— ———————————————
/home/oracle/Sw/oradata/test/tbs02.dbf 5 TBS2
SQL> select count(1) from ImgCpyTab;
COUNT(1)
———-
72476
এই দৃশ্যটি পরীক্ষা করার জন্য, উদ্দেশ্যমূলকভাবে ফিজিক্যাল ডেটা ফাইলটি সরান, যেমনটি দেখানো হয়েছে নিচের কোড, এবং select কমান্ড প্রত্যাশিত ত্রুটি নিক্ষেপ করে।
mv /home/oracle/Sw/oradata/test/tbs02.dbf /home/oracle/Sw/oradata/test/tbs02.dbf_BKP
select count(1) from scott.IMGCPYTAB
*
ERROR at line 1:
ORA-01116: error in opening database file 5
ORA-01110: data file 5: ‘/home/oracle/Sw/oradata/test/tbs02.dbf’
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3
এই ক্ষেত্রে, শারীরিক ফাইল পুনরুদ্ধার করার কোন প্রয়োজন নেই। পরিবর্তে, ব্যাকআপে স্যুইচ করুন এবং এটি পুনরুদ্ধার করুন। এটি খুব দ্রুত, এমনকি ডাটা ফাইল বা টেরাবাইটের ডাটাবেস আকারেও।
নিম্নলিখিত কোডটি ডেটাফাইলটিকে অফলাইন মোডে রাখে:
SQL> alter database datafile 5 offline;
Database altered.
এরপরে, ডেটা ফাইলটিকে অনুলিপিতে স্যুইচ করুন এবং পুনরুদ্ধার করুন:
[oracle@localhost backup]$ rman target /
Recovery Manager: Release 11.2.0.2.0 – Production on Thu Jun 5 18:17:15 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: TEST (DBID=2122535405)
RMAN> switch datafile 5 to copy;
using target database control file instead of recovery catalog
datafile 5 switched to datafile copy “/home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1”
RMAN> recover datafile 5;
Starting recover at 05-JUN-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=149 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 05-JUN-14
RMAN> sql ‘alter database datafile 5 online’;
sql statement: alter database datafile 5 online
RMAN> exit
নিম্নলিখিত কোডে দেখানো হয়েছে, তারিখ ফাইলটি ফিরে এসেছে এবং টেবিলটি অ্যাক্সেসযোগ্য:
FILE_NAME FILE_ID TABLESPACE_NAME
————————- ——————— ———————————————
TBS2 /home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1 AVAILABLE
SQL> select count(1) from scott.IMGCPYTAB;
COUNT(1)
———-
72476
দ্রষ্টব্য: আপনি যদি file_name দেখতে পান কলাম, আপনি জানেন যে ডাটাবেস ইমেজ কপি ফাইল ব্যবহার করে।
কেস 2:সম্পূর্ণ ডাটাবেস দুর্নীতি বা ডিস্ক ব্যর্থতা
আপনার যদি সম্পূর্ণরূপে দূষিত ডেটা বেস বা ডিস্ক ব্যর্থতা থাকে তবে আপনি নিম্নলিখিত পদক্ষেপগুলি ব্যবহার করে ডাটাবেসকে অনুলিপিতে স্যুইচ করতে পারেন:
- ডাটাবেস বন্ধ করুন।
- যদি কন্ট্রোল ফাইল অনুপস্থিত থাকে, এটি পুনরুদ্ধার করুন।
- ছবির কপিগুলি ক্যাটালগ করুন৷ ৷
- ডাটাবেসকে একটি অনুলিপিতে পরিবর্তন করুন।
- আর্কাইভগুলি উপলব্ধ না হওয়া পর্যন্ত পুনরুদ্ধার করুন এবং তারপরে ডাটাবেস খুলুন।
উপসংহার
এই পোস্টে RMAN ইমেজ কপি ব্যাকআপ এবং পুনরুদ্ধারের বৈশিষ্ট্যটি কীভাবে ব্যবহার করা যায় তা নিয়ে আলোচনা করা হয়েছে৷ এটি শারীরিক দুর্নীতির ক্ষেত্রে ডেটা ফাইল এবং ডাটাবেসগুলি বাস্তবায়ন এবং পুনরুদ্ধারের জন্য কিছু ব্যবহারের ক্ষেত্রেও প্রদান করেছে৷ ইনক্রিমেন্টাল মার্জ ব্যাকআপ বৈশিষ্ট্য ডাটাবেস ব্যাকআপকে সহজ করে এবং দ্রুত এবং নমনীয় ডেটা পুনরুদ্ধার নিশ্চিত করে৷
কোনো মন্তব্য করতে বা প্রশ্ন জিজ্ঞাসা করতে প্রতিক্রিয়া ট্যাবটি ব্যবহার করুন৷
৷