Oracle Cloud (OCI) মাইগ্রেশন: Deployment অপশন, পদ্ধতি, Downtime ও খরচ গাইড

"আমাদের Oracle ডেটাবেজগুলো কি ক্লাউডে সরিয়ে নেওয়া উচিত?" — আইটি ম্যানেজারদের কাছ থেকে সবচেয়ে বেশি যে প্রশ্ন পাই তার একটি এটি, আর সৎ উত্তর হলো: নির্ভর করে — আপনার workload, আপনার downtime সহনশীলতা, আপনার কমপ্লায়েন্স সীমাবদ্ধতা, আর সবচেয়ে বড় কথা, শুরুর আগেই খরচ বুঝছেন কিনা তার ওপর। ভালোভাবে করা ক্লাউড মাইগ্রেশন hardware refresh চক্র কমায়, patching ও backup সহজ করে, আর elastic ক্ষমতা দেয়। খারাপভাবে করা ক্লাউড মাইগ্রেশন একটি চমকে দেওয়া বিল, একটি পারফরম্যান্স অবনতি, আর এমন একটি টিম তৈরি করে যারা ভাবে অন-প্রিমিসেই থেকে গেলে ভালো হতো। এই গাইডে Oracle Cloud Infrastructure (OCI) বাস্তবসম্মতভাবে ব্যাখ্যা করছি: deployment অপশন, মাইগ্রেশন পদ্ধতি ও প্রতিটির downtime খরচ, দাম আসলে কীভাবে কাজ করে, আর বাস্তব মাইগ্রেশনের ভিত্তিতে একটি ধাপে-ধাপে পরিকল্পনা।

১. Oracle-কে OCI-তে কেন সরাবেন (এবং কেন নয়)

Oracle Cloud Infrastructure হলো Oracle-এর নিজের ক্লাউড, আর Oracle workload-এর জন্য এর একটি প্রকৃত সুবিধা আছে: licensing ও engineering একই সারিতে থাকে। Autonomous Database ও Exadata Cloud Service সেই একই engine চালায় যা Oracle বানায়, সঙ্গে স্বয়ংক্রিয় patching, backup, এবং (Autonomous-এর ক্ষেত্রে) self-tuning। সরানোর সৎ যুক্তি:

• আর hardware refresh নয়: প্রতি ৪–৫ বছর অন্তর সার্ভার কেনা আর "কী জানি লাগে" ভেবে অতিরিক্ত provision করা বন্ধ হয়।
• অপারেশনাল স্বয়ংক্রিয়তা: Patching, backup, এবং (Autonomous-এর সঙ্গে) tuning প্ল্যাটফর্মই সামলায়।
• Elastic ক্ষমতা: মাস-শেষের জন্য CPU বাড়ান, পরে কমিয়ে দিন — যতটুকু ব্যবহার করেন কেবল ততটুকুরই দাম দিন।
• Built-in HA/DR: দ্বিতীয় একটি ডেটা সেন্টার না কিনেই cross-availability-domain ও cross-region Data Guard।

আর সতর্কতার সৎ যুক্তি: যদি আগেই টাকা দিয়ে কেনা hardware-এ আপনার কম, অনুমানযোগ্য লোড থাকে, যদি data-residency নিয়মওয়ালা দেশে থাকেন, কিংবা এমন একটি অ্যাপ্লিকেশন চালান যা কেবল নির্দিষ্ট একটি অন-প্রিমিস কনফিগারেশনে সার্টিফায়েড, তাহলে ক্লাউড বেশি খরচ করে কম দিতে পারে। আমি সবসময় "cloud-first" আদেশের বদলে workload-ধরে-workload মূল্যায়নের পরামর্শ দিই। ভুল ডেটাবেজটি ক্লাউডে সরানো একটি সাধারণ ও ব্যয়বহুল ভুল।

২. OCI ডেটাবেজ Deployment অপশন

OCI একটি মাত্র পণ্য নয় — সঠিক service বেছে নেওয়াই একক সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত, কারণ এটিই খরচ, নিয়ন্ত্রণ এবং কতটা প্রশাসন আপনার দায়িত্বে থাকবে তা নির্ধারণ করে।

অপশন	যার জন্য সেরা	আপনি সামলাবেন
Autonomous Database	নতুন অ্যাপ, data warehouse, ন্যূনতম DBA পরিশ্রম চায় এমন টিম	শুধু schema ও ডেটা — বাকিটা Oracle সামলায়
Exadata Cloud Service (ExaCS)	চরম পারফরম্যান্স দরকার এমন বড়, mission-critical OLTP / মিশ্র workload	ডেটাবেজ ও config; Exadata hardware Oracle সামলায়
Base Database Service	পূর্ণ নিয়ন্ত্রণ দরকার এমন বিদ্যমান ডেটাবেজের lift-and-shift	একটি managed VM-এ পূর্ণ ডেটাবেজ প্রশাসন
Database on Compute (IaaS)	সর্বোচ্চ নিয়ন্ত্রণ, custom config, অ-প্রমিত setup	সবকিছু — OS, ডেটাবেজ, backup, patching

