Log transaksi tumbuh tak terduga atau menjadi penuh di SQL Server

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: 317375
Ringkasan
Jika autogrow opsi disetel di Microsoft SQL Server 2005 dan kemudian versi, SQL Server 2000 dan SQL Server 7.0, file catatan transaksi dapat memperluas secara otomatis ke log maksimum ukuran file 2 terabyte (TB) per berkas log.

Biasanya, ukuran file catatan transaksi menstabilkan ketika dapat memegang jumlah maksimal transaksi yang dapat terjadi antara truncations log transaksi yang dipicu oleh pos pemeriksaan atau transaksi log backup.

Namun, dalam beberapa kasus transaksi log Mei menjadi sangat besar dan berjalan keluar dari ruang atau menjadi penuh. Biasanya, Anda menerima pesan galat berikut ketika file catatan transaksi menggunakan ruang disk yang tersedia dan tidak dapat memperluas lagi:
Kesalahan: 9002, keparahan: 17 negara: 2
File log untuk database ' %. * ls' penuh.
Jika Anda menggunakan SQL Server 2005, Anda menerima pesan galat yang menyerupai berikut ini:
Kesalahan: 9002, keparahan: 17 negara: 2
Transaksi log untuk database ' %. * ls' penuh. Untuk mengetahui mengapa ruang dalam log tidak dapat digunakan kembali, lihat kolom log_reuse_wait_desc di sys.databases
Selain pesan kesalahan ini, SQL Server dapat menandai database sebagai tersangka karena kurangnya ruang untuk ekspansi log transaksi. Untuk informasi lebih lanjut tentang bagaimana untuk memulihkan dari situasi ini, lihat "Tidak cukup ruang Disk" topik dalam SQL Server buku Online.

Selain itu, perluasan transaksi log dapat terjadi untuk satu alasan berikut atau di salah satu skenario berikut:
  • file catatan transaksi yang sangat besar.
  • Transaksi mungkin gagal dan mulai untuk roll kembali.
  • Transaksi dapat mengambil waktu lama untuk menyelesaikan.
  • Masalah kinerja dapat terjadi.
  • Memblokir dapat terjadi.
  • Database berpartisipasi dalam grup ketersediaan AlwaysOn.
Informasi lebih lanjut
Transaksi log ekspansi dapat terjadi untuk salah satu alasan berikut atau skenario.


Catatan Dalam SQL Server 2005 dan versi yang lebih baru, Anda dapat memeriksa kolom log_reuse_wait dan log_reuse_wait_desc sys.databases Katalog tampilan untuk menentukan mengapa ruang log transaksi adalah tidak kembali dan mengapa log transaksi tidak terpotong.


Transaksi tidak terikat
Eksplisit transaksi tetap tidak terikat jika Anda tidak mengeluarkan perintah KOMIT atau ROLLBACK eksplisit. Hal ini terjadi paling sering ketika aplikasi masalah Batal atau perintah Transact-SQL membunuh tanpa perintah ROLLBACK sesuai. Pembatalan transaksi terjadi, tetapi itu tidak roll kembali. Oleh karena itu, SQL Server tidak bisa memotong setiap transaksi yang terjadi setelah ini karena transaksi dibatalkan masih terbuka. Anda dapat menggunakan DBCC OPENTRAN Transact-SQL referensi untuk memverifikasi bahwa ada transaksi aktif dalam database pada waktu tertentu. Untuk informasi lebih lanjut tentang skenario khusus ini, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
295108 Transaksi tidak lengkap dapat memegang sejumlah besar bukti kunci dan memblokir kasus
171224 Memahami bagaimana perintah Transact-SQL membunuh bekerja
Selain itu, lihat topik "DBCC OPENTRAN" dalam SQL Server buku Online.

