Česky na konci článku.

When a production database becomes slow, the most dangerous response is to make changes before understanding the problem.

Increasing memory, adding CPU, creating indexes or changing database parameters can sometimes improve performance.

But they can also hide the real problem.

For a Senior Database Administrator, database performance troubleshooting should follow a structured methodology:

Measure → Isolate → Diagnose → Change → Validate

The objective is not simply to make one query faster.

The objective is to identify the root cause of the bottleneck and make the database platform more predictable under real production workloads.

1. Start With Response Time

Users experience response time.

The database administrator sees resources, waits and execution plans.

These two views need to be connected.

A simplified request path looks like:

User
↓
Application
↓
Connection Pool
↓
Network
↓
Database
↓
Storage

If the application reports a response time of 5 seconds, that does not automatically mean the SQL statement spent 5 seconds executing inside the database.

The time could be distributed across several layers.

For example:

Application processing 800 ms
Connection acquisition 200 ms
Network latency 50 ms
Database execution 2,900 ms
Storage waits 1,050 ms
————————————————
Total 5,000 ms

Optimizing SQL alone would address only part of the problem.

This is why senior DBA troubleshooting must be cross-layer.

2. Establish a Performance Baseline

Before changing anything, establish what „normal“ looks like.

Useful baseline metrics include:

  • average query latency
  • database response time
  • transactions per second
  • CPU utilization
  • memory utilization
  • I/O latency
  • IOPS
  • active sessions
  • connection count
  • lock waits
  • replication lag
  • cache hit ratios
  • database growth

Without a baseline, it is difficult to determine whether a change actually improved the system.

A useful performance investigation therefore starts with:

Current State
↓
Historical Baseline
↓
Difference
↓
Investigation

One of the most valuable questions is:

What changed?

3. Performance Problems Often Begin With a Change

A database that has been stable for months suddenly becomes slow.

The DBA should immediately investigate recent changes.

For example:

  • application deployment
  • database upgrade
  • statistics refresh
  • new indexes
  • changed execution plan
  • increased data volume
  • new workload
  • storage migration
  • configuration change
  • network change
  • increased concurrency

A performance regression often has a timeline.

Finding the moment when the system behavior changed can dramatically reduce troubleshooting time.

4. Find the SQL Consuming the Most Resources

A database can execute millions of SQL statements.

The DBA needs to identify which statements actually matter.

Useful dimensions include:

  • total execution time
  • average execution time
  • CPU consumption
  • logical reads
  • physical reads
  • executions
  • rows processed
  • memory consumption
  • wait time

Consider two queries:

Query A
Executions: 10
Avg time: 8 sec
Total time: 80 sec
Query B
Executions: 2,000,000
Avg time: 10 ms
Total time: 20,000 sec

Query A is individually slow.

Query B may be the much larger production problem.

This distinction is extremely important.

A senior DBA should therefore analyze both:

Per-execution cost

and

Total workload cost.

5. Execution Plans Can Change

One of the most dangerous database performance problems is an unexpected execution-plan change.

A query that previously used:

Index Scan
↓
Small number of rows

may suddenly use:

Full Table Scan
↓
Millions of rows

The SQL text may not have changed.

Possible reasons include:

  • changed statistics
  • changed data distribution
  • different bind values
  • optimizer changes
  • database upgrades
  • new indexes
  • dropped indexes
  • changed configuration

This is why a senior DBA should not simply compare SQL text.

The DBA needs to compare execution plans and runtime behavior.

6. Oracle Performance Troubleshooting

Oracle provides a particularly rich set of performance diagnostics.

Important areas include:

  • AWR
  • ASH
  • ADDM
  • execution plans
  • wait events
  • SQL statistics
  • system statistics
  • I/O performance
  • session activity

A simplified investigation might look like:

AWR
↓
Top SQL
↓
ASH
↓
Execution Plan
↓
Wait Events
↓
Root Cause

For example, AWR may show that database time increased dramatically.

