# Oracle Veritabanı ve PL/SQL: Mimari, SQL ve Performans

> Oracle mimarisini SQL ve PL/SQL temellerinden transaction, optimizer, performans, RAC, Data Guard, modernizasyon, JSON ve vektör aramaya kadar katmanlı biçimde ele alan kapsamlı teknik ders notları.

- Author: Muhammet Ali Köker
- Language: tr
- Canonical: https://alikoker.com.tr/oracle-veritabani-plsql-mimari-sql-performans
- Translation: https://alikoker.com.tr/en/oracle-database-plsql-architecture-sql-performance
- Published: 2021-01-01T00:00:00+03:00
- Modified: 2026-08-22T04:42:00+03:00
- Type: article

Bu not, Oracle veritabanı ve PL/SQL konularını birbiriyle ilişkili tek bir sistem olarak ele alır. Yayının 2021 tarihli çerçevesi korunmuş, sürüme bağlı bölümler Oracle'ın güncel belgeleri esas alınarak Ağustos 2026'da gözden geçirilmiştir. Amaç komut ezberlemek değil; bir SQL deyiminin bellekte, diskte, işlem günlüğünde, optimizer'da ve eşzamanlı oturumlarda neye dönüştüğünü kavramaktır.

## Ünite 1: Oracle'ın Çalışma Modeli

### Instance ve veritabanı

Oracle'da **instance** ile **veritabanı** aynı şey değildir.

**Instance** bellekteki SGA ile arka plan süreçlerinden oluşur. Sunucu kapandığında yok olur. **Veritabanı** datafile, control file ve redo log gibi kalıcı dosyalardır. Instance veritabanını açar; veritabanı tek başına sorgu işlemez.

Bu ayrım RAC'ta daha görünür hale gelir: aynı veritabanını birden çok instance açabilir. Paylaşılan veri birdir, işlem yapan instance'lar birden fazladır.

### SGA ve PGA

```text
SGA — paylaşılır
├── Database Buffer Cache
├── Shared Pool
│   ├── Library Cache
│   └── Data Dictionary Cache
├── Redo Log Buffer
├── Large Pool
└── diğer bileşenler

PGA — sürece/oturuma özeldir
├── sort alanı
├── hash alanı
└── cursor ve çalışma durumu
```

**Buffer Cache**, disk bloklarının bellekteki kopyalarını tutar. Oracle bir satırı değil, bloğu okur. Bu nedenle mantıksal okuma sayısı çoğu performans incelemesinde satır sayısından daha anlamlıdır.

**Shared Pool**, ayrıştırılmış SQL, PL/SQL ve sözlük bilgisini barındırır. Aynı SQL'in bind değişkenleriyle yeniden kullanılması hard parse sayısını düşürür.

**Redo Log Buffer**, değişiklik bilgisini LGWR diske yazmadan önce tutar.

### Arka plan süreçleri

Temel süreçler:

```text
DBWn   değişmiş blokları datafile'lara yazar
LGWR   redo kayıtlarını online redo log'a yazar
CKPT   checkpoint bilgisini günceller
SMON   instance recovery gibi sistem işlerini yürütür
PMON   başarısız süreç ve oturum kaynaklarını temizler
ARCn   dolan redo log'ları arşivler
MMON   performans ve AWR altyapısına veri sağlar
LREG   servis bilgisini listener'a kaydeder
```

### COMMIT neden hızlıdır?

`COMMIT`, değişmiş tüm veri bloklarının datafile'a yazılmasını beklemez. Dayanıklılık için gerekli redo kaydının kalıcı hale gelmesini bekler.

```text
DML
 ↓
Buffer Cache'te değişmiş blok
 ↓
Redo Log Buffer'da değişiklik kaydı
 ↓
COMMIT
 ↓
LGWR redo'yu diske yazar
 ↓
DBWn veri bloğunu daha sonra yazabilir
```

Bu düzen **write-ahead logging** ilkesidir. Redo önce kalıcı olur; çökme sonrası datafile'a henüz yazılmamış değişiklik yeniden uygulanabilir.

**Akılda kalacak ayrım:** LGWR işlemin dayanıklılığını, DBWn veri bloklarının kalıcı yerleşimini sağlar.

### Bağlantı ve oturum

**Bağlantı**, istemci ile Oracle süreci arasındaki iletişim yoludur. **Oturum**, bu bağlantı üzerindeki kullanıcı bağlamıdır.

Dedicated server modelinde her bağlantıya ayrı server process verilir. Shared server süreçleri paylaşır. Uygulama sunucularında HikariCP benzeri connection pool kullanıldığında asıl amaç, pahalı bağlantı kurma maliyetini her istek için yeniden ödememektir.

Pool büyük tutulduğu için sistem hızlı olmaz. Gereğinden büyük pool, Oracle üzerinde daha fazla eşzamanlı çalışma, latch/mutex baskısı, PGA tüketimi ve I/O kuyruğu oluşturabilir. Pool boyutu uygulama thread sayısından değil, veritabanının sürdürebildiği eşzamanlı iş miktarından türetilmelidir.

### Sürüm çizgisi

Ağustos 2026 açısından iki sürüm özellikle önemlidir:

```text
19c    Long Term Support; Premier Support Aralık 2029'a,
       Extended Support Aralık 2032'ye kadar planlanmıştır.

21c    Innovation Release; kısa yaşam döngülü ara sürümdür.

26ai   Long Term Support; Oracle'ın güncel uzun dönem sürümüdür.
       Linux x86-64 on-prem Enterprise Edition Ocak 2026'da
       23.26.1 Release Update ile genel kullanıma açılmıştır.
```

Oracle'ın 26ai ürün adı ile 23.26.x teknik sürüm numaralarını birlikte kullanması ilk bakışta karışıklık yaratır. Üretim kararı verirken ürün adından çok **sertifikasyon, COMPATIBLE değeri, RU seviyesi ve destek takvimi** izlenmelidir.

## Ünite 2: Fiziksel, Mantıksal ve Multitenant Yapı

### Fiziksel dosyalar

```text
Datafile       tablo ve indeks blokları
Control file   veritabanı yapısı, checkpoint ve dosya bilgisi
Online redo    değişiklik günlüğü
Archive log    dolan redo'nun arşiv kopyası
SPFILE         instance parametreleri
Password file  ayrıcalıklı yönetici doğrulaması
```

Control file ve redo log üyeleri kritik yapılardır. Aynı fiziksel arıza alanında duran iki kopya gerçek yedeklilik değildir.

### Mantıksal depolama

```text
Database
└── Tablespace
    └── Segment
        └── Extent
            └── Block
```

**Tablespace** mantıksal yönetim katmanıdır. **Segment** tablo veya indeks gibi bir nesnenin depolama alanıdır. **Extent**, segmente ayrılan bitişik blok grubudur. **Block**, Oracle'ın temel G/Ç birimidir.

Bir segment tek tablespace içinde kalır; tablespace birden çok datafile'a yayılabilir.

SYSTEM ve SYSAUX sistem üstverisini taşır. UNDO eski sürümleri ve rollback bilgisini, TEMP sıralama/hash gibi geçici çalışmaları tutar. Uygulama nesneleri ayrı kullanıcı tablespace'lerinde tutulmalıdır.

### Veri sözlüğü

Kapsam önekleri:

```text
USER_*   oturum sahibinin nesneleri
ALL_*    erişilebilen nesneler
DBA_*    tüm veritabanı; yönetim yetkisi ister
V$       instance'ın dinamik durumu
GV$      RAC'ta tüm instance'ların dinamik durumu
```

`DBA_TABLES` kalıcı tanımı; `V$SESSION` o anki çalışma durumunu anlatır. Sorun giderirken bu iki veri türü birbirine karıştırılmamalıdır.

### CDB ve PDB

Modern Oracle kurulumu multitenant yapıdadır:

```text
CDB
├── CDB$ROOT
├── PDB$SEED
├── UYGULAMA1
└── UYGULAMA2
```

CDB ortak altyapıyı taşır. PDB uygulamanın gördüğü mantıksal veritabanıdır. PDB kendi kullanıcılarına, tablespace'lerine ve nesnelerine sahip olabilir; instance süreçlerini CDB ile paylaşır.

**Common user** birden çok container'da geçerlidir. **Local user** yalnız PDB içindedir. Uygulama kullanıcıları normalde local olmalıdır.

```sql
ALTER SESSION SET CONTAINER = uygulama1;
CREATE USER app IDENTIFIED BY "...";
```

PDB'nin taşınabilirliği, klonlama ve izolasyon multitenant mimarinin asıl kazancıdır. Tek sunucuda çok sayıda bağımsız uygulama veritabanı çalıştırılırken her biri için ayrı instance açma maliyeti ortadan kalkar.

### UNDO modu

Local UNDO, PDB'nin kurtarma ve taşıma işlemlerinde daha bağımsız davranmasını sağlar. Yeni kurulumlarda bu model tercih edilir.

## Ünite 3: Veri Tipleri, Şema Nesneleri ve Kısıtlamalar

### Karakter verisi

`VARCHAR2` Oracle'ın temel değişken uzunluklu karakter tipidir. `CHAR` sabit uzunluk içindir. `CLOB` büyük metin taşır.

```sql
ad       VARCHAR2(100 CHAR)
kod      CHAR(3 CHAR)
aciklama CLOB
```

`BYTE` ile `CHAR` uzunluk semantiği aynı değildir. UTF-8 ortamında bir karakter birden çok bayt olabilir. Kullanıcı metinlerinde karakter semantiği çoğu zaman daha güvenlidir.

`MAX_STRING_SIZE=STANDARD` iken SQL `VARCHAR2` üst sınırı 4000 bayt, `EXTENDED` iken 32767 bayttır. 32 MB değildir. Daha büyük metin için LOB kullanılır.

### Sayısal veri

