ব্যাংকিংয়ের জন্য Oracle Database: HA আর্কিটেকচার, কমপ্লায়েন্স ও সিকিউরিটি গাইড

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

১. কেন ব্যাংকিং একজন Oracle DBA-এর কাছ থেকে বেশি প্রত্যাশা করে

একটি ম্যানুফ্যাকচারিং কোম্পানির জন্য Oracle পরিচালনা আর একটি ব্যাংকের জন্য Oracle পরিচালনার মধ্যে পার্থক্যটা ঠিক একটি গাড়ি রক্ষণাবেক্ষণ আর একটি উড়োজাহাজ রক্ষণাবেক্ষণের মধ্যকার পার্থক্যের মতো। দুটোতেই দক্ষ রক্ষণাবেক্ষণ লাগে — কিন্তু ব্যর্থতার পরিণতি, এবং সেই সূত্রে প্রয়োজনীয় মানদণ্ড, মৌলিকভাবেই আলাদা।

ব্যাংকিং-নির্দিষ্ট Oracle প্রয়োজনীয়তা যা স্ট্যান্ডার্ড DBA প্র্যাকটিসের চেয়ে বেশি:

• ডাউনটাইমে কোনো ছাড় নেই: কোর ব্যাংকিং সিস্টেম নিরবচ্ছিন্নভাবে ট্রানজেকশন প্রসেস করে। ব্যবসায়িক সময়ে যেকোনো অপরিকল্পিত আউটেজ গ্রাহকের ওপর প্রভাব ফেলে, রেগুলেটরি রিপোর্টিং বাধ্যবাধকতা তৈরি করে এবং ব্যবস্থাপনায় এসকেলেশন ডেকে আনে
• ট্রানজেকশন ইন্টিগ্রিটি: প্রতিটি ডেটাবেজ ট্রানজেকশন অবশ্যই atomic, consistent, isolated এবং durable (ACID) হতে হবে — কোনো ব্যতিক্রম নেই। আংশিক ট্রানজেকশন, ডুপ্লিকেট পোস্টিং বা অনুপস্থিত রেকর্ড গ্রহণযোগ্য ভুল নয়, এগুলো রেগুলেটরি ইনসিডেন্ট
• সম্পূর্ণ অডিট ট্রেইল: একটি রেগুলেটেড টেবিলের প্রতিটি রেকর্ডে প্রতিটি পরিবর্তন লগ হতে হবে — কে পরিবর্তন করল, কখন, কী পরিবর্তন হলো এবং আগের মান কী ছিল। ব্যাংকিংয়ে এটি ঐচ্ছিক নয়
• রেগুলেটরি রিপোর্টিং: বাংলাদেশ ব্যাংক সিস্টেম availability, সিকিউরিটি ইনসিডেন্ট, চেঞ্জ কন্ট্রোল লগ এবং ব্যাকআপ কমপ্লায়েন্স নিয়ে পর্যায়ক্রমিক রিপোর্টিং দাবি করে
• ডেটা রিটেনশন: ব্যাংকিং রেগুলেশন অনুযায়ী বেশিরভাগ এখতিয়ারে ট্রানজেকশন রেকর্ড ৭–১০ বছর সংরক্ষণ করতে হয় — ডেটাবেজ আর্কিটেকচারকে পারফরম্যান্স হ্রাস ছাড়াই এটি সমর্থন করতে হবে

২. আইটির জন্য বাংলাদেশ ব্যাংকের রেগুলেটরি প্রয়োজনীয়তা

বাংলাদেশ ব্যাংকের "Guidelines on ICT Security for Scheduled Banks and Financial Institutions" ডেটাবেজ সিস্টেমের জন্য সুনির্দিষ্ট প্রয়োজনীয়তা নির্ধারণ করে। Oracle DBA-এর জন্য প্রাসঙ্গিক মূল বাধ্যবাধকতা:

২.১ Availability প্রয়োজনীয়তা

• কোর ব্যাংকিং সিস্টেমকে বছরে ন্যূনতম ৯৯.৫% availability বজায় রাখতে হবে (বছরে সর্বোচ্চ প্রায় ৪৩ ঘণ্টা ডাউনটাইম)
• পরিকল্পিত রক্ষণাবেক্ষণ অনুমোদিত কম-কার্যকলাপের সময়কালে, আগাম নোটিফিকেশন দিয়ে নির্ধারণ করতে হবে
• ডিজাস্টার রিকভারি সাইট নথিভুক্ত ও পরীক্ষিত failover প্রক্রিয়াসহ বজায় রাখতে হবে
• Recovery Time Objective (RTO) এবং Recovery Point Objective (RPO) আনুষ্ঠানিকভাবে সংজ্ঞায়িত, নথিভুক্ত এবং অন্তত বছরে একবার পরীক্ষা করতে হবে

২.২ অ্যাক্সেস কন্ট্রোল প্রয়োজনীয়তা

• Least privilege নীতি — ব্যবহারকারী ও অ্যাপ্লিকেশন কেবল তাদের কাজের জন্য প্রয়োজনীয় অ্যাক্সেস পাবে
• Privileged অ্যাক্সেস (DBA, SYSDBA) নিয়ন্ত্রিত, লগ ও পর্যালোচিত হতে হবে
• কোনো শেয়ার্ড অ্যাকাউন্ট নয় — প্রতিটি ব্যবহারকারীর একটি অনন্য পরিচয়দাতা থাকতে হবে
• Privileged ডেটাবেজ অ্যাক্সেসের জন্য মাল্টি-ফ্যাক্টর অথেনটিকেশন
• অ্যাক্সেস অধিকার অন্তত প্রতি ৬ মাসে একবার পর্যালোচনা করতে হবে
• চাকরিচ্যুত কর্মীর অ্যাক্সেস বিচ্ছিন্নতার ২৪ ঘণ্টার মধ্যে প্রত্যাহার করতে হবে

২.৩ অডিট ও লগিং প্রয়োজনীয়তা

• সব privileged অপারেশন (SYSDBA কানেকশন, DDL, ইউজার ম্যানেজমেন্ট) অবশ্যই অডিট করতে হবে
• সব আর্থিক ট্রানজেকশনের জন্য অ্যাপ্লিকেশন-স্তরের অডিট ট্রেইল
• অডিট লগ ন্যূনতম ৩ বছর সংরক্ষণ করতে হবে, পরিবর্তন থেকে সুরক্ষিত রেখে
• অডিট লগ পর্যালোচনার প্রক্রিয়া নথিভুক্ত ও নিয়মিত সম্পাদিত হতে হবে

৩. ব্যাংকিংয়ের জন্য High Availability আর্কিটেকচার

একটি ব্যাংকের কোর ব্যাংকিং ডেটাবেজে কোনো স্তরেই সিঙ্গেল পয়েন্ট অফ ফেইলিওর থাকতে পারে না। একটি বাংলাদেশি ব্যাংকের Oracle ডেটাবেজ পরিবেশের জন্য প্রস্তাবিত আর্কিটেকচার:

PRIMARY DATA CENTER (Main Branch / Head Office):
┌─────────────────────────────────────────────┐
│  Load Balancer (Active-Active)              │
│  ┌─────────────┐  ┌─────────────┐          │
│  │ App Server 1 │  │ App Server 2 │  (WLS) │
│  └──────┬──────┘  └──────┬──────┘          │
│         └────────┬────────┘                 │
│          SCAN Listener (3 IPs)              │
│  ┌─────────────┐  ┌─────────────┐          │
│  │ RAC Node 1  │  │ RAC Node 2  │          │
│  │ Oracle 26ai │  │ Oracle 26ai │          │
│  └──────┬──────┘  └──────┬──────┘          │
│         └────────┬────────┘                 │
│    Shared SAN Storage (High Redundancy)     │
└─────────────────────────────────────────────┘
              │  Data Guard (Sync)
              │  Maximum Availability Mode
              ▼
