ফার্মাসিউটিক্যাল পরিবেশে Oracle ডেটাবেজের জন্য Computer System Validation (CSV): GAMP 5, 21 CFR Part 11 ও অডিট ট্রেইল গাইড

অধিকাংশ Oracle DBA গাইড পারফরম্যান্স টিউনিং, ব্যাকআপ কৌশল ও RAC আর্কিটেকচার নিয়ে কথা বলে। খুব কম-ই সেই বিষয়টি স্পর্শ করে যা ফার্মাসিউটিক্যাল প্রতিষ্ঠান আসলে তাদের Oracle DBA-এর কাছ থেকে চায়: এমন একটি ডেটাবেজ পরিবেশ যা রেগুলেটরি ভ্যালিডেশন চাহিদা পূরণ করে, একটি প্রতিরক্ষাযোগ্য অডিট ট্রেইল বজায় রাখে, FDA বা DGDA পরিদর্শন টিকে যায় এবং Computer System Validation-এর সম্পূর্ণ লাইফসাইকেল সমর্থন করে। এই গাইডটি ফার্মা ম্যানুফ্যাকচারিং পরিবেশে Oracle ডেটাবেজ সাপোর্ট করার সরাসরি অভিজ্ঞতা থেকে লেখা — একটি Oracle Certified Professional পটভূমির সাথে আনুষ্ঠানিক CSV প্রশিক্ষণ মিলিয়ে।

১. Computer System Validation (CSV) কী?

Computer System Validation হলো এমন ডকুমেন্টেড প্রমাণ প্রতিষ্ঠার প্রক্রিয়া যে একটি কম্পিউটারাইজড সিস্টেম ধারাবাহিকভাবে এমন ফলাফল তৈরি করে যা পূর্বনির্ধারিত স্পেসিফিকেশন ও গুণগত বৈশিষ্ট্য পূরণ করে। ফার্মাসিউটিক্যাল ম্যানুফ্যাকচারিংয়ে, যেকোনো কম্পিউটারাইজড সিস্টেম যা একটি পণ্যের গুণমান নিয়ন্ত্রণ, রেকর্ড বা প্রভাবিত করে — ম্যানুফ্যাকচারিং রেকর্ড, ব্যাচ ডেটা, ল্যাবরেটরি ফলাফল ও ERP লেনদেন সংরক্ষণকারী ডেটাবেজসহ — অবশ্যই ভ্যালিডেটেড হতে হবে।

ভ্যালিডেশন একটি এককালীন ঘটনা নয়। এটি একটি চলমান শৃঙ্খলা যা অন্তর্ভুক্ত করে:

• সিস্টেমের প্রাথমিক ইনস্টলেশন ও কনফিগারেশন
• হার্ডওয়্যার, সফটওয়্যার বা কনফিগারেশনে পরবর্তী সব পরিবর্তন
• সিস্টেম ভ্যালিডেটেড অবস্থায় আছে তা নিশ্চিত করতে পর্যায়ক্রমিক পুনঃপর্যালোচনা
• জীবনকালের শেষে অবসর ও ডেটা মাইগ্রেশন

একজন ফার্মা পরিবেশের Oracle DBA-এর জন্য এর মানে ডেটাবেজে আপনার নেওয়া প্রতিটি ক্রিয়া — একটি প্যারামিটার পরিবর্তন, একটি স্কিমা হালনাগাদ, একটি প্যাচ প্রয়োগ, একটি ইউজার তৈরি — অবশ্যই ডকুমেন্টেড, পর্যালোচিত এবং অনেক ক্ষেত্রে প্রোডাকশনে চালানোর আগে একটি চেঞ্জ কন্ট্রোল প্রক্রিয়ার মাধ্যমে আনুষ্ঠানিকভাবে অনুমোদিত হতে হবে।

২. যে রেগুলেটরি কাঠামোগুলো আপনাকে জানতে হবে

২.১ 21 CFR Part 11 (FDA — USA)

US Code of Federal Regulations-এর Title 21, Part 11, FDA-নিয়ন্ত্রিত শিল্পে ইলেকট্রনিক রেকর্ড ও ইলেকট্রনিক স্বাক্ষরের চাহিদা প্রতিষ্ঠা করে। আপনার ফার্মা কোম্পানি যদি USA-তে রপ্তানি করে, কিংবা আপনার ERP বা LIMS সিস্টেম যদি কাগজের রেকর্ডের বিকল্প হিসেবে কাজ করা ইলেকট্রনিক রেকর্ড তৈরি করে, তবে Part 11 প্রযোজ্য। Oracle DBA কাজের সাথে প্রাসঙ্গিক মূল চাহিদাগুলো:

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

২.২ EU Annex 11 (EMA — Europe)

