practical, popular, and well‑sequenced travel plan from Gurgaon / Delhi NCR to Dharamshala & McLeod Ganj

 

How to Reach (Most Popular & Practical)

Best Options from Delhi NCR

1. Overnight Volvo Bus (Most common)

   • Boarding: Majnu Ka Tila / ISBT Kashmere Gate
   • Duration: 10–12 hrs
   • Cost: ₹1,200–2,000
   • Drop: Dharamshala / McLeod Ganj

2. Train + Cab (Comfortable)

   • Train: Delhi → Pathankot (overnight)
   • Cab: Pathankot → Dharamshala (3 hrs)

✅ For 3 days: Volvo bus is best
✅ For 5 days: Either option works

---

✅ 3 DAYS ITINERARY (Most Popular & Efficient)

Day 0 (Night) – Travel

• Overnight Volvo from Delhi/Gurgaon → Dharamshala

---

Day 1 – McLeod Ganj Core Sightseeing

Morning

• Reach Dharamshala / McLeod Ganj (6–8 AM)
• Hotel check‑in & freshen up
• Breakfast at Common Ground / Jimmy’s Italian

Late Morning – Walking Circuit (In Order)

1. Tsuglagkhang Complex
   • Dalai Lama Temple
   • Tibetan Museum
   • Prayer Wheels
2. Bhagsu Naag Temple
3. Bhagsu Waterfall

Afternoon

• Lunch at Nick’s Italian / Tibetan Kitchen
• Café hopping (Illiterati / Moonpeak Espresso)

Evening

• Sunset at Naddi View Point
• Market walk (souvenirs, shawls, thangkas)

Stay: McLeod Ganj
✅ Easy day, no exhaustion

---

Day 2 – Nature + Dharamshala

Early Morning

• Triund Trek
  • Start: 6–7 AM
  • Duration: 4–5 hrs up
  • View: Dhauladhar range (most popular attraction)

✅ Alternative (if skipping trek)

• Dal Lake
• St. John in the Wilderness Church

Afternoon

• Lunch at Triund (or McLeod Ganj if skipped)

Evening – Dharamshala Town

1. War Memorial
2. HPCA Cricket Stadium
3. Tea Garden Walk

Stay: Dharamshala or McLeod Ganj

---

Day 3 – Relax & Return

Morning

• Tushita / Dip Tse Chok Ling Monastery
• Brunch

Afternoon

• Shopping + rest

Evening

• Volvo bus back to Delhi NCR

---

✅ 5 DAYS ITINERARY (Relaxed + Complete)

Perfect if you want slow travel, photography, cafés, and monasteries.

---

Day 1 – Arrival & Light Exploration

• Reach McLeod Ganj by morning
• Rest + café hopping
• Tsuglagkhang Complex
• Evening market walk

---

Day 2 – Bhagsu & Waterfalls

1. Bhagsu Naag Temple
2. Bhagsu Waterfall
3. Shiva Café hike
4. Sunset at Naddi

Optional: Sound healing / meditation session

---

Day 3 – Triund Trek Day

• Early start for Triund Trek
• Spend time at top
• Return by evening

✅ Stay at McLeod Ganj
✅ No rushing

---

Day 4 – Dharamshala Town + Norbulingka

1. St. John Church
2. War Memorial
3. HPCA Stadium
4. Norbulingka Institute
   • Art, culture & peaceful gardens

Evening: Café + live music

---

Day 5 – Spiritual & Return

• Tushita Meditation Centre
• Dal Lake
• Brunch + shopping
• Evening bus back to Delhi

---

Best Time to Visit

• ✅ March–June: Pleasant weather
• ✅ Sept–Nov: Clear mountain views
• ⚠️ July–Aug: Monsoon (lush but risky treks)
• ❄️ Dec–Feb: Cold, possible snow

---

Budget Estimate (Per Person)

• Transport: ₹2,500–4,000
• Stay: ₹1,500–3,000/day
• Food: ₹800–1,000/day
• Trek/Taxi: ₹1,000–1,500

---

Pro Tips (Very Important)

• Carry cash (ATMs limited)
• Start treks early morning
• Book buses 2–3 days in advance
• Pack light jacket even in summer
• Avoid rushing Dharamshala town on Day 1

 

🏃‍♀️ 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.