Cara mempertahankan dan memecahkan BizTalk Server Database

Microsoft BizTalk Server database dan kesehatan database yang sangat penting untuk sukses BizTalk Server pesan lingkungan. Artikel ini membahas hal-hal yang penting untuk dipertimbangkan saat Anda bekerja dengan BizTalk Server database. Pertimbangan ini meliputi:

• Anda harus menonaktifkan Auto Update statistik dan Auto membuat statistik Microsoft SQL Server pilihan.
• Anda harus mengatur tingkat Max paralelisme properti dengan benar.
• Menentukan ketika Anda dapat membangun kembali BizTalk Server indeks.
• Mengunci, deadlocking, atau memblokir dapat terjadi.
• Anda mungkin mengalami masalah dengan database besar atau tabel.
• SQL BizTalk Server agen pekerjaan
• Layanan kasus mungkin akan dihentikan.
• Anda mungkin mengalami masalah kinerja SQL Server dan BizTalk Server.
• Anda harus mengikuti praktek-praktek terbaik dalam BizTalk Server.

Artikel ini menjelaskan cara untuk mempertahankan BizTalk Server database dan bagaimana memecahkan masalah BizTalk Server database.

Masalah yang dikenal

Anda harus menonaktifkan opsi Auto Update statistik dan Auto membuat statistik

Anda harus menonaktifkan Auto membuat statistik dan Auto Update statistik pilihan pada BizTalkMsgBoxDb database. Untuk menentukan apakah pengaturan ini dinonaktifkan, jalankan disimpan prosedur berikut dalam SQL Server:
Anda harus menetapkan pengaturan CurrentSetting off. Jika pengaturan ini diatur ke pada, mematikan dengan mengeksekusi disimpan prosedur berikut dalam SQL Server:
Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Anda harus mengatur tingkat Max paralelisme properti dengan benar

Pada komputer yang menjalankan SQL Server dan hosting BizTalkMsgBoxDb database, mengatur tingkat Max paralelisme run_value dan config_value properti untuk nilai 1. Untuk menentukan tingkat Max paralelisme pengaturan, mengeksekusi berikut disimpan prosedur terhadap Master database di SQL Server: Jika properti run_value dan config_value tidak diatur ke nilai 1, jalankan disimpan prosedur berikut dalam SQL Server untuk mengatur mereka untuk 1:
Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Menentukan ketika Anda dapat membangun kembali BizTalk Server indeks

Kebanyakan BizTalk Server indeks berkumpul (indeks ID: 1). Anda dapat menggunakan pernyataan DBCC SHOWCONTIG SQL Server untuk menampilkan informasi fragmentasi untuk tabel BizTalk Server.

Indeks BizTalk Server berbasis GUID. Oleh karena itu, fragmentasi biasanya terjadi. Jika nilai kepadatan Scan yang dikembalikan oleh pernyataan DBCC SHOWCONTIG kurang dari 30 persen, BizTalk Server indeks dapat dibangun downtime.

Banyak BizTalk Server tabel berisi kolom yang menggunakan DataType definisi. Online pengindeksan tidak dapat dilakukan dalam kolom ini. Oleh karena itu, Anda harus tidak pernah kembali BizTalk Server indeks sementara BizTalk Server proses data.

Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft: Untuk informasi lebih lanjut tentang bagaimana untuk menganalisis DBCC SHOWCONTIG pernyataan output, kunjungi website Microsoft berikut:

Mengunci, deadlocking, atau memblokir dapat terjadi

Biasanya, kunci dan blok terjadi di lingkungan BizTalk Server. Namun, ini kunci atau blok tidak tetap untuk waktu yang panjang. Oleh karena itu, menghalangi dan deadlocking menunjukkan masalah potensial.

Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Anda mungkin mengalami masalah dengan database besar atau meja

Kita telah melihat bahwa ketika BizTalkMsgBoxDb database lebih besar dari 5 GB, masalah kinerja yang dapat terjadi. Idealnya, BizTalkMsgBoxDb database harus tidak mengadakan data. BizTalkMsgBoxDb database harus dipertimbangkan buffer sampai data diproses atau pindah ke BizTalkDTADb database.

Lingkungan yang menggunakan SQL Server yang kuat di bagian belakang dan banyak berjalan lama orchestrations mungkin memiliki database BizTalkMsgBoxDb yang lebih besar dari 5 GB. Volume tinggi lingkungan yang menggunakan orchestrations berjalan lama tidak harus memiliki database BizTalkMsgBoxDb yang jauh lebih kecil daripada 5 GB.

