(পূর্ব প্রকাশিতের পর)

ওরাকল ডাটাবেজ অ্যাডমিনিস্ট্রেটর সম্পর্কিত গুরুত্বপূর্ণ বিষয়গুলো নিয়ে গত কয়েক সংখ্যায় বিস্তারিত আলোচনা হয়েছে। প্রথমে আমরা জেনেছি ওরাকল আর্কিটেকচারের সাথে গুরুত্বপূর্ণ ফাইলগুলো, অবজেক্ট এবং ইউজারকে কিভাবে ম্যানেজ করাতে হয়। সর্বশেষ দুটি সংখ্যায় ওরাকল নেট আর্কিটেকচার, নেট কনফিগারেশন সম্পর্কে আলোচনা করা হয়েছে। এ লেখায় আলোচনা করা হয়েছে নেমিং মেথড কনফিগারেশন, ওরাকল ডাটাবেজ ব্যাকআপ এবং এর রিকভারি সম্পর্কে। আর এর মাধ্যমে ওরাকল 9i ডাটাবেজ অ্যাডমিনিস্ট্রেশনের এই পর্যায়ের আলোচনা শেষ করা হবে।

নেমিং মেথড কনফিগারেশন

হোস্ট নেমিং (ক্লায়েন্ট) :
এই মেথড ব্যবহার করার জন্য অবশ্যই ক্লায়েন্ট কমপিউটারে টিসিপি/আইপি প্রটোকল ইনস্টল থাকতে হবে। এ ছাড়াও টিসিপি/আইপি প্রটোকল অ্যাডাপ্টর এবং ওরাকল নেট সার্ভিস ইনস্টল থাকতে হবে। এই প্রক্রিয়ার হোস্ট নেম ডোমেইন নেম সার্ভিস (ডিএনস), নেটওয়ার্ক ইনফরমেশন সার্ভিস (এনআইএস) অথবা কেন্দ্রীয়ভাবে পরিচালনা করা টিসিপি/আই হোস্ট ফাইল প্রভৃতি আইপি অ্যাড্রেস ট্রানশ্লেশন মেকানিজমের মাধ্যমে স্থির করা হয়। হোস্ট নেমিং মেথড কনফিগার করার আগে অবশ্যই এগুলো ক্লায়েন্ট প্রান্তে ইনস্টল থাকতে হবে।



হোস্ট নেমিং উদাহরণ :

TRACE_LEVEL_CLIENT = OFF
sqlnet.authentication_services = (NTS)
names.directory_path = (HOSTNAME)

হোস্ট নেমিং (সার্ভার সাইড) :

এই মেথড ব্যবহার করার জন্য অবশ্যই সার্ভার কমপিউটারে টিসিপি/আইপি প্রটোকল ইনস্টল থাকতে হবে। এ ছাড়াও টিসিপি/আইপি প্রটোকল অ্যাডাপ্টার ও ওরাকল নেট সার্ভিস ইনস্টল থাকতে হবে।

হোস্ট নেমিং উদাহরণ :
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = stc-sun02.us.oracle.com)
(ORACLE_HOME = /u03/ora9i/rel12)
(SID_NAME = TEST)

লোকাল নেমিং : এর কিছু বিশেষ সুবিধা রয়েছে।
সার্ভিস নেম অ্যাড্রেস স্থির করা তুলনামূলক সহজ সরল।
ভিন্ন প্রটোকলও এ কাজ করতে পারে।
গ্রাফিক্যাল কনফিগার টুলের মাধ্যমে একে কনফিগার করা যায়।
tnsnames.ora: ফাইলের নমুনা।

# TNSNAMES.ORA Network Configuration File:/u03/ora9i/rel12/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

MY_SERVICE.US.ORACLE.COM =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = stc-sun02.us.oracle.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = TEST.us.oracle.com)
)
)

Sqlnet.ora ফাইলের নমুনা

