Indeks Penyimpan Kolom - Performa kueri

Berlaku untuk:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics AnalyticsPlatform System (PDW)

Rekomendasi untuk mencapai performa kueri yang sangat cepat yang dirancang untuk disediakan indeks penyimpan kolom.

Indeks penyimpan kolom dapat mencapai performa hingga 100x lebih baik pada beban kerja analitik dan pergudangan data dan kompresi data hingga 10x lebih baik daripada indeks rowstore tradisional. Rekomendasi ini membantu kueri Anda mencapai performa kueri yang sangat cepat yang dirancang untuk disediakan oleh indeks penyimpan kolom. Penjelasan lebih lanjut tentang performa penyimpan kolom ada di akhir.

Rekomendasi untuk meningkatkan performa kueri

Berikut adalah beberapa rekomendasi untuk mencapai indeks penyimpan kolom berkinerja tinggi dirancang untuk disediakan.

1. Atur data untuk menghilangkan lebih banyak grup baris dari pemindaian tabel lengkap

  • Manfaatkan urutan penyisipan. Dalam kasus umum di gudang data tradisional, data memang dimasukkan dalam urutan waktu dan analitik dilakukan dalam dimensi waktu. Misalnya, menganalisis penjualan menurut kuartal. Untuk beban kerja semacam ini, eliminasi grup baris terjadi secara otomatis. Di SQL Server 2016 (13.x), Anda dapat mengetahui jumlah grup baris yang dilewati sebagai bagian dari pemrosesan kueri.

  • Manfaatkan indeks berkluster rowstore. Jika predikat kueri umum ada di kolom (misalnya, C1) yang tidak terkait dengan urutan penyisipan baris, Anda dapat membuat indeks berkluster rowstore pada kolom C1 lalu membuat indeks penyimpan kolom berkluster dengan menghilangkan indeks berkluster rowstore. jika Anda membuat indeks penyimpan kolom berkluster secara eksplisit menggunakan MAXDOP = 1, indeks penyimpan kolom berkluster yang dihasilkan diurutkan dengan sempurna pada kolom C1. Jika Anda menentukan MAXDOP = 8, maka Anda akan melihat tumpang tindih nilai di delapan grup baris. Kasus umum strategi ini ketika Anda awalnya membuat indeks penyimpan kolom dengan sekumpulan data besar. Catatan, untuk indeks penyimpan kolom non-kluster (NCCI), jika tabel rowstore dasar memiliki indeks berkluster, baris sudah diurutkan. Dalam hal ini, indeks penyimpan kolom nonclustered yang dihasilkan akan secara otomatis diurutkan. Salah satu poin penting yang perlu diperhatikan adalah bahwa indeks penyimpan kolom tidak secara inheren mempertahankan urutan baris. Saat baris baru disisipkan atau baris yang lebih lama diperbarui, Anda mungkin perlu mengulangi proses karena performa kueri analitik mungkin memburuk

  • Manfaatkan partisi tabel. Anda dapat mempartisi indeks penyimpan kolom lalu menggunakan eliminasi partisi untuk mengurangi jumlah grup baris yang akan dipindai. Misalnya, tabel fakta menyimpan pembelian yang dilakukan oleh pelanggan. Pola kueri umum adalah menemukan pembelian triwulanan yang dilakukan oleh pelanggan tertentu, Anda dapat menggabungkan pesanan sisipan dengan partisi pada kolom pelanggan. Setiap partisi akan berisi baris dalam urutan waktu untuk pelanggan tertentu. Selain itu, pertimbangkan untuk menggunakan partisi tabel jika ada kebutuhan untuk menghapus data dari penyimpan kolom. Beralih dan memotong partisi yang tidak diperlukan lagi adalah strategi yang efisien untuk menghapus data tanpa menghasilkan fragmentasi yang diperkenalkan dengan memiliki grup baris yang lebih kecil.

  • Hindari menghapus data dalam jumlah besar. Menghapus baris terkompresi dari grup baris bukanlah operasi sinkron. Akan mahal untuk mendekompresi grup baris, menghapus baris, lalu mengompresinya kembali. Oleh karena itu, jika Anda menghapus data dari grup baris terkompresi, grup baris ini akan tetap dipindai meskipun menampilkan lebih sedikit baris. Jika jumlah baris yang dihapus untuk beberapa grup baris cukup besar agar baris ini digabungkan menjadi grup baris yang lebih sedikit, maka mengatur ulang penyimpan kolom akan meningkatkan kualitas indeks dan performa kueri. Jika proses penghapusan data Anda biasanya mengentalkan seluruh grup baris, pertimbangkan untuk menggunakan partisi tabel, alihkan partisi yang tidak diperlukan lagi, dan potong bukan menghapus baris.

    Catatan

    Dimulai dengan SQL Server 2019 (15.x), tuple-mover dibantu oleh tugas penggabungan latar belakang yang secara otomatis memadatkan grup baris delta TERBUKA yang lebih kecil yang telah ada selama beberapa waktu seperti yang ditentukan oleh ambang internal, atau menggabungkan grup baris TERKOMPRESI dari tempat sejumlah besar baris telah dihapus. Ini meningkatkan kualitas indeks penyimpan kolom dari waktu ke waktu.
    Jika menghapus data dalam jumlah besar dari indeks penyimpan kolom diperlukan, pertimbangkan untuk membagi operasi tersebut menjadi batch penghapusan yang lebih kecil dari waktu ke waktu, memungkinkan tugas penggabungan latar belakang untuk menangani tugas penggabungan grup baris yang lebih kecil dan meningkatkan kualitas indeks, menghilangkan kebutuhan untuk menjadwalkan jendela pemeliharaan reorganisasi indeks setelah penghapusan data.
    Untuk informasi selengkapnya tentang istilah dan konsep penyimpan kolom, lihat Indeks penyimpan kolom: Gambaran Umum.