`NUMBER(p,s)` ondalık duyarlılığı denetler. Parasal veride `NUMBER` kullanılmalıdır. `BINARY_FLOAT` ve `BINARY_DOUBLE` IEEE 754 kayan nokta davranışı taşır; bilimsel hesap için uygundur, parasal kesinlik için değildir.

```sql
tutar NUMBER(12,2)
oran  NUMBER(7,6)
```

### Tarih ve zaman

Oracle `DATE` tipi tarih yanında saat, dakika ve saniyeyi de tutar.

```text
DATE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
```

Bir güne ait kayıtları eşitlikle aramak yerine yarı açık aralık kullanmak hem doğru hem indeks dostudur:

```sql
WHERE tarih >= DATE '2026-08-22'
  AND tarih <  DATE '2026-08-23'
```

Sütuna `TRUNC(tarih)` uygulamak normal B-tree indeksini kullanılamaz hale getirebilir; gereksinim sabitse function-based index düşünülebilir.

### JSON, XML ve VECTOR

Native `JSON`, ilişkisel veri yanında belge verisini de aynı işlem sınırında tutmayı sağlar. `XMLTYPE` daha eski kurumsal entegrasyonlarda önemini korur. `VECTOR` yüksek boyutlu embedding verisini saklar; son ünitede ayrıca ele alınır.

### Tablo ve kısıtlamalar

```sql
CREATE TABLE calisan (
    id       NUMBER GENERATED ALWAYS AS IDENTITY,
    eposta   VARCHAR2(200 CHAR) NOT NULL,
    maas     NUMBER(12,2),
    dept_id  NUMBER,
    CONSTRAINT pk_calisan PRIMARY KEY (id),
    CONSTRAINT uk_calisan_eposta UNIQUE (eposta),
    CONSTRAINT ck_calisan_maas CHECK (maas >= 0),
    CONSTRAINT fk_calisan_dept FOREIGN KEY (dept_id) REFERENCES departman(id)
);
```

Kısıtlama uygulama kodunun yerine değil, onun altına konur. Aynı veritabanına farklı uygulamalar ve yönetim araçları erişebildiği için veri bütünlüğünün son sınırı veritabanıdır.

**PRIMARY KEY** benzersiz ve `NOT NULL`'dır. **UNIQUE** benzersizlik sağlar; NULL davranışı farklıdır. **FOREIGN KEY** referans bütünlüğünü korur. **CHECK** aynı satırdaki koşulu zorlar.

Foreign key sütunları uygun iş yüklerinde indekslenmelidir. Oracle bu indeksi otomatik oluşturmaz. İndeks yokluğu parent satır silme/güncelleme işlemlerinde geniş tarama ve kilit baskısı oluşturabilir.

### Sequence ve identity

Sequence yüksek eşzamanlılıkta anahtar üretmek için tasarlanmıştır:

```sql
CREATE SEQUENCE seq_siparis CACHE 100;
```

Sequence **boşluksuz numara garantisi vermez**. Cache kaybı, rollback ve paralel oturumlar boşluk oluşturur. Muhasebesel belge numarası gibi boşluksuz iş kuralları sequence ile eşitlenmemelidir.

Identity sütunu sequence kullanımını görünür şema tanımından kaldırır; altta aynı sınıf problem çözülür.

### View ve materialized view

View saklanmış sorgudur; normalde veri tutmaz. Materialized view sonucu fiziksel olarak saklar ve pahalı sorguları önceden hesaplayabilir.

`QUERY REWRITE` ile optimizer uygun sorguyu materialized view'a yönlendirebilir. `FAST REFRESH` için gerekli log ve kısıtlar tasarım aşamasında düşünülmelidir.

### Geçici tablolar ve synonym

Global temporary table'ın tanımı kalıcı, verisi oturum veya işlem ömründedir. Private temporary table'ın tanımı da geçicidir.

Synonym nesne adını soyutlar. Public synonym tüm veritabanı ad alanını etkilediğinden ölçülü kullanılmalıdır.

## Ünite 4: DML, İşlemler ve Eşzamanlılık

### Temel DML

```sql
INSERT INTO hedef (...) VALUES (...);
UPDATE hedef SET ... WHERE ...;
DELETE FROM hedef WHERE ...;
MERGE INTO hedef h USING kaynak k ON (...) ...;
```

`MERGE`, koşula göre update/insert akışını tek SQL deyiminde kurar. Yine de kaynak kümede aynı hedef satırı birden çok kez eşleştiren veri hataları önceden çözülmelidir.

`RETURNING INTO`, değiştirilen değeri ikinci sorgu olmadan PL/SQL'e taşır.

### İşlem sınırı

```text
ilk DML
  ↓
transaction
  ↓
COMMIT     kalıcılaştırır
ROLLBACK   geri alır
SAVEPOINT  kısmi geri dönüş noktası oluşturur
```

DDL işlemlerinin örtük commit davranışı operasyon betiklerinde özellikle önemlidir.

### Read consistency

Oracle'ın MVCC yaklaşımında okuyucu normal olarak yazıcıyı, yazıcı da okuyucuyu bloke etmez. Sorgu, gerekli eski blok sürümünü UNDO'dan kurarak tutarlı görüntüyü görür.

**READ COMMITTED** varsayılandır; her SQL deyimi kendi başlangıç anına ait görüntüyü görür. **SERIALIZABLE** işlem boyunca daha kararlı bir görüntü sağlar ancak çakışma durumunda hata üretebilir. Oracle dirty read sağlamaz.

### Kilitleme

```sql
SELECT * FROM is_kuyrugu
WHERE durum = 'BEKLIYOR'
FOR UPDATE SKIP LOCKED;
```

`FOR UPDATE` kötümser kilitlemedir. `NOWAIT` beklemek yerine hemen hata verir. `WAIT n` sınırlı bekler. `SKIP LOCKED`, iş kuyruğu tüketicilerinin birbirini beklemeden farklı satırlar almasını sağlar.

İyimser kilitlemede satır uzun süre tutulmaz; sürüm değeri update sırasında denetlenir:

```sql
UPDATE belge
SET icerik = :icerik, surum = surum + 1
WHERE id = :id AND surum = :beklenen;
```

Etkilenen satır sıfırsa başka işlem önce yazmıştır.

### Deadlock

Deadlock iki işlemin birbirinin tuttuğu kaynağı beklemesidir. Oracle döngüyü saptar ve bir deyimi hata ile sonlandırır. Uygulama transaction'ın kalan durumunu bilinçli yönetmelidir.

En basit önlem, aynı nesneleri her kod yolunda aynı sırayla güncellemektir.

### Sıcak satırlar ve lock-free reservation

Modern Oracle sürümlerindeki `RESERVABLE` sayısal sütunlar, stok ve bakiye gibi çok sık değişen değerlerde klasik satır kilidi baskısını azaltmak için tasarlanmıştır. Değişiklikler rezervasyon olarak tutulur ve uygunluk commit sırasında doğrulanır.

Bu özellik veri modelini yeniden düşünmeden kullanılmamalıdır. Çözülmesi gereken sorun gerçekten tek satır üzerindeki yoğun güncelleme çekişmesiyse anlamlıdır.

## Ünite 5: SELECT, JOIN, NULL ve Alt Sorgular

### Mantıksal işlem sırası

SQL yazım sırası ile mantıksal değerlendirme sırası farklıdır:

```text
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY
```

Bu nedenle `SELECT` alias'ı normalde `WHERE` içinde kullanılamaz; `ORDER BY` aşamasında kullanılabilir.

### JOIN

```text
INNER JOIN       yalnız eşleşenler
LEFT JOIN        sol tarafın tamamı
RIGHT JOIN       sağ tarafın tamamı
FULL OUTER JOIN  iki tarafın tamamı
CROSS JOIN       kartezyen çarpım
```

Outer join'de sağ tablo filtresinin `ON` yerine `WHERE` bölümüne konması sonucu değiştirebilir:

```sql
LEFT JOIN dept d
  ON d.id = c.dept_id AND d.aktif = 'E'
```

ile

```sql
LEFT JOIN dept d ON d.id = c.dept_id
WHERE d.aktif = 'E'
```

aynı değildir. İkinci biçim NULL genişletilmiş satırları eler ve davranışı inner join'e yaklaştırır.

### NULL

NULL sıfır veya boş metin değildir; bilinmeyen değeri temsil eder.

```text
NULL = NULL      TRUE değildir
x IS NULL        doğru testtir
COUNT(*)         satır sayar
COUNT(x)         x NULL olmayan satırları sayar
```

Oracle tarihsel olarak boş karakter dizisini `NULL` gibi ele alır; bu davranış başka veritabanlarına taşınan kodda sürpriz yaratabilir.

### NOT IN tuzağı

Alt sorgu NULL döndürebiliyorsa `NOT IN` tüm sonucu bilinmeyen hale getirebilir. Anti-join niyeti için çoğu durumda `NOT EXISTS` daha güvenlidir:

```sql
WHERE NOT EXISTS (
    SELECT 1 FROM departman d
    WHERE d.id = c.dept_id
)
```

### Alt sorgu ve EXISTS

Skaler alt sorgu tek değer üretir. Correlated subquery dış satıra başvurur. Optimizer çoğu `IN` ve `EXISTS` biçimini benzer plana dönüştürebilir; semantik ve NULL davranışı performans ezberinden önce gelir.

### CTE

`WITH`, karmaşık sorguyu adlandırılmış adımlara böler:

```sql
WITH dept_ort AS (
  SELECT dept_id, AVG(maas) ort
  FROM calisan
  GROUP BY dept_id
)
SELECT c.*
FROM calisan c
JOIN dept_ort d ON d.dept_id = c.dept_id
WHERE c.maas > d.ort;
```

CTE'nin fiziksel olarak materialize edilip edilmeyeceğine optimizer karar verebilir. `WITH` yazmak tek başına geçici tablo oluşturmaz.

### Özyinelemeli sorgu ve CONNECT BY

Hiyerarşik veri iki ana yolla işlenir: ANSI recursive subquery factoring ve Oracle'ın `CONNECT BY` sözdizimi.

