🏃‍♀️ 30‑DAY EXERCISE PLAN

🟢 Week 1 (Days 1–7)

Goal: Build routine

• Brisk walk: 30 min
• Stretching: 10 min
• Core:
  • Plank – 3×20 sec
  • Crunches – 3×10
    ✅ 5 workout days

---

🟡 Week 2 (Days 8–14)

Fat‑burning

• Jumping jacks – 3×30
• Squats – 3×15
• Lunges – 3×10 each leg
• Push‑ups (wall/knee) – 3×10
• Walk/cycling – 20 min
  ✅ 6 days

---

🟠 Week 3 (Days 15–21)

Strength + Cardio

Day A (Bodyweight)

• Squats – 4×15
• Push‑ups – 4×12
• Plank – 3×30 sec

Day B (Cardio)

• Fast walk / jog – 40 min
  ✅ Alternate days

---

🔴 Week 4 (Days 22–30)

Advanced Fat Loss

• Squats – 3×20
• Mountain climbers – 3×30 sec
• Burpees – 3×8
• Plank – 3×45 sec
• Stretching – 10 min
  ✅ 6 days + 1 recovery day

---

📉 EXPECTED RESULTS (SAFE & REALISTIC)

• Weight loss: 2–4 kg in 30 days
• Reduced belly fat
• Improved stamina & digestion
• Better sleep and energy levels

30‑DAY Weight Loss VEGETARIAN DIET PLAN + EXERCISE PLAN

 

✅ BASIC GUIDELINES

• Eat 300–500 calories less than daily needs
• Drink 2.5–3 liters water/day
• Sleep 7–8 hours
• Avoid sugar, fried food, bakery items
• Control portions (very important)

---

🥗 30‑DAY VEGETARIAN DIET PLAN

🌅 Early Morning (Daily)

• Warm water + lemon
• Optional:
  • 5 soaked almonds or
  • 1 tsp soaked chia seeds

---

🍳 Breakfast (Rotate Options)

Option 1

• Vegetable oats / dal chilla (2)
• Mint chutney

Option 2

• Paneer bhurji (100 g) + 1 multigrain toast

Option 3

• Poha / Upma (less oil, more veggies) – small bowl
• 1 fruit

Option 4

• Besan chilla (2) + curd

---

🍎 Mid‑Morning Snack

• 1 fruit (apple, papaya, guava, orange)
• OR coconut water
• OR green tea

---

🍛 Lunch (Balanced Veg Plate)

👉 ½ plate vegetables | ¼ protein | ¼ carbs

Protein (choose one):

• Dal
• Rajma / Chole
• Paneer / Tofu
• Curd (200 ml)

Carbs:

• 1–2 multigrain rotis
• OR 1 small bowl brown rice

Add:

• Raw salad
• 1 tsp ghee allowed

---

☕ Evening Snack

• Roasted chana / makhana
• Sprouts chaat
• Buttermilk
• Handful of peanuts (2–3 times/week)

🚫 Avoid biscuits, samosa, namkeen

---

🌙 Dinner (Light + Protein‑Rich)

• Sabzi + paneer/tofu
• OR vegetable soup + salad
• OR curd + sautéed vegetables

⏰ Finish dinner before 8 pm

---

🏃‍♀️ 30‑DAY VEGETARIAN EXERCISE PLAN

🟢 Week 1 (Days 1–7)

Goal: Build routine

• Brisk walk: 30 min
• Stretching: 10 min
• Core:
  • Plank – 3×20 sec
  • Crunches – 3×10
    ✅ 5 workout days

---

🟡 Week 2 (Days 8–14)

Fat‑burning

• Jumping jacks – 3×30
• Squats – 3×15
• Lunges – 3×10 each leg
• Push‑ups (wall/knee) – 3×10
• Walk/cycling – 20 min
  ✅ 6 days

---

🟠 Week 3 (Days 15–21)

Strength + Cardio

Day A (Bodyweight)

• Squats – 4×15
• Push‑ups – 4×12
• Plank – 3×30 sec

Day B (Cardio)

• Fast walk / jog – 40 min
  ✅ Alternate days

---

🔴 Week 4 (Days 22–30)

Advanced Fat Loss

• Squats – 3×20
• Mountain climbers – 3×30 sec
• Burpees – 3×8
• Plank – 3×45 sec
• Stretching – 10 min
  ✅ 6 days + 1 recovery day

