Diagnostik di SQL Server membantu mendeteksi macet dan terjebak pengoperasian I/O

PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.

Klik disini untuk melihat versi Inggris dari artikel ini: 897284
Ringkasan
sistem manajemen database (DBMS), seperti misalnya SQL Server, bergantung pada data file input dan output (I/O) operasi. Salah satu dari item berikut ini dapat menyebabkan pengoperasian I/O terjebak atau macet dan sangat mempengaruhi SQL Server tanggapan dan kinerja:

  • peranti penangkap keras yang rusak
  • Salah konfigurasi peranti penangkap keras
  • Pengaturan firmware
  • Pengandar filter
  • Kompresi
  • Bug
  • Kondisi lain di lintasan I/O
Masalah I/O ini dapat menyebabkan perilaku berikut terjadi:

  • Pemblokiran
  • Sanggahan kait dan waktu habis
  • Waktu respons yang lambat
  • Peregangan batas sumber daya
Mulai Microsoft SQL Server 2000 Service Pack 4 (SP4), SQL Server termasuk logika yang membantu mendeteksi macet dan terjebak kondisi database I/O membaca dan menulis dan berkas log I/O membaca dan menulis. Ketika operasi I/O telah ditunda selama 15 menit atau lebih, SQL Server melakukan langkah-langkah berikut ini:

  1. Mendeteksi bahwa operasi telah ditunda
  2. Menulis pesan informasi untuk log galat SQL Server

    Teks dari pesan log yang menyerupai berikut ini:

    2004-11-11 00:21:25.26 spid1 SQL Server telah mengalami 192 occurrence(s) IO permintaan memakan waktu lebih lama daripada 15 menit untuk menyelesaikan pada berkas [E:\SEDATA\stressdb5.ndf] dalam database stressdb (7). Menangani berkas OS adalah 0x00000000000074D4. Offset IO panjang terbaru: 0x00000000022000 ".

Penjelasan pesan informasi

perpesanan teksDeskripsi
Nomor > occurrence(s)Jumlah permintaan I/O yang tidak selesai membaca atau menulis operasi dalam kurang dari 15 menit.
Informasi fileNama lengkap file, database nama, dan nomor identifikasi (DBID) pangkalan data.
Menanganisistem operasi menangani berkas. Anda dapat menggunakan menangani sistem operasi dengan debugger atau dengan utilitas lain untuk membantu melacak permintaan I/O (IRP) paket permintaan.
OffsetOffset terakhir terjebak pengoperasian I/O atau terakhir terhenti I/O operasi. Anda dapat menggunakan offset dengan debugger atau dengan utilitas lain untuk membantu melacak IRP permintaan.

Catatan Saat pesan informasi ditulis ke log galat SQL Server, operasi I/O mungkin tidak lagi macet atau macet.
Pesan informasi ini menunjukkan bahwa beban saat ini mungkin mengalami salah satu dari kondisi berikut ini:

  • Beban kerja melebihi kemampuan garis jatuh berseri I/O.
  • Beban kerja melebihi kemampuan sistem saat ini.
  • garis jatuh berseri I/O telah mengalami malfungsi peranti penangkap lunak; mungkin firmware atau masalah pengandar.
  • garis jatuh berseri I/O telah mengalami malfungsi komponen peranti penangkap keras.
Untuk informasi lebih lanjut tentang SQL Server 2000 I/O pola, kunjungi website Microsoft berikut:Catatan TechNet artikel ini juga berlaku untuk Microsoft SQL Server 2005 dan versi yang lebih baru.
Informasi lebih lanjut

I/O terjebak dan I/O macet

Terjebak I/O

Terjebak I/O didefinisikan sebagai permintaan I/O yang tidak selesai. Seringkali, terjebak I/O menunjukkan IRP terjebak. Untuk menyelesaikan kondisi I/O terjebak, biasanya Anda harus me-restart komputer atau melakukan tindakan yang sama. Kondisi I/O terjebak biasanya menunjukkan salah satu dari berikut ini:

  • peranti penangkap keras yang rusak
  • Bug dalam komponen garis jatuh berseri I/O