ASH can then help identify which sessions and SQL statements contributed to that increase.

The execution plan can reveal how those statements were executed.

The important point is:

The diagnostic tool provides evidence. The DBA provides the interpretation.

7. PostgreSQL Performance Troubleshooting

PostgreSQL provides a different set of tools and concepts.

Important areas include:

  • pg_stat_activity
  • pg_stat_statements
  • EXPLAIN
  • EXPLAIN ANALYZE
  • WAL activity
  • autovacuum
  • table and index bloat
  • locks
  • checkpoints
  • replication
  • I/O

A typical investigation could start with:

SELECT pid,
usename,
state,
wait_event_type,
wait_event,
query
FROM pg_stat_activity
WHERE state <> ‚idle‘;

The goal is to understand what active sessions are doing and whether they are waiting.

For important SQL, the next step may be:

EXPLAIN (ANALYZE, BUFFERS)
SELECT …

This can provide valuable information about:

  • actual execution time
  • row estimates
  • actual rows
  • buffer activity
  • execution nodes

The difference between estimated rows and actual rows can be particularly useful when investigating optimizer problems.

8. MySQL Performance Troubleshooting

For MySQL, the investigation typically includes:

  • Performance Schema
  • sys schema
  • slow query log
  • execution plans
  • InnoDB metrics
  • buffer pool activity
  • locks
  • transactions
  • replication

A DBA may begin with:

EXPLAIN
SELECT …

and then investigate the actual workload using Performance Schema and other monitoring data.

Important questions include:

  • Which statements consume the most time?
  • Which statements perform the most reads?
  • Are transactions holding locks?
  • Is InnoDB waiting for I/O?
  • Is the buffer pool appropriately sized?
  • Is replication introducing additional load?

9. Logical Reads vs. Physical Reads

A particularly important performance distinction is between logical and physical reads.

Conceptually:

Application
↓
Database
↓
Buffer / Cache
↓
Storage

A logical read can often be served from memory.

A physical read requires access to storage.

If a query performs an excessive number of physical reads, storage latency can become a major bottleneck.

But reducing physical I/O is not always as simple as increasing memory.

The DBA must first understand:

  • which objects are being accessed
  • which queries are responsible
  • whether the access path is appropriate
  • whether the workload is cache-friendly
  • whether storage itself is the limiting factor

10. Locking and Blocking Can Look Like a Performance Problem

Sometimes the database is not CPU-bound or I/O-bound at all.

Sessions may simply be waiting for other sessions.

For example:

Session A
|
+—- UPDATE customer
|
+—- Lock held
|
Session B ————+
|
WAITING

One transaction can therefore cause dozens or hundreds of other sessions to wait.

The resulting symptoms may look like:

  • high response time
  • low CPU
  • low I/O
  • increasing active sessions

This is a classic example of why resource utilization alone cannot explain database performance.

11. Concurrency Changes Everything

A query that performs well with one session may perform poorly with 500 concurrent sessions.

Concurrency can amplify:

  • CPU consumption
  • memory usage
  • locks
  • I/O
  • connection overhead
  • context switching
  • contention

Consider:

1 query × 1 session
↓
50 ms
Same query × 1,000 sessions
↓
Contention
↓
Queueing
↓
Higher latency

Performance testing must therefore consider concurrency, not only single-query execution time.

12. Don’t Ignore the Application

The DBA should never assume that every performance problem is caused by the database.

Application behavior can create enormous database load.

Examples include:

  • N+1 queries
  • unnecessary polling
  • excessive connections
  • repeated identical queries
  • missing pagination
  • inefficient transactions
  • fetching unnecessary columns
  • committing too frequently
  • keeping transactions open too long

A technically optimized database can still perform badly if the application generates an inefficient workload.

This is why senior DBAs need to communicate effectively with developers.

13. Performance Tuning Is a Trade-Off

There is rarely a change that improves everything.

For example, adding an index can improve:

SELECT performance

but increase:

INSERT cost
UPDATE cost
DELETE cost
Storage usage

