Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Dalam artikel ini, kami membahas teknik untuk membantu Anda mengoptimalkan aktivitas Salin dengan sumber database SQL, menggunakan Azure SQL Database sebagai referensi. Kami mencakup berbagai aspek pengoptimalan termasuk kecepatan transfer data, biaya, pemantauan, kemudahan pengembangan, dan penyeimbangan berbagai pertimbangan ini untuk hasil terbaik.
Pilihan Aktivitas Menyalin
Catatan
Metrik yang disertakan dalam artikel ini adalah hasil kasus pengujian yang membandingkan dan kontras perilaku di berbagai kemampuan, dan bukan tolok ukur rekayasa formal. Semua kasus pengujian sedang memindahkan data dari wilayah Timur US 2 ke wilayah Barat US 2.
Saat memulai aktivitas Salin di dalam pipeline, penting untuk memahami sistem sumber dan tujuan sebelum pengembangan dimulai. Anda harus menyatakan apa yang Anda optimalkan, dan memahami cara memantau sumber, tujuan, dan alur untuk mencapai pemanfaatan, performa, dan konsumsi sumber daya terbaik.
Ketika mengambil data dari Azure SQL Database, penting untuk memahami:
- Operasi input/output per detik (IOPS)
- Volume data
- DDL dari satu atau beberapa tabel
- Skema Pembagian
- Kunci Primer atau kolom lain dengan distribusi data yang baik (condong)
- Hitung batasan yang dialokasikan dan terkait seperti jumlah koneksi bersamaan
Hal yang sama berlaku untuk tujuan Anda. Dengan pemahaman tentang keduanya, Anda dapat merancang alur untuk beroperasi dalam batas dan batas sumber dan tujuan sambil mengoptimalkan prioritas Anda.
Catatan
Bandwidth jaringan antara sumber dan tujuan, bersama dengan input/output per detik (IOPS) masing-masing, keduanya dapat menjadi hambatan bagi throughput, dan disarankan untuk memahami batasan-batasan ini. Namun, jaringan tidak berada dalam cakupan artikel ini.
Setelah memahami sumber dan tujuan, Anda dapat menggunakan berbagai opsi dalam aktivitas Salin untuk meningkatkan performanya untuk prioritas Anda. Opsi ini dapat mencakup:
- Opsi pemartisian sumber - Tidak ada, Partisi fisik, Rentang dinamis
- Tingkat isolasi sumber - Tidak ada, Baca tidak berkomitmen, Baca berkomitmen, Cuplikan
- Pengaturan optimalisasi throughput cerdas - Otomatis, Standar, Seimbang, Maksimum
- Pengaturan tingkat paralelisme salinan - Otomatis, Nilai yang Ditentukan
- Partisi logis - Rancangan pipa untuk menghasilkan beberapa aktivitas Salin bersamaan
Detail sumber: Azure SQL Database
Untuk memberikan contoh konkret, kami menguji beberapa skenario, memindahkan data dari Azure SQL Database ke tabel Fabric Lakehouse (tabel) dan Fabric Warehouse. Dalam contoh ini, kami menguji empat tabel sumber. Semua memiliki skema dan jumlah rekaman yang sama. Satu menggunakan tumpukan, yang kedua menggunakan indeks berkluster, sedangkan yang ketiga dan keempat menggunakan 8 dan 85 partisi masing-masing. Contoh ini menggunakan kapasitas uji coba (F64) di Microsoft Fabric (US Barat 2).
- Tingkat Layanan: Tujuan Umum
- Tingkat Komputasi: Tanpa Server
- Konfigurasi Perangkat Keras: Seri standar (Gen5)
- Max vCore: 80
- Minimum vCores 20
- Jumlah Catatan: 1.500.000.000
- Wilayah: US Timur 2
Evaluasi Default
Sebelum mengatur opsi Partisi sumber, penting untuk memahami perilaku default aktivitas Salin.
Pengaturan default adalah:
Sumber
- Opsi Partisi - Tidak ada
- Tingkat Isolasi - Tidak Ada
Pengaturan tingkat lanjut
- Pengoptimalan lalu lintas cerdas - Otomatis
- Tingkat paralelisme salinan - Otomatis
Untuk tujuan pengaturan tolok ukur awal untuk perbandingan di masa mendatang, kami menggunakan pengaturan default untuk eksekusi aktivitas salin yang memuat 1,5 miliar rekaman ke setiap tujuan dan membutuhkan waktu sedikit lebih dari 2 jam per aktivitas salin.
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Gudang Kain | Tidak | Otomatis | 1 | 02:23:21 |
| Fabric Lakehouse | Tidak | Otomatis | 1 | 02:10:37 |
Dalam artikel ini, kami berfokus pada durasi total. Total durasi mencakup tahapan lain seperti antrean, skrip prakopi, dan durasi transfer. Untuk informasi selengkapnya tentang tahapan ini, lihat detail eksekusi aktivitas penyalinan. Untuk mendapatkan gambaran umum ekstensif tentang properti aktivitas Salin dengan Azure SQL Database sebagai sumber, lihat properti sumber Azure SQL Database untuk aktivitas Salin.
Pengaturan
Pengoptimalan throughput cerdas (ITO)
ITO menentukan jumlah maksimum Alokasi sumber daya CPU, memori, dan jaringan yang dapat dikonsumsi aktivitas. Jika Anda mengatur ITO ke Maksimum (atau 256), layanan memilih nilai tertinggi yang menyediakan throughput yang paling dioptimalkan. Dalam artikel ini, semua kasus pengujian mengatur ITO ke Maksimum, meskipun layanan hanya menggunakan apa yang diperlukan dan nilai aktual lebih rendah dari 256.
Untuk pemahaman yang lebih mendalam tentang ITO, lihat Pengoptimalan throughput yang cerdas.
Catatan
Pengaturan tahap diperlukan ketika tujuan aktivitas Penyalinan adalah Fabric Warehouse. Opsi seperti Tingkat Paralelisme Penyalinan dan Pengoptimalan Throughput Cerdas hanya berlaku pada kasus ini dari Sumber ke Penahapan. Kasus uji terkait Lakehouse tidak memiliki tahap penahapan yang diaktifkan.
Opsi partisi
Saat sumber Anda adalah database relasional seperti database Azure SQL, di bagian Tingkat Lanjut , Anda dapat menentukan opsi Partisi. Secara default, pengaturan ini diatur ke Tidak Ada, dengan dua opsi lain dari partisi Fisik tabel dan Rentang Dinamis.
Rentang dinamis
Tabel timbunan
Rentang Dinamis memungkinkan layanan untuk secara cerdas menghasilkan kueri terhadap sumbernya. Jumlah kueri yang dihasilkan sama dengan jumlah salinan paralel yang digunakan layanan yang dipilih saat runtime. Tingkat paralelisme salinan dan salinan paralel yang digunakan penting untuk dipertimbangkan saat mengoptimalkan penggunaan opsi partisi Rentang dinamis.
Batas pemisahan
Batas atas dan bawah Partisi adalah bidang opsional yang memungkinkan Anda menentukan langkah partisi. Dalam kasus pengujian ini, kami telah menentukan batas atas dan bawah. Jika bidang ini tidak ditentukan, sistem menimbulkan overhead ekstra dalam mengkueri sumber untuk menentukan rentang. Untuk performa optimal, dapatkan batasan sebelumnya, terutama untuk beban historis satu kali.
Untuk informasi selengkapnya, lihat tabel di bagian Salinan Paralel dari Database SQL dalam artikel konektor Azure SQL Database.
Kueri SQL berikut menentukan rentang min dan maks kami:
Kemudian kami memberikan detail tersebut dalam konfigurasi Rentang dinamis.
Berikut adalah contoh kueri yang dihasilkan oleh aktivitas Salin menggunakan Rentang dinamis:
SELECT * FROM [dbo].[orders] WHERE [o_orderkey] > '4617187501' AND [o_orderkey] <= '4640625001'
Tingkat paralelisme salinan
Secara bawaan, Otomatis ditetapkan untuk Tingkat paralelisme penyalinan. Namun, Otomatis mungkin tidak mencapai jumlah salinan paralel yang optimal. Salinan paralel berkorelasi dengan jumlah sesi yang ditetapkan pada database sumber. Jika terlalu banyak salinan paralel yang dihasilkan, CPU database sumber berisiko terlalu terbebani, yang menyebabkan kueri menjadi tertunda.
Dalam kasus pengujian asli untuk Rentang dinamis menggunakan Otomatis, layanan benar-benar menghasilkan 251 salinan paralel pada runtime. Dengan menentukan nilai dalam Tingkat paralelisme salinan, Anda mengatur jumlah maksimum salinan paralel. Pengaturan ini memungkinkan Anda membatasi jumlah sesi bersamaan yang dibuat ke sumber Anda, memungkinkan Anda mengontrol manajemen sumber daya dengan lebih baik. Dalam kasus pengujian ini, dengan menentukan 50 sebagai nilai, durasi total dan pemanfaatan sumber daya sumber ditingkatkan.
| Tujuan | Pilihan Partisi | Tingkat paralelisme salinan | Penggunaan Salinan Paralel | Total Durasi |
|---|---|---|---|---|
| Gudang Kain | Tidak | Otomatis | 1 | 02:23:21 |
| Gudang Kain | Rentang Dinamis | 50 | 50 | 00:13:05 |
Rentang dinamis dengan Derajat salinan paralel dapat secara signifikan meningkatkan kinerja. Namun, menggunakan pengaturan memerlukan batas yang telah ditentukan sebelumnya atau memungkinkan layanan menentukan nilai pada runtime. Mengizinkan layanan menentukan nilai selama waktu eksekusi dapat memengaruhi lama waktu keseluruhan, tergantung pada DDL dan volume data dari tabel sumber. Selain itu, memungkinkan layanan untuk menentukan nilai pada runtime juga harus dipasangkan dengan pemahaman tentang berapa banyak salinan paralel yang dapat ditangani sumber Anda. Jika nilainya terlalu tinggi, performa sistem sumber dan aktivitas penyalinan dapat menurun.
Untuk informasi selengkapnya tentang fitur salinan paralel, lihat Fitur performa aktivitas menyalin: Salinan paralel.
Gudang Kain dengan Variasi Dinamis
Secara default, tingkat Isolasi tidak ditentukan, dan Tingkat paralelisme diatur ke Otomatis.
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Gudang Kain | Tidak | Otomatis | 1 | 02:23:21 |
| Gudang Kain | Rentang Dinamis | Otomatis | 251 | 00:39:03 |
Fabric Lakehouse (Tabel) dengan rentang dinamis
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Fabric Lakehouse | Tidak | Otomatis | 1 | 02:23:21 |
| Fabric Lakehouse | Rentang Dinamis | Otomatis | 251 | 00:36:40 |
| Fabric Lakehouse | Rentang Dinamis | 50 | 50 | 00:12:01 |
Indeks dalam kluster
Dibandingkan dengan tabel tumpukan, tabel dengan indeks kunci berkluster pada kolom yang dipilih untuk kolom partisi rentang dinamis meningkatkan performa dan pemanfaatan sumber daya secara drastis. Ini benar bahkan ketika tingkat paralelisme salinan diatur ke otomatis.
Fabric Warehouse dengan indeks berkluster
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Gudang Kain | Tidak | Otomatis | 1 | 02:23:21 |
| Gudang Kain | Rentang Dinamis | Otomatis | 251 | 00:09:02 |
| Gudang Kain | Rentang Dinamis | 50 | 50 | 00:08:38 |
Fabric Lakehouse (Tabel) dengan indeks berkluster
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Fabric Lakehouse | Tidak | Otomatis | 1 | 02:23:21 |
| Fabric Lakehouse | Rentang Dinamis | Otomatis | 251 | 00:06:44 |
| Fabric Lakehouse | Rentang Dinamis | 50 | 50 | 00:06:34 |
Desain partisi logis
Pola desain partisi logis lebih maju dan membutuhkan lebih banyak upaya pengembang. Namun, desain ini digunakan dalam skenario dengan persyaratan pemuatan data yang ketat. Desain ini awalnya dikembangkan untuk memenuhi kebutuhan database Oracle lokal untuk memuat data 180 GB dalam waktu kurang dari 1,5 jam. Desain asli, menggunakan default aktivitas salin, memakan waktu lebih dari 65 jam. Dengan menggunakan Desain Pemartisian Logis, kami melihat data yang sama ditransfer dalam waktu kurang dari 1,5 jam.
Desain ini juga digunakan dalam seri blog ini: Peningkatan performa alur Bagian 1: Cara mengonversi interval waktu menjadi detik). Desain ini baik untuk ditiru di lingkungan Anda saat Anda memuat tabel sumber besar dan membutuhkan performa pemuatan yang optimal dengan menggunakan teknik seperti mengatur rentang data untuk mempartisi bacaan data sumber. Desain ini menghasilkan banyak rentang subdate. Kemudian menggunakan aktivitas For-Each untuk melakukan iterasi melalui rentang, banyak aktivitas salin dijalankan untuk menyalin data dari rentang yang ditentukan. Dalam aktivitas For-Each, semua aktivitas salin berjalan secara paralel (hingga jumlah batch maksimum 50) dan memiliki tingkat paralelisme salinan yang diatur ke Otomatis.
Untuk contoh di bawah ini, nilai tanggal yang dipartisi diatur ke nilai-nilai ini:
- Nilai awal: 1992-01-01
- Nilai akhir: 1998-08-02
- Jumlah Hari Interval Bucket: 50
Salinan paralel dan durasi total adalah nilai maksimum yang diamati di antara semua 50 aktivitas penyalinan yang dibuat. Karena semua 50 kegiatan berjalan secara paralel, durasi total maksimum adalah durasi yang dibutuhkan untuk menyelesaikan semua aktivitas penyalinan secara paralel.
Fabric Warehouse dengan desain partisi logis
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Gudang Kain | Tidak | Otomatis | 1 | 02:23:21 |
| Gudang Kain | Desain Logis | Otomatis | 1 | 00:12:11 |
Fabric Lakehouse (Tabel) dengan desain partisi yang logis
| Tujuan | Pilihan Partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Fabric Lakehouse | Tidak | Otomatis | 1 | 02:10:37 |
| Fabric Lakehouse | Desain Logis | Otomatis | 1 | 00:09:14 |
Partisi fisik tabel
Catatan
Saat menggunakan partisi fisik, kolom dan mekanisme partisi akan secara otomatis ditentukan berdasarkan definisi tabel fisik Anda.
Untuk menggunakan partisi fisik tabel, tabel sumber harus dipartisi. Untuk memahami bagaimana jumlah partisi memengaruhi performa, kami membuat dua tabel yang dipartisi, satu dengan 8 partisi dan yang lainnya dengan 85 partisi.
Jumlah partisi fisik membatasi Tingkat paralelisme salinan. Anda masih dapat membatasi angka dengan menentukan nilai yang kurang dari jumlah partisi.
Fabric Warehouse dengan partisi fisik
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang digunakan | Durasi total |
|---|---|---|---|---|
| Gudang Kain | Tidak | Otomatis | 1 | 02:23:21 |
| Gudang Kain | Fisik | Otomatis | 8 | 00:26:29 |
| Gudang Kain | Fisik | Otomatis | 85 | 00:08:31 |
Fabric Lakehouse (Tabel) dengan partisi fisik
| Tujuan | Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total |
|---|---|---|---|---|
| Fabric Lakehouse | Tidak | Otomatis | 1 | 02:10:37 |
| Fabric Lakehouse | Fisik | Otomatis | 8 | 00:36:36 |
| Fabric Lakehouse | Fisik | Otomatis | 85 | 00:12:21 |
Tingkat isolasi
Mari kita bandingkan bagaimana menentukan pengaturan tingkat Isolasi yang berbeda memengaruhi performa. Saat Anda memilih Isolation level dengan Degree of copy parallelism diatur ke Otomatis, aktivitas Salin berisiko membebani sistem sumber dan gagal. disarankan untuk membiarkan Tingkat Isolasi sebagai Tidak Ada jika Anda ingin membiarkan Derajat paralelisme penyalinan diatur ke Otomatis.
Catatan
Azure SQL Database secara default ke tingkat *Isolasi Read_Committed_Snapshot.
Mari kita perluas kasus pengujian untuk Rentang dinamis dengan Tingkat paralelisme salinan diatur ke 50 dan melihat bagaimana Tingkat isolasi memengaruhi performa.
| Tingkat isolasi | Durasi total | Unit Kapasitas | DB Maks CPU % | Maksimum Sesi DB |
|---|---|---|---|---|
| Tidak ada (default) | 00:14:23 | 93,960 | 70 | 76 |
| Baca Belum Dikonfirmasi | 00:13:46 | 89,280 | 81 | 76 |
| Read Committed (Dibaca Terikat) | 00:25:34 | 97,560 | 81 | 76 |
Tingkat Isolasi yang Anda pilih untuk kueri sumber database Anda akan lebih merupakan persyaratan daripada jalur pengoptimalan, namun penting untuk memahami perbedaan performa dan konsumsi Unit Kapasitas di antara setiap opsi.
Untuk informasi selengkapnya tentang tingkat Isolasi,** lihat IsolationLevel Enum.
ITO dan konsumsi kapasitas
Mirip dengan Derajat salinan paralel, Pengoptimalan throughput cerdas (ITO) adalah nilai maksimum lain yang dapat diatur. Jika Anda mengoptimalkan biaya, ITO adalah pengaturan yang bagus untuk dipertimbangkan penyesuaiannya guna mencapai hasil yang Anda inginkan.
Rentang ITO:
| ITO | Nilai Maksimum |
|---|---|
| Otomatis | Tidak ditentukan |
| Standard | 64 |
| Seimbang | 128 |
| Maksimum | 256 |
Meskipun drop-down memungkinkan pengaturan di atas, kami juga mengizinkan penggunaan nilai kustom antara 4 dan 256.
Catatan
Jumlah aktual ITO yang digunakan dapat ditemukan di output aktivitas Salin pada bidang usedDataIntegrationUnits.
Untuk kasus uji Heap rentang Dinamis di mana Derajat salinan Paralel diatur ke Auto, layanan memilih Balanced dengan nilai aktual 100. Mari kita lihat apa yang terjadi ketika ITO dipotong menjadi dua dengan menentukan Nilai Kustom 50:
| ITO ditentukan | Durasi total | Unit Kapasitas | DB Maks CPU % | Maksimum Sesi DB | Menggunakan throughput yang dioptimalkan |
|---|---|---|---|---|---|
| Maksimum (256) | 00:13:46 | 89,280 | 81 | 76 | Seimbang (100) |
| 50 | 00:18:28 | 48,600 | 76 | 61 | Standar (48) |
Dengan memotong ITO sebesar 50%, total durasi meningkat sebesar 34%, namun layanan menggunakan Unit Kapasitas 45,5% lebih sedikit. Jika Anda tidak mengoptimalkan untuk durasi Total yang ditingkatkan dan ingin mengurangi Unit Kapasitas yang digunakan, akan bermanfaat untuk mengatur ITO ke nilai yang lebih rendah.
Ringkasan
Bagan berikut meringkas perilaku pemuatan ke dalam tabel Fabric Warehouse dan Fabric Lakehouse. Jika tabel memiliki partisi fisik, maka menggunakan opsi Partisi: Partisi fisik tabel akan menjadi pendekatan yang paling seimbang untuk durasi transfer, unit kapasitas, dan overhead komputasi pada sumber daya. Pengaturan ini sangat ideal jika Anda memiliki lebih banyak sesi yang berjalan terhadap database selama waktu pergerakan data.
Jika tabel Anda tidak memiliki partisi fisik, Anda masih memiliki opsi untuk menggunakan opsi Partisi: Rentang Dinamis. Opsi ini akan memerlukan langkah sebelumnya untuk menentukan batas atas dan bawah, tetapi masih memberikan peningkatan durasi transfer yang signifikan dibandingkan dengan opsi default dengan biaya konsumsi kapasitas yang sedikit lebih tinggi, pemanfaatan komputasi sumber, dan kebutuhan untuk menguji Tingkat paralelisme yang optimal.
Faktor penting lainnya untuk memaksimalkan performa pekerjaan penyalinan Anda adalah menjaga pergerakan data di dalam satu wilayah cloud. Misalnya, pergerakan data antara penyimpanan data sumber dan penyimpanan data tujuan di AS Barat, dengan pabrik data di AS Barat, mengungguli tugas penyalinan yang memindahkan data dari AS Timur ke AS Barat.
Terakhir, jika kecepatan adalah aspek pengoptimalan yang paling penting, memiliki DDL yang dioptimalkan dari tabel sumber Anda sangat penting dalam menggunakan opsi partisi fisik. Untuk tabel yang tidak dipartisi, coba Rentang dinamis, dan pengaturan ini tidak cukup cepat, pertimbangkan partisi logis atau pendekatan hibrid partisi logis ditambah rentang Dinamis dalam subbatas.
Panduan
Penyesuaian Biaya Pengoptimalan throughput cerdas dan Derajat Salinan Paralel. Kecepatan Untuk tabel yang dipartisi, jika ada sejumlah partisi yang baik, gunakan opsi Partisi: Partisi fisik tabel. Jika tidak, jika data condong atau ada sejumlah partisi terbatas, pertimbangkan untuk menggunakan Rentang Dinamis. Untuk heap dan tabel dengan indeks, gunakan Rentang Dinamis dengan Derajat Salinan Paralel yang akan membatasi jumlah kueri yang ditangguhkan pada sumber Anda. Jika Anda dapat menentukan batas atas/bawah partisi, Anda dapat mewujudkan peningkatan performa lebih lanjut.
Pertimbangkan keberlanjutan dan upaya pengembang. Saat meninggalkan opsi default membutuhkan waktu paling lama untuk memindahkan data, berjalan dengan default mungkin merupakan opsi terbaik, terutama jika DDL tabel sumber tidak diketahui. Ini juga menyediakan konsumsi Unit Kapasitas yang wajar.
Kasus uji
Kasus pengujian Gudang Kain
| Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total | Unit Kapasitas | CPU Maks % | Jumlah Sesi Maks |
|---|---|---|---|---|---|---|
| Tidak | Otomatis | 1 | 02:23:21 | 51,839 | < 1 | 2 |
| Fisik (8) | Otomatis | 8 | 00:26:29 | 49,320 | 3 | 10 |
| Fisik (85) | Otomatis | 85 | 00:08:31 | 108.000 | 15 | 83 |
| Rentang Dinamis (Heap) | Otomatis | 242 | 00:39:03 | 282,600 | 100 | 272 |
| Rentang Dinamis (Heap) | 50 | 50 | 00:13:05 | 92,159 | 81 | 76 |
| Rentang Dinamis (Indeks Berkluster) | Otomatis | 251 | 00:09:02 | 64,080 | 9 | 277 |
| Rentang Dinamis (Indeks Berkluster) | 50 | 50 | 00:08:38 | 55,440 | 10 | 77 |
| Desain Logis | Otomatis | 1 | 00:12:11 | 226,108 | 91 | 50 |
Kasus pengujian Fabric Lakehouse (Tables)
| Opsi partisi | Tingkat paralelisme salinan | Salinan paralel yang sudah digunakan | Durasi total | Unit Kapasitas | CPU Maks % | Jumlah Sesi Maks |
|---|---|---|---|---|---|---|
| Tidak | Otomatis | 1 | 02:10:37 | 47,520 | <1% | 2 |
| Fisik (8) | Otomatis | 8 | 00:36:36 | 64,079 | 2 | 10 |
| Fisik (85) | Otomatis | 85 | 00:12:21 | 275,759 | ||
| Rentang Dinamis (Heap) | Otomatis | 251 | 00:36:12 | 280,080 | 100 | 276 |
| Rentang Dinamis (Heap) | 50 | 50 | 00:12:01 | 101,159 | 68 | 76 |
| Rentang Dinamis (Indeks Berkluster) | Otomatis | 251 | 00:06:44 | 59,760 | 11 | 276 |
| Rentang Dinamis (Indeks Berkluster) | 50 | 50 | 00:06:34 | 54,760 | 10 | 76 |
| Desain Logis | Otomatis | 1 | 00:09:14 | 164,908 | 82 | 50 |
Konten terkait
- Cara menyalin data menggunakan aktivitas salin
- Panduan performa dan skalabilitas aktivitas penyalinan
- Menyalin dan mengubah data di Azure SQL Database
- Mengonfigurasi Azure SQL Database dalam aktivitas salin
- Membuat tabel dan indeks yang dipartisi di Azure SQL Database
- Microsoft Fabric Blog: Peningkatan performa alur bagian 3 - Mendapatkan lebih dari 50% peningkatan untuk beban historis