2. Rencanakan memori yang cukup untuk membuat indeks penyimpan kolom secara paralel

Membuat indeks penyimpan kolom secara default adalah operasi paralel, kecuali memori tersebut dibatasi. Membuat indeks secara paralel membutuhkan lebih banyak memori daripada membuat indeks secara serial. Ketika ada memori yang cukup, membuat indeks penyimpan kolom mengambil urutan 1,5 kali selama membangun pohon B pada kolom yang sama.

Memori yang diperlukan untuk membuat indeks penyimpan kolom tergantung pada jumlah kolom, jumlah kolom string, tingkat paralelisme (DOP), dan karakteristik data. Misalnya, jika tabel Anda memiliki kurang dari 1 juta baris, SQL Server hanya akan menggunakan satu utas untuk membuat indeks penyimpan kolom.

Jika tabel Anda memiliki lebih dari 1 juta baris, tetapi SQL Server tidak bisa mendapatkan peruntukan memori yang cukup besar untuk membuat indeks menggunakan MAXDOP, SQL Server akan secara otomatis berkurang MAXDOP sesuai kebutuhan agar sesuai dengan peruntukan memori yang tersedia. Di dalam beberapa kasus, DOP harus dikurangi menjadi satu agar dapat membangun indeks di bawah memori yang dibatasi.

Dimulai dengan SQL Server 2016 (13.x), kueri akan selalu beroperasi dalam mode batch. Dalam rilis sebelumnya, eksekusi batch hanya digunakan ketika DOP lebih besar dari satu.

Performa Penyimpan Kolom Dijelaskan

Indeks penyimpan kolom mencapai performa kueri tinggi dengan menggabungkan pemrosesan mode batch dalam memori berkecepatan tinggi dengan teknik yang sangat mengurangi persyaratan I/O. Karena kueri analitik memindai sejumlah besar baris, kueri biasanya terikat IO, dan karenanya mengurangi I/O selama eksekusi kueri sangat penting untuk desain indeks penyimpan kolom. Setelah data dibaca ke dalam memori, sangat penting untuk mengurangi jumlah operasi dalam memori.

Indeks penyimpan kolom mengurangi I/O dan mengoptimalkan operasi dalam memori melalui kompresi data tinggi, eliminasi penyimpan kolom, penghapusan grup baris, dan pemrosesan batch.

Pemadatan data