# SQLNET.ORA Network Configuration File:
/u03/ora9i/rel12/network/admin/sqlnet.ora

# Generated by Oracle configuration tools.
NAMES.DEFAULT_DOMAIN = us.oracle.com
NAMES.DIRECTORY_PATH= (TNSNAMES, HOSTNAME)
SQLNET.EXPIRE_TIME=0

ব্যাকআপ ও রিকভারি ইস্যুগুলো

ডাটাবেজ অ্যাডমিনিস্ট্রেশনের যেসব কাজ প্রতিদিন করতে হয় তার মধ্যে প্রধান এবং অন্যতম কাজ হলো সবার জন্য সবসময় ডাটাবেজ ব্যবহার নিশ্চিত করা। সিস্টেম ফেইলিওর থেকে রক্ষা পাওয়ার জন্য ডিবিএ-কে সতর্কতামূলক ব্যবস্থা নিতে হয়। কোনো কারণে যদি ডাটাবেজ ফেইলিওর দেখা দেয়, তাহলে অবশ্যই ডিবিএ-কে যত দ্রুত সম্ভব কম ডাটা হারানো সাপেক্ষে ডাটাবেজ অপারেশন স্বাভাবিক করতে হবে। বিভিন্ন ফেইলিওর থেকে রক্ষা পাওয়ার জন্য ডিবিএ-কে নিয়মিত ডাটাবেজ ব্যাকআপ নিতে হয়। শুধু নির্ভুল ব্যাকআপ ব্যবহার করেই ডাটাবেজ আপ করা যায়।

বিভিন্ন ধরনের ফেইলিওরের কারণে ডাটাবেজ ব্যাকআপের প্রয়োজন হয়।

০১. স্টেটমেন্ট ফেইলিওর,
০২. ইউজার প্রসেস ফেইলিওর,
০৩. ইউজার এরর,
০৪. নেটওয়ার্ক ফেইলিওর,
০৫. ইনস্ট্যান্স ফেইলিওর এবং
০৬. মিডিয়া ফেইলিওর।

বিভিন্ন ধরনের ফেইলিওর সাপেক্ষে রিকভারির জন্য বিভিন্ন ধরনের ডিবিএ সম্পৃক্ততা দরকার।

স্টেটমেন্ট ফেইলিওরের জন্য যেসব কারণ দায়ী তা হলো :

০১. অ্যাপ্লিকেশনের লজিক এরর।
০২. টেবিলে ইনভ্যালিড ভাটা প্রবেশের চেষ্টা করালে।
০৩. অপর্যাপ্ত প্রিভেলেজ নিয়ে কোনো অপারেশন করার চেষ্টা করলে।
০৪. বরাদ্দ করা কোটা অতিক্রম করা সত্ত্বেও কোনো টেবিল তৈরি করার চেষ্টা করলে।
০৫. টেবিল স্পেসে অপর্যাপ্ত স্থান থাকা সত্ত্বেও কোনো টেবিলে ইনসার্ট বা আপডেট অপারেশন চালানো।

যখন কোনো স্টেটমেন্ট ফেইলিওর সংঘটিত হয় তখন ওরাকল সার্ভার অথবা অপারেটিং সিস্টেম একটি এরর মেসেজ দেয়। স্টেটমেন্ট ফেইলিওরের হাত থেকে রক্ষা পাওয়ার জন্য নিম্নোক্ত ব্যবস্থাগুলো গ্রহণ করা হয়ে থাকে : ০১. প্রোগ্রামের লজিক্যাল ফ্লোকে সংশোধিত করা। যদিও এই কাজ অ্যাপ্লিকেশন ডেভেলপারের চেয়ে ডিবিএ’র ওপর বর্তায়। ০২. এসকিউএল স্টেটমেন্টকে মডিফাই করা এবং তা রিইস্যু করা। এটাও অ্যাপ্লিকেশন ডেভেলপারের কাজ। ০৩. ইউজারকে ততক্ষণ পর্যন্ত প্রিভিলেজ দেয়া, যাতে সে ওই স্টেটমেন্ট সফলভাবে সম্পন্ন করতে পারে। ০৪. Alter Vser কমান্ড প্রয়োগ করে কোটা সীমা পরিবর্তন করা। ০৫. টেবিল স্পেসে ফাইল স্পেসযুক্ত করা। টেকনিক্যালি ডিবিএ-কে অবশ্যই এটা নিশ্চিত করা প্রয়োজন, যাতে এই ধরনের ঘটনা না ঘটে। তবে প্রয়োজনের খাতিরে কখনও কখনও এই কাজ করতে হতে পারে। এ ছাড়া ডিবিএ Resize অথবা Auto Extend ডাটাবেজে প্রয়োগ করতে পারে। ০৬. রিসাম্বেল স্কেস এলোমেলো করতে পারে।