BizTalkDTADb database tidak memiliki ukuran yang ditetapkan. Namun, jika kinerja berkurang, database mungkin terlalu besar. Biasanya, 15 GB untuk 20 GB dianggap terlalu besar. Bila Anda memiliki besar BizTalk Server Database, Anda mungkin mengalami masalah berikut:

• BizTalkMsgBoxDb database terus tumbuh. Namun, log file dan ukuran data tetap besar.
• BizTalk Server membutuhkan waktu lebih lama dari biasanya untuk memproses bahkan pesan sederhana aliran skenario.
• Kesehatan dan aktivitas pelacakan (TOPI) queries memerlukan waktu lebih lama dari biasanya dan mungkin waktu.
• Database log file pernah terpotong.
• Pekerjaan SQL BizTalk Server agen berjalan lebih lambat dari biasanya.
• Beberapa tabel secara signifikan lebih besar atau baris terlalu banyak dibandingkan dengan ukuran biasa meja.

Database dapat menjadi besar karena berbagai alasan. Alasan ini dapat meliputi:

• SQL BizTalk Server agen pekerjaan tidak berjalan
• Contoh ditangguhkan dalam jumlah besar
• Disk kegagalan
• Pelacakan
• Penyendatan
• Kinerja SQL Server
• Latency jaringan

Pastikan bahwa Anda tahu apa yang diharapkan di lingkungan Anda untuk menentukan apakah masalah data yang terjadi.

Secara default, pelacakan diaktifkan pada default host. BizTalk mensyaratkan bahwa Memungkinkan pelacakan Host pilihan diperiksa pada inang tunggal. Ketika pelacakan diaktifkan, pelacakan Data Decode layanan (TDDS) bergerak pelacakan acara data dari BizTalkMsgBoxDb database ke BizTalkDTADb database. Jika pelacakan host berhenti, TDDS tidak memindahkan data ke BizTalkDTADb database dan TrackingData_x_x tabel pada BizTalkMsgBoxDb database akan tumbuh.

Kami merekomendasikan bahwa Anda mendedikasikan satu host ke Pelacakan. Untuk memungkinkan TDDS untuk mempertahankan peristiwa pelacakan baru dalam volume tinggi skenario, membuat beberapa contoh dari sejumlah pelacakan tunggal. Tuan rumah lebih dari satu pelacakan tidak harus ada.

Ada terlalu banyak baris dalam tabel. Ada tidak ada beberapa baris yang terlalu banyak. Selain itu, jumlah baris ini bervariasi menurut jenis data disimpan dalam tabel. Misalnya, tabel dta_DebugTrace yang memiliki lebih dari 1 juta baris mungkin memiliki terlalu banyak baris. A Nama hostTabel Q_Suspended yang memiliki lebih dari 200.000 baris mungkin memiliki terlalu banyak baris.

Menggunakan SQL BizTalk Server agen benar pekerjaan

Pekerjaan SQL BizTalk Server agen penting untuk mengelola database BizTalk Server dan untuk mempertahankan kinerja tinggi.

The Cadangan BizTalk Server Agen SQL Server pekerjaan adalah satu-satunya metode yang didukung untuk membuat cadangan BizTalk Server database. Pekerjaan ini mengharuskan semua BizTalk Server database menggunakan Model pemulihan penuh. Anda harus mengkonfigurasi pekerjaan ini lingkungan BizTalk Server yang sehat. SQL Server metode yang dapat digunakan untuk membuat cadangan database BizTalk Server hanya jika SQL Server agen berhenti dan jika semua BizTalk Server host contoh dihentikan.

The MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server agen pekerjaan berjalan jauh. Oleh karena itu, SQL Server agen pekerjaan sejarah tidak pernah menampilkan berhasil menyelesaikan. Jika terjadi kegagalan, pekerjaan restart dalam satu menit dan akan terus berjalan jauh. Oleh karena itu, Anda bisa dengan aman mengabaikan kegagalan. Selain itu, pekerjaan sejarah dapat dibersihkan. Anda hanya harus peduli jika Riwayat pekerjaan laporan bahwa pekerjaan ini terus-menerus gagal dan me-restart.

The MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server agen pekerjaan adalah satu-satunya pekerjaan BizTalk Server yang tidak dapat diaktifkan karena dimulai oleh MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server agen pekerjaan.