Indeks penyimpan kolom mencapai kompresi data hingga 10x lebih besar daripada indeks rowstore. Ini sangat mengurangi I/O yang diperlukan untuk menjalankan kueri analitik dan karenanya meningkatkan performa kueri.

  • Indeks penyimpan kolom membaca data terkompresi dari disk, yang berarti lebih sedikit byte data yang perlu dibaca ke dalam memori.

  • Indeks penyimpan kolom menyimpan data dalam bentuk terkompresi dalam memori, yang mengurangi I/O dengan mengurangi berapa kali data yang sama dibaca ke dalam memori. Misalnya, dengan pemadatan 10x, indeks penyimpan kolom dapat menyimpan 10x lebih banyak data dalam memori dibandingkan dengan menyimpan data dalam bentuk yang tidak dikompresi. Dengan lebih banyak data dalam memori, kemungkinan besar indeks penyimpan kolom akan menemukan data yang dibutuhkan dalam memori tanpa menimbulkan bacaan tambahan dari disk.

  • Penyimpan kolom mengindeks data berdasarkan kolom alih-alih menurut baris, mencapai tingkat kompresi tinggi dan mengurangi ukuran data yang disimpan pada disk. Setiap kolom dikompresi dan disimpan secara independen. Data dalam kolom selalu memiliki jenis data yang sama dan cenderung memiliki nilai yang sama. Teknik kompresi data sangat baik dalam mencapai tingkat kompresi yang lebih tinggi ketika nilai serupa.

  • Misalnya, jika tabel fakta menyimpan alamat pelanggan dan memiliki kolom untuk negara/wilayah, jumlah total nilai yang mungkin kurang dari 200. Beberapa nilai tersebut akan diulang berkali-kali. Jika tabel fakta memiliki 100 juta baris, kolom negara/wilayah akan memadatkan dengan mudah dan membutuhkan penyimpanan yang sangat sedikit. Pemadatan baris demi baris tidak dapat memanfaatkan kesamaan nilai kolom dengan cara ini dan akan menggunakan lebih banyak byte untuk memadatkan nilai di kolom negara/wilayah.

Eliminasi kolom

Indeks penyimpan kolom melewati pembacaan dalam kolom yang tidak diperlukan untuk hasil kueri. Kemampuan ini, yang disebut eliminasi kolom, semakin mengurangi I/O untuk eksekusi kueri dan karenanya meningkatkan performa kueri.

  • Penghapusan kolom dimungkinkan karena data diatur dan dikompresi kolom menurut kolom. Sebaliknya, ketika data disimpan baris demi baris, nilai kolom di setiap baris disimpan secara fisik bersama-sama dan tidak dapat dengan mudah dipisahkan. Prosesor Kueri perlu dibaca di seluruh baris untuk mengambil nilai kolom tertentu, yang meningkatkan I/O karena data tambahan tidak perlu dibaca ke dalam memori.

  • Misalnya, jika tabel memiliki 50 kolom dan kueri hanya menggunakan 5 kolom tersebut, indeks penyimpan kolom hanya mengambil 5 kolom dari disk. Ini melewati pembacaan di 45 kolom lainnya. Ini mengurangi I/O dengan 90% lain dengan asumsi semua kolom memiliki ukuran yang sama. Jika data yang sama disimpan di rowstore, prosesor kueri perlu membaca 45 kolom tambahan.

Eliminasi grup baris

Untuk pemindaian tabel lengkap, persentase besar data biasanya tidak cocok dengan kriteria predikat kueri. Dengan menggunakan metadata, indeks penyimpan kolom dapat melewati pembacaan di grup baris yang tidak berisi data yang diperlukan untuk hasil kueri, semuanya tanpa I/O aktual. Kemampuan ini, yang disebut eliminasi grup baris, mengurangi I/O untuk pemindaian tabel penuh dan karenanya meningkatkan performa kueri.

Kapan indeks penyimpan kolom perlu melakukan pemindaian tabel penuh?

Dimulai dengan SQL Server 2016 (13.x), Anda dapat membuat satu atau beberapa indeks pohon B berkluster reguler pada indeks penyimpan kolom berkluster seperti yang Anda bisa pada tumpukan rowstore. Indeks pohon B berkluster dapat mempercepat kueri yang memiliki predikat kesetaraan atau predikat dengan rentang kecil nilai. Untuk predikat yang lebih rumit, pengoptimal kueri mungkin memilih pemindaian tabel lengkap. Tanpa kemampuan untuk melewati grup baris, pemindaian tabel penuh akan sangat memakan waktu, terutama untuk tabel besar.

Kapan kueri analitik mendapat manfaat dari eliminasi grup baris untuk pemindaian tabel penuh?