I/O macet

Macet I/O didefinisikan sebagai permintaan I/O yang menyelesaikan atau yang memerlukan banyak waktu untuk menyelesaikan. Macet I/O perilaku ini biasanya terjadi karena salah satu dari alasan berikut ini:

  • Konfigurasi peranti penangkap keras
  • Pengaturan firmware
  • Masalah pengandar filter yang memerlukan bantuan dari peranti penangkap keras atau vendor peranti penangkap lunak untuk melacak dan menyelesaikan

SQL Server macet I/O dan terjebak I/O perekaman dan pelaporan

Dukungan Microsoft SQL Server menangani banyak kasus setiap tahunnya yang melibatkan masalah I/O terjebak atau macet. Masalah I/O ini muncul dengan cara yang berbeda. Masalah I/O beberapa masalah yang paling sulit untuk mendiagnosis dan debug, dan mereka memerlukan waktu dan sumber daya untuk debugging dari Microsoft dan pelanggan. Fitur pelaporan yang telah ditambahkan ke SQL Server 2000 SP4 dan versi yang lebih baru secara signifikan mengurangi waktu yang diperlukan untuk mengidentifikasi masalah I/O.

Pelaporan dan perekaman permintaan I/O dirancang secara per berkas. Deteksi dan pelaporan permintaan I/O macet dan terjebak adalah dua tindakan yang terpisah.

Rekaman

Ada dua saat saat merekam tindakan yang terjadi di SQL Server. Pertama adalah ketika operasi I/O benar-benar selesai. Jika permintaan I/O memerlukan waktu lebih dari 15 menit untuk menyelesaikan, operasi data yang terjadi. Saat kedua adalah ketika penulis malas berjalan. Ketika menjalankan malas penulis, penulis malas memeriksa semua data yang ditunda dan semua log ditunda permintaan I/O berkas. Jika melampaui ambang 15-kedua, operasi data yang terjadi.

Pelaporan

Pelaporan terjadi dalam interval yang 5 menit atau lebih terpisah. Pelaporan terjadi ketika permintaan I/O selanjutnya dibuat pada berkas. Jika tindakan data telah terjadi dan 5 menit atau lebih telah berlalu sejak terakhir laporan terjadi, informasi pesan yang disebutkan di bagian "Ringkasan" ditulis ke log galat SQL Server.

15-kedua ambang bukanlah disesuaikan. Namun, Anda dapat menonaktifkan macet atau terjebak I/O deteksi dengan menggunakan bendera pelacakan 830, meskipun kami tidak menyarankan Anda melakukannya.

Untuk menonaktifkan deteksi ketika SQL Server dimulai, gunakan -T830 parameter permulaan untuk menonaktifkan deteksi setiap kali SQL Server dimulai. Untuk menonaktifkan deteksi contoh SQL Server yang sedang berjalan, gunakan pernyataan berikut ini:

DBCC traceoff (830, -1)
Pengaturan ini sangat efektif untuk hidup proses SQL Server.

Catatan Permintaan I/O yang menjadi macet atau macet dilaporkan hanya satu kali. Misalnya, jika pesan melaporkan bahwa permintaan I/O 10 macet, laporan 10 tersebut tidak akan terjadi lagi. Jika pesan berikutnya melaporkan bahwa permintaan I/O 15 macet, ini berarti bahwa permintaan I/O baru 15 menjadi macet.

Pelacakan paket permintaan I/O (IRP)

SQL Server menggunakan Microsoft Windows API panggilan standar untuk membaca dan menulis data. Sebagai contoh, SQL Server menggunakan fungsi berikut ini:

  • WriteFile
  • ReadFile
  • WriteFileScatter
  • ReadFileGather
Membaca atau menulis permintaan ditangani oleh Windows sebagai paket permintaan I/O (IRP). Untuk menentukan status IRP, gunakan kedua berikut:

  • Bantuan dukungan Platform Microsoft
  • Kernel debugger