Skenario yang dapat mengakibatkan tidak terikat transaksi:
  • Desain aplikasi yang mengasumsikan bahwa semua kesalahan causerollbacks.
  • Desain aplikasi yang tidak benar-benar mempertimbangkan perilaku SQL Server ketika gulung kembali dengan bernama transaksi atau bersarang khusus bernama transaksi. Jika Anda mencoba untuk memutar kembali transaksi bernama batin, Anda menerima pesan galat berikut:
    Server: Msg 6401, tingkat 16, negara bagian 1, baris 13 tidak bisa memutar kembali InnerTran. Notransaction atau savepoint nama itu ditemukan.
    Setelah SQL Servergenerates pesan kesalahan, terus pernyataan berikutnya. Ini adalah bydesign. Untuk selengkapnya, lihat "Transaksi yang bersarang" atau "Dalam SQLServer" topik dalam SQL Server buku Online.

    Kami merekomendasikan berikut bila Anda desain aplikasi Anda:
    • unit hanya satu transaksi pena (mempertimbangkan kemungkinan bahwa proses lain dapat menghubungi Anda).
    • Memeriksa @@TRANCOUNT sebelum Anda mengeluarkan KOMIT, ROLLBACK, kembali, atau serupa perintah atau pernyataan.
    • Menulis kode Anda dengan asumsi bahwa @@TRANCOUNT lain mungkin "sarang" Anda dan merencanakan untuk @@TRANCOUNT luar untuk memutar kembali ketika terjadi kesalahan.
    • Review savepoint dan tandai pilihan untuk transaksi. (Ini tidak melepaskan bukti kunci!)
    • Melakukan pengujian lengkap.
  • Sebuah aplikasi yang memungkinkan untuk interaksi pengguna di dalam transaksi. Hal ini menyebabkan transaksi untuk tetap terbuka untuk waktu yang lama, dan ini menyebabkan menghalangi dan transaksi log pertumbuhan karena transaksi terbuka tidak dipotong dan transaksi baru ditambahkan ke log setelah transaksi terbuka.
  • Sebuah aplikasi yang tidak memeriksa @@TRANCOUNT untuk verifythat ada yang tidak ada transaksi terbuka.
  • Jaringan atau kesalahan lain yang menutup applicationconnection klien ke SQL Server tanpa memberitahukan hal itu.
  • Koneksi penggabungan. Setelah dibuat, thread pekerja SQL Server reuses mereka jika mereka tidak melayani koneksi. Jika sambungan pengguna mulai transaksi dan terputus sebelum melakukan atau bergulir kembali transaksi, dan koneksi setelah yang reuses kain yang sama, transaksi sebelumnya masih tetap terbuka. Situasi ini hasil dalam bukti kunci yang tetap buka dari transaksi sebelumnya dan mencegah pemotongan transaksi berkomitmen dalam log. Hal ini menghasilkan ukuran file log yang besar. Untuk informasi lebih lanjut tentang koneksi penggabungan, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
    164221 Cara mengaktifkan koneksi penggabungan dalam aplikasi ODBC


Sangat besar transaksi
Log catatan dalam file catatan transaksi yang terpotong secara oleh transaksi-transaksi. Jika ruang lingkup transaksi besar, bahwa transaksi dan transaksi dimulai setelah itu tidak dihapus dari log transaksi kecuali selesai. Hal ini dapat mengakibatkan file log yang besar. Jika transaksi cukup besar, berkas log mungkin menggunakan ruang disk yang tersedia dan menyebabkan "log transaksi penuh" jenis pesan kesalahan seperti 9002 kesalahan. Untuk informasi lebih lanjut tentang apa yang harus dilakukan ketika Anda menerima pesan galat semacam ini, lihat bagian "Informasi selengkapnya" dalam artikel ini. Selain itu, dibutuhkan banyak waktu dan SQL Server overhead untuk memutar kembali transaksi besar.

Operasi: DBCC DBREINDEX dan membuat indeks
Karena perubahan dalam pemulihan model di SQL Server 2000, ketika Anda menggunakan modus pemulihan penuh dan Anda menjalankan DBCC DBREINDEX, log transaksi dapat memperluas secara signifikan lebih dibandingkan dengan SQL Server 7.0 dalam modus pemulihan setara dengan penggunaan pilih ke atau kopi karbon massal dan "Trunc. Log on chkpt."off.

Meskipun ukuran log transaksi setelah operasi DBREINDEX mungkin menjadi masalah, pendekatan ini menyediakan log gulung balik performa yang lebih baik.

Ketika memulihkan dari transaksi log backup
Hal ini dijelaskan dalam artikel Pangkalan Pengetahuan Microsoft berikut:
232196 Log ruang digunakan tampaknya tumbuh setelah memulihkan dari cadangan

Jika Anda menetapkan SQL Server 2000 untuk menggunakan massal-log mode dan Anda mengeluarkan pernyataan kopi karbon massal atau pilih ke, sejauh berubah setiap ditandai dan kemudian didukung saat Anda membuat cadangan log transaksi. Meskipun hal ini memungkinkan Anda kembali atas transaksi log dan pulih dari kegagalan bahkan setelah Anda melakukan operasi massal, ini menambah ukuran transaksi log. SQL Server 7.0 tidak termasuk fitur ini. SQL Server 7.0 hanya mencatat extent yang berubah, tapi ini tidak mencatat extent sebenarnya. Oleh karena itu, penebangan menggunakan secara signifikan lebih banyak ruang di SQL Server 2000 daripada di SQL Server 7.0 dalam massal-Log mode, tetapi tidak sebanyak seperti yang dilakukannya dalam mode penuh.

