Gambar tersebut menunjukkan arsitektur internal Microsoft SQL Server yang terdiri dari tiga komponen utama, yaitu Protocol Layer, Relational Engine, dan Storage Engine. Pertama kali perintah diterima oleh Protocol Layer. Pada komponen ini ditentukan language event dari perintah. Selanjutnya dipilah mana yang perlu diteruskan ke Relational Engine dan mana yang langsung dikembalikan. Perintah yang diteruskan ke Relational Engine kemudian dianalisis apakah perlu diteruskan ke Storage Engine atau tidak. Untuk data yang perlu diteruskan ke Storage Engine akan dilakukan analisa mengenai Access Method yang dipakai. Jika merupakan perintah yang berkaitan dengan perubahan data akan diteruskan ke Transaction Manager untuk mencatat log perubahan. Sedangkan untuk perintah yang tidak melibatkan perubahan data akan dilakukan pengecekan ke Buffer Manager apakah data yang diminta sudah ada. Jika data yang diminta belum ada maka dilakukan akses ke file fisik. Selanjutnya hasil perintah dikembalikan ke Relational Engine untuk selanjutnya diteruskan ke Protocol Layer.
Agar dapat dipahami lebih mudah, kita ambil contoh misalnya terdapat perintah sederhana use database MyDB. Bagaimana perintah ini akan diproses dan komponen apa saja yang dilibatkan?
Perintah USE MyDB adalah perintah pengaturan konteks sesi, bukan perintah manipulasi data. Tujuannya bukan membaca atau menulis data, tetapi mengubah database aktif pada koneksi klien saat ini di Microsoft SQL Server. Karena itu, alurnya berhenti relatif cepat dan tidak melibatkan Storage Engine untuk akses data tabel. Secara lebih detail sebagai berikut:
Langkah 1: aplikasi klien (misalnya SSMS atau aplikasi lain) mengirim perintah:
USE MyDB;
Perintah ini:
- Dikemas dalam format TDS (Tabular Data Stream) sebagai language event
- Dikirim melalui jaringan
- Diterima oleh SQL Server Network Interface (SNI)
Langkah 2: setelah sampai di server:
- Protocol Layer mem-parsing struktur TDS
- Mengenali bahwa pesan ini adalah perintah SQL
- Mengekstrak string “USE MyDB”
- Memastikan:
- sesi sudah login
- format pesan valid secara protokol
Jika valid, perintah diteruskan ke Relational Engine.
Langkah 3: inti pemrosesan perintah USE MyDB terjadi.
a. Parsing SQL
Relational Engine:
- Mengenali USE sebagai statement pengaturan konteks
- Membentuk representasi internal sederhana
- Tidak membuat query plan kompleks
b. Binding & Validasi Metadata
Relational Engine kemudian:
- Mengecek apakah database MyDB ada
- Mengecek status database (ONLINE / OFFLINE)
- Mengecek hak akses user ke database tersebut
Semua informasi ini diambil dari metadata sistem, bukan dari tabel user.
Jika salah satu gagal:
- Error langsung dikembalikan ke klien
- Storage Engine tidak dilibatkan
Jika semua valid:
- SQL Server mengubah database context pada sesi koneksi
- Nilai current database pada session state diperbarui
- Tidak ada query plan
- Tidak ada operator fisik
- Tidak ada permintaan halaman data
Langkah 4: SQL Server mengirim respons melalui:
- Protocol Layer → SNI → TDS
Biasanya berupa pesan:
Changed database context to ‘MyDB’.
Selanjutnya kita ambil contoh lain yang lebih kompleks. Misalnya terdapat perintah delete from user where idUser=’admin’. Bagaimana perintah ini akan diproses dan komponen apa saja yang dilibatkan?
Perintah DELETE adalah perintah manipulasi data (DML) yang mengubah data fisik. Karena itu, alurnya pasti melibatkan Relational Engine dan Storage Engine, termasuk mekanisme transaksi dan logging di Microsoft SQL Server.
Langkah 1: aplikasi klien mengirim perintah SQL ke server:
- Perintah dikemas sebagai language event dalam TDS (Tabular Data Stream)
- Dikirim lewat jaringan
- Diterima oleh SQL Server Network Interface (SNI)
Langkah 2: setelah sampai di server Protocol Layer kemudian:
- Mem-parsing struktur TDS
- Memastikan pesan valid secara protokol
- Mengecek status sesi (login, koneksi aktif)
- Mengekstrak string SQL:
DELETE FROM user WHERE idUser = ‘admin’
Jika valid, perintah diteruskan ke Relational Engine.
Langkah 3: Relational Engine mulai memahami perintah SQL secara formal:
- Mengenali DELETE sebagai perintah DML
- Membentuk parse tree
- Mengidentifikasi:
- tabel user
- kolom idUser
- kondisi WHERE
Jika terjadi kesalahan sintaks, proses berhenti di sini.
Langkah 4: masih di Relational Engine, SQL Server melakukan binding:
- Memastikan tabel user ada
- Memastikan kolom idUser ada
- Memeriksa hak akses DELETE pengguna
- Menentukan skema dan metadata objek
Jika salah satu gagal, error dikembalikan ke klien dan Storage Engine tidak dilibatkan.
Langkah 5: karena ini perintah yang menyentuh data fisik, Query Optimizer aktif:
- Mengecek apakah ada index pada idUser
- Membandingkan beberapa strategi eksekusi:
- Index Seek + Delete
- Table Scan + Delete
- Memperkirakan biaya berdasarkan statistik
- Memilih query plan paling efisien
Hasilnya adalah query plan fisik.
Langkah 6: Query Executor menjalankan query plan:
- Mengeksekusi operator satu per satu
- Ketika perlu membaca atau mengubah data,
ia memanggil Storage Engine
Langkah 7: Storage Engine menerima permintaan:
- Menentukan cara akses data:
- Jika ada index → Index Seek
- Jika tidak → Table Scan
- Menentukan row mana yang memenuhi kondisi
idUser = ‘admin’
Langkah 8: Storage Engine kemudian:
- Meminta halaman data (data pages)
- Buffer Manager mengecek:
- apakah halaman sudah ada di buffer pool
- jika belum → baca dari data file (disk)
- Halaman data dimuat ke memori
Langkah 9: karena DELETE mengubah data:
- SQL Server mencatat operasi ke Transaction Log terlebih dahulu
- Ini bagian dari prinsip Write-Ahead Logging (WAL)
- Jika terjadi crash, perubahan bisa di-redo atau rollback
Langkah 10: baris data yang dihapus:
- Ditandai sebagai deleted
- Halaman menjadi dirty page
Secara teknis:
- Baris tidak langsung dihapus dari disk
- SQL Server:
- menandai row sebagai tidak aktif
- indeks juga diperbarui
- Penulisan ke disk dilakukan kemudian oleh proses background
Langkah 11: jika perintah berhasil:
- Transaksi di-commit
- Storage Engine mengembalikan status ke Relational Engine
- Relational Engine mengirim hasil ke klien:
- jumlah baris yang terhapus
- pesan sukses
Jika di tengah proses terjadi error:
- Transaction Manager melakukan rollback
- Data dikembalikan ke kondisi semula
- Informasi rollback juga dicatat di log
Materi slide dapat dilihat di sini