Untuk informasi selengkapnya tentang IRP dan IRP pelacakan, lanjutkan ke pencarian kata bukti kunci "IRP" dan situs web Microsoft berikut ini:Catatan Kernel debugging dapat proses invasif karena kernel debugging dapat mengharuskan Anda untuk menghentikan sistem untuk menyelesaikan tindakan debugging. Kami sarankan Anda memeriksa untuk pemutakhiran yang tersedia untuk item berikut ini:

  • BIOS
  • Firmware
  • Komponen garis jatuh berseri I/O lainnya
Hubungi vendor peranti penangkap keras Anda sebelum Anda melakukan tindakan debug tambahan. Sesi debug mungkin meliputi pengandar pihak ketiga, firmware, atau komponen filter pengandar.

Kinerja sistem dan permintaan rencana tindakan

Keseluruhan kinerja sistem dapat memainkan peran bukti kunci I/O diproses. Anda harus mempertimbangkan kesehatan umum sistem ketika Anda sedang menginvestigasi laporan pengoperasian I/O macet atau terjebak. Beban berlebihan dapat menyebabkan keseluruhan sistem menjadi lambat. Ini termasuk I/O pemrosesan. Perilaku sistem pada waktu yang bermasalah dapat faktor bukti kunci dalam menentukan penyebab masalah. Sebagai contoh, jika penggunaan CPU menjadi tinggi atau penggunaan CPU tetap tinggi ketika masalah terjadi, perilaku ini dapat menunjukkan bahwa proses pada sistem menggunakan banyak CPU bahwa proses lainnya yang yang terpengaruh.

Penghitung kinerja

Untuk mengawasi kinerja I/O, periksa penghitung kinerja berikut untuk informasi garis jatuh berseri I/O khusus:

  • Rata-rata Disk Sec/Transfer
  • Rata-rata Disk antrian panjang
  • Saat ini Disk antrian panjang
Misalnya, waktu rata-rata Disk Sec/Transfer di komputer yang menjalankan SQL Server adalah biasanya kurang dari 15 milidetik. Jika nilai rata-rata Disk Sec/Transfer naik, ini menunjukkan bahwa subsistem I/O yang tidak secara optimal menjaga dengan permintaan I/O.

Hati-hati saat Anda menggunakan penghitung kinerja karena SQL Server mengambil manfaat penuh dari asinkron I/O kemampuan yang push disk antrian panjang berat. Oleh karena itu, lama disk antrian panjang sendiri tidak menunjukkan ada masalah.

Pada Monitor sistem Windows, Anda dapat meninjau penghitung "Disk fisik: Disk byte/detik" untuk setiap terpengaruh disk dan membandingkan tingkat aktivitas terhadap penghitung "proses: IO Data byte/detik" dan "proses: IO lainnya byte/detik" untuk setiap proses untuk mengidentifikasi apakah pengaturan khusus proses yang menghasilkan berlebihan I/O permintaan. Ada berbagai I/O terkait penghitung tersedia dalam proses objek yang mengungkapkan informasi yang lebih rinci. Jika Anda menentukan bahwa contoh SQL Server tidak bertanggung jawab untuk berlebihan IO beban di server, baca Bagian berikutnya pada "Indeks dan paralelisme". Untuk rincian diskusi mendeteksi dan memecahkan I/O kertas macet, Baca bagian "I/O kemacetan" dalam laporan MSDN Memecahkan masalah kinerja pada SQL Server 2008 atau Memecahkan masalah kinerja pada SQL Server 2005.

Indeks dan paralelisme