Aplikasi-aplikasi client tidak memproses semua hasil
Jika Anda mengeluarkan query ke SQL Server dan Anda tidak menangani hasil segera, Anda mungkin memegang bukti kunci dan mengurangi concurrency pada server.

Misalnya, bahwa Anda mengeluarkan query yang memerlukan baris dari dua halaman untuk mengisi set hasil Anda. SQL Server mem-parsing, mengkompilasi dan menjalankan query. Ini berarti bahwa bukti kunci bersama ditambahkan pada dua halaman yang mengandung baris yang harus Anda miliki untuk memenuhi permintaan Anda. Selain itu, misalnya, bahwa tidak semua baris cocok ke satu paket SQL Server TDS (metode yang server yang berkomunikasi dengan klien). Paket TDS diisi dan dikirim ke klien. Jika semua baris dari halaman pertama muat pada paket TDS, SQL Server melepaskan bukti kunci bersama pada halaman tersebut tetapi meninggalkan bukti kunci bersama pada halaman kedua. SQL Server kemudian menunggu untuk klien untuk meminta lebih banyak data (Anda dapat melakukan ini dengan menggunakan DBNEXTROW DBRESULTS, SQLNextRow SQLResults, atau FetchLast FetchFirst misalnya).

Ini berarti bahwa bukti kunci bersama diadakan sampai klien permintaan sisa data. Proses-proses lain yang meminta data dari halaman kedua dapat diblokir.

Query waktu sebelum log transaksi selesai perluasan dan Anda menerima pesan kesalahan 'Log lengkap' palsu
Dalam situasi ini, meskipun ada cukup ruang disk, Anda masih menerima pesan galat "luar angkasa".

Situasi ini bervariasi untuk SQL Server 7.0 dan SQL Server 2000.

Query dapat menyebabkan log transaksi secara otomatis memperluas jika log transaksi hampir penuh. Ini mungkin memerlukan waktu tambahan, dan query mungkin dihentikan atau dapat melebihi periode time-out karena ini. SQL Server 7.0 kembali kesalahan 9002 dalam situasi ini. Masalah ini tidak sahih untuk SQL Server 2000.

Di SQL Server 2000, jika Anda memiliki pilihan auto-menyusut dihidupkan untuk database, ada waktu kecil yang log transaksi berusaha memperluas secara otomatis. Namun, itu tidak dapat memperluas karena fungsi auto-menyusut berjalan pada waktu yang sama. Ini juga dapat menyebabkan palsu kasus kesalahan 9002.

Biasanya, perluasan otomatis file catatan transaksi terjadi dengan cepat. Namun, dalam beberapa situasi berikut, mungkin diperlukan waktu lebih lama dari biasanya:
  • Pertumbuhan bertahap terlalu kecil.
  • Server ini lambat karena berbagai alasan.
  • kandar cakram tidak cukup cepat.


Unreplicated transaksi
Ukuran transaksi log database penerbit dapat memperluas jika Anda menggunakan replikasi. Transaksi yang mempengaruhi objek yang direplikasi ditandai sebagai "Untuk replikasi." Transaksi ini, seperti transaksi tidak terikat, tidak dihapus setelah pemeriksaan atau setelah Anda kembali ke log transaksi sampai tugas log-pembaca kopi karbon transaksi ke database distribusi dan unmarks mereka. Jika masalah dengan tugas log-pembaca mencegah dari membaca transaksi ini dalam database penerbit , ukuran transaksi log dapat terus memperluas sebagai jumlah transaksi non-direplikasi meningkat. Anda dapat menggunakan DBCC OPENTRAN Transact-SQL referensi untuk mengidentifikasi transaksi non-direplikasi tertua.

Untuk informasi lebih lanjut tentang bagaimana memecahkan masalah unreplicated transaksi, lihat topik "sp_replcounters" dan "sp_repldone" dalam SQL Server buku Online.

Untuk informasi lebih lanjut, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
306769 FIX: Log transaksi snapshot diterbitkan database tidak bisa dipotong
240039 FIX: DBCC OPENTRAN tidak melaporkan informasi replikasi
198514 FIX: Kembalikan ke server baru menyebabkan transaksi untuk tetap dalam log


AlwaysOn 'AVAILABILITY_REPLICA' menerapkan catatan log transaksi ke database sekunder