DR DATA CENTER (Separate Location):
┌─────────────────────────────────────────────┐
│  Physical Standby Database (Active DG)      │
│  Oracle 26ai — Read queries offloaded here  │
│  ┌─────────────┐  ┌─────────────┐          │
│  │ Standby  1  │  │ Standby  2  │ (opt)    │
│  └─────────────┘  └─────────────┘          │
└─────────────────────────────────────────────┘

৩.১ ব্যাংকিংয়ের জন্য Oracle RAC কনফিগারেশন

Oracle RAC সার্ভার-স্তরের হাই অ্যাভেইলেবিলিটি দেয় — একটি ডেটাবেজ নোড ব্যর্থ হলে অন্যটি ট্রানজেকশন সেবা চালিয়ে যায় এবং TAF (Transparent Application Failover) স্বয়ংক্রিয়ভাবে সেশন পুনঃসংযোগ করে। একটি ব্যাংকিং পরিবেশের জন্য:

• প্রোডাকশনে ন্যূনতম ২টি RAC নোড — বড় ট্রানজেকশন ভলিউমের জন্য ৩টি নোড
• Cluster interconnect: ডেডিকেটেড ১০/২৫ GbE নেটওয়ার্ক — কখনোই অ্যাপ্লিকেশন ট্রাফিকের সঙ্গে শেয়ার করবেন না
• শেয়ার্ড স্টোরেজের জন্য High Redundancy (৩-way mirror) সহ ASM
• স্বয়ংক্রিয় সেশন রিকভারির জন্য অ্যাপ্লিকেশন স্তরে TAF কনফিগার করা
• সার্ভিস-ভিত্তিক কানেকশন ম্যানেজমেন্ট — OLTP, batch, reporting-এর জন্য আলাদা সার্ভিস

-- Create separate database services for different workloads
-- OLTP service — balanced across RAC nodes
EXEC DBMS_SERVICE.CREATE_SERVICE(
  service_name    => 'BANK_OLTP',
  network_name    => 'BANK_OLTP',
  failover_method => 'BASIC',
  failover_type   => 'SELECT',
  failover_retries=> 30,
  failover_delay  => 5
);
EXEC DBMS_SERVICE.START_SERVICE('BANK_OLTP');

-- Reporting service — pin to Node 2 to isolate report load from OLTP
EXEC DBMS_SERVICE.CREATE_SERVICE(
  service_name    => 'BANK_REPORT',
  network_name    => 'BANK_REPORT',
  preferred_instances => 'BANKDB2'
);
EXEC DBMS_SERVICE.START_SERVICE('BANK_REPORT');

৩.২ ডিজাস্টার রিকভারির জন্য Data Guard

ব্যাংকিংয়ের জন্য Maximum Availability প্রোটেকশন মোডই স্ট্যান্ডার্ড — সিনক্রোনাস redo ট্রান্সপোর্ট, standby সিঙ্কে থাকলে জিরো ডেটা লস। Standby সাইটকে অবশ্যই একটি ভৌতভাবে আলাদা অবস্থানে থাকতে হবে (ভিন্ন ভবন, ভিন্ন পাওয়ার গ্রিড, বড় ব্যাংকের ক্ষেত্রে আদর্শভাবে ভিন্ন শহর)।

-- Verify Data Guard protection mode and apply lag
SELECT protection_mode, protection_level, switchover_status
FROM V$DATABASE;

-- Check apply lag (should be near zero for Maximum Availability)
SELECT name, value, datum_time
FROM V$DATAGUARD_STATS
WHERE name IN ('transport lag','apply lag');