Misalnya, bisnis ritel telah memodelkan data penjualan mereka menggunakan tabel fakta dengan indeks penyimpan kolom berkluster. Setiap penjualan baru menyimpan berbagai atribut transaksi termasuk tanggal produk dijual. Menariknya, meskipun indeks penyimpan kolom tidak menjamin urutan yang diurutkan, baris dalam tabel ini akan dimuat dalam urutan pengurutan tanggal. Seiring waktu tabel ini akan tumbuh. Meskipun bisnis ritel mungkin menyimpan data penjualan selama 10 tahun terakhir, kueri analitik mungkin hanya perlu menghitung agregat untuk kuartal terakhir. Indeks penyimpan kolom dapat menghilangkan akses data untuk 39 kuartal sebelumnya hanya dengan melihat metadata untuk kolom tanggal. Ini adalah pengurangan tambahan 97% dalam jumlah data yang dibaca ke dalam memori dan diproses.

Grup baris mana yang dilewati dalam pemindaian tabel penuh?

Untuk menentukan grup baris mana yang akan dihilangkan, indeks penyimpan kolom menggunakan metadata untuk menyimpan nilai minimum dan maksimum setiap segmen kolom untuk setiap grup baris. Ketika tidak ada rentang segmen kolom yang memenuhi kriteria predikat kueri, seluruh grup baris dilewati tanpa melakukan IO aktual. Ini berfungsi karena data biasanya dimuat dalam urutan yang diurutkan dan meskipun baris tidak dijamin diurutkan, nilai data serupa sering terletak dalam grup baris yang sama atau grup baris tetangga.

Untuk informasi selengkapnya tentang grup baris, lihat Panduan Desain Indeks Penyimpan Kolom.

Eksekusi Mode Batch

Eksekusi mode batch mengacu pada pemrosesan sekumpulan baris, biasanya hingga 900 baris, bersama-sama untuk efisiensi eksekusi. Misalnya, kueri SELECT SUM (Sales) FROM SalesData menggabungkan total penjualan dari tabel SalesData. Dalam eksekusi mode batch, mesin eksekusi kueri menghitung agregat dalam grup 900 nilai. Ini menyebarkan metadata biaya akses dan jenis overhead lainnya di semua baris dalam batch, daripada membayar biaya untuk setiap baris sehingga secara signifikan mengurangi jalur kode. Pemrosesan mode batch beroperasi pada data terkompresi jika memungkinkan dan menghilangkan beberapa operator pertukaran yang digunakan oleh pemrosesan mode baris. Ini mempercepat eksekusi kueri analitik berdasarkan urutan besarnya.

Tidak semua operator eksekusi kueri dapat dijalankan dalam mode batch. Misalnya, operasi DML seperti Sisipkan, Hapus, atau Perbarui dijalankan baris pada satu waktu. Operator mode batch menargetkan operator untuk mempercepat performa kueri seperti Pemindaian, Gabung, Agregat, urutkan dan sebagainya. Karena indeks penyimpan kolom diperkenalkan di SQL Server 2012 (11.x), ada upaya berkelanjutan untuk memperluas operator yang dapat dijalankan dalam mode batch. Tabel di bawah ini menunjukkan operator yang berjalan dalam mode batch sesuai dengan versi produk.