The DTA membersihkan dan arsip SQL Server agen pekerjaan membantu mempertahankan BizTalkDTADb database dengan membersihkan dan pengarsipan pesan dilacak. Pekerjaan ini membaca setiap baris dalam tabel dan membandingkan cap waktu untuk menentukan apakah catatan harus dihapus.

Semua pekerjaan SQL BizTalk Server agen kecuali MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server agen pekerjaan harus menjalankan berhasil.

Untuk informasi lebih lanjut tentang semua pekerjaan BizTalk Server SQL Server agen, klik nomor artikel berikut ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

Layanan kasus mungkin akan dihentikan

Contoh layanan dapat ditangguhkan (resumable) atau dihentikan (tidak resumable). Contoh layanan ini mungkin pesan, orkestrasi atau Port.

Contoh layanan ini dapat membuat BizTalkMsgBoxDb database tumbuh tidak perlu dan dapat dihentikan. Tabel berikut mencantumkan apa metode dapat digunakan, tergantung pada versi BizTalk:Untuk informasi selengkapnya tentang skrip Terminate.vbs, kunjungi website MSDN berikut: Contoh caching tidak muncul di Kelompok Hub Halaman, dan Anda tidak dapat menangguhkan atau menghentikan mereka. Pembatasan ini adalah penyebab umum meja pertumbuhan. Untuk mencegah pesan zombie baru untuk contoh layanan cache dalam BizTalk Server 2006, menginstal perbaikan terbaru pada artikel Basis Pengetahuan Microsoft 936536. Masalah ini telah diperbaiki di BizTalk Server 2006 R2 dan versi yang lebih baru.

Catatan Pesan zombie adalah pesan yang diteruskan tetapi tidak dikonsumsi.

Untuk informasi lebih lanjut, klik nomor artikel berikut ini untuk melihat artikel di dalam Basis Pengetahuan Mirosoft: Ketika BizTalk Server host misalnya berakhir, cache item tidak dapat dihapus. Untuk mengatasi perilaku ini dalam BizTalk Server 2006, instal perbaikan terbaru dalam Basis Pengetahuan Microsoft artikel 944426. Dalam BizTalk Server 2006 R2, menginstal BizTalk 2006 R2 Paket Layanan 1. Masalah ini telah diperbaiki di BizTalk Server 2009 dan versi yang lebih baru.

Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Masalah umum lainnya adalah bahwa Routing kegagalan laporan (RFRs) dapat membangun BizTalkHostQ dan BizTalkHostQ_Suspended tabel. RFRs tidak dihapus, dan perilaku ini dapat menyebabkan BizTalkMsgBoxDb database untuk tumbuh. Untuk mengatasi masalah ini di BizTalk Server 2006, menginstal perbaikan terbaru pada Basis Pengetahuan Microsoft artikel 941690. Masalah ini telah diperbaiki di BizTalk Server 2006 R2 dan versi yang lebih baru.

Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Istilah "anak yatim pesan" dan "zombie pesan" sering digunakan secara bergantian.

Pesan yatim piatu adalah pesan yang tidak memiliki contoh terkait. Misalnya, laporan kegagalan routing adalah pesan yatim piatu.

Pesan zombie adalah pesan yang diteruskan tetapi tidak dikonsumsi. Misalnya, pesan disampaikan kepada orkestrasi konvoi. Namun, konvoi orkestrasi turun jalan kode lain. Contoh orkestrasi selesai. Pesan tersebut akan dibuang dan sekarang dikenal sebagai pesan zombie.

Untuk keterangan zombie pesan, kunjungi website MSDN berikut:

Anda mungkin mengalami masalah kinerja SQL Server dan BizTalk Server

BizTalk Server membuat ratusan transaksi pendek, sangat cepat ke SQL Server dalam satu menit. Jika SQL Server tidak bisa mempertahankan kegiatan ini, BizTalk Server mungkin mengalami masalah kinerja. Dalam kinerja Monitor, memantau Rata-rata Disk sec/membaca, rata-rata Disk sec/Transfer dan Rata-rata Disk sec/menulis Monitor kinerja counters di PhysicalDisk kinerja objek. Nilai optimal adalah kurang dari 10 ms (milidetik). Nilai MS 20 atau lebih besar dianggap miskin kinerja.