Seringkali, pecah I/O terjadi karena indeks hilang. Perilaku ini dapat sangat push garis jatuh berseri I/O. Akses yang menggunakan indeks mengaktifkan Wisaya (ITW) dapat membantu menyelesaikan I/O tekanan pada sistem. Jika permintaan manfaat dari indeks bukannya Daftar Tabel scan, atau mungkin jika menggunakan Urutkan atau hash, sistem dapat memperoleh keuntungan sebagai berikut:

  • Pengurangan yang dibuat di I/O fisik yang diperlukan untuk menyelesaikan tindakan yang langsung dibuat kinerja keuntungan untuk permintaan.
  • Lebih sedikit halaman dalam data cache harus diaktifkan. Oleh karena itu, halaman-halaman yang ada di data cache tetap relevan dengan permintaan aktif.
  • Jenis dan hash digunakan karena indeks mungkin hilang atau karena Statistik sudah ketinggalan zaman. Anda dapat mengurangi Code penggunaan dan sanggahan dengan menambahkan indeks satu atau lebih.
  • Pengurangan membuat sumber daya, operasi paralel, atau keduanya. Karena SQL Server tidak menjamin eksekusi query paralel, dan karena dianggap sebagai beban pada sistem, terbaik untuk mengoptimalkan semua permintaan untuk serial eksekusi. Untuk mengoptimalkan permintaan, buka Query Analyzer dan mengatur nilai sp_configure dari tingkat maks paralelisme opsi untuk 1. Jika semua permintaan disetel untuk menjalankan segera sebagai operasi serial, paralel eksekusi ini sering hasil yang lebih baik. Namun, berkali-kali paralel eksekusi dipilih karena jumlah data cukup besar. Indeks hilang, semacam besar mungkin harus terjadi. Beberapa pekerja yang melakukan operasi Urutkan akan membuat respons lebih cepat. Namun, tindakan ini dapat secara drastis meningkatkan tekanan pada sistem. Besar membaca permintaan dari banyak pekerja dapat menyebabkan I/O meledak bersama-sama dengan peningkatan penggunaan CPU dari beberapa pekerja. Berkali-kali permintaan dapat disetel untuk berjalan lebih cepat dan menggunakan lebih sedikit sumber daya jika Indeks ditambahkan atau tindakan lain tuning terjadi.

Contoh-contoh praktis dari dukungan Microsoft SQL Server

Contoh berikut ini telah ditangani oleh dukungan Microsoft SQL Server dan platform eskalasi dukungan. Contoh ini dimaksudkan untuk memberikan rujukan dan bantuan set harapan Anda tentang macet dan terjebak I/O situasi dan tentang bagaimana sistem akan terpengaruh atau dapat merespons. Ada peranti penangkap keras tertentu atau serangkaian pengandar yang menimbulkan risiko tertentu atau peningkatan risiko lain. Semua sistem yang sama dalam hal ini.

Contoh 1: Log penulisan yang terjebak selama 10 detik

Usaha untuk menulis berkas log SQL Server secara berkala menjadi terjebak untuk sekitar 10 detik. Tulis log tidak selesai secara tepat waktu. Perilaku ini membuat kondisi pemblokiran yang menyebabkan klien 30 detik waktu habis.

Aplikasi dikirim berkomitmen untuk SQL Server, dan commit menjadi terjebak sebagai menulis log ditunda. Perilaku ini menyebabkan permintaan untuk melanjutkan memegang bukti kunci dan untuk memblokir permintaan yang masuk dari klien lainnya. Kemudian, klien lainnya mulai waktu habis. Ini senyawa masalah karena aplikasi tidak gulung balik transaksi terbuka saat terjadi waktu habis permintaan. Ini membuat ratusan membuka transaksi yang memegang bukti kunci. Oleh karena itu, situasi memblokir parah terjadi.

Untuk informasi selengkapnya tentang transaksi penanganan dan memblokir, lihat artikel Pangkalan Pengetahuan Microsoft berikut ini:Aplikasi layanan situs web dengan menggunakan sambungan penggabungan. Karena lebih banyak koneksi menjadi diblokir, situs web menciptakan lebih banyak koneksi. Sambungan ini akan diblokir, dan Lingkaran Berkelanjutan berlanjut.