---

📉 EXPECTED RESULTS (SAFE & REALISTIC)

• Weight loss: 2–4 kg in 30 days
• Reduced belly fat
• Improved stamina & digestion
• Better sleep and energy levels

---

⚠️ IMPORTANT NOTES

• If you have thyroid, PCOS, diabetes, knee pain, or BP issues, adjust intensity with doctor advise
• Progress may slow some weeks – do not quit
• Diet consistency matters more than exercise

 

✅ Oracle Optimizer Hints – Complete Performance Guide

---

1️⃣ Access Path Hints (HOW data is accessed)

🔹 FULL

SELECT /*+ FULL(emp) */ * FROM emp;

✅ Use when

• Table scan is cheaper than index (large result set)
• Data warehouse / batch queries
• Index is highly fragmented or low selectivity

❌ Avoid when

• OLTP queries
• Highly selective predicates

---

🔹 INDEX

SELECT /*+ INDEX(emp emp_idx1) */ * FROM emp WHERE empno=100;

✅ Use when

• Optimizer ignores a good index
• Predicate is highly selective

❌ Avoid when

• Index clustering factor is poor
• Query returns large % of table

---

🔹 INDEX_FFS (Fast Full Scan)

SELECT /*+ INDEX_FFS(emp emp_idx1) */ empno FROM emp;

✅ Use when

• Index contains all required columns
• Avoids table access
• Batch/reporting queries

❌ Avoid when

• OLTP row lookup
• Index selective scan is better

---

🔹 NO_INDEX

SELECT /*+ NO_INDEX(emp emp_idx1) */ * FROM emp;

✅ Use when

• Bad index is wrongly chosen
• Index causes excessive random IO

---

2️⃣ Join Method Hints (HOW tables are joined)

Hint	Best For	Notes
USE_NL	Small → Large joins	OLTP
USE_HASH	Large ↔ Large	DWH
USE_MERGE	Sorted inputs	Rare

---

🔹 USE_NL

SELECT /*+ USE_NL(o c) */ *

FROM orders o, customers c

WHERE o.cust_id = c.cust_id;

✅ Use when

• Driving table is small
• Index exists on joined column

❌ Avoid when

• Large datasets
• No index → CPU disaster

---

🔹 USE_HASH

SELECT /*+ USE_HASH(o c) */ *

FROM orders o, customers c;

✅ Use when

• Large volume joins
• Data warehouse queries

❌ Avoid when

• OLTP
• Memory constrained systems

---

🔹 LEADING

SELECT /*+ LEADING(o c l) */ ...

✅ Use when

• Optimizer chooses wrong driving table
• Join order critical

❌ Avoid when

• Tables grow unpredictably

---

3️⃣ Parallel Execution Hints

🔹 PARALLEL

SELECT /*+ PARALLEL(orders 8) */ * FROM orders;

✅ Use when

• Batch jobs
• Reporting queries
• Offline processing

❌ Avoid when

• OLTP
• CPU saturation risk

---

🔹 NOPARALLEL

SELECT /*+ NOPARALLEL */ * FROM orders;

✅ Use when

• Unexpected parallelism
• CPU contention scenarios

---

4️⃣ Subquery & Query Transformation Hints

🔹 UNNEST

SELECT /*+ UNNEST */ *

FROM emp

WHERE deptno IN (SELECT deptno FROM dept);

✅ Use when

• Subquery performs badly
• Join equivalent is faster

---

🔹 NO_UNNEST

SELECT /*+ NO_UNNEST */ ...

✅ Use when

• Subquery logic must be preserved
• Optimizer transforms incorrectly

---

🔹 PUSH_SUBQ

✅ Use when

• Filter subquery earlier
• Reduce result set sooner

---

5️⃣ Aggregation & Grouping

🔹 HASH_GROUP_BY

SELECT /*+ HASH_GROUP_BY */ deptno, COUNT(*)

FROM emp GROUP BY deptno;

✅ Use when

• Large aggregations
• Enough memory available

---

🔹 SORT_GROUP_BY

✅ Use when

• Small datasets
• Avoid hash memory usage

---

6️⃣ Result Cache Hints

🔹 RESULT_CACHE

SELECT /*+ RESULT_CACHE */ COUNT(*) FROM country;