Untuk informasi lebih lanjut tentang kinerja SQL Server, kunjungi website Microsoft berikut:Untuk informasi lebih lanjut tentang ketersediaan tinggi database BizTalk Server 2004, kunjungi website MSDN berikut: Untuk informasi lebih lanjut tentang ketersediaan tinggi database BizTalk Server 2006, kunjungi website MSDN berikut:Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Praktek-praktek terbaik dalam BizTalk Server

Mulai SQL Server agen pada SQL Server. Ketika SQL Server agen berhenti, built-in jobs SQL BizTalk Server agen yang bertanggung jawab untuk pemeliharaan database tidak dapat dijalankan. Perilaku ini menyebabkan pertumbuhan database, dan pertumbuhan ini dapat menyebabkan masalah kinerja. Pemeliharaan database BizTalk Server telah sangat meningkat dalam BizTalk Server 2004 Paket Layanan 2 (SP2) dan versi yang lebih baru.

Menempatkan SQL Server LDF dan MDF file pada drive terpisah. Ketika file LDF dan MDF untuk BizTalkMsgBoxDb dan BizTalkDTADb database pada drive yang sama, pertentangan disk dapat terjadi.

Jika Anda tidak mendapatkan keuntungan dari badan pesan pelacakan, mengaktifkan fitur ini. Namun, itu adalah ide yang baik untuk mengaktifkan pesan tubuh pelacakan sementara Anda mengembangkan dan memecahkan masalah solusi. Jika Anda melakukannya, pastikan Anda menonaktifkan pesan tubuh pelacakan setelah selesai. Bila badan pesan pelacakan diaktifkan, BizTalk Server Database tumbuh. Jika ada kebutuhan bisnis yang memerlukan memungkinkan badan pesan pelacakan, mengkonfirmasi bahwa TrackedMessages_Copy_BizTalkMsgBoxDb dan DTA membersihkan dan arsip SQL Server agen pekerjaan menjalankan berhasil.

Biasanya, log transaksi lebih kecil menyebabkan performa yang lebih baik. Untuk menyimpan log transaksi lebih kecil, mengkonfigurasi Cadangan BizTalk Server SQL Server agen pekerjaan untuk menjalankan lebih sering. Untuk informasi lebih lanjut tentang optimasi BizTalk Server, kunjungi website MSDN berikut: Prosedur sp_ForceFullBackup disimpan dalam BizTalkMgmtDb database juga dapat digunakan untuk membantu menjalankan ad-hoc penuh cadangan data dan log file. Prosedur yang tersimpan update tabel adm_ForceFullBackup dengan nilai 1. Saat berikutnya Cadangan BizTalk Server pekerjaan berjalan, seperangkat cadangan database penuh akan dibuat.

BizTalk Server terbaik praktik Analyzer (BPA) dapat digunakan untuk mengevaluasi penyebaran BizTalk Server ada. BPA melakukan cek database yang berhubungan dengan banyak. Untuk informasi lebih lanjut tentang BPA, kunjungi website Microsoft berikut:

Pemecahan Masalah

Pemecahan masalah langkah-langkah untuk database SQL BizTalk Server Server terbaik tergantung pada jenis database masalah, seperti menghalangi atau deadlocking. Untuk memecahkan masalah database BizTalk Server, ikuti langkah berikut.

Langkah 1: Mengaktifkan dan menjalankan semua pekerjaan SQL BizTalk Server agen yang diperlukan

Semua BizTalk SQL Server agen pekerjaan kecuali MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb pekerjaan harus diaktifkan dan berjalan berhasil. Tidak menonaktifkan pekerjaan lainnya.

Jika terjadi kegagalan, menggunakan Lihat sejarah pilihan dalam SQL Server untuk melihat kesalahan informasi, dan kemudian memecahkan kegagalan sesuai. Ingat bahwa MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server agen pekerjaan berjalan jauh. Oleh karena itu, Anda hanya harus peduli jika Riwayat pekerjaan laporan bahwa pekerjaan selalu gagal dan me-restart.

Langkah 2: Gunakan alat MsgBoxViewer

Mengumpulkan MsgBoxViewer data sementara Anda mereproduksi masalah.

MsgBoxViewer alat berguna untuk mengatasi masalah karena menyediakan laporan HTML yang memiliki informasi rinci tentang tabel ukuran dan menghitung baris. Laporan juga dapat membantu menentukan apakah BizTalk Server throttling. Selain itu, alat ini menyediakan snapshot dari BizTalk Server database dan konfigurasi BizTalk Server.

