Veritabanı yavaş

Belirti

Uygulama genelinde yavaşlık; sorgular normalden çok uzun sürüyor, kullanıcılar şikayetçi.

1. Önce 'yavaş olan ne' sorusunu netleştir

Her şey mi yavaş yoksa belirli bir sorgu/ekran mı? Ne zaman başladı, bir deploy/patch/veri artışı ile örtüşüyor mu? Sistem genelinde mi yoksa tek DB'de mi? Bu, aramayı CPU/IO/lock/plan değişimi eksenlerinden birine daraltır.

2. Aktif oturumları ve wait event'leri gör

O an ne çalışıyor ve ne bekliyor? Yoğun bir wait event (IO, lock, log) darboğazı işaret eder.

Oracle

SELECT sid, username, status, event, sql_id FROM v$session WHERE status='ACTIVE' AND type='USER';

PostgreSQL

SELECT pid, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state='active';

MySQL

SELECT id, user, command, time, state, info FROM information_schema.processlist WHERE command<>'Sleep' ORDER BY time DESC;

SQL Server

SELECT session_id, status, wait_type, wait_time, blocking_session_id FROM sys.dm_exec_requests WHERE session_id IN (SELECT session_id FROM sys.dm_exec_sessions WHERE is_user_process = 1);

MongoDB

db.currentOp({ active: true, secs_running: { $gt: 1 } })

Redis

SLOWLOG GET 10

3. Bloklama var mı bak

Yavaşlığın en sık nedeni birinin diğerlerini bloklamasıdır. Bloklayan oturumu bulup zincirin başını tespit et.

Oracle

SELECT blocking_session, sid, seconds_in_wait, event FROM v$session WHERE blocking_session IS NOT NULL;

PostgreSQL

SELECT pid, pg_blocking_pids(pid) AS blocked_by, query FROM pg_stat_activity WHERE cardinality(pg_blocking_pids(pid))>0;

MySQL

SELECT * FROM sys.innodb_lock_waits\G

SQL Server

SELECT session_id, blocking_session_id, wait_type FROM sys.dm_exec_requests WHERE blocking_session_id<>0;

4. En maliyetli sorguları çıkar

Kaynağı en çok yiyen ilk 10 sorguyu bul. Genellikle sorunun %90'ı birkaç sorgudan gelir.

Oracle

SELECT sql_id, elapsed_time/1e6 sec, executions, sql_text FROM v$sql ORDER BY elapsed_time DESC FETCH FIRST 10 ROWS ONLY;

PostgreSQL

SELECT calls, total_exec_time, mean_exec_time, query FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

MySQL

SELECT digest_text, count_star, sum_timer_wait/1e12 sec FROM performance_schema.events_statements_summary_by_digest ORDER BY sum_timer_wait DESC LIMIT 10;

SQL Server

SELECT TOP 10 total_elapsed_time/execution_count avg_us, execution_count, SUBSTRING(t.text,1,200) FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) t ORDER BY total_elapsed_time DESC;

5. Şüpheli sorgunun planını incele

Yavaş sorgu için EXPLAIN al. Tam tablo taraması (full scan), eksik index, kötü join sırası veya bayat istatistik ara. Plan aniden değiştiyse istatistik toplamayı düşün.

Oracle

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&sql_id', NULL, 'ALLSTATS LAST'));

PostgreSQL

EXPLAIN (ANALYZE, BUFFERS) <sorgu>;

MySQL

EXPLAIN ANALYZE <sorgu>;

SQL Server

SET STATISTICS PROFILE ON; <sorgu>; SET STATISTICS PROFILE OFF;

MongoDB

db.koleksiyon.find({...}).explain('executionStats')  // COLLSCAN mı IXSCAN mı?

6. Sistem kaynaklarını doğrula

OS düzeyinde CPU, IO bekleme (iowait), bellek ve disk doluluğuna bak. Cache hit oranını kontrol et; düşükse bellek darboğazı olabilir. Sorun DB dışında (disk dolu, komşu VM) olabilir.

7. Hızlı çözüm mü kalıcı çözüm mü karar ver

Acil rahatlama için: kaçak sorguyu kill et, eksik index'i ekle, istatistik topla. Kalıcı için: sorguyu/index'i yeniden tasarla, bellek ayarlarını düzelt, plan kararlılığını sağla (baseline/hint).