Oracle ডেটাবেজ হেলথ চেক: কী পরীক্ষা করবেন, কী ঠিক করবেন, এবং উপেক্ষা করলে কী মূল্য দিতে হয়

প্রোডাকশনে থাকা বেশিরভাগ Oracle ডেটাবেজে অন্তত একটি গুরুতর সমস্যা থাকে, যা তার DBA জানেন না। এর কারণ DBA অদক্ষ নন — বরং একটি কাঠামোবদ্ধ হেলথ চেক না থাকলে, ধীরে ধীরে বড় হওয়া সমস্যাগুলো সংকটে পরিণত না হওয়া পর্যন্ত কখনো কোনো অ্যালার্ট বাজায় না। একটি backup যা গত তিন সপ্তাহ ধরে নীরবে ব্যর্থ হয়ে চলেছে। একটি tablespace যা ৯৪% ধারণক্ষমতায় পৌঁছে গেছে। ছয় মাস আগে কোনো "দ্রুত সমাধানের" সময় ড্রপ করে দেওয়া একটি index যা আর কখনো rebuild করা হয়নি, ফলে প্রতিটি সংশ্লিষ্ট কোয়েরি একটি full table scan করছে। একটি user account যা এক বছর আগে চাকরি ছেড়ে যাওয়া একজন কর্মচারীর, এখনো DBA প্রিভিলেজ সহ সক্রিয়। এই গাইডে একটি যথাযথ Oracle হেলথ চেকে যে প্রতিটি ক্যাটেগরি কভার করা আবশ্যক তার প্রতিটি নিয়ে আলোচনা করা হয়েছে — সাথে নিজে চালানোর জন্য SQL কোয়েরিও দেওয়া হয়েছে।

১. আপনার কখন হেলথ চেক দরকার?

হেলথ চেক শুধু তখনই দরকার হয় না যখন কিছু একটা স্পষ্টভাবে ভুল হয়। যেসব প্রতিষ্ঠান হেলথ চেক থেকে সবচেয়ে বেশি উপকৃত হয় সেগুলো হলো যেখানে সবকিছু ঠিকঠাক চলছে বলে মনে হয় — কারণ ঠিক তখনই লুকানো সমস্যাগুলো অলক্ষ্যে জমতে থাকে।

যেসব নির্দিষ্ট পরিস্থিতিতে তৎক্ষণাৎ একটি হেলথ চেক করা উচিত:

• কোনো নতুন DBA এমন একটি ডেটাবেজের দায়িত্ব নিচ্ছেন যা তিনি নিজে তৈরি করেননি
• আসন্ন কমপ্লায়েন্স অডিট বা নিয়ন্ত্রক পরিদর্শন
• কোনো অ্যাপ্লিকেশন একটি Oracle ডেটাবেজে লাইভ হতে যাচ্ছে
• সপ্তাহ বা মাসজুড়ে ধীরে ধীরে performance খারাপ হচ্ছে
• কোনো বড় Oracle ভার্সন আপগ্রেডের আগে
• হার্ডওয়্যার পরিবর্তন, storage মাইগ্রেশন, বা সার্ভার প্রতিস্থাপনের পরে
• নতুন IT সেবা চুক্তি সই করার আগে — আপনি কী উত্তরাধিকার সূত্রে পাচ্ছেন তা বুঝে নিন
• রুটিন প্রতিরোধমূলক রক্ষণাবেক্ষণ হিসেবে বছরে একবার — এমনকি সবকিছু ঠিকঠাক মনে হলেও

২. ক্যাটেগরি ১ — Performance

Performance-এর সমস্যা খুব কমই হঠাৎ করে দেখা দেয়। এগুলো ধীরে ধীরে বাড়ে — এক বছর আগে যে কোয়েরিতে ২ সেকেন্ড লাগত এখন তাতে ১২ সেকেন্ড লাগে, কিন্তু কেউ খেয়াল করেনি কারণ পরিবর্তনটি ধীর ছিল। ব্যবহারকারীরা অভিযোগ শুরু করার আগেই একটি হেলথ চেক এগুলো খুঁজে বের করে।

২.১ Top Wait Events

Wait events আপনাকে জানায় Oracle সবচেয়ে বেশি কীসের জন্য অপেক্ষা করছে। শীর্ষ ৫টি wait event বেশিরভাগ performance সমস্যার ব্যাখ্যা দেয়।