✅ Use when

• Read‑mostly tables
• Reference data

❌ Avoid when

• High DML rate tables

---

7️⃣ Cursor & Parsing Hints

🔹 BIND_AWARE

✅ Use when

• Data skew exists
• Bind peeking causes bad plans

---

🔹 CURSOR_SHARING_EXACT

✅ Use when

• Prevent unwanted cursor sharing
• SQL stability is critical

---

8️⃣ Anti‑Hints (Disable Optimizer Features)

🔹 NO_MERGE

SELECT /*+ NO_MERGE */ ...

✅ Use when

• View merge causes bad plans

---

🔹 NO_PARALLEL

✅ Use when

• Unexpected PX usage

---

🔹 NO_GATHER_OPTIMIZER_STATISTICS

✅ Use when

• Query stats collection causes overhead

---

9️⃣ When SHOULD You Use Hints ✅

✔ Reproducible bad execution plan
✔ Statistics verified as accurate
✔ SQL rewrite not feasible
✔ Emergency performance fix
✔ Plan stability required

---

🔟 When You Should NOT Use Hints ❌

❌ As first tuning action
❌ Without understanding execution plan
❌ For dynamic workloads
❌ Across application code blindly
❌ Instead of fixing SQL design

---

🔑 Best‑Practice Strategy (Golden Order)

1️⃣ Fix SQL logic
2️⃣ Add correct indexes
3️⃣ Refresh statistics
4️⃣ SQL Profiles
5️⃣ SQL Baselines
6️⃣ Hints (last resort)

✅ When to Use Hints

✔ Emergency fix
✔ Ad‑hoc SQL
✔ No control over stats
✔ Temporary workaround

---

✅ When to Use SQL Baselines (Recommended)

✔ Production applications
✔ Long‑term plan stability
✔ After tuning complete

✔ Upgrade‑safe deployments 

---

🎯 Real‑World DBA Tip

Hints freeze assumptions. Plans age badly.
Use them surgically and document heavily.

Oracle Database Production Hardening Checklist - Best Practice

 

✅ Oracle Database Production Hardening Checklist (RHEL)

---

1️⃣ OS & Kernel Hardening

🔒 OS Configuration

• Dedicated server / VM for Oracle only
• Correct RHEL version certified for Oracle
• Minimal packages installed (no GUI, dev tools)
• NTP / chrony configured and synced

chronyc tracking

---

⚙ Kernel Parameters

Verify:

sysctl -a | egrep "shm|sem|fs.aio|max_map_count"

Key settings:

• kernel.shmmni, shmmax, shmall
• kernel.sem sized for workload
• fs.aio-max-nr sufficient
• vm.swappiness = 1
• vm.zone_reclaim_mode = 0

✅ Persist in /etc/sysctl.conf

---

❌ Transparent Huge Pages (THP)

• THP set to never

cat /sys/kernel/mm/transparent_hugepage/enabled

---

2️⃣ CPU & NUMA Hardening

🧠 NUMA Validation

lscpu | grep NUMA

numactl --hardware

• NUMA detected and considered
• Oracle memory interleaving enabled
• No CPU pinning unless justified

Recommended:

numactl --interleave=all

---

🔥 CPU Oversubscription

• No CPU quota throttling (VM / container)
• vCPU ≤ physical CPU
• Hyper‑threading understood and planned

---

3️⃣ Memory Hardening

📦 SGA & PGA

• SGA < per‑NUMA node memory
• PGA target sized (avoid PGA spills)
• HugePages configured (if applicable)

Check HugePages:

grep Huge /proc/meminfo

---

🚨 Swap

• Swap enabled but minimal
• No Oracle paging to swap

vmstat 1 5

---

4️⃣ Storage & IO Hardening

💾 Disk Separation (Mandatory)

• Datafiles
• Redo logs
• Archive logs / FRA
• Temp
• Backups

No sharing of redo + data.

---

⏱ IO Latency Targets

IO Type	Target
Redo writes	< 5 ms
Data reads	< 15 ms
Temp IO	< 20 ms

Verify:

iostat -xm 1 5

---

🧩 ASM (If Used)

• Diskgroup redundancy defined
• Rebalance power controlled
• No mixed latency tiers in same DG

---

5️⃣ Oracle Parameter Hardening