```sql
SELECT LEVEL, ad
FROM calisan
START WITH yonetici_id IS NULL
CONNECT BY NOCYCLE PRIOR id = yonetici_id;
```

`NOCYCLE`, bozuk hiyerarşide sonsuz dolaşmayı önler. `LEVEL`, `CONNECT_BY_ISLEAF` ve `SYS_CONNECT_BY_PATH` hiyerarşi raporlamasında yararlıdır.

## Ünite 6: Fonksiyonlar, Toplama ve Analitik SQL

### Dönüşümde örtük davranıştan kaçının

```sql
WHERE tarih >= DATE '2026-01-01'
```

biçimi,

```sql
WHERE tarih >= '01-JAN-26'
```

biçiminden daha güvenlidir. İkinci ifade `NLS_DATE_FORMAT` ve dil ayarlarına bağımlıdır.

Aynı ilke sayısal dönüşüm için de geçerlidir. Sütuna örtük dönüşüm uygulanması hem hata riskini hem indeks kaybını artırır.

### Karakter, tarih ve regex fonksiyonları

`SUBSTR`, `INSTR`, `REPLACE`, `TRIM`, `UPPER`, `LOWER`, `REGEXP_*`, `ADD_MONTHS`, `LAST_DAY`, `TRUNC`, `EXTRACT`, `TO_CHAR`, `TO_DATE` temel araçlardır.

Türkçe büyük/küçük harf ve sıralama davranışı NLS ayarlarından etkilenebilir. `i/İ` gibi karakterler uygulama testlerinde özellikle doğrulanmalıdır.

Regex güçlüdür ama pahalıdır. Basit eşleşmeyi `LIKE` ile çözmek veya sorguya uygun function-based index tasarlamak çoğu zaman daha ucuzdur.

### Aggregate ile analytic farkı

Aggregate fonksiyon satırları gruplar. Analytic fonksiyon satırları korur ve pencere hesabı ekler.

```sql
SELECT ad, dept_id, maas,
       AVG(maas) OVER (PARTITION BY dept_id) AS dept_ort
FROM calisan;
```

Correlated subquery ile her satırda yeniden yapılabilecek bir hesap çoğu zaman tek analytic geçişle çözülebilir.

### RANK ailesi

```text
ROW_NUMBER   her satıra benzersiz sıra
RANK         eşitlikte sıra atlar
DENSE_RANK   eşitlikte sıra atlamaz
```

Deterministik `ROW_NUMBER` için `ORDER BY` ifadesi eşitlikleri kıracak kadar tam olmalıdır.

### LAG ve LEAD

Önceki veya sonraki satıra self join olmadan erişir:

```sql
SELECT ay, tutar,
       LAG(tutar) OVER (ORDER BY ay) onceki,
       tutar - LAG(tutar) OVER (ORDER BY ay) fark
FROM aylik_satis;
```

### ROWS ve RANGE

`ROWS` fiziksel satır konumuna, `RANGE` sıralama değerinin akran grubuna göre pencere kurar. `LAST_VALUE` gibi fonksiyonlarda varsayılan pencere beklenmeyen sonuç üretebilir; pencere sınırı açık yazılmalıdır.

### ROLLUP, CUBE ve GROUPING SETS

Bu yapılar ara toplamları tek taramada üretir. Aynı tabloyu birden çok `UNION ALL` sorgusuyla tekrar okumaktan daha doğal ve çoğu zaman daha ucuzdur.

### PIVOT ve UNPIVOT

`PIVOT` satır değerlerini sütunlara, `UNPIVOT` sütunları satırlara dönüştürür. Dinamik sütun listesi gerekiyorsa uygulama katmanı veya dinamik SQL gerekebilir.

### Küme işlemleri, ROWNUM ve ROWID

`UNION` tekrarları eler, `UNION ALL` sonuçları elemeden birleştirir. `INTERSECT` ortak satırları, `MINUS` ilk sorguda olup ikincide olmayanları döndürür. Aynı konumu sağlayan `UNION ALL`, duplicate elimination yapmadığı için daha ucuzdur.

`ROWNUM` satır üretimi sırasında atanır. Bu nedenle klasik top-N sorgularında sıralama iç sorguda yapılır. 12c ve sonrasında `FETCH FIRST` daha okunaklıdır.

`ROWID` satırın fiziksel/yerleşim adresini temsil eder ve tek satıra çok hızlı erişim sağlayabilir. İş anahtarı değildir. Satır taşıma, export/import veya tablo yeniden yapılanmasıyla değişebilir; uygulama kimliği olarak saklanmamalıdır.

### FETCH FIRST ve sayfalama

```sql
SELECT ...
ORDER BY id
FETCH FIRST 100 ROWS ONLY;
```

Derin `OFFSET` sayfalama atlanan satırları üretmeye devam ettiği için pahalıdır. Büyük veri kümelerinde **keyset pagination** daha kararlıdır:

```sql
WHERE id > :son_id
ORDER BY id
FETCH FIRST 100 ROWS ONLY;
```

## Ünite 7: İndeks Yapıları

### İndeksin bedeli vardır

İndeks okumayı hızlandırabilir; her DML işleminde bakım maliyeti üretir. Gereksiz indeks, disk alanından daha çok redo, undo ve buffer cache tüketir.

### B-tree

Varsayılan indeks türüdür. Eşitlik ve aralık aramalarında temel yapıdır.

```sql
CREATE INDEX ix_calisan_dept_maas
ON calisan(dept_id, maas);
```

Bileşik indekste **sütun sırası** belirleyicidir. `(a,b)` indeksi `a` ile başlayan erişim desenlerine doğal olarak uygundur. "En seçici sütun her zaman başa yazılır" kuralı eksiktir; sorgu kalıpları, join düzeni, aralık koşulları ve sort gereksinimi birlikte değerlendirilmelidir.

### Kapsayan erişim

Sorgunun ihtiyaç duyduğu sütunların tamamı indekste bulunursa tablo bloğuna erişim gerekmeyebilir. Ancak her sütunu indekse eklemek yazma ve cache maliyetini büyütür.

### Function-based index

```sql
CREATE INDEX ix_soyad_upper ON calisan(UPPER(soyad));
```

Sorgu ifadesi indeks ifadesiyle uyumlu olmalıdır. Function-based index, sorgu tasarımı yerine otomatik bir çözüm değildir.

### Bitmap index

Düşük kardinaliteli analitik sütunlarda çok etkilidir. Eşzamanlı DML yoğun OLTP tablolarında uygun değildir; bitmap parçalarının kilit davranışı geniş çakışma yaratabilir.

### Reverse key, invisible ve IOT

**Reverse key**, artan anahtarların aynı leaf block üzerinde oluşturduğu sıcak noktayı dağıtabilir; aralık taramasını kaybettirir.

**Invisible index**, indeksi silmeden optimizer etkisini sınamak için kullanışlıdır.

**Index-organized table**, satır verisini primary key ağacında tutar; primary-key erişimini hızlandırırken başka erişim desenlerinin maliyetini değiştirebilir.

### NULL ve indeks

Tek sütunlu klasik B-tree, tüm anahtar bileşenleri NULL olan satırı indekslemez. `IS NULL` sorgularında bu ayrıntı önemlidir. Sabit ek sütun veya function-based index gibi tasarımlar gerektiğinde kullanılabilir.

### Rebuild ezberi

B-tree indeksleri rutin takvimle yeniden oluşturmak doğru bakım politikası değildir. Oracle ağaç yapısını dengeler. Rebuild yalnız ölçülmüş bir neden varsa yapılmalıdır.

### Otomatik indeksleme

Automatic Indexing iş yükünü izleyip aday indeksleri test edebilir. Sürüm, platform ve lisans koşulları ayrıca kontrol edilmelidir. Özellik iyi veri modelinin yerini almaz; en değerli kullanım biçimi, ölçüm ve insan incelemesiyle birlikte çalışmasıdır.

## Ünite 8: Bölümleme

### Neden bölümleme?

Bölümleme büyük tabloyu uygulamaya tek tablo, depolama ve optimizer'a ayrı parçalar olarak gösterir.

Temel kazanımlar:

- partition pruning,
- zaman aralığına göre hızlı bakım,
- bölüm düzeyinde erişilebilirlik,
- paralel çalışma,
- arşivleme ve veri yaşam döngüsü yönetimi.

### Türler

```text
RANGE       tarih ve sıralı değerler
INTERVAL    aralık bölümlerini otomatik üretir
HASH        anahtarı eşit dağıtmaya çalışır
LIST        ayrık iş değerleri
COMPOSITE   iki yöntemi birleştirir
REFERENCE   child tabloyu parent bölümlemesiyle hizalar
```

### Partition pruning

Bölümleme ancak sorgu ilgili bölümleri eleyebiliyorsa okuma maliyetini düşürür. Bölüm anahtarını fonksiyonla sarmak veya hiç filtrelememek pruning kazancını ortadan kaldırabilir.

Execution plan'daki `PSTART`, `PSTOP` ve partition erişim satırları gerçek davranışı gösterir.

### Local ve global index

Local index bölümleri tablo bölümleriyle hizalıdır; bakım kolaydır. Global index farklı erişim desenlerini karşılar fakat partition maintenance sırasında daha dikkatli yönetilir.

### EXCHANGE PARTITION

```sql
ALTER TABLE satis
EXCHANGE PARTITION p2025
WITH TABLE satis_arsiv_2025
INCLUDING INDEXES WITHOUT VALIDATION;
```

Uygun yapıda bu işlem satırları tek tek taşımadan metadata değişimiyle büyük veri kümelerini ayırabilir. Veri ambarı ve arşivleme için güçlü bir tekniktir.

## Ünite 9: Optimizer, İstatistik ve Yürütme Planı

### Optimizer'ın amacı

Aynı SQL sonucu çok farklı fiziksel yollarla üretilebilir. Cost-based optimizer istatistiklerden tahmin ettiği maliyete göre plan seçer.