Increasing memory may reduce:

Physical I/O

but excessive memory allocation can create:

OS memory pressure

Increasing parallelism may reduce execution time for one large query but increase:

CPU contention

A good DBA therefore asks:

What is the overall workload impact?

Not simply:

„Did this query get faster?“

14. Configuration Changes Should Be Evidence-Based

Database configuration contains hundreds of parameters.

Changing them without evidence creates risk.

A safer approach is:

Problem
↓
Evidence
↓
Hypothesis
↓
Small Change
↓
Measurement
↓
Validation

For example:

„I/O latency is high.“

is an observation.

„Increasing the buffer pool will solve the problem.“

is a hypothesis.

The DBA should then test the hypothesis rather than treating it as fact.

15. Performance Tuning Needs Regression Testing

A successful optimization today can become a problem tomorrow.

Imagine that an index improves:

Query A

but the same index causes:

INSERT workload

to become significantly slower.

Or a new execution plan improves one customer workload but makes another workload much worse.

Therefore performance changes should be validated against representative workloads.

The goal is:

Optimize the system, not one metric.

16. Automation Can Prevent Performance Incidents

Once a recurring performance problem has been identified, it should become a candidate for automation.

Examples:

Replication lag
↓
Threshold detection
↓
Alert

or:

Query latency
↓
Baseline comparison
↓
Anomaly detection
↓
Alert

or:

Disk growth
↓
Capacity forecast
↓
Early warning
↓
Planning

This changes the DBA role from:

Incident responder

to:

Reliability engineer

17. Performance Engineering and Database Reliability

Performance and reliability are closely connected.

A database that regularly operates at:

CPU: 95%
Connections: 98%
Storage: 95%

may technically be available.

But it has very little resilience.

A small increase in workload can push the system into failure.

A reliable database platform therefore needs headroom.

The DBA should understand:

  • current utilization
  • growth trends
  • capacity limits
  • failure scenarios
  • recovery capability

Performance engineering is therefore also a form of risk management.

18. The Senior DBA’s Real Advantage

Tools can collect metrics.

Monitoring systems can generate alerts.

AI can analyze patterns.

Cloud platforms can automate infrastructure.

But an experienced DBA can connect the evidence.

For example:

Query latency increased
↓
Execution plan changed
↓
Logical reads increased
↓
Buffer pressure increased
↓
Physical I/O increased
↓
Storage latency increased
↓
Application response time increased

The individual metrics are useful.

The relationship between them is what reveals the root cause.

That is where senior-level database expertise becomes extremely valuable.

A Practical Senior DBA Troubleshooting Model

When investigating a production performance problem, use this sequence:

1. Define the symptom

What exactly is slow?

2. Establish the baseline

What did normal look like?

3. Identify the affected workload

Which applications, SQL statements or sessions are involved?

4. Identify the bottleneck

CPU, memory, I/O, locks, network or concurrency?

5. Compare historical behavior

What changed?

6. Validate the execution plan

Is SQL being executed efficiently?

7. Identify the root cause

Do not stop at the symptom.

8. Make a controlled change

Change one important variable.

9. Measure

Did the system actually improve?

10. Prevent recurrence

Automate detection, document the solution and improve the architecture.

Final Takeaway

Advanced Database Performance Troubleshooting is not about memorizing hundreds of database parameters.

It is about understanding how the entire system behaves.

The most important relationships are:

SQL → Execution Plan → Resources → Waits → Storage → Application → Business Impact

Oracle, PostgreSQL and MySQL provide different diagnostic mechanisms, but the underlying engineering principles are remarkably similar.

A strong DBA does not immediately ask:

„What parameter should I change?“

The better question is:

„What evidence do I have about the actual bottleneck?“

And the most important question after fixing the problem is:

„How do we make sure this problem is detected earlier—or does not happen again?“

That is the transition from traditional Database Administration to Database Performance Engineering and Database Reliability Engineering.

About the Author

Tomas Solar
Principal Database Reliability Engineer