European Medicines Agency-এর GMP নির্দেশিকার Annex 11 EU-নিয়ন্ত্রিত ফার্মা ম্যানুফ্যাকচারিংয়ে কম্পিউটারাইজড সিস্টেম পরিচালনা করে। পরিধিতে 21 CFR Part 11-এর অনুরূপ কিন্তু কিছু বিষয়ে অতিরিক্ত জোর দেয়:

• সরবরাহকারী/ভেন্ডর মূল্যায়ন ও ডকুমেন্টেশন
• ডেটা ব্যাকআপ ও রিকভারি ভ্যালিডেশন
• ভ্যালিডেশনের অংশ হিসেবে ডিজাস্টার রিকভারি টেস্টিং
• কম্পিউটার সিস্টেম ব্যর্থতার জন্য ইনসিডেন্ট ম্যানেজমেন্ট

২.৩ GAMP 5 (ISPE কাঠামো)

International Society for Pharmaceutical Engineering-এর Good Automated Manufacturing Practice গাইড হলো CSV বাস্তবায়নের জন্য শিল্পের ব্যবহারিক কাঠামো। GAMP 5 ভ্যালিডেশনে একটি ঝুঁকি-ভিত্তিক পদ্ধতি উপস্থাপন করে — ভ্যালিডেশন প্রচেষ্টার মাত্রা সিস্টেমের ঝুঁকি ও জটিলতার সাথে মেলা উচিত। GAMP 5 সফটওয়্যারকে পাঁচটি ক্যাটাগরিতে ভাগ করে:

• Category 1: অবকাঠামো সফটওয়্যার (OS, ডেটাবেজ ইঞ্জিন) — qualify করুন, validate নয়
• Category 3: নন-কনফিগারড সফটওয়্যার (স্ট্যান্ডার্ড অফ-দ্য-শেল্ফ অ্যাপ্লিকেশন)
• Category 4: কনফিগারড সফটওয়্যার (SAP-এর মতো ERP সিস্টেম, কাস্টম-কনফিগারড Oracle অ্যাপ)
• Category 5: কাস্টম সফটওয়্যার — সম্পূর্ণ ভ্যালিডেশন লাইফসাইকেল প্রয়োজন

Oracle DBA-এর দৃষ্টিতে: Oracle Database ইঞ্জিন নিজে Category 1 (অবকাঠামো কোয়ালিফিকেশন)। Oracle-এ চলা ERP বা LIMS অ্যাপ্লিকেশন সাধারণত Category 4 বা 5 এবং সম্পূর্ণ ভ্যালিডেশন প্রয়োজন। ডেটাবেজ কনফিগারেশন — প্যারামিটার, ইউজার অ্যাকাউন্ট, অডিট সেটিংস, সিকিউরিটি — অবকাঠামো কোয়ালিফিকেশনের অংশ হিসেবে qualify করতে হবে।

২.৪ DGDA (বাংলাদেশ — Directorate General of Drug Administration)

DGDA বিধিমালার অধীনে পরিচালিত বাংলাদেশি ফার্মা কোম্পানিগুলোর কাছ থেকে ক্রমবর্ধমানভাবে আন্তর্জাতিক GMP মান, বিশেষত WHO-GMP ও EU-GMP চাহিদার সাথে সামঞ্জস্য প্রত্যাশিত। DGDA যদিও 21 CFR Part 11-এর সমতুল্য একটি নিবেদিত কম্পিউটারাইজড সিস্টেম নির্দেশিকা প্রকাশ করেনি, পরিদর্শকরা অডিট ট্রেইল, অ্যাক্সেস কন্ট্রোল, ডেটা ইন্টিগ্রিটির প্রমাণ ও চেঞ্জ কন্ট্রোল ডকুমেন্টেশন খুঁজতে প্রশিক্ষিত — বিশেষত যেসব কোম্পানি রপ্তানি নিবন্ধন বা আন্তর্জাতিক অংশীদারিত্ব খুঁজছে।

৩. Oracle-এর জন্য IQ / OQ / PQ কাঠামো

যেকোনো সিস্টেমের জন্য CSV-এর ভিত্তিপ্রস্তর হলো তিন-পর্যায়ের কোয়ালিফিকেশন: Installation Qualification (IQ), Operational Qualification (OQ) এবং Performance Qualification (PQ)। একটি Oracle ডেটাবেজ পরিবেশের জন্য প্রতিটির অর্থ নির্দিষ্টভাবে এখানে দেওয়া হলো।

৩.১ Installation Qualification (IQ)

IQ নিশ্চিত করে যে Oracle ডেটাবেজ সঠিকভাবে ইনস্টল করা হয়েছে, সব কম্পোনেন্ট উপস্থিত এবং ইনস্টলেশন অনুমোদিত ডিজাইন স্পেসিফিকেশনের সাথে মেলে। একটি সাধারণ Oracle IQ ডকুমেন্টে থাকে:

• Oracle সফটওয়্যার সংস্করণ ও প্যাচ লেভেল যাচাই
• অপারেটিং সিস্টেম সংস্করণ, kernel প্যারামিটার ও প্রি-রিকুইজিট
• স্টোরেজ লেআউট — ডেটাফাইল, redo log, control file, archive log গন্তব্য
• ডেটাবেজ ইনিশিয়ালাইজেশন প্যারামিটার (SGA সাইজ, PGA, অডিট সেটিংস, character set)
• নেটওয়ার্ক কনফিগারেশন — listener, TNSNAMES, Oracle Net সেটিংস
• ইনস্টল করা Oracle কম্পোনেন্ট ও অপশন
• সার্ভিস অ্যাকাউন্ট, OS-লেভেল অনুমতি, ডিরেক্টরি স্ট্রাকচার
• প্রমাণ স্ক্রিনশট — প্রকৃত বনাম প্রত্যাশিত কনফিগারেশন নিশ্চিত করা SQL কোয়েরির আউটপুট

IQ ডকুমেন্ট সম্পাদিত, সাক্ষ্যবহ ও স্বাক্ষরিত হয় — বিচ্যুতি লগ করা হয় এবং OQ-তে যাওয়ার আগে সমাধান করা হয়।

৩.২ Operational Qualification (OQ)

OQ নিশ্চিত করে যে Oracle ডেটাবেজ তার সংজ্ঞায়িত প্যারামিটারের মধ্যে সঠিকভাবে কাজ করে — এটি যা করার জন্য ডিজাইন করা তা-ই করে। Oracle-এর জন্য OQ টেস্ট স্ক্রিপ্টে সাধারণত থাকে:

• ডেটাবেজ startup ও shutdown প্রক্রিয়া
• ইউজার তৈরি, প্রিভিলেজ বরাদ্দ ও অ্যাক্সেস কন্ট্রোল যাচাই
• অডিট ট্রেইল সক্রিয়করণ ও যাচাই — DML অপারেশন লগ হচ্ছে তা নিশ্চিত করা
• ব্যাকআপ ও রিকভারি টেস্টিং — RMAN ব্যাকআপ চালানো, সম্পন্ন যাচাই, বিকল্প অবস্থানে রিস্টোর টেস্ট
• Archive log জেনারেশন ও আর্কাইভিং যাচাই
• Alert log মনিটরিং — অপারেশন চলাকালীন কোনো অপ্রত্যাশিত ত্রুটি নেই তা নিশ্চিত করা
• অ্যাপ্লিকেশন সার্ভার থেকে সংযোগ টেস্টিং
• পাসওয়ার্ড পলিসি প্রয়োগ টেস্টিং
• RAC বা Data Guard পরিধিতে থাকলে high-availability টেস্টিং

৩.৩ Performance Qualification (PQ)

PQ নিশ্চিত করে যে ডেটাবেজ প্রকৃত বা সিমুলেটেড প্রোডাকশন পরিস্থিতিতে নির্ভরযোগ্যভাবে পারফর্ম করে। ফার্মায় Oracle-এর জন্য এতে থাকে:

• বাস্তবসম্মত লেনদেন ভলিউমসহ লোড টেস্টিং
• রেসপন্স টাইম ব্যবসায়িক চাহিদা পূরণ করছে তা নিশ্চিত করা
• অডিট ট্রেইল পারফরম্যান্স যাচাই — অডিটিং লেনদেন প্রসেসিংকে অগ্রহণযোগ্য মাত্রায় নামিয়ে দেয় না তা নিশ্চিত করা
• রিকভারি টাইম টেস্টিং — একটি পূর্ণ রিস্টোরে কত সময় লাগে? এটি কি Recovery Time Objective পূরণ করে?
• সমসাময়িক ইউজার টেস্টিং
• পিরিয়ড-এন্ড রিপোর্টিং পারফরম্যান্স (ব্যাচ প্রসেসিং)

৪. Oracle-এর জন্য অডিট ট্রেইল চাহিদা

অডিট ট্রেইল একটি ভ্যালিডেটেড Oracle পরিবেশের সবচেয়ে গুরুত্বপূর্ণ ও সবচেয়ে ঘন ঘন পরিদর্শিত উপাদান। নিয়ন্ত্রকরা দেখতে চান — একটি নিয়ন্ত্রিত রেকর্ডে প্রতিটি পরিবর্তনের জন্য — কে পরিবর্তন করেছে, কী পরিবর্তন হয়েছে, কখন হয়েছে এবং আগের মান কী ছিল।

Oracle একাধিক স্তরের অডিটিং দেয় যা এই চাহিদা পূরণ করতে পারে:

৪.১ Unified Auditing (Oracle 12c ও পরবর্তী)