✅ Mandatory Parameters

show parameter processes;

show parameter sessions;

show parameter open_cursors;

Ensure:

• open_cursors ≥ 2–3× app need
• processes sized for peak
• sessions = processes * 1.5

---

⚡ Performance Safety

• cursor_sharing = FORCE (only if needed)
• result_cache_mode evaluated
• optimizer_adaptive_features controlled
• parallel_degree_policy understood

---

6️⃣ Security & Access Hardening

🔐 OS Level

• Oracle user non‑login shell (if allowed)
• SSH key‑based access
• No password reuse
• Root access logged

---

🔑 Database Level

• Password profiles enforced
• Default accounts locked
• Strong SYS password
• ADMIN roles minimized

SELECT username FROM dba_users WHERE account_status!='OPEN';

---

7️⃣ Resource Management (Very Important)

🎛 Oracle Resource Manager

• Enabled in production
• Separate OLTP / Batch consumers
• CPU runaway prevention

SHOW PARAMETER resource_manager_plan;

---

8️⃣ Backup & Recovery Hardening

🛡 RMAN

• Daily incremental
• Weekly full
• Archive log backups
• Controlfile autobackup ON

SHOW ALL;

---

🔁 Restore Testing

• Restore tested quarterly
• PITR validated
• Backup success monitored

---

9️⃣ Monitoring & Alerting

📊 OS Monitoring

• CPU, load
• Memory pressure
• IO latency
• Filesystem usage

---

🧠 Oracle Monitoring

• AWR enabled
• ASH accessible
• Tablespace growth alerts
• Session thresholds

---

🔍 Baselines

• CPU baseline captured
• IO latency baseline captured
• AWR baseline saved post go‑live

---

🔟 Patch & Lifecycle Management

🧩 Oracle

• Quarterly RU applied
• OPatch version updated
• Patch rollback plan ready

---

🧩 OS

• Kernel patches tested
• Reboot procedure documented
• Firmware audited (if bare metal)

---

1️⃣1️⃣ High Availability & DR

• Data Guard configured (if required)
• DG lag alerts
• Switchover tested
• DR RTO/RPO documented

---

1️⃣2️⃣ Documentation & Audit Readiness

• SOPs (CPU, IO, Outage)
• RCA template
• Architecture diagram
• Capacity forecast
• CMDB updated

---

✅ Final “GO‑LIVE” Gate Criteria

✔ Stable CPU baseline
✔ Disk latency within SLA
✔ RMAN recoverable
✔ Resource controls enabled
✔ Security controls enforced

---

📌 Pro Tip (Real‑World)

Most production outages happen due to lack of resource controls, not lack of hardware.

Oracle Database CPU Performance Troubleshooting

 

Oracle Database CPU Performance Troubleshooting (RHEL)

1. Typical CPU Performance Symptoms

• High CPU utilization (near 100%)
• Load average increases rapidly
• Slow query response while disk latency is normal
• AWR shows:
  • DB CPU
  • CPU time
  • resmgr:cpu quantum
• OS %idle very low and %wa low (CPU, not IO)

---

2. Step‑1: Confirm CPU Pressure at OS Level

✅ Check load vs CPU cores

uptime

nproc

lscpu | egrep 'CPU\(s\)|Core|Socket|Thread'

Interpretation

• Load average ≤ CPU cores → system OK
• Load average >> CPU cores → CPU contention

Example:

load average: 48.21, 45.12, 40.90
CPU cores: 24

➡️ CPU saturation confirmed

---

3. Step‑2: Identify CPU Utilization & Wait

✅ top (quick overview)Focus on top line:

top

%Cpu(s): 92.4 us, 3.1 sy, 0.2 ni, 2.0 id, 1.5 wa

CPU‑bound system

• %us + %sy high
• %id near 0
• %wa low

---

✅ vmstat – verify run queue

vmstat 1 10

Key columns:

Column	Meaning
r	Runnable processes
us	User CPU
sy	System CPU
id	Idle
wa	IO wait

If r > CPU cores consistently → CPU contention

---

4. Step‑3: Identify Top CPU Consumers

✅ Per‑process CPU usage

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -20

Look for:

• Oracle foreground sessions
• Oracle background processes (ora_*)
• Non‑DB processes stealing CPU

---

✅ Real‑time per‑process view