Asıl soru "indeks var mı?" değil, **optimizer kaç satır bekliyor ve hangi maliyet modelini görüyor?** sorusudur.

### İstatistikler

Temel bilgiler:

- satır ve blok sayısı,
- sütun kardinalitesi,
- NULL sayısı,
- minimum/maksimum,
- histogram,
- indeks istatistikleri.

```sql
EXEC DBMS_STATS.GATHER_TABLE_STATS(
  ownname => 'APP', tabname => 'CALISAN', cascade => TRUE);
```

İstatistik toplamak her yavaş sorgunun çözümü değildir. Gereksiz veya uygunsuz toplama plan değiştirip yeni regresyon üretebilir.

### Histogram

Değerler eşit dağılmıyorsa tek kardinalite ortalaması yanıltıcıdır. Histogram skew bilgisini taşır. Her sütuna histogram oluşturmak doğru değildir; predicate kullanımı ve dağılım birlikte değerlendirilir.

### Erişim yolları

```text
Full Table Scan
Index Unique Scan
Index Range Scan
Index Full Scan
Index Fast Full Scan
Rowid access
Partition access
```

Full scan kötü plan demek değildir. Büyük bir yüzde okunacaksa sıralı çoklu blok tarama, binlerce rastgele index-to-table erişiminden daha ucuz olabilir.

### Join yöntemleri

**Nested loops**, dış küme küçük ve iç erişim ucuzsa güçlüdür. **Hash join**, büyük eşitlik join'lerinde sık kullanılır. **Sort merge join**, sıralı veri veya uygun eşitsizlik koşullarında anlamlı olabilir.

Yanlış join seçiminin nedeni çoğu zaman yanlış kardinalite tahminidir.

### Bind değişkenleri ve plan seçimi

Bind değişkenleri parse maliyetini ve shared pool parçalanmasını azaltır:

```sql
SELECT * FROM siparis WHERE musteri_id = :id;
```

Ancak veri dağılımı çok dengesizse tek plan her bind değeri için iyi olmayabilir. Bind peeking ve adaptive cursor sharing gibi mekanizmalar bu gerilimi yönetmeye çalışır. Önce veri dağılımı ve gerçek child cursor davranışı ölçülmelidir.

### Execution plan

```sql
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
```

Tahmini plan tek başına yetmez. Mümkün olduğunda **actual rows ile estimated rows** karşılaştırılır. Büyük sapma optimizer'ın yanlış bilgiyle karar verdiğini gösterir.

### Hint

Hint, optimizer'a verilen direktiftir; ilk çözüm değildir. Bugünkü veri dağılımını koda sabitlemek yarının regresyonu olabilir.

### Plan kararlılığı

SQL Plan Baseline iyi planları korumak için kullanılabilir. SQL Profile tahmin kalitesini düzeltmeye, SQL Patch kodu değiştirmeden belirli davranışı etkilemeye yarayabilir. Bunlar kök nedeni anlamadan uygulanacak sihirli anahtarlar değildir.

### SQL Monitor

Uzun veya paralel SQL'in adım adım gerçek çalışma sürelerini görmek için SQL Monitor güçlüdür. AWR, ASH, SQL Monitor ve bazı tuning özelliklerinin Diagnostic/Tuning Pack lisans koşulları ayrıca kontrol edilmelidir.

## Ünite 10: PL/SQL Temelleri, Cursor ve Toplu İşlemler

### PL/SQL neden vardır?

SQL küme temellidir: hangi verinin istendiğini söyler. PL/SQL koşul, döngü, hata yönetimi ve modüler programlama ekler. En iyi PL/SQL, SQL'in iyi yaptığı işi satır satır yeniden yazmaz.

```sql
DECLARE
    v_toplam NUMBER;
BEGIN
    SELECT SUM(tutar) INTO v_toplam
    FROM siparis
    WHERE tarih >= TRUNC(SYSDATE,'MM');

    DBMS_OUTPUT.PUT_LINE(v_toplam);
EXCEPTION
    WHEN OTHERS THEN
        RAISE;
END;
/
```

Blok yapısı `DECLARE`, `BEGIN`, `EXCEPTION`, `END` bölümlerinden oluşur. Yalnız `BEGIN ... END` zorunludur.

### %TYPE ve %ROWTYPE

```sql
v_maas calisan.maas%TYPE;
v_satir calisan%ROWTYPE;
```

Bu tanımlar şema tipini koda kopyalamaz; sütun değiştiğinde PL/SQL tipi de uyarlanır. Sabit `VARCHAR2(100)` tekrarından daha dayanıklıdır.

### Döngü mü SQL mi?

Aşağıdaki desen gereksiz context switch üretir:

```sql
FOR r IN (SELECT id FROM calisan WHERE dept_id = 10) LOOP
    UPDATE calisan SET maas = maas * 1.05 WHERE id = r.id;
END LOOP;
```

Tek SQL daha doğaldır:

```sql
UPDATE calisan
SET maas = maas * 1.05
WHERE dept_id = 10;
```

**Kural:** önce küme temelli SQL; gerçekten procedural davranış gerekiyorsa PL/SQL.

### Cursor

Implicit cursor her DML ve `SELECT INTO` için Oracle tarafından yönetilir. `SQL%ROWCOUNT`, `SQL%FOUND` gibi öznitelikler sonucu verir.

Explicit cursor, sonuç kümesini kontrollü dolaşmak gerektiğinde kullanılır:

```sql
CURSOR c_dept(p_id NUMBER) IS
    SELECT id, ad FROM calisan WHERE dept_id = p_id;
```

Cursor FOR loop çoğu `OPEN/FETCH/CLOSE` tekrarını ortadan kaldırır.

### REF CURSOR

REF CURSOR, sorgu sonucunu çağıran katmana cursor olarak döndürmek için kullanılır. Dinamik sonuç kümelerinde yararlıdır; ancak modern uygulama katmanlarında doğrudan SQL/JDBC result set çoğu zaman daha sade olabilir.

### Koleksiyonlar

PL/SQL üç temel koleksiyon ailesi sunar: **associative array**, **nested table** ve **VARRAY**. Associative array çoğunlukla PL/SQL belleğinde anahtar-değer yapısıdır. Nested table SQL tipleriyle de bütünleşebilir ve eleman sayısı dinamik olabilir. VARRAY üst sınırı olan, sırası korunan dizi yapısıdır. `COUNT`, `FIRST`, `LAST`, `NEXT`, `PRIOR`, `EXTEND`, `TRIM` ve `DELETE` gibi yöntemler koleksiyon yaşam döngüsünü yönetir.

Koleksiyon seçimi yalnız sözdizimi değildir: PGA tüketimi, SQL'e aktarılabilirlik, eleman sırası ve maksimum boyut gereksinimi birlikte düşünülür.

### BULK COLLECT ve FORALL

PL/SQL ile SQL motoru arasındaki geçiş çok sayıda satırda pahalıdır. `BULK COLLECT` veriyi toplu alır, `FORALL` toplu DML yapar.

```sql
SELECT id BULK COLLECT INTO v_ids
FROM is_kuyrugu
WHERE durum = 'BEKLIYOR'
FETCH FIRST 1000 ROWS ONLY;

FORALL i IN 1..v_ids.COUNT
    UPDATE is_kuyrugu
    SET durum = 'ISLENDI'
    WHERE id = v_ids(i);
```

Toplu alma belleği tüketir. Çok büyük sonuçta `LIMIT` ile parça parça işlemek gerekir.

### Pipelined table function

Pipelined function tüm sonucu bellekte üretmeden satırları geldikçe SQL motoruna döndürebilir. Gerçek bir dönüşüm gereksiniminde yararlıdır; basit sorguyu paketlemek için kullanılmamalıdır.

## Ünite 11: Hata Yönetimi, Procedure, Function, Package ve Trigger

### Exception

Oracle hatası yönetilmezse çağırana yayılır. `WHEN OTHERS THEN NULL` hatayı çözmez; yalnız görünmez yapar.

```sql
EXCEPTION
    WHEN NO_DATA_FOUND THEN
        ...
    WHEN DUP_VAL_ON_INDEX THEN
        ...
    WHEN OTHERS THEN
        ...
        RAISE;
```

`SQLCODE`, `SQLERRM` ve `DBMS_UTILITY.FORMAT_ERROR_BACKTRACE` tanılama için kullanılabilir.

### RAISE_APPLICATION_ERROR

İş kuralı ihlalini anlamlı hata koduyla çağırana taşır:

```sql
RAISE_APPLICATION_ERROR(-20001, 'Yetersiz bakiye');
```

Hata mesajı bir log mekanizmasının yerine geçmez; uygulama korelasyon kimliği ve transaction bağlamı ayrıca tutulmalıdır.

### Autonomous transaction

Bağımsız transaction, ana işlem rollback olsa bile kayıt tutabilir. Hata günlüğünde yararlı olabilir. İş kuralını ana transaction'dan koparmak için kullanılmamalıdır; aksi halde veri bütünlüğü kırılır.

### Procedure ve function

**Procedure** bir iş yapar. **Function** bir değer üretir. Function içinde beklenmedik DML yapmak yan etki oluşturur ve SQL içindeki kullanımını zorlaştırır.

```sql
CREATE OR REPLACE FUNCTION kdv(p_tutar NUMBER)
RETURN NUMBER DETERMINISTIC IS
BEGIN
    RETURN p_tutar * 0.20;
END;
/
```

`DETERMINISTIC` yalnız gerçekten aynı girdinin her zaman aynı çıktıyı verdiği fonksiyon için yazılmalıdır. Bu bir optimizasyon vaadi değil, doğruluk sözleşmesidir.

`RESULT_CACHE` az değişen ve çok okunan sonuçları SGA'da tutabilir. `PRAGMA UDF`, SQL içinden sık çağrılan PL/SQL fonksiyonlarında context switch maliyetini azaltabilir. SQL Macro daha da ileri giderek SQL ifadesini çağrı yerine genişletebilir.