20+ years of experience with Oracle, PostgreSQL, MySQL, SQL Server and MongoDB.

Specialized in Database Administration, Performance Engineering, High Availability, Disaster Recovery, Database Reliability, Automation, Database Migration and Database Architecture.

The best performance optimization is not the one that makes a query faster once. It is the one that makes the entire database platform predictable under real production load.

Troubleshooting výkonu databází: Jak najít skutečný bottleneck v Oracle, PostgreSQL a MySQL

Série #91 — část 2 | Advanced Database Performance

Když se produkční databáze zpomalí, jednou z nejnebezpečnějších reakcí je začít okamžitě měnit konfiguraci bez pochopení problému.

Přidání paměti, CPU, indexů nebo změna databázových parametrů může někdy výkon zlepšit.

Stejně tak ale může skutečný problém pouze zamaskovat.

Pro Senior Database Administrátora by proto měl troubleshooting výkonu probíhat systematicky:

Measure → Isolate → Diagnose → Change → Validate

Tedy:

Změřit → Izolovat → Diagnostikovat → Změnit → Ověřit

Cílem není pouze zrychlit jeden SQL dotaz.

Cílem je najít kořenovou příčinu bottlenecku a vytvořit databázovou platformu, jejíž výkon je předvídatelný i při reálném produkčním zatížení.

1. Začněte response time

Uživatel vnímá především dobu odezvy.

DBA naopak vidí zdroje, wait events a execution plans.

Tyto dva pohledy je potřeba propojit.

Zjednodušený průchod požadavku může vypadat:

Uživatel
↓
Aplikace
↓
Connection Pool
↓
Síť
↓
Databáze
↓
Storage

Pokud aplikace hlásí response time 5 sekund, neznamená to automaticky, že SQL běželo 5 sekund v databázi.

Čas může být rozložen mezi několik vrstev:

Application processing 800 ms
Connection acquisition 200 ms
Network latency 50 ms
Database execution 2 900 ms
Storage waits 1 050 ms
———————————–
Celkem 5 000 ms

Optimalizace SQL by v takovém případě vyřešila pouze část problému.

Proto musí seniorní DBA při troubleshootingu uvažovat napříč celým technologickým stackem.

2. Vytvořte performance baseline

Než začnete cokoliv měnit, potřebujete vědět, jak vypadá normální stav.

Mezi důležité metriky patří:

  • průměrná latence SQL
  • response time databáze
  • transactions per second
  • využití CPU
  • využití paměti
  • I/O latency
  • IOPS
  • počet aktivních sessions
  • počet connections
  • lock waits
  • replication lag
  • cache hit ratio
  • růst databáze

Bez baseline je velmi obtížné určit, zda změna skutečně přinesla zlepšení.

Performance investigation by proto měla začínat:

Aktuální stav
↓
Historická baseline
↓
Rozdíl
↓
Analýza

Jedna z nejdůležitějších otázek zní:

Co se změnilo?

3. Performance problém často začíná změnou

Databáze může být měsíce stabilní a najednou se výrazně zpomalí.

První otázkou DBA by proto mělo být, co se v poslední době změnilo.

Například:

  • deployment nové verze aplikace
  • refresh statistik
  • změna execution planu
  • nové indexy
  • změna objemu dat
  • nový workload
  • migrace storage
  • změna konfigurace
  • změna síťové infrastruktury
  • zvýšení concurrency

Performance regression má často velmi konkrétní časovou osu.

Nalezení okamžiku, kdy se chování systému změnilo, může výrazně zkrátit dobu troubleshootingu.

4. Najděte SQL, které skutečně zatěžuje databázi

Databáze může zpracovávat miliony SQL statementů.

DBA musí zjistit, které z nich jsou skutečně důležité.

Sledovat lze například:

  • celkový čas
  • průměrný čas
  • CPU consumption
  • logical reads
  • physical reads
  • počet executions
  • počet zpracovaných řádků
  • memory consumption
  • wait time

Například:

Query A
Executions: 10
Avg time: 8 sec
Total time: 80 sec
Query B
Executions: 2 000 000
Avg time: 10 ms
Total time: 20 000 sec

Query A je individuálně pomalý.

Query B ale může být mnohem větším produkčním problémem.

To je velmi důležité rozlišení.

Senior DBA by proto měl analyzovat:

náklady jednoho execution

i

celkové náklady workloadu.

5. Execution Plan se může změnit

Jedním z nejnebezpečnějších performance problémů je neočekávaná změna execution planu.

Dotaz, který dříve používal:

Index Scan
↓
Malý počet řádků

může najednou používat:

Full Table Scan
↓
Miliony řádků

SQL se přitom vůbec nemuselo změnit.

Důvodem může být:

  • změna statistik
  • změna distribuce dat
  • jiné bind values
  • změna optimizeru
  • upgrade databáze
  • nový index
  • odstraněný index
  • změna konfigurace

Senior DBA proto nemůže porovnávat pouze SQL text.

Musí porovnávat execution plans a skutečné runtime chování.

6. Troubleshooting výkonu v Oracle

Oracle poskytuje velmi rozsáhlé možnosti diagnostiky výkonu.

Mezi důležité oblasti patří:

  • AWR
  • ASH
  • ADDM
  • execution plans
  • wait events
  • SQL statistics
  • system statistics
  • I/O performance
  • session activity

Typický postup může vypadat:

AWR
↓
Top SQL
↓
ASH
↓
Execution Plan
↓
Wait Events
↓
Root Cause

Například AWR může ukázat výrazný nárůst database time.

ASH následně pomůže identifikovat konkrétní sessions a SQL, které se na nárůstu podílely.

Execution plan pak může ukázat, jakým způsobem byly tyto dotazy skutečně provedeny.

Důležité je:

Diagnostický nástroj poskytuje data. DBA poskytuje interpretaci.

7. Troubleshooting PostgreSQL

PostgreSQL používá jinou sadu nástrojů a mechanismů.

Důležité jsou například:

  • pg_stat_activity
  • pg_stat_statements
  • EXPLAIN
  • EXPLAIN ANALYZE
  • WAL activity
  • autovacuum
  • table a index bloat
  • locks
  • checkpoints
  • replication
  • I/O

Analýzu lze například začít:

SELECT pid,
usename,
state,
wait_event_type,
wait_event,
query
FROM pg_stat_activity
WHERE state <> ‚idle‘;

Cílem je zjistit, co aktivní sessions právě dělají a na co případně čekají.

U důležitých SQL může následovat:

EXPLAIN (ANALYZE, BUFFERS)
SELECT …;

To poskytuje informace například o:

  • skutečném execution time
  • odhadu počtu řádků
  • skutečném počtu řádků
  • buffer activity
  • jednotlivých execution nodes

Velmi důležitý může být rozdíl mezi odhadovaným a skutečným počtem řádků.

8. Troubleshooting MySQL

U MySQL se performance investigation typicky zaměřuje na:

  • Performance Schema
  • sys schema
  • slow query log
  • execution plans
  • InnoDB metrics
  • buffer pool
  • locks
  • transactions
  • replication

DBA může například začít:

EXPLAIN
SELECT …;

a následně analyzovat skutečný workload pomocí Performance Schema a dalších diagnostických nástrojů.

Důležité otázky:

  • Které SQL spotřebovává nejvíce času?
  • Které SQL provádí nejvíce reads?
  • Drží některé transakce locky?
  • Čeká InnoDB na I/O?
  • Je Buffer Pool správně nastaven?
  • Nevytváří replication další zátěž?

9. Logical Reads vs. Physical Reads

Velmi důležité je rozlišovat mezi logical reads a physical reads.

Zjednodušeně:

Aplikace
↓
Databáze
↓
Buffer / Cache
↓
Storage

Logical read může být obsloužen z paměti.

Physical read vyžaduje přístup ke storage.