থাম্ব রুল হিসেবে: যখন DBA কাজের চাপ কমাতে চান এবং অ্যাপ্লিকেশন সামঞ্জস্যপূর্ণ, তখন Autonomous বেছে নিন; যখন parameter, patching সময়সূচি ও customisation-এর ওপর পূর্ণ নিয়ন্ত্রণসহ একটি বিশ্বস্ত lift-and-shift দরকার, তখন Base Database / Exadata বেছে নিন। বিদ্যমান জটিল ডেটাবেজওয়ালা বেশিরভাগ এন্টারপ্রাইজ Base Database বা ExaCS দিয়ে শুরু করে এবং নতুন workload-এর জন্য Autonomous বিবেচনা করে।

৩. মাইগ্রেশন পদ্ধতি — এবং প্রতিটির Downtime খরচ

আপনি যে পদ্ধতি বেছে নেবেন তা সবার আগে একটি প্রশ্ন দিয়ে চালিত: ব্যবসা কতটা downtime সহ্য করতে পারে? সেটি, সঙ্গে আপনার ডেটাবেজের আকার ও version, পছন্দটি দ্রুত সংকীর্ণ করে ফেলে।

৩.১ Data Pump (Export / Import) — সবচেয়ে সরল, সবচেয়ে বেশি Downtime

ধ্রুপদী পদ্ধতি: source export করুন, dump ফাইল OCI Object Storage-এ কপি করুন, target-এ import করুন। সরল ও নির্ভরযোগ্য, তবে export + transfer + import যতক্ষণ চলে ততক্ষণ ডেটাবেজ কার্যত অফলাইন — ছোট ডেটাবেজ বা উদার maintenance window-এর জন্য ঠিক আছে। টুলটি নিয়ে আমি বিস্তারিত লিখেছি আমার Data Pump গাইডে; OCI-র বাড়তি দিকটি হলো Object Storage credential আর একটি URL থেকে import চালানো।