top -H -p $(pgrep -d',' -f ora_)

This shows Oracle threads consuming CPU.

---

5. Step‑4: Per‑CPU & Core Imbalance

✅ mpstat (very important on NUMA)

mpstat -P ALL 1 5

Look for:

• Some CPUs at 100%
• Others mostly idle

➡️ Indicates:

• NUMA imbalance
• CPU affinity or pinning problem

---

6. Step‑5: Context Switching & Syscall Overhead

✅ pidstat – CPU & context switches

pidstat -u -w 1 5

High:

• cswch/s (context switches)
• nvcswch/s

➡️ Too many active sessions or excessive parsing

---

7. Step‑6: Oracle Side – Is Database the CPU Consumer?

✅ CPU usage inside Oracle

SELECT stat_name, value

FROM v$sysstat

WHERE stat_name IN ('CPU used by this session','DB CPU');

Check ratio:

• DB CPU close to total DB time → CPU bottleneck
• IO waits dominant → not CPU issue

---

8. Step‑7: Identify Oracle Sessions Using CPU

✅ Active CPU sessions

SELECT s.sid, s.serial#, s.username,

s.program, s.status,

p.spid OS_PID

FROM v$session s, v$process p

WHERE s.paddr = p.addr

AND s.status = 'ACTIVE'

AND s.wait_class = 'CPU'

ORDER BY s.last_call_et DESC;

🔁 Correlate SPID with OS:

top -p <spid>

---

9. Step‑8: SQL Responsible for CPU Usage

✅ Top CPU SQL

SELECT sql_id,

cpu_time/1000000 cpu_sec,

executions,

cpu_time/executions avg_cpu

FROM v$sql

ORDER BY cpu_time DESC

FETCH FIRST 10 ROWS ONLY;

Red flags:

• High avg_cpu
• Low executions but high total CPU
• Cartesian joins
• Missing indexes

---

10. Step‑9: Run Queue vs CPU Throttling

✅ Check cgroups / VM CPU limits

cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us

cat /sys/fs/cgroup/cpu/cpu.cfs_period_us

Quota < total cores → CPU throttling

---

11. Step‑10: Oracle Resource Manager (Very Common)

✅ Check RM activation

SHOW PARAMETER resource_manager_plan;

✅ CPU waits due to RM

SELECT event, total_waits, time_waited/100 time_sec

FROM v$system_event

WHERE event LIKE 'resmgr%';

If high:

• Sessions are being CPU throttled intentionally

---

12. Common CPU Root Causes

Cause	Symptom
Bad execution plan	Single SQL consumes most CPU
Missing index	Full scans
High parse rate	Hard parsing
Too many sessions	Context switching
CPU oversubscription	VM / container CPU cap
NUMA imbalance	Some CPUs overloaded

---

13. Immediate Mitigation Actions

✅ Short‑term:

• Kill runaway sessions
• Reduce parallelism
• Disable unnecessary jobs
• Temporarily increase CPU shares

✅ Medium‑term:

• SQL tuning (indexes, hints)
• Bind variables
• Increase cursor cache
• Enable Result Cache (where valid)

✅ Long‑term:

• SQL baselines
• CPU capacity increase
• NUMA pinning
• Resource Manager redesign

---

14. One‑Shot CPU Triage Command Set

uptime

vmstat 1 5

mpstat -P ALL 1 5

top -H -p $(pgrep -d',' -f ora_)

Oracle:

SELECT sql_id, cpu_time/1000000 cpu_sec

FROM v$sql

ORDER BY cpu_time DESC FETCH FIRST 5 ROWS ONLY;

---

15. CPU vs IO – Golden Rule

Observation	Root Cause
High %us, low %wa	CPU bottleneck
High load, CPUs idle	IO bottleneck
High DB CPU in AWR	SQL tuning required
RM waits	Resource controls

Production Server/Database/Application troubleshooting Runbook for Issue like CPU, Memory, I/o , Kernel

 

0️⃣ Runbook Objectives

This runbook helps you:

✅ Quickly identify CPU, I/O, memory, or process issues
✅ Correlate OS metrics with database / application symptoms
✅ Avoid random commands during incidents
✅ Reach root cause, not just symptom relief

---

1️⃣ Incident Intake (ALWAYS FIRST)

Before touching the system, collect:

Question	Why
What is impacted? (DB, app, batch, login)	Scope
Since when?	Time correlation
All users or subset?	Severity
Any recent changes?	Deploy / patch
Error messages?	Symptom confirmation

📌 Do not skip this step. It saves 30–40% time later.

---

2️⃣ High‑Level System Health Snapshot (30 seconds)

2.1 Uptime & Load

uptime

Focus on:

• Load average vs CPU cores
• Sudden spike timeframe

✅ Load > CPU count → investigate
✅ Load + low CPU → likely I/O wait

---

2.2 Disk Space (quick sanity)

df -h

🚨 Any filesystem ≥ 90% → fix immediately

---

3️⃣ Real‑Time CPU & Memory View (top)

top

3.1 CPU Line Interpretation

%Cpu(s): 12 us, 5 sy, 0 ni, 60 id, 23 wa

Metric	Meaning
us	App/SQL CPU
sy	Kernel CPU
id	Idle
wa	I/O wait

🚨 wa > 15% → jump to I/O section

---

3.2 Process Area

• Sort by CPU: Shift + P
• Sort by MEM: Shift + M

Note:

• PID
• %CPU
• %MEM
• COMMAND

👉 Take PID(s) for next step.

---

4️⃣ Exact Process Diagnosis (ps)

✅ Master Command (use this by default)

ps -eo user,pid,ppid,stat,%cpu,%mem,etime,wchan,comm --sort=-%cpu

What to Look For

Symptom	Indicator
High CPU	%cpu, R state
Hung process	D state
Long running	High etime
I/O wait	wchan = io_schedule
Zombie	Z

---

🔴 Critical: Find Blocked (I/O) Processes

ps -eo pid,stat,wchan,etime,comm | awk '$2 ~ /D/'

If you see:

• ora_*
• java
• mysqld

➡️ Storage / filesystem issue almost certain

---

5️⃣ Kernel Stress View (vmstat)

vmstat 1 5

Key Columns

Column	Meaning
r	Runnable processes
b	Blocked (I/O wait)
si/so	Swap usage
wa	I/O wait

Interpretation Rules

Observation	Meaning
b > 0	Processes stuck in I/O
wa high	Disk latency
si/so > 0	Memory pressure
r > CPU cores	CPU contention

---

6️⃣ Storage Diagnosis (iostat)

iostat -xz 1 5

Critical Metrics

Metric	Bad Threshold
%util	> 80%
await	> 20 ms
await >> svctm	Queueing issue

Conclusions

Pattern	Root Cause
High await + D state	Storage latency
High util	Disk saturation
NFS disks slow	Network / mount issue

🚨 DBWR / LGWR in D state = immediate escalation

---

7️⃣ Memory Focused Check

ps -eo pid,stat,rss,vsz,%mem,comm --sort=-rss | head

If:

• RSS very high
• Swap active

➡️ Tune memory / restart leaking service

---

8️⃣ Oracle / Database‑Specific Quick Checks

8.1 Oracle Processes

ps -eo pid,stat,%cpu,wchan,etime,comm | grep ora_

8.2 Dangerous Signs

Process	Issue
ora_dbw* in D	Datafile I/O
ora_lgwr in D	Redo disk
Many ora_w* in D	Parallel I/O stall

➡️ Do NOT bounce DB blindly

---

9️⃣ Decision Matrix (Very Important)

Observation	Action
High CPU, no D	Tune app/SQL
High wa + D	Storage escalation
Z processes	Restart parent
Swap active	Add memory / reduce usage
Disk full	Cleanup immediately

---

🔔 Escalation Triggers

Escalate to Storage / Infra when:

• D state persists > 5 minutes
• await > 50 ms
• DB background processes blocked

Escalate to App/DB Team when:

• CPU us > 80%
• Single PID dominating CPU
• SQL identified as hot spot

---

✅ One‑Glance Incident Command Set

uptime

top

ps -eo pid,stat,%cpu,%mem,wchan,comm --sort=-%cpu

vmstat 1 5

iostat -xz 1 5

---

🧠 Golden Rule (Remember This)

High load does NOT always mean CPU problem.
D state + wa = storage until proven otherwise.

Step by step troubleshoot performance issue Linux , Oracle - CPU , Memory, I/O

 

🔍 Correlation of ps, top, iostat, and vmstat

Mental Model (Very Important)