Untuk informasi lebih lanjut tentang cara men-download alat MsgBoxViewer, kunjungi website Microsoft berikut:Untuk informasi lebih lanjut tentang throttling di BizTalk Server, kunjungi website MSDN berikut:Ketika BizTalk Server berjalan lebih lambat dari biasanya, jalankan alat MsgBoxViewer, dan kemudian memeriksa laporan HTML yang dihasilkan untuk setiap masalah. The Ringkasan bagian daftar peringatan di kuning dan potensi masalah merah.

Selain itu, Anda dapat menggunakan alat MsgBoxViewer untuk menentukan tabel yang terbesar dan memiliki catatan kebanyakan output. Tabel berikut mencantumkan tabel BizTalk Server yang biasanya tumbuh terbesar. Anda dapat menggunakan data ini untuk menentukan di mana masalah potensial mungkin ada. Pertimbangkan skenario berikut.

Nama hostQ_Suspended tabel

Jika Nama hostQ_Suspended tabel memiliki banyak catatan, tabel bisa berlaku ditangguhkan komponen yang tercantum dalam Kelompok Hub atau dalam TOPI. Hal ini dapat dihentikan. Jika hal ini tidak muncul di Kelompok Hub atau dalam TOPI, contoh-contoh mungkin cache contoh atau yatim piatu routing kegagalan laporan. Ketika ditangguhkan contoh dihentikan, item dalam tabel ini dan mereka terkait baris dalam tabel spul dan contoh yang dibersihkan.

Dalam skenario ini, menangani kasus ditangguhkan oleh resume mereka atau mengakhiri mereka. Alat BizTalk Terminator juga dapat digunakan.

Nama hostQ tabel

Jika Nama hostQ tabel memiliki banyak catatan, jenis berikut contoh mungkin ada:

• Siap menjalankan contoh
• Contoh aktif
• Contoh dehidrasi

BizTalk Server membutuhkan waktu untuk "mengejar" dan proses contoh. Tabel ini dapat tumbuh ketika tingkat masuk pengolahan outpaces tingkat keluar pengolahan. Skenario ini dapat terjadi ketika terjadi masalah lain, seperti BizTalkDTADb besar database atau SQL Server disk penundaan.

Menghimpun, bagian, dan fragmen tabel

Jika tabel spul, bagian, dan fragmen memiliki banyak catatan, banyak pesan sedang aktif, dehidrasi, atau ditangguhkan. Tergantung pada ukuran, jumlah bagian dan pengaturan fragmentasi dalam tabel ini, sebuah pesan tunggal dapat menelurkan semua tabel ini. Setiap pesan telah tepat satu baris dalam tabel spul dan setidaknya satu baris dalam tabel bagian.

Contoh tabel

BizTalk Administrator harus tidak memungkinkan untuk banyak kasus ditangguhkan untuk tetap dalam tabel contoh. Contoh dehidrasi hanya harus tetap jika logika bisnis memerlukan berjalan lama orchestrations. Ingat contoh satu layanan dapat dikaitkan dengan banyak pesan dalam tabel spul.

TrackingData_x_x Tabel

Jika TrackingData_x_x Tabel besar, pelacakan host (TDDS) tidak menjalankan atau tidak menjalankan berhasil. Jika pelacakan host contoh berjalan, meninjau log peristiwa dan TDDS_FailedTrackingData tabel dalam database BizTalkDTADb untuk informasi kesalahan. Jika BizTalk throttling dengan keadaan 6 (besar database), tabel ini juga akan disingkat dengan menggunakan alat BizTalk Terminator.

Jika ada kesenjangan yang besar antara urutan nomor di BizTalkMsgBoxDb TrackingData_x_x tabel dan tabel BAMPrimaryImport atau BizTalkDTADb TDDS_StreamStatus, kemudian TDDS mungkin tidak memindahkan data dari BizTalkMsgBoxDb database. Untuk memperbaiki ini, gunakan alat BizTalk Terminator untuk membersihkan tabel ini dan mengatur ulang urutan nomor.

Pada BizTalk Server 2006 R2, menginstal BizTalk 2006 R2 Paket Layanan 1 untuk mengatasi masalah yang dikenal dengan data pelacakan. Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Tabel Tracking_Spool1 atau Tracking_Spool2

Jika tabel Tracking_Spool1 atau Tracking_Spool2 menjadi besar di BizTalk Server 2004 SP1 dan versi sebelumnya BizTalk Server 2004, mengkonfirmasi bahwa TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server agen pekerjaan diaktifkan dan berjalan.

Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Untuk informasi lebih lanjut tentang sampel Database pemeliharaan SDK, kunjungi website MSDN berikut:

dta_DebugTrace meja dan dta_MessageInOutEvents

Tabel dta_DebugTrace dihuni ketika Bentuk awal dan akhir diaktifkan pada orkestrasi. Jika tabel dta_DebugTrace memiliki banyak catatan, peristiwa debugging orkestrasi sedang digunakan atau sedang digunakan. Jika orkestrasi debugging ini tidak diperlukan untuk operasi biasa, Hapus centang pada kotak untuk Bentuk awal dan akhir pilihan properti orkestrasi.

Tabel dta_MessageInOutEvents dihuni ketika Pesan mengirim dan menerima diaktifkan pada orchestrations dan/atau pipa. Jika peristiwa pelacakan ini tidak diperlukan, Hapus centang pada kotak untuk opsi ini di orkestrasi dan/atau pipa properti.

Jika peristiwa jejak dinonaktifkan atau jika ada jaminan simpanan dalam BizTalkMsgBoxDb database, tabel ini dapat terus tumbuh karena TDDS terus bergerak data ini ke dalam tabel ini.

Secara default, global pelacakan diaktifkan. Jika pelacakan global tidak diperlukan, dapat dinonaktifkan. Untuk informasi lebih lanjut, kunjungi website Microsoft berikut:Jika tabel dta_DebugTrace dan/atau dta_messageInOutEvents tabel dalam BizTalkDTADb database terlalu besar, Anda dapat memotong meja secara manual setelah Anda menghentikan pelacakan host. BizTalk Terminator alat ini juga menyediakan fungsi ini.

Dalam BizTalk Server 2004, lihat dtav_FindMessageFacts di BizTalkDTADb database mencegah tabel dta_MessageInOutEvents truncating. Untuk mengatasi perilaku ini, ikuti langkah berikut:

1. Berhenti pelacakan host dan DTA membersihkan dan arsip pekerjaan.
2. Jika Anda ingin memotong dta_messageInOutEvents meja, menyimpan dan kemudian menghapus pandangan dtav_FindMessageFacts. Untuk melakukannya, ikuti langkah-langkah berikut:
   1. Dalam SQL Server, mengakses lihat dtav_FindMessageFacts di BizTalkDTADb database.
   2. Klik kanan dtav_FindMessageFacts Lihat, klik Semua tugas, lalu klik Menghasilkan skrip SQL. Ketika Menghasilkan skrip SQL membuka kotak dialog, membuat tidak ada perubahan, dan kemudian klik Oke.
   3. Nama file dtav_FindMessageFacts.sql, dan kemudian klik Simpan.
   4. Klik kanan dtav_FindMessageFacts melihat, dan kemudian klik Hapus. Klik Drop semua.

Anda sekarang dapat memotong table(s). Jika Anda memotong dta_messageInOutEvents meja, Anda juga harus memotong tabel dta_url. Tabel dta_url hanya ada di BizTalk Server 2004.

Ketika Anda selesai, ikuti langkah berikut untuk kembali menciptakan tampilan dtav_FindMessageFacts:

1. Buka permintaan baru dalam SQL Server.
2. Dalam Database tersedia Daftar, pilih BizTalkDTADb database.
3. Menjalankan skrip disimpan dtav_FindMessageFacts.sql. Ini akan menciptakan kembali pandangan dalam BizTalkDTADb database.

Restart host pelacakan dan DTA membersihkan dan arsip pekerjaan.

Untuk informasi lebih lanjut tentang pelacakan database ukuran pedoman, kunjungi website MSDN berikut:

meja dta_ServiceInstanceExceptions

Tabel dta_ServiceInstanceExceptions biasanya menjadi besar di lingkungan yang secara teratur telah menunda kasus.

Langkah 3: Menyelidiki kebuntuan skenario

Dalam skenario kebuntuan, mengaktifkan DBCC melacak server SQL sehingga informasi kebuntuan ditulis SQLERROR log.

Dalam SQL Server 2005 dan versi yang lebih baru, jalankan pernyataan berikut:Dalam SQL Server 2000, mengeksekusi pernyataan berikut:Selain itu, menggunakan utilitas PSSDiag untuk mengumpulkan data pada Kunci: kebuntuan acara danKunci: kebuntuan rantai acara.