### Package

Package specification dış sözleşmedir; body uygulamadır. İlgili procedure, function, type ve sabitleri tek ad alanında toplar.

İyi package tasarımı:

- küçük ve kararlı public API,
- ayrıntıların body içinde gizlenmesi,
- gereksiz global session state'ten kaçınma,
- transaction sınırını çağıranın kontrol etmesi,
- SQL ve PL/SQL bağımlılıklarının açık olması.

Package içine her procedure'de `COMMIT` koymak yeniden kullanılabilirliği bozar. Transaction sınırı iş akışının sahibinde olmalıdır.

### Trigger

Trigger olayla otomatik çalışır. Güçlü olduğu için görünmez yan etki üretme riski de yüksektir.

Kullanım alanları:

- basit ve merkezi audit gereksinimi,
- view üzerinde `INSTEAD OF` DML,
- legacy bütünlük gereksinimleri,
- belirli sistem/DDL olayları.

İş akışının ana bölümünü trigger'a gizlemek bakım maliyetini artırır.

### Mutating table

Row-level trigger, değişmekte olan tablonun tutarlı tamamını sorgulamaya çalışırsa mutating table hatası oluşabilir. Compound trigger, row ve statement aşamalarını aynı nesnede birleştirerek bu sınıf sorunları çözmeye yardımcı olur.

### Trigger yerine constraint

Bir kural `NOT NULL`, `UNIQUE`, `CHECK` veya `FOREIGN KEY` ile ifade edilebiliyorsa trigger yazılmamalıdır. Declarative constraint optimizer ve yönetim araçları tarafından anlaşılır; trigger'ın procedural davranışı daha opaktır.

## Ünite 12: Dinamik SQL ve Veritabanı Güvenliği

### EXECUTE IMMEDIATE

Dinamik SQL, SQL yapısının çalışma zamanında değişmesi gerektiğinde kullanılır.

```sql
v_sql := 'SELECT COUNT(*) FROM calisan WHERE dept_id = :1';
EXECUTE IMMEDIATE v_sql INTO v_sayi USING p_dept;
```

Değerler string birleştirmeyle SQL'e gömülmemelidir. Bind variable hem enjeksiyonu önler hem parse tekrarını azaltır.

### Nesne adları bind edilemez

Tablo ve sütun adı dinamikse allow-list gerekir:

```sql
IF p_tablo NOT IN ('CALISAN','DEPARTMAN') THEN
    RAISE_APPLICATION_ERROR(-20001,'Geçersiz tablo');
END IF;

v_sql := 'SELECT COUNT(*) FROM ' ||
         DBMS_ASSERT.SIMPLE_SQL_NAME(p_tablo);
```

`DBMS_ASSERT` doğrulama yardımcısıdır; tasarımsız dinamik SQL'i güvenli hale getiren sihirli katman değildir.

### DBMS_SQL

Sütun veya bind sayısı da çalışma zamanında değişiyorsa `DBMS_SQL` daha düşük seviyeli kontrol sağlar. Sabit yapıdaki dinamik SQL için `EXECUTE IMMEDIATE` daha okunaklıdır.

### Nesne tipleri, PRAGMA ve koşullu derleme

Oracle object type ile veri ve davranışı bir şema tipinde birleştirebilir. VARRAY ve nested table gibi collection tipleriyle birlikte kullanılabilir. Bu yapılar bazı entegrasyonlarda değerlidir; sıradan ilişkisel modelin otomatik yerine geçmez.

`PRAGMA` derleyiciye veya çalışma zamanına özel bilgi verir. `AUTONOMOUS_TRANSACTION`, `EXCEPTION_INIT`, `UDF` ve `INLINE` gibi direktiflerin her biri farklı bir problem çözer. Gereksiz pragma, kodu hızlandırmaktan çok davranışı görünmez hale getirebilir.

Koşullu derleme `PLSQL_CCFLAGS` ve `$IF` yapılarıyla sürüm veya deployment farklarını tek kaynakta yönetebilir. Çok sayıda koşul oluşuyorsa bunun mimari dallanmanın işareti olduğu unutulmamalıdır.

### Kullanıcı, privilege ve role

Oracle güvenliği en az ayrıcalık ilkesiyle kurulmalıdır.

```text
System privilege   CREATE SESSION gibi sistem işlemi
Object privilege   SELECT/INSERT/EXECUTE gibi nesne erişimi
Role               privilege grubu
```

`SELECT ANY TABLE` gibi `ANY` privilege'ları etki alanını bütün veritabanına genişletir. Uygulama hesaplarında normal çözüm değildir.

Şema sahibi ile uygulamanın runtime hesabını ayırmak saldırı yüzeyini küçültür. Uygulama hesabı DDL yetkisi taşımamalıdır.

### Profile

Profile parola ve kaynak politikalarını sınırlayabilir. Ancak bağlantı havuzu kullanan uygulamalarda idle/session limitleri pool davranışıyla birlikte test edilmelidir.

### Unified Auditing

Denetim hangi kullanıcının hangi nesneye ne zaman eriştiğini kaydeder. Audit politikası "her şeyi kaydet" yaklaşımıyla kurulursa log hacmi ve sorgulama maliyeti işlevi anlamsızlaştırabilir. Güvenlik olayı, mevzuat ve yüksek riskli işlemler hedeflenmelidir.

### VPD

Virtual Private Database, sorguya kullanıcı bağlamına göre predicate ekleyerek satır düzeyinde erişim politikası uygular. Uygulama filtresinin unutulmasına güvenmek yerine kuralı veri katmanına taşır.

### TDE, maskeleme ve redaction

Transparent Data Encryption at-rest veriyi korur. Ağ üzerinde TLS ihtiyacının yerini tutmaz. Data Redaction sorgu sonucunu kullanıcıya göre maskeleyebilir. Dynamic masking ile gerçek veriyi değiştirmeden görünüm sınırlandırılır.

### SQL Firewall

Oracle AI Database 26ai'de SQL Firewall veritabanı çekirdeğine yerleştirilmiştir. Belirli hesap için normal SQL ve bağlantı bağlamı yakalanır, allow-list üretilir; beklenmeyen SQL loglanabilir veya engellenebilir.

SQL Firewall enjeksiyon riskini azaltan ek savunmadır. **Bind variable, en az ayrıcalık ve güvenli uygulama tasarımının yerine geçmez.** Ayrıca kullanım için güncel lisans koşulları kontrol edilmelidir.

## Ünite 13: Alan Yönetimi, UNDO ve Flashback

### Blok ve satır yerleşimi

Oracle satırı blokta saklar. Satır büyüyüp mevcut blokta sığmazsa **row migration** oluşabilir. Satır baştan tek bloğa sığmıyorsa **row chaining** oluşur. Her ikisi de ek blok erişimi yaratabilir.

`PCTFREE`, update ile büyümesi beklenen satırlar için blokta alan bırakır. Modern ASSM ortamında free list yönetimini Oracle üstlenir.

### Segment alanı

Extent büyümesi, tablespace doluluğu ve autoextend değerleri izlenmelidir. Autoextend kapasite planlamasının yerine geçmez; yalnız disk dolana kadar hatayı erteler.

### Compression

Table ve index compression I/O'yu azaltabilir; CPU ve lisans maliyeti sürüme/özelliğe göre değerlendirilir. Sıkıştırma oranı sentetik tahminle değil gerçek veri örneğiyle ölçülmelidir.

### UNDO ne tutar?

UNDO üç temel iş yapar:

1. rollback,
2. consistent read,
3. flashback mekanizmalarının bir bölümü.

Uzun sorgu eski blok sürümüne ihtiyaç duyar. Gerekli undo yeniden kullanılmışsa `ORA-01555: snapshot too old` oluşabilir.

Çözüm yalnız UNDO tablespace'i büyütmek değildir. Uzun sorgu süresi, undo üretim hızı, retention hedefi ve gereksiz commit sıklığı birlikte incelenir.

### Flashback Query

```sql
SELECT * FROM siparis
AS OF TIMESTAMP SYSTIMESTAMP - INTERVAL '10' MINUTE
WHERE id = 100;
```

Flashback Query geçmiş tutarlı görüntüyü okur. Flashback Table nesneyi geçmiş noktaya döndürebilir. Flashback Database daha geniş bir kurtarma mekanizmasıdır ve önceden gerekli altyapının etkinleştirilmesini ister.

Flashback yedekleme değildir. Fiziksel kayıp, veri merkezi kaybı veya arşiv zinciri problemi için RMAN/Data Guard sınıfı koruma gerekir.

## Ünite 14: Yedekleme, Kurtarma ve Veri Taşıma

### RPO ve RTO

Teknik araç seçmeden önce iki hedef belirlenir:

- **RPO:** kabul edilebilir veri kaybı.
- **RTO:** kabul edilebilir hizmet kesintisi.

"Her gece yedek alıyoruz" bir kurtarma stratejisi değildir. RPO/RTO ölçülmeden yedek sıklığı, arşivleme ve standby mimarisi anlamlı seçilemez.

### ARCHIVELOG

ARCHIVELOG modunda dolan online redo log'lar arşivlenir. Bu, online backup ve point-in-time recovery gibi üretim gereksinimlerinin temelidir.

### RMAN

RMAN Oracle'ın fiziksel yedek ve kurtarma aracıdır.

```text
full backup
incremental level 0 / level 1
archive log backup
control file / SPFILE backup
backup validation
restore / recover
```

RMAN backup set kullanılmayan blokları atlayabilir ve recovery zincirini kataloglayabilir.

### Restore ile recover farklıdır

**Restore** yedek dosyasını geri getirir. **Recover** redo/archivelog uygulayarak dosyayı hedef SCN veya zamana ilerletir.

Bu iki aşama karıştırılırsa kurtarma senaryosu kavranmaz.

### FRA