Setelah kira-kira 45 detik, tulis log selesai. Namun, saat ini, ratusan sambungan yang didukung. Masalah pemblokiran menyebabkan beberapa menit waktu pemulihan untuk SQL Server dan aplikasi. Dikombinasikan dengan masalah aplikasi, kondisi I/O macet berpengaruh sangat negatif pada sistem.
Pemecahan masalah
Masalah ini dilacak ke permintaan I/O terjebak di pengandar adaptor Bus Host (HBA). Komputer memiliki banyak HBA Kartu Bisnis dengan dukungan kegagalan. Ketika satu HBA di belakang atau tidak berkomunikasi dengan jaringan Area penyimpanan (SAN), nilai batas waktu "coba lagi sebelum kegagalan" dikonfigurasi untuk 10 detik. Saat batas waktu terlewati, permintaan I/O diarahkan ke HBA kedua. HBA kedua menangani permintaan dan cepat selesai. Untuk membantu mencegah kondisi kios tersebut, pabrik peranti penangkap keras yang disarankan "coba lagi sebelum kegagalan" pengaturan 5 detik.

Contoh 2: Filter pengandar intervensi

Banyak program peranti penangkap lunak antivirus dan cadangan produk menggunakan pengandar filter I/O. Pengandar filter I/O ini menjadi bagian dari permintaan I/O kehabisan memori, dan mereka memiliki akses ke permintaan IRP. Layanan Dukungan Produk Microsoft telah melihat berbagai masalah dari bug yang membuat terjebak I/O kondisi atau macet I/O kondisi implementasi pengandar filter.

Salah satu kondisi tersebut adalah pengandar filter cadangan pemrosesan yang diizinkan cadangan file yang dibuka saat terjadi cadangan. administrator sistem telah disertakan direktori berkas data SQL Server di berkas cadangan pilihan. Ketika terjadi cadangan, cadangan mencoba mengumpulkan citra yang benar dari berkas pada waktu cadangan dimulai. Melakukan hal ini tertunda permintaan I/O. Permintaan I/O yang diizinkan untuk menyelesaikan hanya satu per satu sebagai mereka ditangani oleh peranti penangkap lunak.

Ketika memulai cadangan, kinerja SQL Server menurun drastis karena I/o SQL Server dipaksa untuk menyelesaikan satu per satu. Untuk masalah majemuk, "satu per satu" logika itu pengoperasian I/O tidak dapat dilakukan asinkron. Oleh karena itu, ketika SQL Server diharapkan untuk mengirimkan permintaan I/O dan untuk melanjutkan, pekerja terjebak di membaca atau menulis panggilan permintaan I/O selesai. Pemrosesan tugas seperti SQL Server Baca-depan efektif dinonaktifkan oleh tindakan pengandar filter. Selain itu, bug lain di pengandar filter kiri "satu per satu" tindakan dalam proses, bahkan ketika operasi pembuatan cadangan telah selesai. Satu-satunya cara untuk memulihkan kinerja SQL Server adalah untuk menutup dan kemudian buka kembali pangkalan data, atau me-restart SQL Server sehingga menangani berkas dirilis dan reacquired tanpa interaksi pengandar filter.
Pemecahan masalah
Untuk mengatasi masalah ini, berkas data SQL Server yang dihapus dari proses pembuatan cadangan file. Pembuatan peranti penangkap lunak juga memperbaiki masalah yang tersisa berkas dalam mode "satu per satu".

Contoh 3: Kesalahan tersembunyi

Banyak sistem yang lebih tinggi-end memiliki garis jatuh berseri I/O multichannel menangani penyeimbangan muatan atau kegiatan serupa. Dukungan produk Microsoft telah menemukan masalah dengan penyeimbangan beban peranti penangkap lunak mana permintaan I/O gagal tetapi peranti penangkap lunak tidak menangani kondisi kesalahan dengan benar. peranti penangkap lunak dapat mencoba pengulangan tak terbatas. Operasi I/O menjadi macet dan SQL Server tidak dapat menyelesaikan tindakan tertentu. Seperti log menulis kondisi yang dijelaskan sebelumnya, banyak sistem buruk perilaku ini dapat terjadi setelah kondisi wedges sistem.
Pemecahan masalah
Untuk mengatasi masalah ini, restart SQL Server sering diperlukan. Namun, kadang-kadang Anda harus memulai ulang sistem operasi untuk memulihkan pemrosesan. Kami juga menyarankan Anda untuk mendapatkan pembaruan peranti penangkap lunak dari I/O vendor.