BizTalkMsgBoxDB database adalah volume tinggi dan tinggi-transaksi Online Transaction Processing (OLTP) database. Beberapa deadlocking diharapkan, dan deadlocking ini ditangani secara internal oleh mesin BizTalk Server. Ketika perilaku ini terjadi, tidak ada kesalahan tercantum dalam log kesalahan. Ketika Anda menyelidiki kebuntuan skenario, kebuntuan yang Anda sedang menyelidiki dalam output harus berkorelasi dengan kesalahan kebuntuan dalam log peristiwa.

Untuk informasi lebih lanjut tentang PSSDiag SQL, klik nomor artikel berikut ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

Langkah 4: Mencari diblokir proses

Gunakan Activity Monitor di SQL Server untuk mendapatkan server pengidentifikasi proses (SPID) dari proses sistem penguncian. Kemudian, jalankan SQL Profiler untuk menentukan pernyataan SQL yang mengeksekusi di SPID penguncian.

Untuk memecahkan masalah penguncian dan memblokir dalam SQL Server, menggunakan PSSDiag untuk SQL utilitas untuk menangkap semua peristiwa Transact-SQL yang memiliki script memblokir diaktifkan.

Dalam SQL Server 2005 dan versi yang lebih baru, Anda dapat menentukan diblokir proses ambang pengaturan untuk menentukan yang SPID atau SPIDs yang menghalangi melebihi ambang batas yang Anda tetapkan.

Untuk informasi lebih lanjut tentang PSSDiag SQL, klik nomor artikel berikut ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft: Untuk informasi lebih lanjut tentang ambang batas diblokir proses, kunjungi website MSDN berikut: Catatan Ketika Anda mengalami penguncian atau persoalan blokir dalam SQL Server, kami sarankan agar Anda menghubungi layanan dukungan pelanggan Microsoft. Layanan dukungan pelanggan Microsoft dapat membantu Anda mengkonfigurasi opsi utilitas PSSDiag benar.

Langkah 5: Menginstal paket layanan terbaru BizTalk Server dan pembaruan kumulatif

BizTalk Server 2006 R2 dan versi telah pindah ke model pembaruan kumulatif (CU). Pembaruan Kumulatif akan berisi perbaikan terbaru panas. BizTalk Server 2006 R2 Service Pack 1 juga tersedia:BizTalk Server 2004 SP1 memiliki built-in tidak membersihkan dan pengarsipan fungsionalitas untuk BizTalkDTADb database. Fungsi ini disertakan dengan BizTalk Server 2004 SP2. Tergantung pada ukuran basis data BizTalkDTADb, menginstal BizTalk Server 2004 SP2 dapat mengambil jam karena program penataan pembersihan BizTalkDTADb database.

Untuk informasi tentang dikenal masalah ketika Anda menginstal BizTalk Server 2004 Paket Layanan 2, klik nomor artikel berikut ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

Ketika Anda menginstal BizTalk Server 2004 SP2, kami menyarankan Anda untuk mengikuti langkah-langkah berikut:

1. Menginstal perbaikan terbaru dalam Basis Pengetahuan Microsoft artikel 894253. Ikuti langkah-langkah pada artikel Basis Pengetahuan ini untuk melaksanakan bts_tracking_shrinkexistingdatabase.sql skrip SQL Server 2000. Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
   894253 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;894253) FIX: dtasp_PruneTrackingdatabase() disimpan prosedur dapat mengambil banyak waktu untuk membersihkan database DTA di BizTalk Server 2004
2. Menginstal BizTalk Server 2004 SP2. Untuk informasi selengkapnya, klik nomor artikel berikut untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
   888751 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;888751) Cara mendapatkan paket layanan BizTalk Server 2004

Hapus semua data

Jika database terlalu besar atau jika metode yang disukai untuk menghapus semua data, semua data dapat dihapus.

Perhatian Tidak menggunakan metode ini dalam lingkungan di mana data bisnis penting atau jika data yang diperlukan.

BizTalkMsgBoxDb Database membersihkan langkah

Untuk menghapus semua data dalam BizTalkMsgBoxDb database, Anda dapat menggunakan alat BizTalk Terminator. Jika tidak, ikuti langkah berikut ini.

Catatan Tindakan ini menghapus semua pesan. Menjadi sangat berhati-hati jika Anda mengikuti langkah-langkah dalam lingkungan produksi.