-- Export on source
expdp system/****@PRODDB full=Y
  directory=DATA_PUMP_DIR
  dumpfile=proddb_full_%U.dmp
  filesize=10G parallel=8
  logfile=proddb_exp.log

-- Upload dumpfiles to OCI Object Storage, then import on target ADB
impdp admin/****@TARGET_high
  directory=DATA_PUMP_DIR
  credential=OCI_CRED
  dumpfile=https://objectstorage.../proddb_full_%U.dmp
  parallel=8 logfile=proddb_imp.log
  transform=segment_attributes:n

৩.২ Zero Downtime Migration (ZDM) — Oracle-এর স্বয়ংক্রিয় টুল

ZDM হলো Oracle-এর বিনামূল্যের, সমর্থিত স্বয়ংক্রিয়তা যা একটি মাইগ্রেশন end-to-end সাজায়, সাধারণত ক্লাউডে একটি Data Guard standby ব্যবহার করে যাতে cutover downtime ন্যূনতম হয়। OCI-তে বেশিরভাগ প্রোডাকশন মাইগ্রেশনের জন্য আমি ZDM পরামর্শ দিই — এটি সেই ধাপগুলো script করে দেয় যা হাতে করতে গেলে ভুল হওয়ার ঝুঁকি থাকে।

# Evaluate (dry run) — validates everything without migrating
$ZDM_HOME/bin/zdmcli migrate database
  -sourcedb PRODDB
  -rsp /home/zdmuser/proddb.rsp
  -sourcenode onprem-db01
  -targetnode oci-db01
  -eval

# Run the actual migration
$ZDM_HOME/bin/zdmcli migrate database
  -sourcedb PRODDB -rsp /home/zdmuser/proddb.rsp
  -sourcenode onprem-db01 -targetnode oci-db01

৩.৩ Data Guard — বড় ডেটাবেজের জন্য প্রায়-শূন্য Downtime

OCI-তে একটি physical standby গড়ুন, নেটওয়ার্কের ওপর দিয়ে সেটিকে অন-প্রিমিস primary-র সঙ্গে sync হতে দিন, আর সম্পূর্ণ catch-up হয়ে গেলে একটি switchover করুন। Cutover downtime কেবল সেই switchover-টুকুই — প্রায়ই কয়েক সেকেন্ড থেকে দু-এক মিনিট। যেসব বড়, ব্যস্ত ডেটাবেজ দীর্ঘ outage সহ্য করতে পারে না তাদের জন্য এই পদ্ধতি। আপনি যদি ইতিমধ্যে অন-প্রিমিসে Data Guard চালান, ক্লাউড standby সেই একই অনুশাসন কেবল ভিন্ন একটি ডেটা সেন্টারের দিকে তাক করা — আর switchover-এর কারিগরি দিকগুলো হুবহু একই।

৩.৪ GoldenGate — Cross-Version, Heterogeneous, বা Validation সহ প্রায়-শূন্য

সবচেয়ে কঠিন ক্ষেত্রগুলোর জন্য — major version জুড়ে মাইগ্রেট করা, ভিন্ন প্ল্যাটফর্মের মধ্যে, কিংবা যেখানে পুরনো ও নতুন সমান্তরালে চালিয়ে cutover-এর আগে validate করা দরকার — Oracle GoldenGate প্রায়-শূন্য downtime সহ logical replication দেয়। এটি সবচেয়ে নমনীয় এবং সবচেয়ে জটিল; যেসব ক্ষেত্র সরল পদ্ধতিগুলো সামলাতে পারে না কেবল তাদের জন্য একে সংরক্ষণ করুন।

৩.৫ পদ্ধতি বেছে নেওয়া

• ছোট DB, নমনীয় window: Data Pump।
• স্ট্যান্ডার্ড প্রোডাকশন মাইগ্রেশন: ZDM (এটি সাধারণত আড়ালে Data Guard চালায়)।
• বড়, mission-critical, ন্যূনতম outage: Data Guard switchover।
• Cross-version / heterogeneous / সমান্তরাল-রান validation: GoldenGate।

৪. নেটওয়ার্ক — যে ধাপটি টিমগুলো কম গুরুত্ব দেয়

পাবলিক ইন্টারনেটের ওপর দিয়ে টেরাবাইট সরানো ধীর ও উন্মুক্ত। নেটওয়ার্ক আগেভাগে পরিকল্পনা করুন:

• FastConnect আপনার ডেটা সেন্টার ও OCI-এর মধ্যে একটি প্রাইভেট, ডেডিকেটেড, অনুমানযোগ্য-bandwidth লিংক দেয় — বড় বা চলমান transfer-এর জন্য সঠিক পছন্দ।
• Site-to-Site VPN (IPSec-এর ওপর) ছোট workload-এর জন্য সস্তা একটি অপশন।
• খুব বড় ডেটাবেজের এককালীন bulk load-এর জন্য OCI Object Storage-এ dump ফাইল staging করে সেখান থেকে import করা প্রায়ই একটি live নেটওয়ার্ক pull-এর চেয়ে দ্রুত।
• সবসময় প্রথমে বাস্তবে অর্জনযোগ্য throughput মাপুন — তাত্ত্বিক bandwidth-এর ওপর গড়া মাইগ্রেশন পরিকল্পনা মানেই এমন পরিকল্পনা যা তার window ছাড়িয়ে যায়।

৪.১ Hybrid Latency-র ফাঁদ

এমন একটি দ্বিতীয় নেটওয়ার্ক সমস্যা আছে যার জন্য কেউ বাজেট রাখে না: মাইগ্রেশনের পরে কী হয়, যখন অ্যাপ্লিকেশন অন-প্রিমিসে থেকে যায় আর কেবল ডেটাবেজটি সরে। প্রতিটি SQL round trip এখন আপনার ডেটা সেন্টার ও OCI region-এর মাঝের লিংকটি পার হয়।

LAN-এ একটি round trip-এর খরচ এক মিলিসেকেন্ডের ভগ্নাংশ। একটি ক্লাউড region-এ ভূগোলভেদে তা হতে পারে ৫, ২০ বা ৬০ মিলিসেকেন্ড। শুনতে তুচ্ছ লাগে — যতক্ষণ না মনে পড়ে একটি সাধারণ ERP স্ক্রিন কতটা কথাবার্তায় ভরা (chatty)। আমি এমন স্ক্রিন trace করেছি যা render করতে ৪০০টি single-row query ছুড়েছে। প্রতিটি ০.৩ ms হলে কেউ টের পায় না; প্রতিটি ২০ ms হলে সেই স্ক্রিন এখন আট সেকেন্ড নেয় আর ব্যবহারকারীরা ফোন তুলে নেয়।

Hybrid ডিজাইনে প্রতিশ্রুতি দেওয়ার আগে আমি একটি সরল পরীক্ষা চালাই: অ্যাপ্লিকেশন সার্ভার থেকে target region-এ ping করি, তারপর OCI-তে একটি pilot ডেটাবেজের বিপরীতে একটি প্রতিনিধিত্বমূলক business transaction চালিয়ে SQL*Net roundtrips to/from client পরিসংখ্যান তুলনা করি। অ্যাপ্লিকেশন যদি chatty হয়, হয় অ্যাপ্লিকেশন tier-ও ডেটাবেজের সঙ্গে OCI-তে যাবে, নয়তো আগে chattiness-টা ঠিক করতে হবে। Latency-কে না দেখার ভান করা কাজ করে না — physics সবসময় জেতে।

৫. খরচ — OCI প্রাইসিং আসলে কীভাবে কাজ করে

এখানেই বেশিরভাগ ক্লাউড প্রকল্প ভুল করে। ক্লাউড খরচ একটি একক সংখ্যা নয়; এটি ক্রমাগত চলতে থাকা কয়েকটি মিটারের যোগফল। একে নিয়ন্ত্রণ করতে হলে সেগুলো বুঝতে হবে:

• Compute (OCPU/ECPU): সবচেয়ে বড় খরচের খাত। Autonomous আপনাকে CPU বাড়ানো-কমানো করতে দেয় — এটি ব্যবহার করুন। কেবল মাস-শেষে যতটুকু লাগে এমন একটি workload-এর জন্য দিনরাত ১৬টি CPU চালিয়ে রাখা অপচয়ের সবচেয়ে সাধারণ উৎস।
• Storage: ডেটাবেজ storage সঙ্গে backup storage। Backup জমে ওঠে; যুক্তিসঙ্গত retention সেট করুন।
• Egress (ডেটা বাইরে): OCI থেকে বেরিয়ে যাওয়া ডেটা মিটার করা হয়। ভেতরে আসা সাধারণত বিনামূল্যে। কথাবার্তায় ভরা cross-region বা back-to-on-prem ট্রাফিক জমে ওঠে।
• Licensing মডেল: "License Included" ঘণ্টাপ্রতি রেটে Oracle লাইসেন্স মিশিয়ে দেয়; "Bring Your Own License" (BYOL) আপনার আগে থেকে থাকা লাইসেন্স পুনরায় ব্যবহার করে এবং সেগুলো থাকলে অনেক সস্তা। ভুলটি বেছে নিলে আপনার বিল দ্বিগুণ হয়ে যেতে পারে।

ব্যবহারিক খরচ-শৃঙ্খলা: fixed বড় shape-এর বদলে Autonomous auto-scaling চালু করুন, প্রথম দিন থেকেই OCI-তে বাজেট ও alert সেট করুন, লাইসেন্স থাকলে BYOL ব্যবহার করুন, non-production ডেটাবেজগুলোকে রাতে ও সপ্তাহান্তে বন্ধ করার সময়সূচি দিন, আর প্রতি মাসে খরচের dashboard পর্যালোচনা করুন। যেসব টিম খরচকে একটি চলমান অপারেশনাল মেট্রিক হিসেবে দেখে — এককালীন অনুমান হিসেবে নয় — তাদেরই ক্লাউড বিল অনুমানযোগ্য থাকে।

৬. যে মূল্যায়ন সবাই এড়িয়ে যায় — Licensing ও Egress

একটি মাইগ্রেশন মূল্যায়নে কী কী থাকা উচিত? কোনো technical ডিজাইনের আগে যাচাই করুন ঠিক কোন Oracle লাইসেন্সগুলোর মালিক আপনি, সেগুলো BYOL-এর যোগ্য কিনা, আর প্রতি মাসে কী পরিমাণ ডেটা OCI থেকে বাইরে যাবে। এই দুটি বিষয় — licensing মডেল ও egress — আপনি যে shape বাছবেন তার চেয়েও বেশি করে আপনার মাসিক বিল নির্ধারণ করে, অথচ বেশিরভাগ টিম সেগুলো আবিষ্কার করে চুক্তি সইয়ের পরে।

Licensing-এর হোমওয়ার্কটি আকর্ষণহীন, তবে নিজের খরচ বহু গুণে তুলে দেয়। আপনার Oracle ordering document গুলো বের করে গুনুন আসলে কী আছে: Enterprise Edition processor লাইসেন্স, Partitioning বা Advanced Security-র মতো option, আর support চলমান কিনা (BYOL-এর জন্য সক্রিয় support লাগে)। আমি এমন ক্লায়েন্ট দেখেছি যারা প্রতিটি ডেটাবেজের জন্য License Included ধরে বাজেট করেছিল — পরে দেখা গেল পুরো estate BYOL-এ চালানোর মতো যথেষ্ট EE processor তাদের আগেই ছিল; সংশোধিত অনুমান প্রায় ৪০% কম। উল্টোটাও দেখেছি: একটি টিম BYOL ধরে নিয়েছিল, তারপর আবিষ্কার করল তাদের লাইসেন্স Standard Edition আর target shape-এর জন্য Enterprise দরকার। সেই চমক এসেছিল চুক্তি সইয়ের এক সপ্তাহ আগে।

Egress হলো নীরব ফাঁদ। ডেটাবেজের ডেটার প্রতিটি ভোক্তার মানচিত্র বানান: অন-প্রিমিস ফাইল সার্ভারে টানা রিপোর্ট, অন-প্রিমিসে থেকে যাওয়া একটি data warehouse-এ রাত্রিকালীন extract, replication feed, কমপ্লায়েন্সের জন্য ফেরত পাঠানো backup কপি। এগুলোর প্রতিটিই OCI ছেড়ে যাওয়া মিটার-করা ট্রাফিক। রাতপ্রতি সামান্য ২০০ GB extract মানে মাসে প্রায় ৬ TB — প্রতি মাসে, চিরকাল। দ্বিতীয় invoice হাতে আসার সময় নয়, মাইগ্রেশনের আগেই এটি মডেল করুন।

৭. মাঝ-মাইগ্রেশনে কামড় বসানো চমকগুলো

প্রতিটি মাইগ্রেশন পরিকল্পনা টিকে থাকে source ডেটাবেজের সঙ্গে প্রথম সাক্ষাৎ পর্যন্ত। এই চমকগুলো আমি এখন প্রথম দিনেই খুঁজে দেখি, কারণ এদের প্রতিটি কোনো না কোনো সময় আমার ঘণ্টার পর ঘণ্টা (বা একটি সপ্তাহান্ত) খেয়ে নিয়েছে:

• Character set: Autonomous Database হলো AL32UTF8 — ব্যস, এটুকুই। আপনার source যদি WE8ISO8859P1 বা WE8MSWIN1252 হয়, single-byte অক্ষর import-এ multi-byte হয়ে যেতে পারে, আর অন-প্রিমিসে আরামে ভরে থাকা একটি VARCHAR2(50 BYTE) কলাম ক্লাউডে ORA-12899 দিয়ে উপচে পড়ে। এক মাইগ্রেশনে প্রথম test import-এই আমরা হাজার হাজার এমন পেয়েছিলাম। সমাধানটি — extended character semantics বা কলাম চওড়া করা — সহজ; cutover রাতের ২টায় এটি আবিষ্কার করা সহজ নয়। আপনার আসল ডেটা আগেভাগে test-import করুন।
• TDE বাধ্যতামূলক: OCI-তে ডেটাবেজ storage encrypted — সবসময়। আপনার অন-প্রিমিস ডেটাবেজ কখনো Transparent Data Encryption ব্যবহার না করে থাকলে, আপনার টিম এখন একটি wallet ও একটি master key-র lifecycle-এর মালিক। TDE wallet হারানো মানে ডেটাবেজটাই হারানো, তাই key কোথায় থাকবে (OCI Vault নাকি wallet ফাইল), কে rotate করতে পারবে, কীভাবে backup হবে — মাইগ্রেশনের দিনের আগেই ঠিক করুন।
• Timezone আচরণ: ক্লাউড VM ডিফল্টে UTC। আপনার অ্যাপ্লিকেশন যদি SYSDATE-এর স্থানীয় সময় ফেরত দেওয়ার ওপর নির্ভর করে — আর বাংলাদেশে আমি যত ERP ছুঁয়েছি সবগুলোই করে — তাহলে OS ও ডেটাবেজ স্তরে সচেতনভাবে timezone সেট করতে হবে, নয়তো cutover-এর পরে লেখা প্রতিটি timestamp ছয় ঘণ্টা এদিক-ওদিক হবে। আমরা এটি একটি pilot-এ ধরেছিলাম, যখন ঢাকার সকাল ৯টায় "আজকের লেনদেন" রিপোর্টটি খালি এসেছিল।
• Database link ও DNS: যে link গুলো আপনার অন-প্রিমিস DNS দিয়ে hostname resolve করে, ডেটাবেজ একটি VCN-এ জেগে ওঠার মুহূর্তেই সেগুলো কাজ বন্ধ করে দেয়। সরানোর আগে প্রতিটি database link, external table, directory object ও UTL_FILE path-এর তালিকা করুন — এরাই সেই অদৃশ্য নির্ভরতা যা কেবল একটি month-end job চলার সময়েই fail করে।
• Sequence, job ও password: Scheduler job এমন টুল রেফার করতে পারে যা target-এ নেই, Autonomous-এ profile password-এর নিয়ম ভিন্ন, আর case-sensitivity-র ডিফল্টগুলো কড়া। এগুলোর কোনোটিই কঠিন নয়; না দেখে রাখলে cutover-এ সবগুলোই বিরক্তিকর।

৮. Post-Migration পারফরম্যান্স Validation — আমি আসলে যা যাচাই করি

ক্লাউড ডেটাবেজটি পুরনোটির মতোই ভালো চলছে — তা প্রমাণ করবেন কীভাবে? Cutover-এর আগে source থেকে একটি পারফরম্যান্স baseline ধরে রাখুন, তারপর AWR আর গুটিকয়েক প্রতিনিধিত্বমূলক business transaction দিয়ে target-এ একই workload তুলনা করুন। Baseline ছাড়া মাইগ্রেশনের পরের প্রতিটি "সিস্টেম ধীর লাগছে" অভিযোগ এমন এক তর্কে পরিণত হয় যা কেউ জিততে পারে না।

আমার validation সেট, যে ক্রমে চালাই:

-- 1. Baseline BEFORE migration: keep a month of AWR on the source
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
       retention => 43200);   -- minutes = 30 days

-- 2. After cutover: compare top SQL by elapsed time per execution
SELECT sql_id, executions,
       ROUND(elapsed_time/NULLIF(executions,0)/1e6,3) AS sec_per_exec
FROM   v$sqlstats
ORDER  BY elapsed_time DESC FETCH FIRST 20 ROWS ONLY;

-- 3. Check nothing lost its plan: compare against source AWR
--    (awrsqrpt.sql on source vs target for the same sql_id)

-- 4. Confirm statistics are fresh on the target
SELECT COUNT(*) FROM dba_tab_statistics
WHERE  owner = 'APPOWNER' AND (stale_stats = 'YES' OR last_analyzed IS NULL);

SQL-এর বাইরে আমি সেই একঘেয়ে জিনিসগুলো যাচাই করি যা প্রায়ই বাদ পড়ে: RMAN বা automatic backup আসলেই সম্পন্ন হচ্ছে (প্রমাণ হিসেবে একটি ফাইল restore করুন), Data Guard বা cross-region DR ঠিকঠাক log পাঠাচ্ছে, একটি পূর্ণ ব্যবসায়িক দিন ধরে alert log পরিষ্কার, batch job গুলো তাদের পুরনো window-র ভেতরেই শেষ হচ্ছে, আর আসলটির আগে একটি clone-এ month-end close পরীক্ষা করা। আমার health check চর্চার নিয়মটি মাইগ্রেশনের পরে দ্বিগুণ প্রযোজ্য: একটি সিস্টেম validate হয় প্রমাণ দিয়ে, প্রথম সপ্তাহে অভিযোগ না আসা দিয়ে নয়।

আরেকটি অভ্যাস যা আমাকে বহুবার বাঁচিয়েছে: cutover-এর পরে অন্তত একটি পূর্ণ business cycle — month-end সহ — source ডেটাবেজটি অক্ষত ও recoverable রাখুন। Storage সস্তা; চাপের মুখে পুনরায় মাইগ্রেট করা সস্তা নয়।

৯. ক্লাউডে নিরাপত্তা ও কমপ্লায়েন্স

অন-প্রিমিস Oracle-এর নিরাপত্তা নিয়ন্ত্রণগুলো OCI-তেও প্রযোজ্য — TDE, network encryption, Database Vault, Unified Auditing — এবং কয়েকটি Autonomous Database-এ ডিফল্টে চালু থাকে (ডেটা সবসময় encrypted)। অতিরিক্ত ক্লাউড-নির্দিষ্ট বিবেচনা:

• Identity & Access Management (IAM): কেবল ডেটাবেজের ভেতরে নয়, ক্লাউড স্তরেও পরিবেশ আলাদা করতে ও least privilege প্রয়োগ করতে OCI policy ও compartment ব্যবহার করুন।
• Data residency: আপনার নিয়ন্ত্রক ও চুক্তিগত বাধ্যবাধকতা পূরণ করে এমন একটি region বেছে নিন — নিয়ন্ত্রিত ডেটা মাইগ্রেট করার আগে এটি নিশ্চিত করুন।
• Private networking: ডেটাবেজগুলোকে পাবলিক IP ছাড়া private subnet-এ রাখুন; আপনার VCN, FastConnect বা VPN দিয়ে সেগুলোতে পৌঁছান।
• Audit: পূর্ণ জবাবদিহির জন্য OCI Audit (control-plane action) ও ডেটাবেজ Unified Auditing (data-plane action) একত্রে ব্যবহার করুন।

১০. একটি ধাপে-ধাপে মাইগ্রেশন পরিকল্পনা

1. মূল্যায়ন (২–৪ সপ্তাহ): প্রতিটি ডেটাবেজ, তার আকার, version, workload প্যাটার্ন, downtime সহনশীলতা ও কমপ্লায়েন্স সীমাবদ্ধতা তালিকাভুক্ত করুন। কোন ডেটাবেজ সরানো উচিত আর কোনটি নয় — ঠিক করুন।
2. ডিজাইন: প্রতিটি ডেটাবেজের জন্য deployment অপশন ও মাইগ্রেশন পদ্ধতি বেছে নিন। target-এর আকার দিন, নেটওয়ার্ক পরিকল্পনা করুন, licensing মডেল বেছে নিন এবং একটি খরচ অনুমান গড়ুন।
3. Pilot: একটি non-critical ডেটাবেজ end-to-end মাইগ্রেট করুন। পারফরম্যান্স, backup, connectivity ও অনুমানের বিপরীতে প্রকৃত খরচ যাচাই করুন। এখানেই সস্তায় চমকগুলো ধরা পড়ে।
4. ঢেউয়ে ঢেউয়ে মাইগ্রেট করুন: ডেটাবেজগুলো batch-এ সরান, সবচেয়ে কম-ঝুঁকিরটা আগে, প্রতিটির জন্য পরীক্ষিত rollback রেখে। পদ্ধতি অনুমতি দিলে source ও target সমান্তরালে চালান, আর cutover-এর আগে validate করুন।
5. অপ্টিমাইজ ও পরিচালনা: cutover-এর পর shape-এর সঠিক আকার দিন, auto-scaling tune করুন, backup ও DR নিশ্চিত করুন এবং মাসিক খরচ পর্যালোচনা প্রতিষ্ঠা করুন। মাইগ্রেশন cutover-এ শেষ হয় না — যখন এটি স্থিতিশীল ও খরচ-নিয়ন্ত্রিত হয় তখনই শেষ হয়।

১১. একটি বাস্তব মাইগ্রেশন

কেস — এক-ঘণ্টার window নিয়ে ম্যানুফ্যাকচারিং ERP-কে OCI-তে

পরিস্থিতি: একটি ম্যানুফ্যাকচারিং গ্রুপ পুরনো হয়ে refresh-এর সময় হওয়া অন-প্রিমিস hardware-এ একটি multi-terabyte ERP ডেটাবেজ চালাত। ব্যবসা কেবল একটি ছোট maintenance window সহ্য করতে পারত এবং একটি "big bang" cutover নিয়ে উদ্বিগ্ন ছিল।

পদ্ধতি: Data Pump-এর বদলে (যা বহু ঘণ্টা অফলাইন থাকতে বাধ্য করত), আমরা OCI-তে একটি Data Guard standby গড়লাম, প্রোডাকশন চালু থাকা অবস্থায় একটি FastConnect লিংকের ওপর দিয়ে সেটিকে synchronise করলাম এবং standby-টি পুঙ্খানুপুঙ্খভাবে validate করলাম। নির্ধারিত window-তে আমরা একটি switchover করলাম — প্রকৃত downtime ছিল কয়েক মিনিট — মূল অন-প্রিমিস ডেটাবেজটিকে একটি নিরাপদ rollback পথের জন্য fallback standby হিসেবে রেখে দিলাম।

ফলাফল: refresh hardware কেনা এড়ানো গেল, patching ও backup managed প্ল্যাটফর্মে চলে গেল, আর BYOL licensing মাসিক খরচকে business case-এর সঙ্গে সঙ্গতিপূর্ণ রাখল। রেখে দেওয়া fallback কখনো লাগেনি, তবে এগিয়ে যাওয়ার আত্মবিশ্বাস সবাইকে দিয়েছিল।

সাধারণ জিজ্ঞাসা (FAQ)

Oracle থেকে OCI মাইগ্রেশনে কত সময় লাগে?

একটি একক প্রোডাকশন ডেটাবেজের জন্য end-to-end ৬–১২ সপ্তাহের পরিকল্পনা করুন: ২–৪ সপ্তাহ মূল্যায়ন, নেটওয়ার্ক ও target build, একটি pilot মাইগ্রেশন, তারপর প্রোডাকশন cutover। Cutover নিজে কয়েক ঘণ্টা (Data Pump) থেকে কয়েক মিনিট (Data Guard switchover বা ZDM) পর্যন্ত হয়। পুরো estate-এর প্রোগ্রাম কয়েক মাস ধরে ঢেউয়ে ঢেউয়ে চলে।

OCI-তে BYOL নাকি License Included বেছে নেব?

Target edition ও option-এর সঙ্গে মেলে এমন চলমান, supported Oracle লাইসেন্স যদি আপনার থাকে, BYOL প্রায় সবসময়ই উল্লেখযোগ্যভাবে সস্তা — প্রায়ই রেটের অর্ধেকের কাছাকাছি। License Included অর্থবহ যখন আপনার কোনো লাইসেন্স নেই, কমপ্লায়েন্স নিয়ে অনিশ্চিত, বা অন-প্রিমিস লাইসেন্স অবসরে পাঠাতে চান। সিদ্ধান্তের আগে আপনার ordering document গুলো audit করুন; ভুল পছন্দ বিল দ্বিগুণ করে দিতে পারে।

পুরনো Oracle version কি সরাসরি Autonomous Database-এ মাইগ্রেট করা যায়?

জায়গায় বসে নয় — Autonomous চালায় Oracle-এর current release, তাই পুরনো source গুলো logical পথে যায়, সাধারণত physical standby-র বদলে Data Pump বা GoldenGate দিয়ে। এতে সরানোটা একই সঙ্গে একটি upgrade ও একটি মাইগ্রেশন হয়ে দাঁড়ায়, তাই নতুন version-এর বিপরীতে অ্যাপ্লিকেশন সামঞ্জস্য আগেভাগে পরীক্ষা করুন — cutover-এর সপ্তাহান্তে নয়।

Oracle Zero Downtime Migration (ZDM) কি সত্যিই বিনামূল্যের?

হ্যাঁ — ZDM একটি বিনামূল্যের, সম্পূর্ণ supported Oracle টুল। আপনি দাম দেন এটি যে OCI resource provision করে তার, আর এর logical online পদ্ধতি বেছে নিলে সেই পদ্ধতির দরকারি GoldenGate licensing-এর। এর physical online workflow চালায় Data Guard, যা বেশিরভাগ Enterprise Edition গ্রাহক মাইগ্রেশন standby-র জন্য এমনিতেই ব্যবহার করতে পারেন।

OCI কি আমাকে TDE encryption ব্যবহারে বাধ্য করে?

কার্যত হ্যাঁ — OCI-র database service-গুলোতে ডেটাবেজ storage ডিজাইনগতভাবেই TDE দিয়ে encrypted। অন-প্রিমিসে কখনো TDE না চালিয়ে থাকলে wallet ও master-key ব্যবস্থাপনার পরিকল্পনা করুন: key কোথায় থাকে, কে rotate করে, কীভাবে backup হয়। হারানো wallet মানে অপুনরুদ্ধারযোগ্য ডেটাবেজ — তাই এটি ডিজাইন পর্বেরই বিষয়।

ডেটাবেজ OCI-তে গেলে আমার অ্যাপ্লিকেশন কি অন-প্রিমিসে থাকতে পারে?

Technically হ্যাঁ, আর FastConnect-এর ওপর তা ভালোই চলতে পারে — তবে আগে latency মাপুন। প্রতিটি SQL round trip এখন WAN পার হয়, আর স্ক্রিনপ্রতি শত শত query ছোড়া একটি chatty অ্যাপ্লিকেশন দৃশ্যমানভাবে ধীর অনুভূত হবে। Hybrid ডিজাইনে প্রতিশ্রুতি দেওয়ার আগে একটি pilot ডেটাবেজের বিপরীতে একটি বাস্তব business transaction পরীক্ষা করুন।

শেষ ভাবনা

ক্লাউড মাইগ্রেশন নিজে কোনো লক্ষ্য নয় — এটি একটি টুল যা আপনার workload-এর সঙ্গে মিললে সাহায্য করে, না মিললে ক্ষতি করে। যে Oracle ডেটাবেজগুলো সবচেয়ে বেশি উপকৃত হয় সেগুলো হলো যেগুলো hardware refresh-এর মুখে, elastic ক্ষমতা প্রয়োজন, কিংবা এমন ভারী অপারেশনাল overhead বহন করছে যা স্বয়ংক্রিয়তা শুষে নিতে পারে। তিনটি জিনিস ঠিক করুন, বাকিটা এসে যাবে: কতটা নিয়ন্ত্রণ দরকার তার সঙ্গে মেলে এমন deployment অপশন বাছুন, আপনার downtime সহনশীলতার সঙ্গে মেলে এমন মাইগ্রেশন পদ্ধতি বাছুন, আর কিছু সরানোর আগে খরচ সৎভাবে মডেল করুন — egress, backup storage ও licensing মডেলসহ। একটি pilot করুন, একটি rollback রাখুন, আর ঢেউয়ে ঢেউয়ে মাইগ্রেট করুন। এভাবে করলে OCI একটি মজবুত প্ল্যাটফর্ম; তাড়াহুড়োর "cloud-first" আদেশ হিসেবে করলে এটি একটি ব্যয়বহুল শিক্ষা।