Fast Recovery Area, archive log, flashback log ve RMAN dosyaları için yönetilen alandır. Boyutu yetersizse archive süreci baskı altına girebilir ve sonunda üretimi etkileyebilir.

### Yedek doğrulama

Yedek alınmış olması geri dönebileceği anlamına gelmez. Düzenli `RESTORE VALIDATE`, test restore ve kurtarma tatbikatı gerekir.

### Data Pump

`expdp`/`impdp` mantıksal taşıma aracıdır. Şema, tablo veya metadata seçilebilir; fiziksel RMAN yedeğinin yerine geçmez.

### SQL*Loader ve external table

Büyük düz dosya yüklemelerinde SQL*Loader ve external table seçenekleri uygulama üzerinden satır satır insert etmekten daha uygundur. Direct path gibi seçenekler redo, constraint ve index davranışıyla birlikte değerlendirilmelidir.

### Transportable tablespace

Çok büyük veri kümesinde satırları mantıksal olarak dışa aktarmak yerine datafile'ları taşıyıp metadata'yı aktarabilir. Platform endian uyumluluğu ve self-contained kontrolü önemlidir.

### Database link

Database link uzak veritabanındaki nesneyi yerel SQL'e açar. Kolaylık sağlar fakat dağıtık transaction, ağ gecikmesi, kimlik bilgisi ve hata bağımlılığı üretir. Yoğun mikroservis entegrasyonunun doğal aracı değildir.

## Ünite 15: İzleme ve Performans

### Performans bir bekleme problemidir

Bir oturum ya CPU kullanır ya bir kaynağı bekler. Bu nedenle yalnız CPU yüzdesine bakmak yetersizdir.

Yaygın bekleme sınıfları:

```text
User I/O
System I/O
Concurrency
Commit
Network
Application
Configuration
Cluster
```

Tek bir yüksek wait event otomatik olarak sorun değildir. Toplam DB time içindeki payı ve iş yükü bağlamı önemlidir.

### V$SESSION ve V$SQL

Canlı sorun için önce aktif oturum ve pahalı SQL bulunur.

```sql
SELECT sid, serial#, username, event, wait_class, sql_id
FROM v$session
WHERE status = 'ACTIVE';
```

SQL'leri yalnız tek çalışma süresine göre sıralamak yanıltıcıdır. Milyon kez çalışan 2 ms'lik sorgu, günde bir kez çalışan 20 saniyelik sorgudan daha fazla kaynak tüketebilir.

Önemli oranlar:

- elapsed time / execution,
- CPU / execution,
- buffer gets / execution,
- disk reads / execution,
- rows / execution.

### AWR ve ASH

AWR dönemsel performans snapshot'larını saklar. ASH aktif oturumları örnekler. Birlikte "hangi zaman aralığında, hangi SQL, hangi bekleme" sorusunu yanıtlar.

AWR/ASH kullanımı için Oracle'ın Diagnostic Pack lisans koşulları kontrol edilmelidir.

### SQL Trace ve TKPROF

Tek oturumu ayrıntılı izlemek için trace güçlüdür:

```sql
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(
  session_id => :sid,
  serial_num => :serial,
  waits      => TRUE,
  binds      => TRUE);
```

Trace üretimde yüksek hacim oluşturabilir. Hedefli ve süreli açılmalıdır.

### ADDM ve advisor'lar

Advisor çıktısı öneridir, hüküm değildir. İndeks veya SQL Profile önerisi iş yükü ve yazma maliyeti ölçülmeden uygulanmamalıdır.

### Resource Manager

Resource Manager farklı consumer group'ların CPU, paralellik ve çalışma süresi sınırlarını yönetebilir. Ağır raporların OLTP gecikmesini bozmasını önlemek için iş yükü izolasyonunda etkilidir.

### Gözlem sırası

Pratik bir sıra:

```text
1. Sorunun zaman aralığını belirle
2. DB time ve ana wait class'ları bul
3. En fazla kaynak tüketen SQL'i bul
4. Actual planı ve cardinality sapmasını incele
5. I/O, lock, parse, network veya CPU kök nedenini ayır
6. Tek değişiklik yap
7. Aynı metrikle yeniden ölç
```

"İndeks ekleyelim" teşhis değildir.

## Ünite 16: RAC, ASM, Data Guard ve GoldenGate

### RAC ne çözer?

Oracle RAC, bir veritabanını birden çok instance'ın aynı anda açmasını sağlar. Amaç yerel yüksek erişilebilirlik ve yatay işlem kapasitesidir.

```text
Instance 1 ─┐
Instance 2 ─┼─ shared database storage
Instance 3 ─┘
```

RAC felaket kurtarma çözümü değildir. Tüm instance'lar aynı veritabanına bağlıdır. Bölgesel felaket için ayrı kopya gerekir.

### Cache Fusion

Bir instance'ın ihtiyaç duyduğu güncel blok başka instance'ın buffer cache'indeyse blok disk üzerinden dolaşmak yerine interconnect üzerinden taşınabilir.

Bu mekanizma hızlıdır fakat yerel bellek kadar ucuz değildir. Aynı sıcak blokların düğümler arasında sürekli gidip gelmesi **global cache contention** üretir.

`gc` önekli wait event'leri RAC blok erişimini anlamak için önemlidir.

### Interconnect

Interconnect düşük gecikmeli, yüksek bant genişlikli ve yedekli olmalıdır. RAC'ta ağ gecikmesi doğrudan veritabanı gecikmesine dönüşebilir.

### Service

Uygulama instance adına değil service'e bağlanmalıdır. Service, iş yükünü belirli instance'lara yönlendirebilir ve bakım/failover sırasında bağlantı davranışını yönetir.

FAN, Fast Connection Failover ve Application Continuity sınıfı özellikler yalnız veritabanının ayakta kalmasını değil, uygulamanın kesintiyi nasıl gördüğünü belirler.

### ASM

Automatic Storage Management veritabanı dosyaları için Oracle'a özgü volume manager ve dosya yönetim katmanıdır.

```text
Disk Group
├── disk/failure group
├── striping
├── redundancy
└── online rebalance
```

`EXTERNAL`, `NORMAL`, `HIGH` ve yeni sürümlerde esnek yedeklilik seçenekleri depolama mimarisine göre seçilir. External redundancy kullanıldığında gerçek yedekliliğin alt depolama sistemi tarafından sağlandığı doğrulanmalıdır.

`+DATA` ile `+FRA` adlarının ayrı olması, fiziksel failure domain'lerin ayrı olduğu anlamına gelmez. Aynı storage array üzerindeki mantıksal ayrım tek başına felaket koruması sağlamaz.

### Data Guard

Data Guard primary veritabanının redo akışını standby'a taşır.

```text
Primary ── redo ──> Standby
```

**Physical standby** blok olarak aynı yapıyı redo apply ile sürdürür. **Logical standby** SQL Apply yaklaşımıyla daha farklı yapı seçenekleri sağlar. **Snapshot standby** geçici test kullanımı için yazılabilir hale getirilebilir.

### Protection mode

```text
Maximum Performance
Maximum Availability
Maximum Protection
```

Seçim, veri kaybı toleransı ile commit gecikmesi arasında yapılan iş kararıdır. Uzak standby'a synchronous redo göndermek WAN gecikmesini commit yoluna ekleyebilir.

### Switchover ve failover

**Switchover** planlı rol değişimidir. **Failover** primary kullanılamadığında standby'ın devralmasıdır. Fast-Start Failover belirli koşullarda broker/observer ile otomatik failover sağlar.

### RAC ile Data Guard farkı

```text
RAC         aynı veritabanı, aynı site/paylaşılan storage sınıfı
Data Guard  ayrı veritabanı kopyası, redo ile güncellik
```

RAC düğüm arızasını, Data Guard site/veritabanı kaybını hedefler. Birlikte kullanılabilirler.

### GoldenGate

GoldenGate mantıksal ve seçilebilir çoğaltma sağlar; heterojen sistem, zero-downtime migration ve aktif-aktif topolojilerde kullanılır. Data Guard'ın doğrudan alternatifi değildir.

```text
Data Guard   fiziksel/redo tabanlı DR
GoldenGate   mantıksal değişiklik çoğaltma ve entegrasyon
```

## Ünite 17: Exadata, Autonomous ve Dağıtık Oracle

### Exadata'nın farkı

Exadata yalnız "daha hızlı disk" değildir. Database server ile storage server birlikte tasarlanır. Smart Scan gibi işlemler filtreleme ve bazı veri işleme adımlarını storage katmanına indirerek veritabanı düğümüne taşınan veri miktarını azaltır.

Yüksek bant genişlikli fabric, flash katmanı, storage index ve offload mekanizmaları büyük tarama ve yoğun konsolidasyonda belirgin kazanç sağlayabilir.

Kötü SQL'i Exadata çözmez. Gereksiz satır ve sütun okuyan sorgu daha pahalı donanımda da gereksiz iş yapar.

### Autonomous Database

Autonomous Database patching, backup, ölçekleme ve belirli tuning işlerini yönetilen hizmete taşır. Bunun karşılığı işletim sistemi ve bazı veritabanı parametreleri üzerindeki doğrudan denetimin azalmasıdır.

Yönetilen hizmet seçimi yalnız DBA sayısını azaltma kararı değildir; ağ, veri yerleşimi, maliyet, bağımlılık, uyumluluk ve operasyon modeli birlikte düşünülür.

### Sharding ve Globally Distributed Database

Sharding veriyi bağımsız database shard'larına yatay böler. RAC'tan farklı olarak ortak storage yoktur.

```text
Shard key → doğru shard → yerel işlem
```

Shard key içermeyen sorgu birden çok shard'a dağılabilir. Bu nedenle sharding önce uygulama veri modelini değiştirir, sonra altyapıyı ölçekler.

Coğrafi yerleşim, failure isolation ve çok büyük veri hacmi için anlamlıdır. Orta ölçekli bir uygulamada gereksiz dağıtım yalnız hata yüzeyini büyütür.