Oracle-এর Unified Auditing সব অডিট রেকর্ড UNIFIED_AUDIT_TRAIL ভিউতে একত্র করে, যা একটি সুরক্ষিত স্কিমায় (AUDSYS) সংরক্ষিত থাকে যা সাধারণ ডেটাবেজ ব্যবহারকারী — DBA-সহ — পরিবর্তন করতে পারে না। রেগুলেটরি কমপ্লায়েন্সের জন্য এটি গুরুত্বপূর্ণ: অডিট ট্রেইল কম্পিউটার-জেনারেটেড হতে হবে এবং যে ব্যক্তি রেকর্ড তৈরি করেছে তার দ্বারা পরিবর্তনযোগ্য নয়।

-- Enable unified auditing policy for DML on a regulated table
CREATE AUDIT POLICY batch_record_audit
  ACTIONS INSERT, UPDATE, DELETE ON manufacturing.batch_records;

AUDIT POLICY batch_record_audit;

৪.২ Fine-Grained Auditing (FGA)

নিয়ন্ত্রিত ডেটা ধারণকারী টেবিলের জন্য Fine-Grained Auditing পরিবর্তিত কলামের পুরনো ও নতুন উভয় মান ধরে রাখে — শুধু একটি পরিবর্তন ঘটেছে এই তথ্য নয়। এটি ভ্যালিডেটেড পরিবেশে অডিট ট্রেইলের "আগে ও পরে" চাহিদা পূরণ করে।

-- FGA policy to capture old and new values on batch status changes
DBMS_FGA.ADD_POLICY(
  object_schema   => 'MANUFACTURING',
  object_name     => 'BATCH_RECORDS',
  policy_name     => 'BATCH_STATUS_AUDIT',
  audit_column    => 'BATCH_STATUS,APPROVED_BY,APPROVAL_DATE',
  statement_types => 'UPDATE'
);

৪.৩ অডিট ট্রেইলে যা ধরে রাখতে হবে

ন্যূনতম, একটি Part 11 / Annex 11 কমপ্লায়েন্ট অডিট ট্রেইলকে Oracle-এর জন্য অবশ্যই রেকর্ড করতে হবে:

• ক্রিয়ার তারিখ ও সময় (সিস্টেম টাইমস্ট্যাম্প — ইউজার-এন্টার্ড নয়)
• ইউজার পরিচয় (অনন্য Oracle ইউজার আইডি — শেয়ারড অ্যাকাউন্ট নয়)
• ক্রিয়ার ধরন (INSERT / UPDATE / DELETE)
• প্রভাবিত টেবিল ও কলাম
• পুরনো মান (পরিবর্তনের আগে)
• নতুন মান (পরিবর্তনের পরে)
• অ্যাপ্লিকেশন কনটেক্সট (সেশন তথ্য, টার্মিনাল, অ্যাপ্লিকেশন নাম)

৪.৪ অডিট ট্রেইল নিজেকে সুরক্ষিত রাখা

নিয়ন্ত্রকরা জিজ্ঞেস করবেন: DBA কি অডিট রেকর্ড পরিবর্তন বা মুছতে পারে? একটি ভ্যালিডেটেড পরিবেশে উত্তর অবশ্যই না হতে হবে — অথবা ন্যূনতম, এমন যেকোনো ক্রিয়া নিজেই অডিট করা এবং দ্বৈত অনুমোদন প্রয়োজন হতে হবে। Oracle-এর Unified Auditing AUDSYS স্কিমা সুরক্ষাসহ এটি সামলায়। অতিরিক্ত সুরক্ষার জন্য অডিট ডেটায় প্রিভিলেজড ইউজার অ্যাক্সেসও সীমিত করতে Oracle Label Security বা Oracle Vault বিবেচনা করুন।

৫. ভ্যালিডেটেড Oracle পরিবেশের জন্য অ্যাক্সেস কন্ট্রোল

21 CFR Part 11 ও GAMP 5 উভয়েই দাবি করে যে নিয়ন্ত্রিত কম্পিউটার সিস্টেমে অ্যাক্সেস নিয়ন্ত্রিত, অনুমোদিত ব্যক্তিদের মধ্যে সীমিত এবং অ্যাক্সেস অধিকার পর্যায়ক্রমে পর্যালোচিত হবে। Oracle DBA-এর জন্য এর অর্থ:

৫.১ কোনো শেয়ারড অ্যাকাউন্ট নয়

প্রতিটি ইউজার — অ্যাপ্লিকেশন সার্ভিস অ্যাকাউন্টসহ — অবশ্যই একটি অনন্য Oracle ইউজারনেম থাকতে হবে। শেয়ারড অ্যাকাউন্ট (যেখানে একাধিক মানুষ একই ইউজার হিসেবে লগ ইন করে) অডিট ট্রেইলকে অর্থহীন করে দেয়: আপনি নির্ধারণ করতে পারবেন না কোন ব্যক্তি পরিবর্তন করেছে। এটি ফার্মা Oracle অডিটে সবচেয়ে সাধারণ ঘাটতিগুলোর একটি।