-- Top 10 wait events (last 7 days from AWR)
SELECT event, total_waits, time_waited_micro/1000000 AS time_waited_sec,
       ROUND(time_waited_micro / SUM(time_waited_micro) OVER() * 100, 1) AS pct_total
FROM (
  SELECT event, SUM(total_waits) AS total_waits,
         SUM(time_waited_micro) AS time_waited_micro
  FROM DBA_HIST_SYSTEM_EVENT
  WHERE snap_id IN (
    SELECT snap_id FROM DBA_HIST_SNAPSHOT
    WHERE begin_interval_time > SYSDATE - 7
  )
  AND wait_class != 'Idle'
  GROUP BY event
)
ORDER BY time_waited_micro DESC
FETCH FIRST 10 ROWS ONLY;

২.২ Elapsed Time অনুসারে Top SQL

Elapsed time অনুসারে শীর্ষ ১০টি SQL স্টেটমেন্ট ডেটাবেজের বেশিরভাগ ওয়ার্কলোডের জন্য দায়ী। এমনকি এদের একটিকেও অপ্টিমাইজ করলে সামগ্রিক performance-এ নাটকীয় প্রভাব পড়তে পারে।

-- Top 10 SQL statements by elapsed time (AWR, last 7 days)
SELECT sql_id,
       ROUND(elapsed_time_total/1000000,1) AS elapsed_sec,
       executions_total,
       ROUND(elapsed_time_total/NULLIF(executions_total,0)/1000000,3) AS avg_sec,
       SUBSTR(sql_text,1,80) AS sql_preview
FROM DBA_HIST_SQLSTAT s
JOIN DBA_HIST_SQLTEXT t USING (sql_id)
WHERE snap_id IN (
  SELECT snap_id FROM DBA_HIST_SNAPSHOT
  WHERE begin_interval_time > SYSDATE - 7
)
ORDER BY elapsed_time_total DESC
FETCH FIRST 10 ROWS ONLY;

২.৩ Missing Indexes (বড় টেবিলে Full Table Scan)

-- Large tables with high full table scan counts
SELECT object_name, value AS full_scans
FROM V$SEGMENT_STATISTICS
WHERE statistic_name = 'table scans (long tables)'
  AND value > 100
ORDER BY value DESC
FETCH FIRST 20 ROWS ONLY;

২.৪ Buffer Cache Hit Ratio

-- Buffer cache hit ratio (should be > 95% for OLTP)
SELECT ROUND(
  (1 - (physical_reads / (db_block_gets + consistent_gets))) * 100, 2
) AS buffer_hit_pct
FROM (
  SELECT SUM(DECODE(name,'physical reads',value)) AS physical_reads,
         SUM(DECODE(name,'db block gets',value)) AS db_block_gets,
         SUM(DECODE(name,'consistent gets',value)) AS consistent_gets
  FROM V$SYSSTAT
  WHERE name IN ('physical reads','db block gets','consistent gets')
);

৩. ক্যাটেগরি ২ — Backup & Recovery Readiness

এটিই সবচেয়ে গুরুত্বপূর্ণ ক্যাটেগরি। ভাঙা বা অপরীক্ষিত backup সহ একটি ডেটাবেজ একটি মাত্র ঘটনা দূরে থাকে এমন data loss থেকে, যা আর পুনরুদ্ধার করা যায় না।

৩.১ সর্বশেষ সফল Backup

-- When was the last successful RMAN backup?
SELECT INPUT_TYPE, STATUS,
       TO_CHAR(START_TIME,'DD-MON-YYYY HH24:MI') AS started,
       TO_CHAR(END_TIME,'DD-MON-YYYY HH24:MI') AS ended,
       ROUND(OUTPUT_BYTES/1024/1024/1024,2) AS output_gb
FROM V$RMAN_BACKUP_JOB_DETAILS
WHERE STATUS = 'COMPLETED'
ORDER BY START_TIME DESC
FETCH FIRST 5 ROWS ONLY;

৩.২ Archive Log Gap পরীক্ষা