ইউজার প্রসেস ফেইলিওরের কারণ

০১. যদি ইউজার সেশনের মধ্যে থাকা অবস্থায় অস্বাভাবিকভাবে বিচ্ছিন্ন হয়ে যায়। উদাহরণস্বরূপ বলা যায়, যখন একজন ইউজার ................Sal Plus উইন্ডো ক্লায়েন্ট সার্ভার কনফিগারেশনে ডাটাবেজের সাথে সংযুক্ত থাকা অবস্থায় ক্লোজ করে দিলে।

০২. ইউজার সেশন অস্বাভাবিকভাবে বন্ধ হয়ে গেলে। ০৩. ইউজার প্রোগ্রাম যদি কোনো অ্যাড্রেস অ্যাকসেপশন রেইজড করে যা সেশনকে টার্মিনেট করে।

ইউজার প্রসেস ফেইলিওর হতে রক্ষা পাওয়ার উপায়

ডিবিএ-কে এই সমস্যার হাত থেকে ডাটাবেজ রক্ষা করার জন্য যৎসামান্যই ভূমিকা পালন করতে হয়। এই সমস্যায় ইউজার প্রসেস কাজ করতে পারে না। যদিও অন্য সব সার্ভার এবং ইউজার প্রসেস কাজ করে। এ ক্ষেত্রে পিমন ব্যাগরাউন্ট প্রসেস নেপথ্যে থেকে অস্বাভাবিকভাবে বন্ধ হওয়া ইউজার প্রসেসকে ডিটেক্ট করে এবং ট্রান্সজেকশন রিলিজ করে যদি কোনো রিসোর্সের সাথে সম্পর্কিত থাকে এবং ওই রিসোর্সকে লক করে দেয়।

সম্ভাব্য ইউজার এরর

০১. যদি ইউজার দুর্ঘটনাবশত কোনো টেবিলকে ড্রপ অথবা ট্রাঙ্কেট করে দেয়।

০২. কোনো ইউজার যদি কোনো টেবিলের সব রো-কে ডিলিট করে দেয়।

০৩. যদি এক ইউজারের কমিটেড ডাটাতে কোনো এরর থেকে থাকে।

ইউজার এরর হতে রক্ষা পাওয়ার উপায়

০১. ডাটাবেজ ইউজারকে ট্রেইন্ড করা,
০২. ভ্যালিড ব্যাকআপ হতে রিকভারি করা,
০৩. কোনো এক্সপোর্ট ফাইল থেকে টেবিল ইম্পোর্ট করা,
০৪. এরর সংঘটিত হওয়ার সময় জানার জন্য লগ মাইনর ব্যবহার করা,
০৫. পয়েন্টিং টাইম রিকভারির মাধ্যমে রিকভার করা,
০৬. অবজেক্ট লেভেল রিকভারি করার জন্য লগ মাইনর ব্যবহার করা এবং
০৭. পুরনো ডাটা ফ্ল্যাশব্যাকের মাধ্যমে দেখা এবং তা রিপিয়ার করা।