Contoh 4: Penyimpanan jarak jauh, pencerminan, dan raid kandar

Banyak sistem menggunakan pencerminan atau mengambil langkah-langkah yang sama untuk menghindari kehilangan data. Beberapa sistem yang menggunakan pencerminan berbasis peranti penangkap lunak dan beberapa berbasis peranti penangkap keras. Dalam situasi yang biasanya ditemukan oleh Microsoft Support untuk sistem tersebut yang meningkatkan latensi.

Meningkatkan keseluruhan I/O waktu terjadi saat I/O harus menyelesaikan cermin sebelum I/O dianggap selesai. Untuk instalasi jauh cermin, pengulangan jaringan dapat terlibat. Ketika terjadi kegagalan kandar dan sistem raid membangun kembali, pola I/O juga akan terputus.
Pemecahan masalah
Pengaturan konfigurasi ketat diperlukan untuk mengurangi latensi cermin atau raid membangun kembali operasi.

Untuk informasi selengkapnya, baca Persyaratan untuk SQL Server untuk mendukung jauh pencerminan pangkalan data pengguna.

Contoh 5: kompresi

Microsoft tidak mendukung Microsoft SQL Server 7.0 atau file data Microsoft SQL Server 2000 dan berkas log di kandar terkompresi. Kompresi NTFS tidak aman untuk SQL Server karena NTFS kompresi pemutusan protokol menulis Ahead pengelogan (WAL). Kompresi NTFS juga memerlukan peningkatan pemrosesan untuk setiap operasi I/O. Kompresi membuat "satu per satu" seperti perilaku yang menyebabkan masalah kinerja parah terjadi.
Pemecahan masalah
Untuk mengatasi masalah ini, buka kompresi data dan berkas log.

Untuk informasi selengkapnya, baca Deskripsi dukungan untuk SQL Server database pada volume terkompresi.

poin data tambahan

PAGEIOLATCH_ * dan writelog menunggu di tampilan manajemen dinamis sys.dm_os_wait_stats (DMV) adalah bukti kunci indictors untuk menyelidiki I/O garis jatuh berseri kinerja. Jika Anda melihat signifikan PAGEIOLATCH menunggu, ini berarti bahwa SQL Server menunggu di subsistem I/O. Sejumlah PAGEIOLATCH menunggu khas dan perilaku yang diharapkan. Namun, jika rata-rata PAGEIOLATCH menunggu kali konsisten lebih dari 10 milidetik (ms), Anda harus menyelidiki mengapa subsistem I/O adalah tekanan. Untuk informasi selengkapnya, lihat kumpulan dokumen berikut ini:



SQL Server memerlukan sistem dukungan "dijamin pengiriman ke media yang stabil" seperti yang tertera di bawah Persyaratan Program SQL Server I/O keandalan. Untuk informasi selengkapnya tentang persyaratan input dan output untuk SQL Server database engine, pergi ke artikel Pangkalan Pengetahuan Microsoft berikut ini:

Pemberi IO 833

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 897284 - Tinjauan Terakhir: 10/01/2015 04:20:00 - Revisi: 1.0

Microsoft SQL Server 2014 Business Intelligence, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Enterprise Core, Microsoft SQL Server 2014 Express, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Web, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Enterprise Core, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, Microsoft SQL Server 2012 Business Intelligence, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 R2 Datacenter, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition

  • kbinfo kbtshoot kbsqlserv2000sp4fea kbmt KB897284 KbMtid
Tanggapan