Operator Mode Batch Kapan ini digunakan? SQL Server 2012 (11.x) SQL Server 2014 (12.x) SQL Server 2016 (13.x) dan SQL Database1 Komentar
Operasi DML (sisipkan, hapus, perbarui, gabungkan) no no no DML bukan operasi mode batch karena tidak paralel. Bahkan ketika kami mengaktifkan pemrosesan batch mode serial, kami tidak melihat keuntungan yang signifikan dengan memungkinkan DML diproses dalam mode batch.
pemindaian indeks penyimpan kolom SCAN Tidak tersedia yes yes Untuk indeks penyimpan kolom, kita dapat mendorong predikat ke simpul SCAN.
Pemindaian indeks penyimpan kolom (tidak terkluster) SCAN yes yes yes yes
pencarian indeks Tidak tersedia Tidak tersedia no Kami melakukan operasi pencarian melalui indeks pohon B nonclustered dalam mode baris.
skalar komputasi Ekspresi yang mengevaluasi ke nilai skalar. yes yes yes Ada beberapa batasan pada jenis data. Ini berlaku untuk semua operator mode batch.
Rangkaian UNION dan UNION ALL no yes yes
filter Menerapkan predikat yes yes yes
kecocokan hash Fungsi agregat berbasis hash, gabungan hash luar, gabungan hash kanan, gabungan hash kiri, gabungan dalam kanan, gabungan dalam kiri yes yes yes Pembatasan untuk agregasi: tidak ada min/maks untuk string. Fungsi agregasi yang tersedia adalah sum/count/avg/min/max.
Pembatasan untuk gabungan: tidak ada gabungan jenis yang tidak cocok pada jenis non-bilangan bulat.
gabungkan gabungan no no no
kueri multi-utas yes yes yes
perulangan berlapis no no no
kueri berutas tunggal yang berjalan di bawah MAXDOP 1 no no yes
kueri berutas tunggal dengan rencana kueri serial no no yes
urutkan Urutan berdasarkan klausa pada SCAN dengan indeks penyimpan kolom. no no yes
sortir atas no no yes
agregat jendela Tidak tersedia Tidak tersedia yes Operator baru di SQL Server 2016 (13.x).

1 Berlaku untuk SQL Server 2016 (13.x), tingkat SQL Database Premium, tingkat Standar - S3 ke atas, dan semua tingkatan vCore, dan Sistem Platform Analitik (PDW)

Untuk informasi selengkapnya, lihat Panduan Arsitektur Pemrosesan Kueri.

Pushdown agregat

Jalur eksekusi normal untuk komputasi agregat untuk mengambil baris yang memenuhi syarat dari simpul SCAN dan menggabungkan nilai dalam Mode Batch. Meskipun ini memberikan performa yang baik, tetapi dengan SQL Server 2016 (13.x), operasi agregat dapat didorong ke node SCAN untuk meningkatkan performa komputasi agregat berdasarkan urutan besarnya di atas eksekusi Mode Batch asalkan kondisi berikut terpenuhi:

  • Agregatnya adalah MIN, , MAXSUM, COUNT dan COUNT(*).
  • Operator agregat harus berada di atas node SCAN atau node SCAN dengan GROUP BY.
  • Agregat ini bukan agregat yang berbeda.
  • Kolom agregat bukan kolom string.
  • Kolom agregat bukan kolom virtual.
  • Jenis data input dan output harus salah satu dari yang berikut ini dan harus pas dalam 64 bit:
    • tinyint, int, bigint, smallint, bit
    • smallmoney, money, decimal dan numeric dengan presisi <= 18
    • smalldate, date, datetime, datetime2, time

Misalnya, pushdown agregat dilakukan di kedua kueri di bawah ini:

SELECT  productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
    
SELECT  SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;

Pushdown predikat string

Saat merancang skema gudang data, pemodelan skema yang direkomendasikan adalah menggunakan skema bintang atau skema snowflake yang terdiri dari satu atau beberapa tabel fakta dan banyak tabel dimensi. Tabel fakta menyimpan pengukuran bisnis atau transaksi dan tabel dimensi menyimpan dimensi di mana fakta perlu dianalisis.

Misalnya, fakta dapat menjadi catatan yang mewakili penjualan produk tertentu di wilayah tertentu sementara dimensi mewakili sekumpulan wilayah, produk, dan sebagainya. Tabel fakta dan dimensi terhubung melalui hubungan kunci primer/asing. Kueri analitik yang paling umum digunakan menggabungkan satu atau beberapa tabel dimensi dengan tabel fakta.

Mari kita pertimbangkan tabel Productsdimensi . Kunci primer umum akan menjadi ProductCode yang umumnya direpresentasikan sebagai jenis data string. Untuk performa kueri, ini adalah praktik terbaik untuk membuat kunci pengganti, biasanya kolom bilangan bulat, untuk merujuk ke baris dalam tabel dimensi dari tabel fakta.

Indeks penyimpan kolom menjalankan kueri analitik dengan gabungan/predikat yang melibatkan kunci berbasis numerik atau bilangan bulat dengan sangat efisien. Namun, dalam banyak beban kerja pelanggan, kami menemukan penggunaan untuk kolom berbasis string yang menautkan tabel fakta/dimensi dan dengan hasilnya performa kueri dengan indeks penyimpan kolom tidak berfungsi. SQL Server 2016 (13.x) meningkatkan performa kueri analitik dengan kolom berbasis string secara signifikan dengan mendorong turun predikat dengan kolom string ke simpul SCAN.