Dalam SQL Server 2012 dengan grup ketersediaan AlwaysOn diaktifkan, Anda dapat melihat pesan di log kesalahan SQL berikut:

Kesalahan: 9002, keparahan: 17 negara: 9.
Transaksi log untuk database ' %. * ls' penuh karena 'AVAILABILITY_REPLICA'

AVAILABILITY_REPLICA log_reuse_wait menunjukkan replika sekunder grup ketersediaan AlwaysOn adalah menerapkan catatan log transaksi ini database ke database sekunder yang sesuai.

Ada dua skenario yang dapat mengakibatkan login pertumbuhan ketersediaan database dan AVAILABILITY_REPLICA ' log_reuse_wait:

Skenario 1: Latency memberikan log perubahan ke sekunder

Ketika transaksi dilakukan di primer, blok login harus disampaikan dan mengeras ke file log database di sekunder. Penundaan akan mencegah pemotongan dari perubahan log dalam database di replika utama.

Skenario 2: Mengulang Latency

Setelah mengeras ke file log database sekunder benang berdedikasi mengulang berlaku catatan log.

Jika operasi mengulang tidak mampu bersaing dengan log transaksi yang dihasilkan, itu dapat berpotensi menyebabkan untuk log pertumbuhan. Primer akan mampu memotong log transaksi jika sekunder replika mengulang operasi di belakang dalam menerapkan perubahan-perubahan ke database sekunder yang sesuai. Jika ada lebih dari satu sekunder, untuk mengidentifikasi database sekunder yang menunda pemotongan log, membandingkan kolom sys.dm_hadr_database_replica_states manajemen dinamis Lihat truncation_lsn di secondaries beberapa.

Anda dapat menggunakan AlwaysOn Dashboard dan sys.dm_hadr_database_replica_states manajemen dinamis dilihat untuk membantu memantau log mengirim antrian dan mengulang antrian. Beberapa bidang bukti kunci adalah:

BidangDeskripsi
log_send_queue_sizeJumlah catatan log yang belum tiba di replika sekunder
log_send_rateTingkat di mana log catatan yang sedang dikirim ke database sekunder
redo_queue_sizeJumlah log catatan dalam file log Replica sekunder yang memiliki tidak belum telah redone, dalam kilobyte (KB)
redo_rateTingkat di mana catatan log yang sedang redone pada database sekunder tertentu, dalam kilobyte (KB) / second
last_redone_lsnNomor login sebenarnya urutan menurun catatan log terakhir yang redone pada database sekunder. last_redone_lsn selalu kurang dari last_hardened_lsn
last_received_lsnLogin ID blok mengidentifikasi titik hingga yang semua log blok telah diterima oleh replika sekunder yang host database sekunder ini. Mencerminkan ID log-blok yang empuk dengan nol. Hal ini tidak sebenarnya log urutan menurun nomor.

Catatan Untuk informasi lebih lanjut tentang pandangan sys.dm_hadr_database_replica_states, lihat website TechNet berikut:

http://technet.Microsoft.com/en-US/Library/ff877972.aspx



Informasi lanjutan
Transaksi log untuk database dikelola sebagai satu set virtual file log (VLFs). SQL Server menentukan ukuran file VLF internal berdasarkan ukuran total berkas log dan kenaikan pertumbuhan yang digunakan ketika log mengembang. Log selalu memperluas dalam satuan seluruh VLFs dan itu hanya dapat memampatkan ke batas VLF. VLF bisa eksis di salah satu dari tiga negara: aktif, RECOVERABLE, dan dapat digunakan kembali.
  • Aktif: bagian aktif dari log dimulai minimal log urutan menurun nomor (LSN) yang mewakili sebuah transaksi (tidak terikat) yang aktif. Bagian aktif dari log berakhir di LSN ditulis terakhir. Setiap VLFs yang berisi setiap bagian dari log aktif dianggap aktif VLFs. (ruang yang tidak terpakai di log fisik bukan merupakan bagian dari setiap VLF.)
  • RECOVERABLE: bagian log yang datang sebelum transaksi aktif tertua ini hanya diperlukan untuk mempertahankan urutan menurun log backup untuk pemulihan.
  • REUSABLE: jika Anda tidak mempertahankan transaksi log backup, atau jika youalready didukung log, SQL Server reuses VLFs sebelum activetransaction tertua.