৫.২ Least Privilege নীতি

অ্যাপ্লিকেশন ইউজারদের কেবল সেই প্রিভিলেজ থাকা উচিত যা তাদের কাজ করতে প্রয়োজন। কোনো অ্যাপ্লিকেশন অ্যাকাউন্টের DBA, SYSDBA বা DROP ANY TABLE প্রিভিলেজ থাকা উচিত নয়। কাজের ফাংশনে ম্যাপ করা রোল তৈরি করুন এবং সরাসরি সিস্টেম প্রিভিলেজের পরিবর্তে রোল বরাদ্দ করুন।

৫.৩ DBA প্রিভিলেজ নিয়ন্ত্রণ

একটি ভ্যালিডেটেড পরিবেশে প্রোডাকশনে DBA অ্যাক্সেস নিয়ন্ত্রিত ও মনিটর করা হতে হবে। অপশনগুলো:

• Oracle Database Vault — নিয়ন্ত্রিত স্কিমা অ্যাক্সেস থেকে SYSDBA-কেও সীমাবদ্ধ করে
• Privileged Access Management (PAM) টুল — DBA প্রোডাকশনে সংযোগের আগে অনুমোদন ওয়ার্কফ্লো প্রয়োজন করে
• দ্বৈত নিয়ন্ত্রণ — প্রোডাকশনে DBA ক্রিয়া সাক্ষ্য ও পাল্টা-স্বাক্ষর করতে দ্বিতীয় একজন অনুমোদিত ব্যক্তি প্রয়োজন করে

৫.৪ পাসওয়ার্ড পলিসি প্রয়োগ

Oracle profile পাসওয়ার্ড জটিলতা, মেয়াদ, ইতিহাস ও লকআউট পলিসি প্রয়োগ করে। ভ্যালিডেটেড পরিবেশে নিয়ন্ত্রিত ইউজারদের বরাদ্দ করা profile অবশ্যই IQ-তে ডকুমেন্টেড এবং OQ-তে টেস্ট করা হতে হবে।

-- Create a validated environment user profile
CREATE PROFILE pharma_validated_profile LIMIT
  FAILED_LOGIN_ATTEMPTS  5
  PASSWORD_LIFE_TIME     90
  PASSWORD_REUSE_TIME    365
  PASSWORD_REUSE_MAX     12
  PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function
  SESSIONS_PER_USER      3;

৬. ফার্মায় Oracle-এর জন্য চেঞ্জ কন্ট্রোল

প্রথমবার ফার্মায় কাজ করার সময় অধিকাংশ Oracle DBA এই ক্ষেত্রটিকে সবচেয়ে চ্যালেঞ্জিং মনে করেন। একটি স্ট্যান্ডার্ড আইটি পরিবেশে একজন DBA প্রয়োজনমতো একটি প্যাচ প্রয়োগ, একটি ইনডেক্স যোগ বা একটি প্যারামিটার পরিবর্তন করতে পারেন। একটি ভ্যালিডেটেড পরিবেশে একটি ভ্যালিডেটেড সিস্টেমে প্রতিটি পরিবর্তন অবশ্যই চেঞ্জ কন্ট্রোলের মধ্য দিয়ে যেতে হবে।

৬.১ কীসের জন্য চেঞ্জ কন্ট্রোল প্রয়োজন

• Oracle প্যাচ প্রয়োগ (CPU প্যাচ, PSU প্যাচ)
• ইনিশিয়ালাইজেশন প্যারামিটার পরিবর্তন
• নিয়ন্ত্রিত টেবিলে স্কিমা পরিবর্তন (DDL: ALTER TABLE, CREATE INDEX, ইত্যাদি)
• ইউজার অ্যাকাউন্ট তৈরি বা প্রিভিলেজ পরিবর্তন
• অডিট পলিসি পরিবর্তন
• ব্যাকআপ কৌশল পরিবর্তন
• ডেটাবেজ সার্ভারে হার্ডওয়্যার পরিবর্তন
• OS আপগ্রেড বা প্যাচ
• বড় Oracle সংস্করণ আপগ্রেড

৬.২ চেঞ্জ কন্ট্রোল প্রক্রিয়া

একটি Oracle ডেটাবেজ পরিবর্তনের জন্য একটি সাধারণ ফার্মা চেঞ্জ কন্ট্রোল এই প্রবাহ অনুসরণ করে:

1. Change Request: DBA প্রস্তাবিত পরিবর্তন, কারণ ও ঝুঁকি মূল্যায়ন বর্ণনা করে একটি লিখিত চেঞ্জ রিকোয়েস্ট জমা দেন
2. Impact Assessment: কোয়ালিটি টিম ভ্যালিডেটেড অবস্থার ওপর প্রভাব পর্যালোচনা করে — এই পরিবর্তনে কি পুনঃকোয়ালিফিকেশন প্রয়োজন?
3. Approval: পরিবর্তন IT ম্যানেজার, কোয়ালিটি ম্যানেজার এবং (বড় পরিবর্তনের জন্য) Regulatory Affairs দ্বারা অনুমোদিত হয়
4. Test in Non-Production: পরিবর্তন প্রথমে একটি ভ্যালিডেটেড টেস্ট/UAT পরিবেশে টেস্ট করা হয়
5. Implementation Plan: ধাপে ধাপে প্রক্রিয়া, রোলব্যাক পরিকল্পনা ও ডাউনটাইম উইন্ডো ডকুমেন্টেড হয়
6. Production Implementation: পরিকল্পনা অনুযায়ী পরিবর্তন চালানো হয়, কোয়ালিটি প্রতিনিধির সাক্ষ্যে
7. Post-Change Verification: যাচাই টেস্ট নিশ্চিত করে যে সিস্টেম এখনও সঠিকভাবে কাজ করছে
8. Change Closure: সব ডকুমেন্ট স্বাক্ষরিত এবং ভ্যালিডেশন মাস্টার ফাইলে দাখিল করা হয়

৭. ডেটা ইন্টিগ্রিটি — ALCOA+ নীতি

ডেটা ইন্টিগ্রিটি ফার্মা কমপ্লায়েন্সের ভিত্তি। রেগুলেটরি সংস্থাগুলো ALCOA+ নীতির বিপরীতে ডেটাবেজ পরিবেশ মূল্যায়ন করে:

• Attributable: কে ডেটা তৈরি বা পরিবর্তন করেছে? (অডিট ট্রেইলে Oracle ইউজার আইডি)
• Legible: ডেটা কি পড়া ও বোঝা যায়? (উপযুক্ত ডেটা টাইপ, character set)
• Contemporaneous: ডেটা কি ঘটনার সময়েই রেকর্ড করা হয়েছিল? (সিস্টেম টাইমস্ট্যাম্প, ইউজার-এন্টার্ড তারিখ নয়)
• Original: প্রথম ধরা ডেটা কি সংরক্ষিত? (অডিট ট্রেইল মূল মান সংরক্ষণ করে)
• Accurate: ডেটা কি আসলে যা ঘটেছে তা প্রতিফলিত করে? (ভ্যালিডেটেড ইনপুট কন্ট্রোল, কোনো ম্যানুয়াল ওভাররাইড নয়)
• + Complete: সব প্রয়োজনীয় ডেটা কি উপস্থিত? (NOT NULL কনস্ট্রেইন্ট, ডেটাবেজ পর্যায়ে বাধ্যতামূলক ফিল্ড প্রয়োগ)
• + Consistent: ডেটা কি সিস্টেমজুড়ে সামঞ্জস্যপূর্ণ? (referential integrity, foreign key প্রয়োগ)
• + Enduring: ডেটা কি প্রয়োজনীয় রিটেনশন পিরিয়ডের জন্য সংরক্ষিত? (রিটেনশন পলিসি, আর্কাইভ কৌশল)
• + Available: প্রয়োজনের সময় ডেটা কি পুনরুদ্ধার করা যায়? (ব্যাকআপ + রিকভারি ভ্যালিডেশন, DR টেস্টিং)

৮. ভ্যালিডেটেড পরিবেশে ব্যাকআপ ও রিকভারি

ফার্মা Oracle পরিবেশে ব্যাকআপ ও রিকভারি স্ট্যান্ডার্ড RMAN কনফিগারেশনের বাইরে যায়। ব্যাকআপ কৌশল নিজেই ভ্যালিডেটেড হতে হবে — অর্থাৎ আপনাকে ডকুমেন্টেড প্রমাণসহ দেখাতে হবে যে আপনার ব্যাকআপ কাজ করে এবং আপনি সংজ্ঞায়িত Recovery Time Objective (RTO) ও Recovery Point Objective (RPO)-এর মধ্যে ডেটাবেজ পুনরুদ্ধার করতে পারেন।

ব্যাকআপের জন্য মূল ভ্যালিডেশন চাহিদা:

• IQ-তে RMAN ব্যাকআপ কনফিগারেশন ডকুমেন্টেড
• ব্যাকআপ সফলতা/ব্যর্থতা মনিটরিং — যেকোনো ব্যর্থ ব্যাকআপ জবে অ্যালার্ট
• নিয়মিত রিস্টোর টেস্ট — ন্যূনতম ত্রৈমাসিক, একটি নন-প্রোডাকশন পরিবেশে
• টাইমস্ট্যাম্পসহ রিস্টোর টেস্ট ফলাফল ডকুমেন্টেড ও QA সাক্ষী দ্বারা স্বাক্ষরিত
• RPO পূরণের জন্য যথেষ্ট archive log রিটেনশন
• ডিজাস্টার রিকভারির জন্য অফসাইট বা রেপ্লিকেটেড ব্যাকআপ কপি
• ব্যাকআপ মিডিয়া ইন্টিগ্রিটি যাচাই (RMAN VALIDATE)