Tool	Answers the Question
ps	Which exact process is responsible?
top	Is the problem CPU or memory pressure right now?
iostat	Is storage slow or saturated?
vmstat	Is the kernel under memory / run‑queue / I/O stress?

👉 Never use only one tool.
Real root cause comes from correlating outputs.

---

1️⃣ top — Real‑Time CPU & Memory Pressure

Best usage

top

(or top -o %CPU on newer systems)

What to focus on (top header)

%Cpu(s): 85.2 us, 10.1 sy,  0.0 ni,  2.0 id,  2.5 wa

Field	Meaning
us	User CPU (app / DB code)
sy	Kernel CPU
id	Idle CPU
wa	I/O wait (very important)

Interpretation

• ✅ High us → application or SQL CPU
• ✅ High sy → kernel, system calls, networking
• 🚨 High wa → storage problem, not CPU

---

Process section (top half)

PID   USER  %CPU  %MEM  COMMAND
2456  oracle 180.2 12.3 ora_dbw0

Now you jump to ps.

---

2️⃣ ps — Identify the Exact Culprit

Correlate with:

ps -eo pid,ppid,stat,%cpu,%mem,etime,wchan,comm | sort -k5 -nr | head

Key correlation

top shows	ps confirms
High CPU PID	%cpu, etime
Hung process	STAT = D
Storage wait	wchan = io_schedule

🚨 Example:

2456  D  io_schedule  ora_dbw0

👉 This tells you:
DBWR is blocked on disk I/O

Now you must check storage.

---

3️⃣ iostat — Storage Bottleneck Detection

Best command

iostat -xz 1 5

Critical columns

Column	Meaning
%util	Disk busy time
await	Avg I/O latency (ms)
svctm	Disk service time
r/s w/s	Read/write rate

---

Interpretation Rules (Golden)

Symptom	Meaning
%util > 80%	Disk saturated
await > 20 ms	Storage slow
await >> svctm	Queueing problem
High writes + DBWR stuck	Redo / data disk issue

🚨 Example:

sda  %util=99.8  await=120ms

✅ Confirms ps + top → storage root cause

---

4️⃣ vmstat — Kernel Stress & Memory I/O

Best command

vmstat 1 5

Key columns

r  b   swpd   free   buff  cache  si so   bi bo   in cs us sy id wa

---

Important fields explained

Column	Meaning
r	Run queue (CPU demand)
b	Blocked processes (I/O)
si/so	Swap in/out
bi/bo	Block I/O
wa	I/O wait (kernel view)

---

Correlation logic

vmstat shows	Combined meaning
b > 0	Processes stuck in I/O
wa high	CPU waiting for disk
r > CPU cores	CPU contention
si/so > 0	Memory pressure

🚨 Example:

r=1 b=6 wa=40

👉 Matches:

• ps → many D
• top → high I/O wait
• iostat → high disk latency

🎯 Root cause confirmed: storage

---

5️⃣ End‑to‑End Correlation Scenarios

---

✅ Scenario A: High Load Average

Observations

• uptime → load = 20
• top → CPU idle
• vmstat → b=10, wa=35
• ps → many D state
• iostat → high await

✅ Conclusion
Load is from I/O wait, not CPU
👉 Storage team issue

---

✅ Scenario B: CPU Spike

Observations

• top → %us=90
• vmstat → r > CPU cores
• ps → process in R state
• iostat → normal

✅ Conclusion
Pure CPU problem
👉 Tune SQL / app / threads

---

✅ Scenario C: Hung Oracle Instance

Observations

• ps → ora_dbw0, ora_lgwr in D
• vmstat → b > 5
• iostat → redo disk latency
• top → high wa

✅ Conclusion
Redo or data disk I/O stall
👉 SAN / ASM / NFS issue

---

6️⃣ Golden Troubleshooting Workflow (Memorize This)

symptom →

top →

ps →

vmstat →

iostat →

root cause

One‑liner sequence

top

ps -eo pid,stat,%cpu,wchan,comm | grep D

vmstat 1 5

iostat -xz 1 5

---

✅ Final Cheat Sheet

Tool	Best for
top	Live CPU/memory
ps	Exact process & state
vmstat	Kernel & wait queues
iostat	Disk latency & saturation

🎯 Never trust a single tool
Real diagnosis = correlation