-- Monitor redo transport to standby
SELECT dest_id, status, target, archiver,
       log_sequence, applied_scn, error
FROM V$ARCHIVE_DEST_STATUS
WHERE target = 'STANDBY';

৪. ব্যাংকিং Oracle-এর জন্য সিকিউরিটি হার্ডেনিং

একটি স্ট্যান্ডার্ড Oracle ইনস্টলেশন কোনো হার্ডেনড ব্যাংকিং ইনস্টলেশন নয়। ব্যাংকিং পরিবেশে যেসব সিকিউরিটি কনফিগারেশন প্রয়োজন সেগুলো এখানে।

৪.১ Oracle Database Vault

ব্যাংকিং Oracle পরিবেশের জন্য Database Vault সবচেয়ে গুরুত্বপূর্ণ সিকিউরিটি কন্ট্রোল। এটি privileged ডেটাবেজ অ্যাকাউন্ট — এমনকি SYSDBA — কে অ্যাপ্লিকেশন ডেটায় অ্যাক্সেস করা থেকে বাধা দেয়। Database Vault ছাড়া আপনার DBA প্রতিটি গ্রাহকের অ্যাকাউন্ট ব্যালেন্স, ট্রানজেকশন রেকর্ড ও ব্যক্তিগত ডেটা পড়তে পারে। রেগুলেটররা ক্রমবর্ধমানভাবে এই কন্ট্রোল বহাল থাকার প্রত্যাশা করছে।

-- Create a Database Vault realm protecting core banking schema
BEGIN
  DVSYS.DBMS_MACADM.CREATE_REALM(
    realm_name    => 'Core Banking Realm',
    description   => 'Protects core banking schema from privileged access',
    enabled       => 'Y',
    audit_options => DVSYS.DBMS_MACADM.G_REALM_AUDIT_FAIL
  );
END;
/

-- Add core banking schema to the realm
BEGIN
  DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM(
    realm_name   => 'Core Banking Realm',
    object_owner => 'COREBANK',
    object_name  => '%',
    object_type  => '%'
  );
END;
/

৪.২ Transparent Data Encryption (TDE)

TDE datafile-গুলোকে at rest এনক্রিপ্ট করে — স্টোরেজ মিডিয়া ভৌতভাবে আপসড় বা চুরি হলে সংবেদনশীল ডেটা রক্ষা করে। ব্যাংকিংয়ে ডেটা প্রোটেকশন স্ট্যান্ডার্ড মানার জন্য এটি আবশ্যক।

-- Enable TDE for the entire database (tablespace encryption)
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<strong_password>";

-- Encrypt sensitive tablespace
ALTER TABLESPACE corebank_data ENCRYPTION ENCRYPT;

-- Verify encryption status
SELECT tablespace_name, encrypted
FROM DBA_TABLESPACES
WHERE encrypted = 'YES';

৪.৩ নেটওয়ার্ক এনক্রিপশন

-- sqlnet.ora — enforce encrypted connections to the database
-- All connections must use AES256 encryption
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192)
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256)

৪.৪ ব্যাংকিংয়ের জন্য পাসওয়ার্ড প্রোফাইল

-- Strict password profile for all banking database users
CREATE PROFILE BANKING_PROFILE LIMIT
  FAILED_LOGIN_ATTEMPTS   5
  PASSWORD_LOCK_TIME      1/24    -- 1 hour lockout
  PASSWORD_LIFE_TIME      60      -- 60-day expiry
  PASSWORD_REUSE_TIME     365
  PASSWORD_REUSE_MAX      12
  PASSWORD_GRACE_TIME     3
  PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function
  SESSIONS_PER_USER       5;

-- Apply to all non-system users
ALTER USER corebank_app PROFILE BANKING_PROFILE;
ALTER USER report_user PROFILE BANKING_PROFILE;

৪.৫ Privilege Analysis