Pushdown predikat string memanfaatkan kamus primer/sekunder yang dibuat untuk kolom untuk meningkatkan performa kueri. Misalnya, mari kita pertimbangkan segmen kolom string dalam grup baris yang terdiri dari 100 nilai string yang berbeda. Ini berarti setiap nilai string yang berbeda dirujuk 10.000 kali rata-rata dengan asumsi 1 juta baris.

Dengan pushdown predikat string, eksekusi kueri menghitung predikat terhadap nilai dalam kamus dan jika memenuhi syarat, semua baris yang mengacu pada nilai kamus secara otomatis memenuhi syarat. Ini meningkatkan performa dengan dua cara:

  1. Hanya baris yang memenuhi syarat yang dikembalikan yang mengurangi jumlah baris yang perlu mengalir keluar dari simpul SCAN.

  2. Jumlah perbandingan string berkurang secara signifikan. Dalam contoh ini, hanya 100 perbandingan string yang diperlukan sebagai terhadap 1 juta perbandingan. Ada beberapa batasan seperti yang dijelaskan di bawah ini:

    • Tidak ada pushdown predikat string untuk grup baris delta. Tidak ada kamus untuk kolom dalam grup baris delta.
    • Tidak ada pushdown predikat string jika kamus melebihi entri 64 KB.
    • EKSPRESI yang mengevaluasi NULL tidak didukung.

Eliminasi segmen

Pilihan jenis data mungkin berdampak signifikan pada predikat filter umum berbasis performa kueri untuk kueri pada indeks penyimpan kolom.

Di data penyimpan kolom, grup baris terdiri dari segmen kolom. Ada metadata dengan setiap segmen untuk memungkinkan eliminasi segmen dengan cepat tanpa membacanya. Penghapusan segmen ini berlaku untuk jenis data numerik, tanggal, dan waktu, dan jenis data datetimeoffset dengan skala kurang dari atau sama dengan dua. Dimulai di SQL Server 2022 (16.x), kemampuan eliminasi segmen diperluas ke jenis data string, biner, guid, dan datetimeoffset untuk skala yang lebih besar dari dua.

Setelah memutakhirkan ke versi SQL Server yang mendukung penghapusan segmen string min/maks (SQL Server 2022 (16.x) dan yang lebih baru), indeks penyimpan kolom tidak akan menguntungkan fitur ini sampai dibangun kembali menggunakan REBUILD atau DROP/CREATE.

Penghapusan segmen tidak berlaku untuk jenis data LOB, seperti panjang jenis data (maks).

Saat ini, hanya SQL Server 2022 (16.x) dan yang lebih baru yang mendukung penghapusan grup baris penyimpan kolom berkluster untuk awalan LIKE predikat, misalnya column LIKE 'string%'. Penghapusan segmen tidak didukung untuk penggunaan non-awalan dari LIKE, seperti column LIKE '%string'.

Di Azure Synapse Analytics dan dimulai dengan SQL Server 2022 (16.x), Anda dapat membuat indeks penyimpan kolom berkluster yang diurutkan, yang memungkinkan pengurutan berdasarkan kolom untuk membantu penghapusan segmen, terutama untuk kolom string. Dalam indeks penyimpan kolom berkluster yang diurutkan, eliminasi segmen pada kolom pertama di kunci indeks paling efektif, karena diurutkan. Perolehan performa karena eliminasi segmen pada kolom lain dalam tabel akan kurang dapat diprediksi. Untuk informasi selengkapnya tentang indeks penyimpan kolom berkluster yang diurutkan, lihat Menggunakan indeks penyimpan kolom berkluster yang diurutkan untuk tabel gudang data besar.

Dengan menggunakan opsi koneksi kueri SET STATISTICS IO, Anda dapat menampilkan eliminasi segmen dalam tindakan. Cari output seperti berikut ini untuk menunjukkan bahwa eliminasi segmen telah terjadi. Grup baris terdiri dari segmen kolom, sehingga ini dapat menunjukkan eliminasi segmen. Contoh output IO SET STATISTICS di bawah ini dari kueri, sekitar 83% data dilewati oleh kueri:

...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...

Langkah berikutnya