Perilaku Oracle LOB adalah sebagai berikut.
Sebuah LOB disimpan inline ketika:
(
The size is lower or equal than 3964
AND
ENABLE STORAGE IN ROW has been defined in the LOB storage clause
) OR (
The value is NULL
)
Sebuah LOB disimpan out-of-row ketika:
(
The value is not NULL
) AND (
Its size is higher than 3964
OR
DISABLE STORAGE IN ROW has been defined in the LOB storage clause
)
Sekarang ini bukan satu-satunya masalah yang dapat memengaruhi kinerja.
Jika LOB akhirnya tidak disimpan inline, perilaku default Oracle adalah menghindari caching mereka (hanya LOB inline yang di-cache di buffer cache dengan bidang lain dari baris). Untuk memberitahu Oracle agar juga meng-cache LOB non inline, opsi CACHE harus digunakan ketika LOB didefinisikan.
Perilaku defaultnya adalah ENABLE STORAGE IN ROW, dan NOCACHE, yang berarti LOB kecil akan disisipkan, LOB besar tidak akan (dan tidak akan di-cache).
Akhirnya, ada juga masalah kinerja di tingkat protokol komunikasi. Klien Oracle biasa akan melakukan 2 perjalanan bolak-balik tambahan per LOB untuk mengambilnya:- satu untuk mengambil ukuran LOB dan mengalokasikan memori yang sesuai- satu untuk mengambil data itu sendiri (asalkan LOB kecil)
Perjalanan pulang pergi ekstra ini dilakukan bahkan jika antarmuka array digunakan untuk mengambil hasil. Jika Anda mengambil 1000 baris dan ukuran array Anda cukup besar, Anda akan membayar untuk 1 perjalanan pulang pergi untuk mengambil baris, dan 2000 perjalanan pulang pergi untuk mengambil konten LOB.
Harap diperhatikan bahwa ini tidak tergantung pada fakta LOB disimpan inline atau tidak. Mereka menyelesaikan masalah yang berbeda.
Untuk mengoptimalkan pada tingkat protokol, Oracle telah menyediakan kata kerja OCI baru untuk mengambil beberapa LOB dalam satu perjalanan pulang pergi (OCILobArrayRead). Saya tidak tahu apakah ada hal serupa dengan JDBC.
Pilihan lain adalah mengikat LOB di sisi klien seolah-olah itu adalah RAW/VARCHAR2 besar. Ini hanya berfungsi jika ukuran maksimum LOB dapat ditentukan (karena ukuran maksimum harus diberikan pada waktu pengikatan). Trik ini menghindari rountrip tambahan:LOB hanya diproses seperti RAW atau VARCHAR2. Kami sering menggunakannya dalam aplikasi intensif LOB kami.
Setelah jumlah perjalanan pulang pergi telah dioptimalkan, ukuran paket (SDU) dapat diubah ukurannya dalam konfigurasi net agar lebih sesuai dengan situasi (yaitu, jumlah perjalanan pulang-pergi besar yang terbatas). Ini cenderung mengurangi peristiwa tunggu "SQL*Net lebih banyak data ke klien" dan "SQL*Net lebih banyak data dari klien".