-- Validate backup integrity (part of periodic review procedure)
RMAN> VALIDATE BACKUPSET ALL;
RMAN> RESTORE DATABASE VALIDATE;

৯. DGDA / FDA পরিদর্শনের প্রস্তুতি

যখন একজন রেগুলেটরি পরিদর্শক আপনার Oracle ডেটাবেজ পরিবেশ পরীক্ষা করেন, তখন তাঁরা সাধারণত চান:

• Validation Master Plan — কোন সিস্টেম ভ্যালিডেটেড এবং কোন মানে
• ডেটাবেজ ও অ্যাপ্লিকেশনের জন্য IQ / OQ / PQ ডকুমেন্টেশন
• বর্তমান ইউজার অ্যাক্সেস তালিকা — কার কী অ্যাক্সেস আছে এবং সাম্প্রতিক অ্যাক্সেস পর্যালোচনার প্রমাণ
• অডিট ট্রেইল নমুনা — তাঁরা একটি নির্দিষ্ট তারিখ পরিসীমা বা একটি নির্দিষ্ট রেকর্ডের জন্য অডিট লগ চাইতে পারেন
• চেঞ্জ কন্ট্রোল রেকর্ড — গত ১–২ বছরে করা সব পরিবর্তন
• ব্যাকআপ লগ ও রিস্টোর টেস্ট রেকর্ড
• সিস্টেম কনফিগারেশন ডকুমেন্টেশন (বর্তমান অবস্থা বনাম ভ্যালিডেটেড বেসলাইন)
• ডেটাবেজ অ্যাক্সেস আছে এমন যে কারও জন্য প্রশিক্ষণ রেকর্ড

ফার্মা Oracle অডিটে সবচেয়ে সাধারণ যে অনুসন্ধানগুলো observation বা warning letter-এ পরিণত হয়:

• শেয়ারড Oracle অ্যাকাউন্ট (একাধিক মানুষ একই লগইন ব্যবহার করছে)
• অডিট ট্রেইল অক্ষম বা সব নিয়ন্ত্রিত টেবিল কভার করছে না
• গত বছর করা ডেটাবেজ পরিবর্তনের জন্য কোনো ডকুমেন্টেড চেঞ্জ কন্ট্রোল নেই
• DBA অডিট ট্রেইল রেকর্ড মুছতে বা পরিবর্তন করতে পারে
• ব্যাকআপ রিস্টোর কখনও টেস্ট করা হয়নি — শুধু ব্যাকআপ জব যাচাই করা হয়, রিস্টোর নয়
• ইউজার অ্যাক্সেস কখনও পর্যালোচিত হয়নি — সাবেক কর্মীদের এখনও সক্রিয় অ্যাকাউন্ট আছে
• প্রোডাকশন ও ডেভেলপমেন্ট/টেস্ট পরিবেশ একই Oracle ইনস্ট্যান্সে

১০. ফার্মা পরিবেশে Oracle DBA-রা যে সাধারণ ভুল করেন

ফার্মা Oracle পরিবেশ সাপোর্ট করার আমার অভিজ্ঞতার ভিত্তিতে, এই ভুলগুলো সবচেয়ে বেশি রেগুলেটরি ঝুঁকি সৃষ্টি করে:

• চেঞ্জ কন্ট্রোল ছাড়া প্যাচ প্রয়োগ: "এটা তো শুধু একটা সিকিউরিটি প্যাচ" — একটি ভ্যালিডেটেড পরিবেশে এখনও চেঞ্জ কন্ট্রোল প্রয়োজন
• অ্যাপ্লিকেশন সংযোগে SYS বা SYSTEM ব্যবহার: অ্যাপ্লিকেশন SYS হিসেবে সংযোগ করলে সব অ্যাক্সেস কন্ট্রোল ও অডিট অ্যাট্রিবিউশন ব্যর্থ হয়
• পারফরম্যান্সের জন্য অডিটিং অক্ষম করা: অডিট ওভারহেড কনফিগারেশনের মাধ্যমে সামলাতে হবে, অডিট অক্ষম করে নয় — একটি ভ্যালিডেটেড পরিবেশে অডিট অক্ষম করা একটি critical finding
• পরিবেশ পৃথকীকরণ না করা: একই Oracle ইনস্ট্যান্সে প্রোডাকশন ও QC ডেটাবেজ চালানো ডেটা ইন্টিগ্রিটি ও অ্যাক্সেস কন্ট্রোল ঝুঁকি সৃষ্টি করে
• স্কিমা পরিবর্তন সরাসরি প্রোডাকশনে ডিপ্লয়: সব DDL পরিবর্তন চেঞ্জ কন্ট্রোলের মধ্য দিয়ে যেতে হবে এবং প্রথমে একটি নন-প্রোডাকশন পরিবেশে টেস্ট করতে হবে
• অডকুমেন্টেড জরুরি পরিবর্তন: চাপের মধ্যে করা জরুরি ফিক্সও অবশ্যই পূর্ববর্তীভাবে চেঞ্জ কন্ট্রোলে ডকুমেন্ট করতে হবে