### MAA

Maximum Availability Architecture, teknoloji listesinden çok RPO/RTO seviyelerine göre tasarım çerçevesidir. RAC, Data Guard, Application Continuity, Exadata ve mantıksal çoğaltma aynı sistemde farklı failure domain'leri kapatabilir.

## Ünite 18: Oracle Forms, APEX ve Modernizasyon

### Forms neden hâlâ önemlidir?

Oracle Forms yeni proje için tipik tercih değildir; ancak uzun ömürlü kurumsal sistemlerde çok sayıda kritik iş kuralı hâlâ Forms trigger'larında yaşar.

Modernizasyonun ilk adımı "yeniden yazmak" değil, **iş kuralının nerede olduğunu bulmaktır**.

```text
Form
├── block
│   ├── record
│   └── item
├── trigger
├── program unit
└── library
```

Forms trigger'ı ile database trigger aynı şey değildir. İsim benzerliği katman farkını gizlememelidir.

### Forms'un temel riski

İş mantığı UI trigger'larına yayılmışsa:

- otomatik test zorlaşır,
- aynı kural başka istemcide yeniden yazılır,
- transaction sınırı belirsizleşir,
- modern API katmanına geçiş pahalılaşır.

Bu nedenle taşınabilir iş kuralları önce PL/SQL package veya açık servis katmanına ayrılmalıdır.

### APEX

APEX metadata'sı Oracle içinde tutulur; HTTP katmanında ORDS yaygın köprüdür. Form, rapor, interactive grid, session state ve PL/SQL süreçleri hızlı kurumsal uygulama geliştirmeyi sağlar.

APEX'in gücü veriye yakınlığıdır. Aynı özellik yanlış kullanılırsa çok fazla iş mantığı sayfa süreçlerine dağılabilir. Package tabanlı servis sınırı APEX'te de değerlidir.

### Modernizasyon stratejisi

Tek seferde yeniden yazım en yüksek riskli yoldur. Daha güvenli sıra:

```text
1. bağımlılık envanteri
2. veri ve transaction kurallarını çıkar
3. iş mantığını UI'dan ayır
4. test karakterizasyonu oluştur
5. API sınırı tanımla
6. fonksiyonları kademeli taşı
7. eski ve yeni akışı ölçerek kapat
```

Strangler yaklaşımı büyük Forms uygulamalarında bu nedenle kullanışlıdır.

### Mikroservis ne zaman?

Bir monoliti tablo sayısına göre mikroservislere bölmek hatadır. Sınır, transaction ve iş kabiliyeti üzerinden çizilmelidir. Aynı transaction içinde sürekli join edilen ve birlikte commit edilen veri, sırf teknoloji modası için ayrı veritabanlarına dağıtılmamalıdır.

## Ünite 19: JSON, Modern SQL ve Yeni Veri Modelleri

### Native JSON

Native `JSON` tipi JSON verisini yalnız metin olarak değil, veritabanının anlayabildiği veri tipi olarak tutar.

Temel erişim araçları:

```text
JSON_VALUE       skaler değer
JSON_QUERY       JSON parçası
JSON_EXISTS      yol varlığı
JSON_TABLE       JSON'u ilişkisel satır/sütunlara açma
JSON_TRANSFORM   belgeyi değiştirme
```

### JSON index

Sabit ve sık kullanılan yol için function-based index ucuz ve hedeflidir. Esnek çok alanlı arama için JSON search index daha geniş kapsar ve daha fazla alan tüketir.

### JSON-relational duality

Duality view aynı veriyi iki modelle sunar:

```text
uygulama → JSON document view
              ↕
        relational tables
```

Veri iki yerde kopyalanmaz. İlişkisel kısıtlar ve join yapısı korunurken uygulama belge modeliyle çalışabilir. ETAG, belge düzeyinde optimistic concurrency kontrolüne yardımcı olur.

Duality view, "NoSQL mi SQL mi?" ikilemini tamamen ortadan kaldırmaz; fakat aynı iş verisini iki farklı kalıcı modelde senkron tutma ihtiyacını önemli ölçüde azaltabilir.

### XML

Yeni genel amaçlı geliştirmede JSON daha yaygındır. XMLTYPE, XQuery ve XMLTable; XSD ve eski kurumsal entegrasyonların bulunduğu sistemlerde hâlâ önemlidir.

`EXTRACTVALUE` gibi eski işlevler yerine `XMLQuery` ve `XMLTable` tercih edilmelidir.

### SQL'de BOOLEAN, domain ve annotation

Yeni sürümler SQL dilini sadeleştiren özellikler eklemiştir. SQL düzeyinde `BOOLEAN`, data use case domain ve annotation gibi yapılar şema anlamını veriye yaklaştırır.

Domain aynı iş anlamını taşıyan sütunlarda tip ve kural tekrarını azaltabilir. Annotation nesnelere araçların okuyabileceği üstveri ekler.

### Blockchain ve immutable table

Bu tablolar değişmezlik gerektiren denetim kayıtlarında kullanılır. Blockchain table satırlar arasında kriptografik zincir kurar; immutable table daha basit değiştirilemezlik kuralları uygular.

Bunlar harici WORM arşivinin veya mevzuat tasarımının otomatik yerine geçmez. Tehdit modeli ve yönetici yetkileri ayrıca değerlendirilmelidir.

### MLE JavaScript

Multilingual Engine, JavaScript modüllerinin veritabanı içinde çalışmasına izin verir. Uygulamadaki bazı JavaScript doğrulama/dönüşüm kodlarının yeniden kullanılmasına yardımcı olabilir.

Veri yoğun toplu işlemde PL/SQL ve SQL çoğu zaman daha doğal kalır. "JavaScript çalışabiliyor" olması veri katmanının uygulama sunucusuna dönüştürülmesi gerektiği anlamına gelmez.

### Property graph ve SQL/PGQ

İlişkisel tablolar vertex/edge modeliyle graph olarak sunulabilir. Fraud, ilişki, bağımlılık ve yol analizi için SQL/PGQ sorguları kullanılabilir. Ayrı bir graph store gerekip gerekmediği iş yükü ve ölçekle belirlenir.

### True Cache

True Cache, primary Oracle Database önünde çoğunlukla disk kullanmayan, read-only ve redo ile güncel tutulan bir cache katmanıdır. Cache miss durumunda blokları kaynaktan alır; commit edilmiş tutarlı veriyi sunar.

Bu model uygulamanın kendi tutarlılık protokolünü yönettiği genel amaçlı cache'ten farklıdır. Yine de okuma gecikmesi, lag toleransı ve failover davranışı uygulama gereksinimine göre ölçülmelidir.

### Select AI

Select AI doğal dil isteğini SQL/yanıt üretim sürecine bağlar. Veri keşfi ve analist etkileşiminde kullanışlıdır. Üretilen SQL'in yetki, maliyet ve doğruluk kontrolü yapılmadan kritik işlemlerde çalıştırılması doğru değildir.

## Ünite 20: Vector Search ve Yapay Zekâ Bütünleşmesi

### Embedding ve VECTOR

Embedding modeli metin, görüntü veya başka içeriği yüksek boyutlu sayı dizisine dönüştürür. Anlamca yakın öğeler seçilen mesafe uzayında yakın konumlanır.

```sql
CREATE TABLE belge (
    id      NUMBER PRIMARY KEY,
    baslik  VARCHAR2(500 CHAR),
    icerik  CLOB,
    gomme   VECTOR(768, FLOAT32)
);
```

Vector boyutu ve eleman tipi kullanılan modele uymalıdır.

### Mesafe

Yaygın ölçüler:

```text
COSINE
EUCLIDEAN
DOT
MANHATTAN
HAMMING
```

"Cosine her zaman iyidir" kuralı yoktur. Embedding modelinin önerdiği mesafe kullanılmalıdır.

### Exact ve approximate search

Tam tarama kesin en yakın komşuları verir fakat veri büyüdükçe maliyeti artar. Approximate nearest neighbor, küçük doğruluk kaybı karşılığında çok daha az aday inceler.

```sql
SELECT id, baslik
FROM belge
ORDER BY VECTOR_DISTANCE(gomme, :q, COSINE)
FETCH APPROXIMATE FIRST 20 ROWS ONLY;
```

### HNSW ve IVF

Oracle iki temel vector index ailesi sunar:

```text
HNSW   In-Memory Neighbor Graph; düşük gecikme, bellek ağırlıklı
IVF    Neighbor Partitions; vektör uzayını kümelere ayırır
```

```sql
CREATE VECTOR INDEX ix_belge_hnsw ON belge(gomme)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95;
```

HNSW bellekte komşuluk grafı kurar. IVF centroid/partition yaklaşımıyla arama alanını daraltır. `TARGET ACCURACY` performans-doğruluk hedefidir; gerçek recall iş verisiyle ölçülmelidir.

26ai release update'leri distributed/local HNSW, online vector index build, quantization ve IVF bakımında yeni seçenekler eklemiştir. Kullanılan sözdizimi RU seviyesine göre resmi belgeden doğrulanmalıdır.

### Hybrid Vector Index

Hybrid Vector Index, Oracle Text ile vector index yapılarını tek arama nesnesinde birleştirir. Amaç yalnız semantik benzerlik veya yalnız keyword eşleşmesi yerine ikisini birlikte puanlamaktır.

Bu özellikle ürün kodu, isim, mevzuat maddesi gibi kesin terimlerin yanında anlamsal yakınlığın da gerekli olduğu kurumsal aramada değerlidir.

### Gömme nerede üretilir?

İki temel model vardır:

1. uygulama/harici model embedding üretir ve VECTOR sütununa yazar,
2. uyumlu model veritabanına yüklenir ve embedding veriye yakın üretilir.

Veri dışarı çıkmamalıysa ikinci model güvenlik ve gecikme açısından avantaj sağlar. Buna karşılık model yaşam döngüsü, GPU/CPU maliyeti ve sürüm yönetimi veritabanı operasyonuna eklenir.