1. Membuat cadangan semua BizTalk Server database. Ingat, BizTalkMgmtDb.dbo.sp_ForceFullBackup disimpan prosedur dapat digunakan untuk memaksa full backup data dan log file. Melaksanakan prosedur ini disimpan, dan kemudian jalankan pekerjaan cadangan BizTalk Server SQL agen.
2. Salin skrip Msgbox_cleanup_logic.sql dari Kandar: \Program Files\Microsoft BizTalk 200x\schema ke SQL Server.
3. Mengeksekusi skrip SQL ini terhadap BizTalkMsgBoxDb database untuk memperbarui bts_CleanupMsgbox disimpan prosedur.
4. Menghentikan semua BizTalk host, layanan, dan kustom terisolasi adapter. Jika Anda menggunakan HTTP atau adaptor SABUN, restart layanan IIS.
5. Melaksanakan prosedur bts_CleanupMsgbox disimpan pada semua database BizTalkMsgBoxDb.
6. Restart semua host contoh dan BizTalk Server layanan.

Untuk informasi tentang masalah yang dikenal dengan prosedur bts_CleanupMsgbox disimpan di BizTalk Server 2006, klik nomor artikel berikut ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

BizTalkDTADb database membersihkan pilihan

Untuk menghapus semua data dari BizTalkDTADb database, Anda dapat menggunakan alat BizTalk Terminator. Jika tidak, gunakan salah satu metode berikut.

Catatan Kedua metode menghapus semua pesan. Metode 2 lebih cepat.

• Metode 1:
  1. Membuat cadangan semua BizTalk Server database.
  2. Melaksanakan prosedur dtasp_PurgeAllCompletedTrackingData disimpan. Untuk informasi lebih lanjut tentang prosedur dtasp_PurgeAllCompletedTrackingData disimpan, kunjungi website MSDN berikut:
     http://MSDN.Microsoft.com/en-us/library/aa561918.aspx (http://msdn.microsoft.com/en-us/library/aa561918.aspx)
     Catatan Tindakan ini menghapus pesan semua selesai.
• Metode 2:
  1. Membuat cadangan semua database BizTalk.
  2. Melaksanakan prosedur dtasp_CleanHMData disimpan. Hanya Gunakan opsi ini apabila BizTalkDTADb database berisi banyak contoh lengkap yang harus dihapus.
     
     Untuk melakukannya, ikuti langkah-langkah berikut:
     1. Menghentikan semua BizTalk host, layanan, dan kustom terisolasi adapter. Jika Anda menggunakan HTTP atau adaptor SABUN, restart layanan IIS.
     2. Melaksanakan prosedur dtasp_CleanHMData disimpan pada BizTalkDTADb database.
     3. Restart semua host dan layanan BizTalk Server.

Langkah-langkah yang hanya BizTalk Server 2004

Untuk menghapus semua data dari database BizTalkDTADb di BizTalk Server 2004, ikuti langkah berikut.

Catatan Tindakan ini menghapus pesan semua selesai.

1. Membuat cadangan semua BizTalk Server database.
2. Menghentikan semua BizTalk host, layanan, dan kustom terisolasi adapter. Jika Anda menggunakan HTTP atau adaptor SABUN, restart layanan IIS.
3. Menginstal perbaikan terbaru dalam Basis Pengetahuan Microsoft artikel 894253. Ikuti langkah-langkah pada artikel Basis Pengetahuan ini untuk menjalankan Bts_tracking_shrinkexistingdatabase.sql script di SQL Server 2000.
   
   Untuk informasi tentang dtasp_PruneTrackingdatabase disimpan prosedur, klik nomor artikel berikut ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
   894253 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;894253) FIX: dtasp_PruneTrackingdatabase() disimpan prosedur dapat mengambil banyak waktu untuk membersihkan database DTA di BizTalk Server 2004
4. Restart semua host dan BizTalk layanan.

Catatan Jika Anda harus memiliki data pelacakan, cadangan BizTalkDTADb database, memulihkan database SQL Server, dan kemudian membersihkan database BizTalkDTADb asli.

Jika Anda memerlukan bantuan untuk menganalisis MsgBoxViewer data atau PSSDiag output, hubungi layanan dukungan pelanggan Microsoft. Untuk daftar lengkap nomor telepon layanan dukungan pelanggan dan informasi tentang biaya dukungan, kunjungi website Microsoft berikut: Catatan Sebelum Anda menghubungi layanan dukungan pelanggan, kompres MsgBoxViewer data, PSSDiag output, dan log peristiwa diperbarui (.evt file). Anda mungkin harus mengirim file ini ke BizTalk Server mendukung insinyur.