ইনস্ট্যান্স ফেইলিওর সংঘটিত হওয়ার কারণ

অনেক কারণে ইনস্ট্যান্স ফেইলিওর হতে পারে :

০১. বৈদ্যুতিক বিভ্রাটের কারণে সার্ভার না পাওয়া,
০২. সিপিইউ ফেইলিওর, মেমরি করাপশন অথবা অপারেটিং সিস্টেম ক্র্যাশ করার কারণে যদি সার্ভার আনঅ্যাভেলেবল হলে,
০৩. যদি কোনো একটি ব্যাকগ্রাউন্ড প্রসেস যেমন- Dbwn, Lgwe, Pmon, Smon ফেইলিওরের সম্মুখীন হয়।

এসব সমস্যা থেকে উত্তরণের জন্য ডিবিএ-কে অবশ্যই যা করতে হয় তা হলো-

০১. ইনস্ট্যান্সকে স্টার্ট করা স্টার্টআপ কমান্ড দিয়ে। এর ফলে ওরাকল সার্ভার স্বয়ংক্রিয়ভাবে রোল ফরোয়ার্ড এবং রোল ব্যাকের মাধ্যমে রিকভার করবে,
০২. অ্যালার্ট লগ ফাইল অথবা অন্য কোনো লগ ফাইল রিট করে ফেইলিওরের প্রকৃত কারণ অনুসন্ধান করা উচিত।

মিডিয়া ফেইলিওর

এটা পুরোপুরি ফিজিক্যাল সমস্যা। এই ধরনের ফেইলিওরে ডিবিএ’র সরাসরি হস্তক্ষেপ প্রয়োজন হয়। যেসব কারণে এটা হয়ে থাকে তা হলো- ০১. যেই হার্ডড্রাইভের অভ্যন্তরে ডাটাবেজ সংরক্ষিত আছে তার হেড ক্র্যাশ করে, ০২. যদি হার্ডড্রাইভে ডাটা লেখা অথবা ডাটা পড়ার সময় কোনো ফিজিক্যাল সমস্যার উদ্ভব হয়, ০৩. যদি ফাইল দুর্ঘটনাবশত নষ্ট হয়ে যায়।

মিডিয়া ফেইলিওরের হাত থেকে রক্ষা পাওয়ার উপায়

পরীক্ষিত কোনো রিকভারি কৌশল মিডিয়া ফেইলিওরের হাত থেকে রক্ষা পাওয়ার জন্য ব্যবহার করা উচিত। ডিবিএ’র কর্মদক্ষতার ওপর নির্ভর করে কতটা কম সময়ে এবং কম ডাটা হারিয়ে রিকভার করা যায়। এক্ষেত্রে কোন প্রক্রিয়ায় ডাটা ব্যাকআপ নেয়া হয় তাও নির্ভর করে। রিকভারি কৌশল নিম্নলিখিত বিষয়গুলোর ওপর নির্ভর করে-
০১. কোন ব্যাকআপ মেথড গ্রহণ করা হচ্ছে এবং কোন ধরনের ফাইল ক্ষতিগ্রস্ত হচ্ছে।
০২. ডাটাবেজ আর্কাইভ মোডে কাজ করছে কি না? যদি আর্কাইভ মোডে কাজ করে তবে আর্কাইভ রিডু লগ ফাইল ব্যবহার করে রিকভার করা যাবে। যদি আরএমএএন ব্যবহার করা হয় তবে ইনক্রিমেন্টাল ব্যাকআপ ব্যবহার করে মিডিয়া ফেইলিওরের হাত থেকে রক্ষা পাওয়া যাবে।

যেসব বিষয়ের ওপর ভিত্তি করে ব্যাকআপ এবং রিকভারি কৌশল গ্রহণ করা হয়-

০১. বিজনেস রিকোয়ারমেন্ট,
০২. অপারেশনাল রিকোয়ারমেন্ট,
০৩. টেকনিক্যাল রিকোয়ারমেন্ট ও
০৪. ম্যানেজমেন্ট রিকোয়ারমেন্ট।