Oracle Privilege Analysis কোন privilege আসলে ব্যবহৃত হচ্ছে তা ধরে রাখে — এতে অব্যবহৃত privilege প্রত্যাহার করে least-privilege অবস্থায় পৌঁছানো যায়।

-- Run privilege analysis to find unused privileges
BEGIN
  DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
    name        => 'BANKING_PRIV_ANALYSIS',
    description => 'Identify unused privileges for least-privilege hardening',
    type        => DBMS_PRIVILEGE_CAPTURE.G_DATABASE
  );
  DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE('BANKING_PRIV_ANALYSIS');
END;
/

-- After 2-4 weeks of normal operation, disable and report
EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE('BANKING_PRIV_ANALYSIS');
EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT('BANKING_PRIV_ANALYSIS');

-- Review unused privileges
SELECT username, sys_priv, used FROM DBA_UNUSED_PRIVS
ORDER BY username, sys_priv;

৫. ব্যাংকিং কমপ্লায়েন্সের জন্য অডিট ট্রেইল

ব্যাংকিং অডিট ট্রেইল অবশ্যই ব্যাপক, tamper-proof এবং রেগুলেটরি রিটেনশন সময়কাল জুড়ে সংরক্ষিত হতে হবে। AUDSYS schema প্রোটেকশনসহ Oracle Unified Auditing এই প্রয়োজনীয়তা পূরণ করে।

৫.১ ব্যাংকিংয়ের জন্য বাধ্যতামূলক অডিট পলিসি