Ketika SQL Server mencapai akhir file log fisik, itu mulai menggunakan ruang dalam file fisik dengan mengeluarkan operasi yang berputar-putar kembali ke awal dari file. Akibatnya, SQL Server mendaur ulang ruang dalam file log yang tidak lagi diperlukan untuk tujuan pemulihan atau cadangan. Jika urutan menurun cadangan log sedang dipertahankan, Bagian dari log sebelum minimum LSN tidak dapat ditimpa sampai Anda membuat cadangan atau memotong catatan log tersebut. Setelah Anda melakukan log backup, SQL Server dapat lingkaran kembali ke awal dari file. Setelah SQL Server lingkaran kembali ke mulai menulis log mencatat sebelumnya dalam berkas log, Bagian reusable log ini kemudian antara akhir dari log logis dan bagian aktif dari log.

Untuk selengkapnya, lihat "Transaksi Log fisik arsitektur" topik dalam SQL Server buku Online. Selain itu, Anda dapat melihat diagram dan diskusi ini di halaman 190 "dalam SQL Server 7.0" (Soukup, Ron. Dalam Microsoft SQL Server 7.0, Microsoft Press, 1999), dan juga pada halaman 182-186 "dalam SQL Server 2000" (Delaney, Kalen. Dalam Microsoft SQL Server 2000, Microsoft Press, 2000). Database SQL Server 2000 dan SQL Server 7.0 memiliki pilihan untuk autogrow dan autoshrink. Anda dapat menggunakan pilihan ini untuk membantu Anda mengecilkan atau memperluas log transaksi Anda.

Untuk informasi lebih lanjut tentang bagaimana pilihan ini dapat mempengaruhi server, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
315512 Pertimbangan untuk Autogrow dan Autoshrink konfigurasi di SQL Server
Pemotongan dari file catatan transaksi berbeda dari kompresi file catatan transaksi. Ketika SQL Server memotong file catatan transaksi, ini berarti bahwa isi dari file (misalnya, transaksi berkomitmen) dihapus. Namun, bila Anda melihat ukuran file dari perspektif ruang disk (misalnya, dalam Penjelajah Windows atau dengan menggunakan perintah dir ), ukuran tetap tidak berubah. Namun, ruang di dalam .ldf file sekarang digunakan kembali oleh transaksi yang baru. Hanya ketika ukuran file catatan transaksi menyusut SQL Server Apakah Anda benar-benar melihat perubahan dalam ukuran fisik berkas log.

Untuk informasi lebih lanjut tentang bagaimana untuk mengecilkan log transaksi, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
256650 Bagaimana untuk mengecilkan log transaksi SQL Server 7.0
272318 Menyusut log transaksi SQL Server 2000 dengan DBCC SHRINKFILE
Untuk informasi lebih lanjut tentang penggunaan log transaksi SQL Server 6.5, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
110139 Penyebab log transaksi SQL yang mengisi

Bagaimana cara menemukan pertanyaan yang mengkonsumsi sejumlah besar ruang login di SQL Server 2005 dan versi yang lebih baru

Dalam SQL Server 2005 dan versi yang lebih baru, Anda dapat menggunakan sys.dm_tran_database_transactions manajemen dinamis Lihat (DMV) untuk Telisik query yang mengkonsumsi jumlah besar ruang log. Kolom berikut di sys.dm_tran_database_transactions DMV dapat berguna:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
Anda dapat permintaan kolom sql_handle sys.dm_exec_requests DMV untuk mendapatkan teks sebenarnya pernyataan yang mengkonsumsi sejumlah besar ruang log. Anda dapat melakukannya dengan bergabung sys.dm_tran_database_transactions DMV dan sys.dm_tran_session_transactions DMV pada kolom transaction_id, dan kemudian menambahkan tambahan bergabung dengan sys.dm_exec_requests pada kolom session_id.

Untuk informasi lebih lanjut tentang sys.dm_tran_database_transactions DMV, pergi ke sys.dm_tran_database_transactions (Transact-SQL) Website Microsoft Developer Network (MSDN).

Untuk informasi lebih lanjut tentang sys.dm_tran_session_transactions DMV, pergi ke sys.dm_tran_session_transactions (Transact-SQL) MSDN website.

Untuk informasi lebih lanjut tentang sys.dm_exec_requests DMV, pergi ke sys.dm_exec_requests (Transact-SQL) MSDN website.

Peringatan: Artikel ini telah diterjemahkan secara otomatis

Properti

ID Artikel: 317375 - Tinjauan Terakhir: 01/13/2014 17:49:00 - Revisi: 5.0

Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 7.0 Standard Edition

  • kbsqlsetup kbinfo kbmt KB317375 KbMtid
Tanggapan