Pokud dotaz provádí extrémní množství physical reads, může se storage latency stát hlavním bottleneckem.

Řešením ale nemusí být automaticky přidání paměti.

DBA musí nejdříve zjistit:

  • které objekty se používají
  • které SQL je čtou
  • zda je access path správný
  • zda je workload vhodný pro cache
  • zda není problém přímo ve storage

10. Locking a blocking mohou vypadat jako performance problém

Databáze nemusí být CPU-bound ani I/O-bound.

Sessions mohou jednoduše čekat na jiné sessions.

Například:

Session A
|
+—- UPDATE customer
|
+—- Lock held
|
Session B ————+
|
WAITING

Jedna transakce může způsobit, že čekají desítky nebo stovky dalších sessions.

Výsledkem může být:

  • vysoký response time
  • nízké CPU
  • nízké I/O
  • rostoucí počet aktivních sessions

Je to typický příklad toho, proč samotné využití zdrojů nedokáže vysvětlit výkon databáze.

11. Concurrency mění úplně všechno

Dotaz, který funguje dobře s jednou session, může mít úplně jiné chování při 500 současných sessions.

Concurrency může znásobit:

  • CPU consumption
  • memory usage
  • locking
  • I/O
  • connection overhead
  • context switching
  • contention

Například:

1 query × 1 session
↓
50 ms
Stejný query × 1 000 sessions
↓
Contention
↓
Queueing
↓
Vyšší latency

Performance testing proto musí zohledňovat concurrency, nejen dobu provedení jednoho SQL.

12. Neignorujte aplikaci

DBA by nikdy neměl automaticky předpokládat, že každý performance problém způsobuje databáze.

Obrovskou zátěž může vytvořit samotná aplikace.

Typické problémy:

  • N+1 queries
  • zbytečný polling
  • příliš mnoho connections
  • opakované stejné dotazy
  • chybějící pagination
  • neefektivní transakce
  • nepotřebné sloupce
  • příliš časté COMMIT
  • příliš dlouhé transakce

Databáze může být technicky velmi dobře optimalizovaná, ale pokud aplikace vytváří neefektivní workload, bude celý systém pomalý.

Proto musí seniorní DBA umět spolupracovat také s vývojáři.

13. Performance tuning je vždy určitý kompromis

Jen málokterá změna zlepší úplně všechno.

Například index může zrychlit:

SELECT performance

ale zároveň zvýšit:

INSERT cost
UPDATE cost
DELETE cost
Storage usage

Více paměti může snížit:

Physical I/O

ale příliš vysoká alokace může způsobit:

OS memory pressure

Vyšší parallelism může zrychlit jeden velký dotaz, ale současně zvýšit:

CPU contention

Dobrý DBA se proto ptá:

„Jaký bude dopad na celý workload?“

Ne pouze:

„Zrychlil se tento dotaz?“

14. Změny konfigurace musí být založené na důkazech

Databáze obsahují stovky konfiguračních parametrů.

Měnit je bez důkazů je rizikové.

Bezpečnější postup:

Problem
↓
Evidence
↓
Hypothesis
↓
Small Change
↓
Measurement
↓
Validation

Například:

„I/O latency je vysoká.“

je pozorování.

„Zvětšení Buffer Pool problém vyřeší.“

je hypotéza.

DBA by měl hypotézu ověřit měřením, nikoli ji automaticky považovat za fakt.

15. Performance tuning potřebuje regression testing

Optimalizace, která dnes pomůže, může být za měsíc problémem.

Například nový index zlepší:

Query A

ale zároveň způsobí výrazné zpomalení:

INSERT workload

Nebo nový execution plan zlepší workload jednoho zákazníka, ale zhorší workload jiného.

Proto je potřeba změny ověřovat proti reprezentativnímu workloadu.

Cíl je:

Optimalizovat systém, ne jeden jediný metric.

16. Automatizace může předcházet performance incidentům

Jakmile identifikujeme opakující se performance problém, měl by se stát kandidátem na automatizaci.