-- Audit all privileged connections
CREATE AUDIT POLICY sysdba_connections
  ACTIONS COMPONENT=DIRECT_PATH_API ALL
  WHEN 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''SYS'''
  EVALUATE PER SESSION;
AUDIT POLICY sysdba_connections;

-- Audit all DDL on core banking schema
CREATE AUDIT POLICY banking_ddl
  ACTIONS CREATE TABLE, ALTER TABLE, DROP TABLE,
          CREATE INDEX, DROP INDEX,
          CREATE PROCEDURE, ALTER PROCEDURE, DROP PROCEDURE
  ON corebank.accounts, corebank.transactions,
     corebank.customers, corebank.loans;
AUDIT POLICY banking_ddl;

-- Audit all DML on financial tables
CREATE AUDIT POLICY banking_dml
  ACTIONS INSERT, UPDATE, DELETE
  ON corebank.accounts,
     corebank.transactions,
     corebank.loan_disbursements;
AUDIT POLICY banking_dml;

-- Audit failed logins (security monitoring)
CREATE AUDIT POLICY failed_logins
  ACTIONS LOGON
  WHEN 'ACTION = 100'
  EVALUATE PER SESSION;
AUDIT POLICY failed_logins;

৫.২ অডিট ট্রেইল সুরক্ষিত রাখা

-- Verify audit trail is stored in AUDSYS (protected from DBA modification)
SELECT user, con_id FROM UNIFIED_AUDIT_TRAIL
WHERE ROWNUM = 1;  -- Should show AUDSYS ownership

-- Create a separate tablespace for audit data with limited access
CREATE TABLESPACE audit_data
  DATAFILE '/oradata/audit/audit01.dbf' SIZE 50G AUTOEXTEND ON;

-- Move audit trail to dedicated tablespace
EXECUTE DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
  audit_trail_type           => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
  audit_trail_location_value => 'AUDIT_DATA'
);

৬. ব্যাংকিং ট্রানজেকশনের জন্য পারফরম্যান্স

ব্যাংকিং OLTP ওয়ার্কলোডের সুনির্দিষ্ট পারফরম্যান্স বৈশিষ্ট্য আছে: উচ্চ concurrency, স্বল্পস্থায়ী ট্রানজেকশন, lock contention-এর প্রতি চরম সংবেদনশীলতা, এবং ব্যাচ প্রসেসিং উইন্ডো যা নির্ধারিত সময়সীমার মধ্যে শেষ হতে হয়।

৬.১ ব্যাংকিংয়ের জন্য Undo Management

ব্যাংকিং সিস্টেমে প্রায়ই লাইভ OLTP-এর পাশাপাশি দীর্ঘস্থায়ী ট্রানজেকশন (end-of-day batch, স্টেটমেন্ট জেনারেশন) চলে। অপর্যাপ্ত undo retention ORA-01555 (snapshot too old) ত্রুটি ঘটায় — ব্যাংকিং অ্যাপ্লিকেশনে যা একটি গুরুতর সমস্যা।

-- Undo configuration for mixed OLTP + batch banking workload
ALTER SYSTEM SET UNDO_TABLESPACE = UNDOTBS1;
ALTER SYSTEM SET UNDO_RETENTION = 10800;  -- 3 hours minimum for banking batch

-- Monitor undo usage and tune retention
SELECT maxquerylen/60 AS max_query_minutes,
       maxqueryid,
       ROUND(undoblks * 8192 / 1024/1024/1024, 2) AS undo_used_gb,
       ssolderrcnt AS ora01555_count
FROM V$UNDOSTAT
WHERE begin_time > SYSDATE - 1
ORDER BY begin_time DESC;

৬.২ Oracle WebLogic দিয়ে Connection Pooling

Oracle WebLogic-এ চলা ব্যাংকিং অ্যাপ্লিকেশন যথাযথ JDBC কানেকশন পুল দিয়ে কনফিগার করতে হবে। দুর্বলভাবে কনফিগার করা কানেকশন পুল ব্যাংকিং অ্যাপ্লিকেশন টিয়ারে পারফরম্যান্স হ্রাসের অন্যতম সাধারণ কারণ।

-- WebLogic JDBC connection pool best practices for banking
-- (Set in WebLogic console or config.xml)

Connection Pool Settings:
  Initial Capacity: 25
  Maximum Capacity: 200
  Minimum Capacity: 25
  Capacity Increment: 5
  Connection Reserve Timeout: 30 seconds
  Statement Cache Size: 100
  Test On Reserve: Enabled
  Test Query: SELECT 1 FROM DUAL

  -- For RAC: use Active GridLink data source
  -- for load balancing and Fast Connection Failover (FCF)

৬.৩ Lock Contention শনাক্ত ও সমাধান

Lock contention পিক আওয়ারে ব্যাংকিং ট্রানজেকশন ধীর হওয়ার সবচেয়ে সাধারণ কারণ। সক্রিয়ভাবে মনিটর ও সমাধান করুন।

-- Find blocking sessions in real time
SELECT
  l.sid AS blocker_sid,
  s.username AS blocker_user,
  l2.sid AS blocked_sid,
  s2.username AS blocked_user,
  s2.status,
  s2.wait_time,
  s2.seconds_in_wait,
  s2.sql_id AS blocked_sql
FROM V$LOCK l
JOIN V$LOCK l2 ON l.id1 = l2.id1 AND l.id2 = l2.id2
JOIN V$SESSION s ON l.sid = s.sid
JOIN V$SESSION s2 ON l2.sid = s2.sid
WHERE l.block = 1
  AND l2.request > 0
ORDER BY s2.seconds_in_wait DESC;

৭. ব্যাংকিংয়ের জন্য ২৪/৭ মনিটরিং

একটি ব্যাংকিং ডেটাবেজের জন্য নির্ধারিত অ্যালার্ট থ্রেশহোল্ড ও এসকেলেশন প্রক্রিয়াসহ নিরবচ্ছিন্ন স্বয়ংক্রিয় মনিটরিং প্রয়োজন। সকালবেলার ম্যানুয়াল চেক যথেষ্ট নয় — সমস্যা রিয়েল-টাইমে শনাক্ত ও অ্যালার্ট হতে হবে।

৭.১ কনফিগার করার মতো গুরুত্বপূর্ণ অ্যালার্ট

• Tablespace ব্যবহার > ৮০% — Warning; > ৯০% Critical
• FRA ব্যবহার > ৮০% — Warning; > ৯০% Critical
• RMAN ব্যাকআপ ব্যর্থতা — তাৎক্ষণিক অ্যালার্ট
• Archive log destination পূর্ণ — তাৎক্ষণিক (ডেটাবেজ থেমে যাবে)
• Data Guard apply lag > ৬০ সেকেন্ড — Warning; > ৩০০ সেকেন্ড Critical
• RAC node eviction — তাৎক্ষণিক
• Blocking sessions > ৫ মিনিট — Warning; > ১৫ মিনিট Escalate
• CPU ব্যবহার > ৮৫% — Warning
• Failed login attempts হঠাৎ বৃদ্ধি — সিকিউরিটি অ্যালার্ট
• Database unreachable — তাৎক্ষণিক P1

৭.২ স্বয়ংক্রিয় Health Check কোয়েরি

-- Daily automated health check script (run at 06:00 before business hours)

-- 1. Last night's backup status
SELECT status, input_type,
       TO_CHAR(end_time,'DD-MON-YYYY HH24:MI') AS completed,
       ROUND(output_bytes/1024/1024/1024,2) AS gb
FROM V$RMAN_BACKUP_JOB_DETAILS
WHERE start_time > SYSDATE - 1
ORDER BY start_time DESC;

-- 2. Data Guard status
SELECT name, value FROM V$DATAGUARD_STATS
WHERE name IN ('transport lag','apply lag');

-- 3. Tablespace critical check
SELECT tablespace_name,
       ROUND((bytes-free)/bytes*100,1) AS pct_used
FROM (SELECT t.tablespace_name,
             SUM(t.bytes) AS bytes,
             SUM(NVL(f.bytes,0)) AS free
      FROM DBA_DATA_FILES t
      LEFT JOIN DBA_FREE_SPACE f ON t.tablespace_name = f.tablespace_name
      GROUP BY t.tablespace_name)
WHERE (bytes-free)/bytes > 0.80
ORDER BY pct_used DESC;

-- 4. Active blocking sessions
SELECT COUNT(*) AS blocking_count
FROM V$LOCK WHERE block = 1;

৮. End-of-Day Batch Processing

ব্যাংকিং end-of-day (EOD) batch সবচেয়ে পারফরম্যান্স-সংবেদনশীল Oracle ওয়ার্কলোডগুলোর একটি। এটি একটি নির্ধারিত উইন্ডোর মধ্যে শেষ হতে হবে — সাধারণত মধ্যরাত থেকে ভোর ৪টা পর্যন্ত — পরবর্তী ব্যবসায়িক দিন শুরুর আগে। মিস করা EOD উইন্ডো বিলম্বিত অ্যাকাউন্ট পোস্টিং, স্টেটমেন্ট ত্রুটি এবং রেগুলেটরি রিপোর্টিং ব্যর্থতায় গড়িয়ে যায়।

EOD batch-এর জন্য Oracle কনফিগারেশন অপটিমাইজেশন:

• Parallel execution: বড় ব্যাচ অপারেশনের জন্য parallel DML সক্রিয় করুন — অ্যাকাউন্ট পোস্টিং ও স্টেটমেন্ট জেনারেশনের EOD রানটাইম নাটকীয়ভাবে কমায়
• Direct-path inserts: বড় insert-এর জন্য APPEND hint ব্যবহার করুন — buffer cache ও redo logging ওভারহেড এড়ায়
• Partitioning: বড় ট্রানজেকশন টেবিল তারিখ অনুযায়ী partition করুন — EOD প্রসেসিং শুধু বর্তমান দিনের partition স্পর্শ করে, পুরো টেবিল নয়
• Dedicated batch service: একটি ডেডিকেটেড RAC নোডে আলাদা Oracle সার্ভিসের মাধ্যমে EOD batch রুট করুন — ব্যাচ I/O যেন অনলাইন ব্যাংকিং availability-এ প্রভাব না ফেলে

-- Example: End-of-day account balance update using parallel execution
ALTER SESSION ENABLE PARALLEL DML;

-- Direct-path insert with parallel for statement archive
INSERT /*+ APPEND PARALLEL(t,4) */ INTO stmt_archive t
SELECT * FROM daily_transactions
WHERE posting_date = TRUNC(SYSDATE);
COMMIT;

-- Partition maintenance after EOD
ALTER TABLE transactions
  SPLIT PARTITION transactions_current
  AT (TRUNC(SYSDATE+1))
  INTO (PARTITION p_today, PARTITION transactions_current);

৯. যেসব সাধারণ ব্যাংকিং Oracle সমস্যা আমি সমাধান করেছি

বাংলাদেশের একটি সরকারি ব্যাংকে Oracle সহায়তা দেওয়ার সরাসরি অভিজ্ঞতা থেকে, এগুলোই সবচেয়ে ঘন ঘন দেখা যাওয়া সমস্যা:

• EOD batch চলাকালীন ORA-01555: দীর্ঘস্থায়ী ব্যাচ কোয়েরির জন্য undo retention খুব কম — undo tablespace যথাযথভাবে সাইজ করে এবং undo retention guarantee সক্রিয় করে সমাধান
• পিক ট্রানজেকশন সময়ে blocking: অ্যাপ্লিকেশন দ্রুত commit করছিল না — দীর্ঘ সময় ধরে রাখা row lock শত শত সেশন ব্লক করছিল; অ্যাপ্লিকেশন কানেকশন পুল টিউনিং ও explicit commit শিডিউলিংয়ের মাধ্যমে সমাধান
• দুপুরের পর ইন্টারনেট ব্যাংকিং ধীর: পিক সকালের কার্যকলাপের পর buffer cache hit ratio কমে যাচ্ছিল — SGA বাড়িয়ে এবং buffer cache advisory সুপারিশ প্রয়োগ করে সমাধান
• Data Guard apply lag বৃদ্ধি: EOD log shipping-এর সময় নেটওয়ার্ক saturation — EOD ব্যাচ লগ আর্কাইভিং নেটওয়ার্ক পিক এড়িয়ে শিডিউল করে এবং ডেডিকেটেড DR রেপ্লিকেশন নেটওয়ার্ক যোগ করে সমাধান
• মিস করা EOD উইন্ডো: বড় টেবিলের জন্য দুর্বল parallel execution plan — partition pruning, parallel hint enforcement এবং statistics refresh-এর মাধ্যমে সমাধান
• DBA-র অতিরিক্ত অ্যাক্সেস: তিনজন DBA-র ভাগ করা একটি DBA অ্যাকাউন্ট, প্রোডাকশনে SYSDBA সহ — Database Vault ও ব্যক্তিগত named অ্যাকাউন্ট দিয়ে সংশোধন

শেষ কথা

ব্যাংকিং পরিবেশে Oracle ডেটাবেজ ম্যানেজমেন্ট বাড়তি কিছু ধাপসহ সাধারণ DBA কাজ নয় — এটি একটি স্বতন্ত্র শৃঙ্খলা যার জন্য রেগুলেটরি প্রয়োজনীয়তা, আর্থিক ট্রানজেকশন প্যাটার্ন, সিকিউরিটি কন্ট্রোল এবং প্রতিটি কনফিগারেশন সিদ্ধান্তের পরিণতি বোঝা প্রয়োজন। বেশিরভাগ পরিবেশে একটি tablespace ভরে যাওয়া নিছক অসুবিধা; একটি ব্যাংকে এটি সম্ভাব্য রেগুলেটরি ইনসিডেন্ট।

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