-- Are there archive log sequence gaps? (gaps = unrecoverable periods)
SELECT thread#, MIN(sequence#) AS min_seq, MAX(sequence#) AS max_seq,
       MAX(sequence#) - MIN(sequence#) + 1 AS expected,
       COUNT(*) AS actual,
       CASE WHEN MAX(sequence#) - MIN(sequence#) + 1 = COUNT(*)
            THEN 'NO GAPS' ELSE 'GAPS FOUND' END AS status
FROM V$ARCHIVED_LOG
WHERE first_time > SYSDATE - 7
  AND standby_dest = 'NO'
GROUP BY thread#;

৩.৩ FRA ব্যবহার

-- FRA usage (> 80% is a warning, > 90% is critical)
SELECT NAME,
       ROUND(SPACE_LIMIT/1024/1024/1024,1) AS limit_gb,
       ROUND(SPACE_USED/1024/1024/1024,1) AS used_gb,
       ROUND(SPACE_USED/SPACE_LIMIT*100,1) AS pct_used,
       CASE WHEN SPACE_USED/SPACE_LIMIT > 0.9 THEN 'CRITICAL'
            WHEN SPACE_USED/SPACE_LIMIT > 0.8 THEN 'WARNING'
            ELSE 'OK' END AS status
FROM V$RECOVERY_FILE_DEST;

৪. ক্যাটেগরি ৩ — Storage & Space Management

Tablespace পূর্ণ হয়ে যাওয়া অপরিকল্পিত Oracle আউটেজের সবচেয়ে সাধারণ কারণগুলোর একটি — এবং সবচেয়ে প্রতিরোধযোগ্যগুলোরও একটি। একটি স্বয়ংক্রিয় space পরীক্ষা প্রতিদিন চালানো উচিত।

৪.১ Tablespace Space ব্যবহার

-- Tablespace usage with autoextend status
SELECT t.tablespace_name,
       ROUND(t.bytes/1024/1024/1024,2) AS total_gb,
       ROUND((t.bytes - f.free)/1024/1024/1024,2) AS used_gb,
       ROUND(f.free/1024/1024/1024,2) AS free_gb,
       ROUND((t.bytes - f.free)/t.bytes*100,1) AS pct_used,
       CASE WHEN (t.bytes - f.free)/t.bytes > 0.90 THEN 'CRITICAL'
            WHEN (t.bytes - f.free)/t.bytes > 0.80 THEN 'WARNING'
            ELSE 'OK' END AS status
FROM (SELECT tablespace_name, SUM(bytes) AS bytes
      FROM DBA_DATA_FILES GROUP BY tablespace_name) t
JOIN (SELECT tablespace_name, SUM(bytes) AS free
      FROM DBA_FREE_SPACE GROUP BY tablespace_name) f
  ON t.tablespace_name = f.tablespace_name
ORDER BY pct_used DESC;

৪.২ শীর্ষ ১০ বৃহত্তম Segment

-- Top 10 largest objects consuming space
SELECT owner, segment_name, segment_type,
       ROUND(bytes/1024/1024/1024,3) AS size_gb
FROM DBA_SEGMENTS
ORDER BY bytes DESC
FETCH FIRST 10 ROWS ONLY;

৪.৩ Redo Log Sizing

-- Redo log switch frequency (should be < 4 switches/hour for OLTP)
SELECT TO_CHAR(first_time,'YYYY-MM-DD HH24') AS hour_block,
       COUNT(*) AS log_switches
FROM V$LOG_HISTORY
WHERE first_time > SYSDATE - 3
GROUP BY TO_CHAR(first_time,'YYYY-MM-DD HH24')
ORDER BY 1 DESC;

ঘণ্টায় ৪টির বেশি log switch হলে সাধারণত বোঝায় redo log-গুলো আকারে ছোট — Oracle খুব ঘন ঘন নতুন log file-এ লিখছে, যা I/O চাপ এবং checkpoint কার্যকলাপের কারণ হচ্ছে।

৫. ক্যাটেগরি ৪ — Security & Access Control

যেকোনো Oracle হেলথ চেকে security findings ধারাবাহিকভাবে সবচেয়ে গুরুতরগুলোর মধ্যে থাকে। অননুমোদিত অ্যাক্সেস, অতিরিক্ত প্রিভিলেজ, এবং নিষ্ক্রিয় account — সবই সাধারণ, এবং সবই উল্লেখযোগ্য ঝুঁকি বহন করে।

৫.১ DBA Role সম্পন্ন ব্যবহারকারী

-- Who has DBA privileges? (should be a very short list)
SELECT grantee, granted_role, admin_option, default_role
FROM DBA_ROLE_PRIVS
WHERE granted_role = 'DBA'
ORDER BY grantee;

৫.২ SYSDBA / SYSOPER প্রিভিলেজ সম্পন্ন ব্যবহারকারী

-- Users with SYSDBA or SYSOPER (the highest Oracle privileges)
SELECT * FROM V$PWFILE_USERS
ORDER BY username;

৫.৩ নিষ্ক্রিয় Account (৯০+ দিন লগইন করেনি)

-- User accounts not used in 90+ days — high risk, should be reviewed
SELECT username, account_status,
       TO_CHAR(last_login,'DD-MON-YYYY') AS last_login,
       ROUND(SYSDATE - CAST(last_login AS DATE)) AS days_inactive,
       profile
FROM DBA_USERS
WHERE account_status = 'OPEN'
  AND (last_login IS NULL OR last_login < SYSDATE - 90)
  AND username NOT IN ('SYS','SYSTEM','DBSNMP','APPQOSSYS',
                       'AUDSYS','GSMADMIN_INTERNAL')
ORDER BY last_login NULLS FIRST;

৫.৪ স্ট্যান্ডার্ড Oracle Account-এ ডিফল্ট পাসওয়ার্ড

-- Check if any Oracle default accounts still have default passwords
SELECT username, account_status
FROM DBA_USERS_WITH_DEFPWD
WHERE account_status = 'OPEN'
ORDER BY username;

৫.৫ Audit Trail স্ট্যাটাস

-- Is auditing enabled? What is being audited?
SELECT name, value FROM V$PARAMETER
WHERE name IN ('audit_trail','unified_auditing','audit_sys_operations');

-- How many audit records accumulated (large number = needs housekeeping)
SELECT COUNT(*) AS audit_record_count FROM UNIFIED_AUDIT_TRAIL
WHERE EVENT_TIMESTAMP > SYSDATE - 30;

৬. ক্যাটেগরি ৫ — Invalid Objects

Invalid objects — stored procedure, function, trigger, view, package — অ্যাপ্লিকেশন এরর এবং performance সমস্যার কারণ হয়। schema পরিবর্তন এবং patch প্রয়োগের পরে এগুলো প্রায়ই পড়ে থাকে।

-- Count invalid objects by owner and type
SELECT owner, object_type, COUNT(*) AS invalid_count
FROM DBA_OBJECTS
WHERE status = 'INVALID'
  AND owner NOT IN ('SYS','SYSTEM','AUDSYS','DBSNMP','APPQOSSYS')
GROUP BY owner, object_type
ORDER BY invalid_count DESC;

-- List all invalid objects (for remediation)
SELECT owner, object_name, object_type,
       TO_CHAR(last_ddl_time,'DD-MON-YYYY HH24:MI') AS last_changed
FROM DBA_OBJECTS
WHERE status = 'INVALID'
  AND owner NOT IN ('SYS','SYSTEM','AUDSYS','DBSNMP','APPQOSSYS')
ORDER BY owner, object_type, object_name;

কোনো patch বা schema পরিবর্তনের পরে, invalid objects গুলো recompile করুন:

-- Recompile all invalid objects (run as DBA)
EXEC UTL_RECOMP.RECOMP_PARALLEL(4);

-- Or recompile a specific schema
EXEC UTL_RECOMP.RECOMP_SERIAL('ERP_OWNER');

৭. ক্যাটেগরি ৬ — Configuration & Parameter Review

ইনস্টলেশনের সময় সেট করা Oracle initialization parameter খুব কমই পুনরায় দেখা হয়। ডেটাবেজ বড় হওয়ার সাথে এবং ওয়ার্কলোড পরিবর্তনের সাথে, go-live-এর সময় যেসব parameter উপযুক্ত ছিল সেগুলো কয়েক বছর পরে bottleneck হয়ে উঠতে পারে।

৭.১ পর্যালোচনা করার মতো মূল Parameter

-- Key parameters affecting performance and stability
SELECT name, value, description
FROM V$PARAMETER
WHERE name IN (
  'sga_target',           -- Total SGA size
  'pga_aggregate_target', -- Total PGA size
  'db_cache_size',        -- Buffer cache
  'shared_pool_size',     -- Shared pool
  'db_block_size',        -- Block size (fixed at creation)
  'processes',            -- Max concurrent processes
  'sessions',             -- Max concurrent sessions
  'open_cursors',         -- Max open cursors per session
  'undo_retention',       -- Undo retention period (seconds)
  'log_buffer',           -- Redo log buffer size
  'parallel_max_servers', -- Max parallel query servers
  'db_file_multiblock_read_count', -- Full scan efficiency
  'optimizer_mode',       -- ALL_ROWS, FIRST_ROWS, etc.
  'cursor_sharing'        -- EXACT, FORCE, SIMILAR
)
ORDER BY name;

৭.২ Memory Advisor সুপারিশ

-- SGA component sizing recommendations from Memory Advisor
SELECT component, current_size/1024/1024 AS current_mb,
       min_size/1024/1024 AS min_mb,
       max_size/1024/1024 AS max_mb
FROM V$SGA_DYNAMIC_COMPONENTS
WHERE current_size > 0
ORDER BY current_size DESC;

৭.৩ Non-Default Parameter (কাস্টমাইজ করা সেটিংস)

-- Parameters changed from Oracle defaults (review each one)
SELECT name, value, default_value, description
FROM V$PARAMETER
WHERE isdefault = 'FALSE'
  AND name NOT IN ('db_name','db_unique_name','control_files',
                   'db_recovery_file_dest','db_recovery_file_dest_size')
ORDER BY name;

৮. ক্যাটেগরি ৭ — High Availability Readiness

অনেক প্রতিষ্ঠান মনে করে তাদের HA আছে কারণ তাদের RMAN backup আছে। কিন্তু backup মানে HA নয় — এটি recovery। এই ক্যাটেগরি পরীক্ষা করে ডেটাবেজটি প্রকৃত availability-র জন্য কনফিগার করা আছে কিনা।

৮.১ Database Mode এবং Archiving

-- Database must be in ARCHIVELOG mode for online backups and DR
SELECT name, log_mode, open_mode, protection_mode,
       database_role, db_unique_name
FROM V$DATABASE;

যদি LOG_MODE = NOARCHIVELOG হয় — এটি একটি critical finding। ডেটাবেজটি অনলাইনে backup নেওয়া যায় না এবং Data Guard standby সাপোর্ট করতে পারে না।

৮.২ Data Guard স্ট্যাটাস (যদি কনফিগার করা থাকে)

-- Check Data Guard configuration status
SELECT database_role, protection_mode, protection_level,
       switchover_status, dataguard_broker
FROM V$DATABASE;

-- Check standby apply lag
SELECT name, value, datum_time
FROM V$DATAGUARD_STATS
WHERE name IN ('transport lag','apply lag','estimated startup time');

৮.৩ Flash Recovery Area Health

-- Check all FRA files and their status
SELECT file_type, percent_space_used, percent_space_reclaimable,
       number_of_files
FROM V$RECOVERY_AREA_USAGE
ORDER BY percent_space_used DESC;

৯. একটি পেশাদার হেলথ চেক কী প্রদান করে

উপরের কোয়েরিগুলো চালালে আপনি কাঁচা ডেটা পাবেন। একটি পেশাদার হেলথ চেক সেই ডেটাকে অগ্রাধিকার অনুসারে সাজানো একটি action plan-এ রূপান্তরিত করে। আমার Oracle হেলথ চেক এনগেজমেন্টের deliverable-এ অন্তর্ভুক্ত থাকে:

• Executive Summary: প্রতিটি ক্যাটেগরির জন্য সামগ্রিক ডেটাবেজ health রেটিং (Green / Amber / Red) — কারিগরি জ্ঞান ছাড়াই ম্যানেজমেন্টের পড়ার উপযোগী
• Critical Findings: যেসব সমস্যা কোনো ঘটনা ঘটানোর আগেই তাৎক্ষণিক পদক্ষেপ দাবি করে — ঝুঁকি অনুসারে সাজানো
• Performance Analysis: Top wait events, সবচেয়ে খারাপ-পারফর্মিং SQL, এবং প্রত্যাশিত প্রভাব সহ নির্দিষ্ট tuning সুপারিশ
• Backup Assessment: backup সম্পূর্ণতা এবং recovery সক্ষমতার সৎ মূল্যায়ন — প্রকৃত recovery সময়ের অনুমান সহ
• Security Report: সমস্ত privilege লঙ্ঘন, নিষ্ক্রিয় account, এবং ডিফল্ট পাসওয়ার্ড — remediation পদক্ষেপ সহ
• Space Forecast: Tablespace বৃদ্ধির প্রক্ষেপণ — প্রতিটি tablespace critical ধারণক্ষমতায় পৌঁছাতে কত মাস বাকি
• Configuration Recommendations: প্রত্যাশিত performance প্রভাব সহ parameter পরিবর্তন
• Invalid Objects List: invalid schema objects-এর সম্পূর্ণ তালিকা এবং remediation স্ক্রিপ্ট
• ২ ঘণ্টার ফলো-আপ কল: findings নিয়ে আলোচনা, প্রশ্নের উত্তর, আপনার টিমের সাথে remediation অগ্রাধিকার নির্ধারণ

১০. বাংলাদেশের Oracle পরিবেশে সাধারণ Findings

বাংলাদেশের ম্যানুফ্যাকচারিং, ফার্মা, ব্যাংকিং এবং সফটওয়্যার প্রতিষ্ঠানগুলোতে হেলথ চেক করার পর, এই findings গুলো আমি সবচেয়ে বেশি মুখোমুখি হই:

• NOARCHIVELOG mode: ডেটাবেজ অনলাইনে backup নেওয়া যায় না বা DR সাপোর্ট করতে পারে না — তাৎক্ষণিক ঝুঁকি
• ডেটাবেজের একই storage-এ backup: ডেটা এবং backup উভয়ের জন্য single point of failure
• একাধিক ব্যবহারকারী একটি Oracle account শেয়ার করছেন: Audit trail অকেজো — পরিবর্তনগুলো ব্যক্তির সাথে সংযুক্ত করা যায় না
• Tablespace autoextend unlimited: কোনো সতর্কতা ছাড়াই সমস্ত ডিস্ক স্পেস গ্রাস করতে পারে — ফাইলসিস্টেম পূর্ণ হয়, সার্ভার ক্র্যাশ করে
• ওয়ার্কলোডের তুলনায় SGA আকারে ছোট: অতিরিক্ত physical reads — ডেটাবেজ প্রয়োজনের চেয়ে অনেক বেশি পরিশ্রম করছে
• ডজনখানেক invalid objects: অ্যাপ্লিকেশন procedure নীরবে ব্যর্থ হচ্ছে বা দুর্বলভাবে চলছে
• কোনো AWR baseline নেই: তুলনা করার মতো কোনো baseline নেই — performance খারাপ হয়েছে কিনা জানা অসম্ভব
• FGA / auditing নিষ্ক্রিয়: নিয়ন্ত্রিত ডেটার জন্য কোনো audit trail নেই — ফার্মা ও ব্যাংকিং পরিবেশে compliance ঝুঁকি

শেষ কথা

একটি Oracle হেলথ চেক হলো DBA-দের কাছে একটি মেডিকেল চেক-আপের সমতুল্য। বেশিরভাগ সময়, নাটকীয় কিছু পাওয়া যায় না। কিন্তু আসল মূল্য সেই মুহূর্তগুলোতে যখন গুরুতর কিছু আগেভাগে ধরা পড়ে — কোনো প্রকৃত recovery-র সময় backup ব্যর্থ হওয়ার আগে, মাঝরাতে tablespace পূর্ণ হওয়ার আগে, কমপ্লায়েন্স অডিটের সময় নিষ্ক্রিয় DBA account আবিষ্কৃত হওয়ার আগে।

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

আপনার Oracle ডেটাবেজের গত ১২ মাসে যদি কোনো কাঠামোবদ্ধ হেলথ চেক না হয়ে থাকে, তবে একটি নির্ধারণ করুন। এই আর্টিকেলের কোয়েরিগুলো একটি শুরুর বিন্দু হিসেবে চালান। আর যদি ফলাফল আপনাকে উদ্বিগ্ন করে, বা আপনি বরং একজন অভিজ্ঞ DBA দিয়ে findings পর্যালোচনা করিয়ে একটি অগ্রাধিকার অনুসারে সাজানো action plan নিতে চান — সেটিই আমি ঠিক অফার করি।