১১. ফার্মা Oracle ভ্যালিডেশনে আমার অভিজ্ঞতা

আমার Oracle Certified Professional ক্রেডেনশিয়ালের পাশাপাশি আমি আনুষ্ঠানিক Computer System Validation সার্টিফিকেশন ধারণ করি — একটি সংমিশ্রণ যা বাংলাদেশের আইটি বাজারে অস্বাভাবিক। আমার কর্মজীবনে আমি বাংলাদেশের একটি শীর্ষস্থানীয় ফার্মাসিউটিক্যাল গ্রুপে Oracle ডেটাবেজ পরিবেশ সাপোর্ট করেছি, যেখানে কাজের মধ্যে ছিল:

• ম্যানুফ্যাকচারিং ERP সমর্থনকারী Oracle ডেটাবেজ ইনস্টলেশনের জন্য IQ/OQ ডকুমেন্টেশন ডিজাইন ও সম্পাদন
• নিয়ন্ত্রিত ম্যানুফ্যাকচারিং ডেটার জন্য অডিট ট্রেইল কনফিগারেশন বাস্তবায়ন ও ভ্যালিডেট
• Oracle প্যাচিং ও স্কিমা পরিবর্তনের জন্য চেঞ্জ কন্ট্রোল প্রক্রিয়া সমর্থন
• রেগুলেটরি পরিদর্শনের জন্য ডেটাবেজ-লেভেল ডকুমেন্টেশন প্রস্তুত
• ভ্যালিডেটেড পরিবেশের চাহিদা নিয়ে অ্যাপ্লিকেশন ইউজার ও আইটি স্টাফকে প্রশিক্ষণ
• ফার্মা ব্যবসায়িক ধারাবাহিকতার চাহিদার সাথে Oracle ব্যাকআপ ও রিকভারি প্রক্রিয়া একীভূত করা

আপনার প্রতিষ্ঠান যদি একটি DGDA পরিদর্শনের প্রস্তুতি নিচ্ছে, একটি ভ্যালিডেটেড পরিবেশে Oracle আপগ্রেড পরিকল্পনা করছে, কিংবা CSV চাহিদা পূরণ করতে হবে এমন একটি নতুন ফার্মা ERP সিস্টেম তৈরি করছে — এই কাজটি আমি প্রযুক্তিগত ও রেগুলেটরি উভয় দৃষ্টিকোণ থেকেই বুঝি।

শেষ কথা

Computer System Validation নিজের খাতিরে আমলাতন্ত্র নয় — এটি সেই শৃঙ্খলা যা নিশ্চিত করে যে প্রতিটি ব্যাচ রিলিজ সিদ্ধান্ত, প্রতিটি কোয়ালিটি রেকর্ড এবং রোগীদের কাছে পাঠানো প্রতিটি পণ্যকে সমর্থনকারী ডেটা বিশ্বাসযোগ্য ও প্রতিরক্ষাযোগ্য। ফার্মায় কাজ করা Oracle DBA-দের জন্য এর মানে সাধারণ আইটি পরিবেশের চেয়ে উচ্চতর মানে কাজ করা: প্রতিটি পরিবর্তন ডকুমেন্টেড, প্রতিটি অ্যাক্সেস নিয়ন্ত্রিত, প্রতিটি ব্যাকআপ টেস্টেড, প্রতিটি অডিট ট্রেইল অক্ষত।

Oracle DBA দক্ষতা ও CSV জ্ঞানের সংমিশ্রণ বিরল। অধিকাংশ প্রতিষ্ঠানের হয় এমন একজন DBA থাকে যিনি রেগুলেটরি কাঠামো বোঝেন না, অথবা এমন একজন ভ্যালিডেশন বিশেষজ্ঞ থাকেন যিনি ডেটাবেজ প্রযুক্তি বোঝেন না। এই ফাঁক পূরণ করা — প্রযুক্তিগত বাস্তবায়ন ও রেগুলেটরি চাহিদা উভয়ই বোঝা — এটিই ফার্মা Oracle কাজকে পরিদর্শনে প্রতিরক্ষাযোগ্য ও প্রোডাকশনে নির্ভরযোগ্য করে তোলে।