বিজনেস রিকোয়ারমেন্ট :

০১. মিন টাইম টু রিকভার : সর্বক্ষণিক ডাটাবেজ চালু রাখা ডিবিএ’র জন্য অন্যতম প্রধান কাজ। যদি কোনো কারণে ডাটাবেজ ফেইলিওর হয় তবে যেন অল্প সময়ের জন্য ডাটাবেজ আনঅ্যাভেলেবল থাকে।

০২. মিন টাইম বিটউইন ফেইলিওর : বিভিন্ন ধরনের ফেইলিওর থেকে ডাটাবেজকে রক্ষা করা ডিবিএ’র অন্যতম প্রধান কাজ। তাই দুটি ফেইলিওরের মধ্যবর্তী সময়ের ব্যবধান বেশি রাখার চেষ্টা করা উচিত। ডিবিএ-কে ব্যাকআপ এবং রিকভারি স্ট্রাকচারকে ভালোভাবে জানা এবং সেই অনুসারে ডাটাবেজকে কনফিগার করা উচিত যাতে ঘন ঘন এই ফেইলিওরের ঘটনা না ঘটে।

০৩. প্রসেস মূল্যায়ন করা : ডিবিএ এবং ঊর্ধ্বতন কর্তৃপক্ষকে অবশ্যই নিয়মিত ব্যাকআপ এবং রিকভারি স্ট্র্যাটেজি মূল্যায়ন করা উচিত।


অপারেশনাল রিকোয়ারমেন্ট :

০১. ২৪ ঘণ্টা অপারেশন যেসব ক্ষেত্রে ২৪/৭ ব্যবস্থায় ডাটাবেজকে সার্ভিস দিতে হয় সেসব ক্ষেত্রে অবশ্যই ব্যাকআপ এবং রিকভারি অপারেশনকে ইফেক্ট করতে পারে। তাই এ ক্ষেত্রে যথাযথ কনফিগারেশন অত্যন্ত জরুরি।
০২. টেস্টিং এবং ভেলিডেটিং ব্যাকআপ ও
০৩. ডাটাবেজ ভেলিডিটি।

টেকনিক্যালি বিবেচ্য বিষয়গুলো :
০১. রিসোর্স : হার্ডওয়্যার, সফটওয়্যার, ম্যানপাওয়ার এবং সময়,
০২. ফিজিক্যাল ইমেজ কপিং (৩ এস সিস্টেম ফাইলের),
০৩. ডাটাবেজ অবজেক্টের লজিক্যাল কপিং ও
০৪. ডাটাবেজ কনফিগারেশন।

ডিজাস্টার রিকভারি ইস্যুগুলো :
আমাদের এটা অবশ্যই মনে রাখতে হবে- যেহেতু আমাদের ডাটা অনেক মূল্যবান তাই যেকোনো মূল্যে তা রক্ষা এবং সংরক্ষণ করতে হবে। সচরাচর যেসব ডিজাস্টার ডাটাবেজ অপারেশনে বাধার সৃষ্টি করতে পারে তা হলো-
০১. ভূমিকম্প, বন্যা, আগুন,
০২. মেশিন নষ্ট হয়ে গেলে,
০৩. স্টোরেজ হার্ডওয়্যার অথবা সফটওয়্যার কাজ না করলে ও
০৪. কোনো কারণে গুরুত্বপূর্ণ ব্যক্তি যেমন- ডিবিএ’র প্রস্থান ইত্যাদি।

সমাধান :

০১. অফসাইড ব্যাকআপ,
০২. ওরাকল ডাটাগার্ড ব্যবহার করা,
০৩. জিও মিররিং,
০৪. মেসেজিং ও
০৫. টিপি মনিটরিং।


কজ ওয়েব

ফিডব্যাক : fthekhar@infobizsol.com