Například:

Replication lag
↓
Threshold detection
↓
Alert

Nebo:

Query latency
↓
Baseline comparison
↓
Anomaly detection
↓
Alert

Nebo:

Disk growth
↓
Capacity forecast
↓
Early warning
↓
Planning

Tím se role DBA posouvá od:

Incident responder

k:

Reliability Engineer

17. Performance Engineering a Database Reliability

Výkon a spolehlivost spolu velmi úzce souvisejí.

Databáze, která dlouhodobě pracuje například na:

CPU: 95 %
Connections: 98 %
Storage: 95 %

může být stále technicky dostupná.

Má ale velmi malou rezervu.

Malé zvýšení workloadu může systém dostat do problémů.

Spolehlivá databázová platforma proto potřebuje headroom.

DBA musí rozumět:

  • současnému využití
  • trendům růstu
  • kapacitním limitům
  • scénářům výpadků
  • schopnosti recovery

Performance engineering je tedy zároveň určitým druhem risk managementu.

18. Skutečná výhoda Senior DBA

Monitoring umí sbírat metriky.

Monitoring platformy dokážou generovat alerty.

AI dokáže analyzovat určité vzorce.

Cloudové platformy dokážou automatizovat infrastrukturu.

Zkušený DBA ale dokáže propojit jednotlivé informace.

Například:

Query latency increased
↓
Execution plan changed
↓
Logical reads increased
↓
Buffer pressure increased
↓
Physical I/O increased
↓
Storage latency increased
↓
Application response time increased

Jednotlivé metriky jsou užitečné.

Ale právě vztah mezi nimi často odhalí skutečnou root cause.

A právě zde se projevuje hodnota zkušeného databázového specialisty.

Praktický troubleshooting model pro Senior DBA

Při řešení produkčního performance problému doporučuji tento postup:

1. Definujte symptom

Co je přesně pomalé?

2. Vytvořte baseline

Jak vypadal normální stav?

3. Identifikujte workload

Která aplikace, SQL nebo sessions jsou problémem zasaženy?

4. Najděte bottleneck

CPU, memory, I/O, locks, network nebo concurrency?

5. Porovnejte historické chování

Co se změnilo?

6. Ověřte execution plan

Provádí se SQL efektivně?

7. Najděte root cause

Nezastavujte se pouze u symptomu.

8. Proveďte kontrolovanou změnu

Změňte jednu důležitou věc.

9. Změřte výsledek

Skutečně se systém zlepšil?

10. Zabraňte opakování

Automatizujte detekci, zdokumentujte řešení a zlepšete architekturu.

Závěr

Pokročilý Database Performance Troubleshooting není o memorování stovek databázových parametrů.

Je o pochopení toho, jak se celý systém chová.

Nejdůležitější vztahy jsou:

SQL → Execution Plan → Resources → Waits → Storage → Application → Business Impact

Oracle, PostgreSQL i MySQL mají rozdílné diagnostické mechanismy, ale základní principy jsou velmi podobné.

Silný DBA se neptá okamžitě:

„Jaký parametr mám změnit?“

Lepší otázka je:

„Jaké důkazy mám o skutečném bottlenecku?“

A po vyřešení problému přichází ještě důležitější otázka:

„Jak zajistíme, aby byl tento problém příště odhalen dříve – nebo aby už vůbec nenastal?“

Právě tím se tradiční Database Administration posouvá směrem k Database Performance Engineering a Database Reliability Engineering.

O autorovi

Tomas Solar
Principal Database Reliability Engineer

Více než 20 let zkušeností s Oracle, PostgreSQL, MySQL, SQL Server a MongoDB.

Specializace na Database Administration, Performance Engineering, High Availability, Disaster Recovery, Database Reliability, Automation, Database Migration a Database Architecture.

Nejlepší performance optimalizace není ta, která jednou zrychlí jeden dotaz. Je to ta, která udělá celou databázovou platformu předvídatelnou při reálném produkčním zatížení.



Komentáře