### RAG

Retrieval-augmented generation akışı:

```text
belge
 ↓
chunk
 ↓
embedding
 ↓
vector / hybrid search
 ↓
en ilgili parçalar
 ↓
LLM context
 ↓
yanıt
```

Veritabanı burada depolama, metadata filtresi, erişim kontrolü ve retrieval görevlerini aynı transaction/güvenlik alanında birleştirebilir.

Chunk boyutu sabit bir doğru değildir. Küçük chunk daha kesin eşleşme, büyük chunk daha fazla bağlam verir. Overlap sınırdaki bağlam kaybını azaltır ama indeks boyutunu büyütür.

### Vector veritabanı her sorunun çözümü değildir

Exact key lookup, range query, transaction, referential integrity ve toplama sorguları ilişkisel modelin doğal alanıdır. Vector search bu özelliklerin yerine değil, semantik erişim gereksiniminin yanına eklenir.

Oracle'ın güçlü tarafı ilişkisel filtre, JSON, text search ve vector search'ü aynı SQL/transaction sınırında birleştirebilmesidir. Mimarinin değeri ancak veri kopyalamayı ve servisler arası tutarlılık maliyetini gerçekten azaltıyorsa ortaya çıkar.

## Hızlı Tekrar

**Instance bellekte, veritabanı kalıcı dosyalarda yaşar.**

**SGA paylaşılır; PGA süreç/oturum çalışma alanıdır.**

**COMMIT datafile'ı değil, dayanıklılık için redo'nun kalıcı olmasını bekler.**

**LGWR redo, DBWn veri bloğu yazar.**

**Oracle satırı değil blok okur.**

**Tablespace mantıksal, datafile fizikseldir.**

**Segment nesnenin alanı; extent blok grubudur.**

**V$ anlık instance, DBA_* kalıcı sözlük bilgisidir.**

**CDB altyapı, PDB uygulama veritabanı sınırıdır.**

**VARCHAR2 üst sınırı EXTENDED modda 32767 bayttır; büyük metin LOB'dur.**

**DATE saat bilgisini de taşır.**

**Sequence boşluksuz numara garantisi vermez.**

**Foreign key için Oracle otomatik indeks oluşturmaz.**

**Constraint ifade edilebilen kural trigger'a bırakılmamalıdır.**

**DELETE DML'dir ve rollback edilebilir; TRUNCATE DDL sınıfındadır ve transaction davranışı farklıdır.**

**Oracle consistent read için UNDO kullanır.**

**READ COMMITTED'da her statement kendi SCN görüntüsünü görür.**

**SKIP LOCKED iş kuyruğu tüketicilerinde yararlıdır.**

**Optimistic locking sürüm karşılaştırır; kullanıcı düşünürken satırı kilitlemez.**

**Deadlock'u önlemenin temel yolu kaynakları aynı sırada güncellemektir.**

**FROM, WHERE'den; WHERE, SELECT'ten önce mantıksal olarak çalışır.**

**LEFT JOIN filtresini WHERE'e taşımak sonucu inner join'e çevirebilir.**

**NULL bilinmeyendir; NULL = NULL TRUE değildir.**

**NOT IN + NULL tehlikelidir; anti-join için NOT EXISTS daha güvenlidir.**

**CTE okunabilirlik sağlar; yazılması otomatik materialization demek değildir.**

**Aggregate satırları azaltır; analytic satırları korur.**

**ROW_NUMBER, RANK ve DENSE_RANK eşitlikte farklı davranır.**

**ROWS fiziksel satır, RANGE akran değer aralığıdır.**

**Derin OFFSET pahalıdır; keyset pagination daha ölçeklenebilir olabilir.**

**İndeks okumayı hızlandırırken her DML'e maliyet ekler.**

**Bileşik indekste sütun sırası sorgu desenine göre seçilir.**

**Bitmap index OLTP için varsayılan tercih değildir.**

**Routine index rebuild bakım politikası değildir.**

**Partitioning'in asıl okuma kazancı pruning'dir.**

**Local index partition ile hizalıdır; global index farklı erişim desenini kapsar.**

**EXCHANGE PARTITION veri taşımadan metadata değişimiyle büyük arşiv işlemleri yapabilir.**

**Full table scan kötü plan demek değildir.**

**Optimizer'ın en kritik girdisi doğru cardinality tahminidir.**

**Actual rows ile estimated rows sapması plan sorununu açıklar.**

**Bind variable güvenlik yanında parse maliyetini de düşürür.**

**Hint ilk çözüm değil, kontrollü müdahaledir.**

**SQL Plan Baseline plan kararlılığı sağlar; kök nedeni ortadan kaldırmaz.**

**PL/SQL satır satır SQL yazmak için değil, procedural gereksinim için kullanılır.**

**BULK COLLECT/FORALL context switch sayısını azaltır.**

**WHEN OTHERS THEN NULL hatayı çözmez, saklar.**

**Function değer üretir; görünmez yan etkilerden kaçınılır.**

**Package specification sözleşme, body uygulamadır.**

**Trigger görünmez yan etkidir; gerekmedikçe iş akışının merkezi yapılmaz.**

**Dinamik değerler bind edilir; nesne adları allow-list ile doğrulanır.**

**DBMS_ASSERT doğrulama aracıdır, güvenli tasarımın yerine geçmez.**

**ANY privilege uygulama hesabı için aşırı geniştir.**

**TDE at-rest şifrelemedir; TLS'in yerini tutmaz.**

**SQL Firewall ek savunmadır; bind variable ve least privilege'ın yerini tutmaz.**

**ORA-01555 yalnız "UNDO küçük" demek değildir; sorgu süresi ve undo üretim hızı birlikte incelenir.**

**Flashback yedekleme değildir.**

**Restore dosyayı geri getirir; recover redo ile ileri taşır.**

**Yedek test restore yapılmadan güvenilir sayılmaz.**

**RPO veri kaybı, RTO kesinti hedefidir.**

**AWR/ASH tarihsel; V$SESSION canlı görünüm sağlar.**

**Performans analizi CPU + wait time üzerinden yapılır.**

**RAC aynı veritabanını birden çok instance ile açar; DR değildir.**

**Cache Fusion blokları instance cache'leri arasında interconnect ile taşır.**

**RAC'ta interconnect gecikmesi veritabanı gecikmesidir.**

**ASM storage yönetir; disk group adı tek başına failure isolation sağlamaz.**

**Data Guard redo tabanlı standby, GoldenGate mantıksal değişiklik çoğaltmadır.**

**Synchronous uzak redo commit gecikmesine WAN RTT ekleyebilir.**

**Exadata kötü SQL'i doğru SQL'e dönüştürmez.**

**Sharding önce veri modeli kararıdır, sonra altyapı kararıdır.**

**Forms modernizasyonunda önce trigger ve bağımlılık envanteri çıkarılır.**

**Mikroservis sınırı tabloya değil iş ve transaction sınırına göre çizilir.**

**Native JSON belgeyi ilişkisel transaction ile aynı veritabanında tutabilir.**

**JSON-relational duality aynı veriyi iki modelle sunar; iki kopya tutmayı hedeflemez.**

**True Cache read-only, redo ile güncel tutulan Oracle cache katmanıdır.**

**VECTOR semantik erişim ekler; primary key ve ilişkisel sorgunun yerini almaz.**

**HNSW graph tabanlı, IVF partition/cluster tabanlı approximate vector index'tir.**

**Hybrid Vector Index keyword ile semantic search'ü birleştirir.**

**RAG'in kalitesi yalnız modelden değil chunking, retrieval, filtre ve yetkilendirmeden gelir.**

## Kaynakça

- Oracle. *Oracle AI Database 26ai Documentation*. https://docs.oracle.com/en/database/oracle/oracle-database/26/
- Oracle. *Oracle Database 19c Documentation*. https://docs.oracle.com/en/database/oracle/oracle-database/19/
- Oracle. *Oracle AI Database SQL Language Reference*. https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/
- Oracle. *Oracle AI Database PL/SQL Language Reference*. https://docs.oracle.com/en/database/oracle/oracle-database/26/lnpls/
- Oracle. *Oracle AI Database Administrator's Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/admin/
- Oracle. *Oracle AI Database Performance Tuning Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/tgdba/
- Oracle. *Oracle Database Backup and Recovery User's Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/bradv/
- Oracle. *Oracle Real Application Clusters Administration and Deployment Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/
- Oracle. *Oracle Data Guard Concepts and Administration*. https://docs.oracle.com/en/database/oracle/oracle-database/26/sbydb/
- Oracle. *Oracle Automatic Storage Management Administrator's Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/ostmg/
- Oracle. *Oracle AI Database Security Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/dbseg/
- Oracle. *Oracle SQL Firewall User's Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlfw/
- Oracle. *JSON-Relational Duality Developer's Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/jsnvu/
- Oracle. *Oracle AI Vector Search User's Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/vecse/
- Oracle. *Oracle True Cache User's Guide*. https://docs.oracle.com/en/database/oracle/oracle-database/26/odbtc/
- Oracle. *Oracle Lifetime Support Policy: Technology Products*. https://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
- Thomas Kyte, Darl Kuhn. *Expert Oracle Database Architecture*, 3rd Edition. Apress.
- Steven Feuerstein, Bill Pribyl. *Oracle PL/SQL Programming*. O'Reilly Media.

## Bu Çalışmaya Atıf

Köker, M. A. (2021). Oracle Veritabanı ve PL/SQL: Mimari, SQL ve Performans. alikoker.com.tr. https://alikoker.com.tr/oracle-veritabani-plsql-mimari-sql-performans

- BibTeX: https://alikoker.com.tr/oracle-veritabani-plsql-mimari-sql-performans.bib
- RIS: https://alikoker.com.tr/oracle-veritabani-plsql-mimari-sql-performans.ris
- CSL-JSON: https://alikoker.com.tr/oracle-veritabani-plsql-mimari-sql-performans.csl.json