Kami memiliki dua Server SQL produksi yang menjalankan SQL Server 2005 SP4 dengan pembaruan kumulatif 3. Kedua server berjalan pada mesin fisik yang identik. DELL PowerEdge R815 dengan 4 x 12 core CPU dan ram 512GB (ya GB), dengan drive terhubung iSCSI SAN 10GB untuk semua database dan log SQL. OS adalah Microsoft Windows Server 2008 R2 Enterprise edisi dengan semua pembaruan SP dan windows. Drive OS adalah array RAID 5 drive SAS 15 x 3GB 2.5 "15k. SAN adalah Dell EqualLogic 6510 dengan drive 48 x 10K SAS 3.5", dikonfigurasi dalam RAID 50, diiris ke dalam berbagai LUN untuk 2 SQL Server, dan juga dibagikan dengan mesin Exchange dan beberapa server VMWare.
Kami memiliki lebih dari 20 database, 11 di antaranya dicerminkan dengan ketersediaan tinggi menggunakan server saksi. Server saksi adalah mesin bertenaga lebih rendah yang menjalankan contoh SQL Server yang digunakan untuk memberikan layanan saksi. Database cermin terbesar adalah 450GB dan menghasilkan sekitar 100-300 iops. Database Mirroring Monitor melaporkan kecepatan pengiriman saat ini sekitar 100kb hingga 10mb per detik, dan mirror melakukan overhead (biasanya) 0 milidetik. Server mirror tidak memiliki masalah mengikuti prinsipal.
Kami secara konsisten mengalami kegagalan mirroring. Terkadang satu basis data akan gagal, di lain waktu hampir semua basis data akan gagal secara bersamaan. Misalnya, tadi malam, kami memiliki 10 dari 11 basis data failover, basis data lainnya tetap dapat diakses sampai saya secara manual gagal.
Saya telah melalui beberapa langkah pemecahan masalah untuk mencoba mengidentifikasi masalah, tetapi sejauh ini belum dapat menyelesaikan masalah:
1) Mesin tersebut datang dengan adaptor jaringan Gigabit Broadcom BCM5709C NetXtreme II 4 yang awalnya kami gunakan sebagai koneksi jaringan utama. Kami telah menginstal Adaptor Dual Port Server PT Intel (R) PRO / 1000 pada kedua mesin untuk menghilangkan NIC sebagai masalah.
2) Semua database memiliki cadangan penuh otomatis setiap malam bersama dengan cadangan log untuk database yang terlibat dalam mirroring. Penggunaan file log dipantau dan jarang digunakan di atas 15%. File log untuk database utama adalah 125GB, terdiri dari 159 file log virtual dengan ukuran mulai dari 511MB hingga 1GB. TempDB menggunakan LUN sendiri, dan terdiri dari file 24 x 2GB.
3) Log SQL Server pada saksi tidak menunjukkan kesalahan selain: Koneksi mirroring ke "TCP: //SQL02.DOMAIN.INET: 5022" telah kehabisan waktu untuk basis data "Data" setelah 30 detik tanpa tanggapan. Periksa layanan dan koneksi jaringan.
Log SQL Server pada server primer dan sekunder menunjukkan pesan yang berkaitan dengan mirroring:
Sambungan mirroring ke "TCP: //SQL01.DOMAIN.INET: 5022" telah kehabisan waktu untuk database "Data" setelah 30 detik tanpa tanggapan. Periksa layanan dan koneksi jaringan.
Basis data yang dicerminkan "Data" mengubah peran dari "PRINCIPAL" menjadi "MIRROR" karena Sinkronisasi Peran. (Sinkronisasi salah eja di sini karena sengaja seperti itulah tampilan pesan yang sebenarnya.)
Basis data yang dicerminkan "Data" mengubah peran dari "PRINCIPAL" menjadi "MIRROR" karena Failover.
Basis data yang dicerminkan "Data" mengubah peran dari "MIRROR" menjadi "PRINCIPAL" karena Failover dari mitra.
Layanan SQL Server terus berjalan dan koneksi jaringan tampaknya tetap terjaga. Kami secara konsisten memiliki antara 500 hingga 2500 sesi yang terhubung ke setiap server (terutama aplikasi robot yang terhubung ke antrian broker layanan pada satu basis data).
4) TCP Chimney dan RSS dll dinonaktifkan menggunakan sintaks NET SH.
5) Saya telah menjalankan SQL Server 2005 Praktik Praktis Terbaik terhadap kedua mesin dan menemukan apa-apa selain kesalahan Event Log 833 Aplikasi yang sangat sesekali, tidak ada yang bertepatan dengan peristiwa failover:
SQL Server telah menemukan 1 kemunculan permintaan I / O yang membutuhkan waktu lebih dari 15 detik untuk diselesaikan pada file [F: \ Data.MDF] dalam database [Data] (9). Pegangan file OS adalah 0x0000000000001010A0. Offset dari I / O panjang terbaru adalah: 0x000007d4b10000).
6) Kadang-kadang kita melihat "Klien tidak dapat menggunakan kembali sesi dengan SPID XXX, yang telah direset untuk pooling koneksi. Kesalahan ini mungkin disebabkan oleh kegagalan operasi sebelumnya. Periksa log kesalahan untuk operasi yang gagal segera sebelum pesan kesalahan ini . " dihasilkan oleh kedua server. Tampaknya tidak ada pesan "sebelumnya" yang menunjukkan masalah apa pun.
7) Kadang-kadang surat basis data menulis kesalahan pada log peristiwa Aplikasi:
Jenis Pengecualian: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Pesan: Ada kesalahan pada koneksi. Alasan: Batas waktu kedaluwarsa. Periode waktu habis berlalu sebelum penyelesaian operasi atau server tidak merespons., Parameter koneksi: Nama Server: MGSQL02, Nama Database: msdb Data: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common. SqlConnectionInfo) HelpLink: NULL Sumber: DatabaseMailEngine
StackTrace Informasi di Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) di Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenCord String, stringpermode, Stringer string, StringName, Stringer, Stringer, Stringer, stringname ) di Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)
Saya percaya Timeout menyebabkan kegagalan; apa yang bisa menyebabkan batas waktu ini? Jelas jika ada masalah jaringan yang sebenarnya seperti kabel yang buruk, atau saklar yang buruk, yang dapat menyebabkan paket kehilangan dan karena itu timeout, namun hal-hal apa lagi yang dapat menyebabkan timeout? Pemblokiran? Jika MSDB, atau beberapa basis data sistem lainnya memiliki batas waktu I / O yang dapat menyebabkan mirrorover failover?
Terima kasih atas sarannya!
MSDN memiliki pendapat berikut tentang mekanisme batas waktu itu sendiri :
Mekanisme Time-Out Mirroring
Karena kesalahan lunak tidak dapat dideteksi secara langsung oleh instance server, kesalahan lunak berpotensi menyebabkan instance server menunggu tanpa batas. Untuk mencegah hal ini, mirroring basis data mengimplementasikan mekanisme time-out-nya sendiri, berdasarkan pada setiap instance server dalam sesi mirroring yang mengirimkan ping pada setiap koneksi terbuka pada interval tetap.
Agar koneksi tetap terbuka, instance server harus menerima ping pada koneksi tersebut dalam periode batas waktu yang ditentukan, ditambah waktu yang diperlukan untuk mengirim satu ping lagi. Menerima ping selama periode waktu habis menunjukkan bahwa koneksi masih terbuka dan server sedang berkomunikasi tentang hal itu. Saat menerima ping, instance server me-reset penghitung waktu habisnya pada koneksi itu.
Jika tidak ada ping yang diterima pada koneksi selama periode time-out, sebuah instance server menganggap koneksi telah habis. Server instance menutup koneksi time-out dan menangani event time-out sesuai dengan keadaan dan mode operasi sesi.
netsh interface tcp show global menunjukkan:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disablednetsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510SELECT name, value_in_use FROM sys.configurations
Kueri Terdistribusi Ad Hoc 0
topeng I / O afinitas 0
topeng afinitas 0
affinity64 I / O mask 0
topeng afinitas64 0
Agen XPs 1
bolehkan pembaruan 0
awe diaktifkan 0
ambang batas proses yang diblokir 5
mode audit c2 0
CLR diaktifkan 1
kepatuhan kriteria umum diaktifkan 0
ambang biaya untuk paralelisme 4
chaining lintas kepemilikan db 0
ambang kursor -1
Database Mail XPs 1
bahasa teks lengkap standar 1033
bahasa default 0
penelusuran bawaan diaktifkan 1
larang hasil dari pemicu 0
faktor isi (%) 0
ft crawl bandwidth (maks) 100
ft crawl bandwidth (min) 0
ft beri tahu bandwidth (maks) 100
ft beri tahu bandwidth (min) 0
index create memory (KB) 0
resolusi xact dalam keraguan 0
pooling ringan 0
mengunci 0
derajat paralelisme maks. 6
maks. merangkak teks lengkap maks. 4
memori server maks (MB) 393216
ukuran penggantian teks maks (B) 65536
utas pekerja maks 0
penyimpanan media 0
memori minimum per kueri (KB) 2048
memori server minimal (MB) 52427
pemicu bersarang 1
ukuran paket jaringan (B) 1400
Prosedur Otomasi Ole 1
objek terbuka 0
Batas waktu PH 60
peringkat precompute 0
dorongan prioritas 0
batas biaya permintaan gubernur 0
permintaan menunggu -1
interval pemulihan (min) 0
akses jarak jauh 1
koneksi admin jarak jauh 0
batas waktu login jarak jauh 20
remote proc trans 0
batas waktu kueri jarak jauh 600
Replikasi XPs 0
memindai procs startup 0
server memicu rekursi 1
set working set size 0
tampilkan opsi lanjutan 1
SMO dan DMO XP 1
SQL Mail XPs 0
mengubah kata-kata derau 0
cutoff tahun dua digit 2049
koneksi pengguna 0
opsi pengguna 4216
Prosedur Asisten Web 0
xp_cmdshell 1
Beberapa waktu yang lalu, saya secara manual mengubah mirroring_connection_timeoutnilai untuk semua database yang dicerminkan ke 30 detik untuk mencoba memperbaiki masalah; ini hanya meningkatkan jumlah waktu antara peristiwa failover. Dengan mirroring_connection_timeoutpengaturan ditetapkan pada default 10 detik, kita melihat lebih banyak kegagalan .
Sebuah komentar telah meminta saya untuk memastikan IPSec dinonaktifkan, jadi saya memposting konten beberapa netshperintah yang menampilkan konfigurasi IPSec dari sistem operasi:
C: \> netsh ipsec dinamis tampilkan semua Tidak ada Kebijakan yang ditugaskan saat ini Kebijakan Mainmode tidak tersedia. Kebijakan Quickmode tidak tersedia. Filter Mainmode Generik tidak tersedia. Filter Mainmode spesifik tidak tersedia. Filter Quickmode Generik tidak tersedia. Filter Quickmode spesifik tidak tersedia. Asosiasi Keamanan MainMode IPsec tidak tersedia. Asosiasi Keamanan QuickMode IPsec tidak tersedia. Parameter Konfigurasi IPsec ------------------------------ StrongCRLCheck: 1 Pengecualian IP: 3 Statistik IPsec ---------------- Assoc Aktif: 0 Melepas SA: 0 Kunci Tertunda: 0 Menambahkan Kunci: 0 Penghapusan Kunci: 0 ReKeys: 0 Terowongan Aktif: 0 Poin SPI salah: 0 Pkts tidak didekripsi: 0 Pkts tidak Otentikasi: 0 Pkts dengan Deteksi Putar Ulang: 0 Bytes Rahasia Terkirim: 0 Bytes Rahasia Diterima: 0 Bytes Terkonfirmasi Dikirim: 0 Bytes yang Diterima Diterima: 0 Transport Bytes Sent: 0 Transport Bytes Diterima: 0 Bytes Sent In Tunnels: 0 Bytes Diterima Di Terowongan: 0 Bytes yang Dibongkar: 0 Bytes yang Diterima Diterima: 0 C: \> netsh ipsec static tampilkan semua ERR IPsec [05072]: Tidak Ada Kebijakan di Toko Kebijakan
UPDATE: 2012-12-20
Kami sekarang telah memindahkan sistem produksi kami ke SQL Server 2012. Kami telah menjalankan ini sejak pagi hari 17 Desember - sejauh ini tidak ada failover. Namun, beberapa hari baik dalam apa yang kita lihat dengan sistem berbasis 2005.
Dalam upaya untuk mendokumentasikan kinerja sistem baru kami, saya telah melihat sys.dm_os_wait_statslebih hati-hati; dan perhatikan DBMIRROR_DBM_EVENT, yang merupakan tipe tunggu tidak berdokumen. Graham Kent di Microsoft memiliki artikel yang menarik tentang pemecahan masalah kegagalan tak terduga dan jenis tunggu ini. Saya akan rekap temuannya di sini:
Pelanggan mengalami rantai pemblokiran besar yang dibangun di atas basis data OLTP volume tinggi di mana semua blocker sedang menunggu di DBMIRROR_DBM_EVENT. Berikut adalah urutan kejadian yang saya alami:
Tinjau rantai pemblokiran itu sendiri - ho bantu di sini karena yang bisa kita lihat adalah bahwa kita sedang menunggu di DBMIRROR_DBM_EVENT
Tinjau sumber untuk jenis menunggu tidak berdokumen. Jelas Anda tidak dapat melakukan ini di luar MS, tetapi saya dapat mengatakan bahwa pada saat penulisan jenis tunggu ini mewakili menunggu yang digunakan ketika kepala sekolah sedang menunggu cermin untuk mengeraskan suatu LSN, yang berarti bahwa transaksi yang menjadi bagiannya tidak dapat dilakukan . Ini langsung menunjuk secara spesifik pada masalah yang tidak bisa dilakukan transaksi karena menunggu di cermin. Sekarang kita perlu menyelidiki mengapa cermin tidak melakukan transaksi atau mengapa kepala sekolah tidak tahu apakah itu.
Tinjau tabel sistem msdb
(a) Lihat tabel [backupset] untuk melihat apakah ukuran log yang dihasilkan pada saat masalah secara signifikan lebih tinggi daripada normal. Jika mereka sangat besar, mungkin saja cermin itu dibanjiri transaksi dan tidak bisa mengikuti volume. Inilah sebabnya buku online akan memberi tahu Anda terkadang menonaktifkan mirroring jika Anda perlu melakukan operasi log yang sangat besar seperti pembuatan ulang indeks. (referensi untuk alasan ini ada di http://technet.microsoft.com/en-us/library/cc917681.aspx ). Di sini saya menggunakan TSQL berikut
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(B) kedua saya melihat data dalam tabel [dbm_monitor_data]. Kuncinya di sini adalah untuk menemukan jangka waktu di mana kami memiliki masalah dan kemudian melihat apakah kami mengalami perubahan signifikan dalam hal-hal berikut:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateIni semua adalah indikator yang mirip dengan bagian (a) karena mereka mungkin menunjukkan komponen atau bagian dari arsitektur yang tidak merespons. Misalnya jika send_queue tiba-tiba mulai tumbuh tetapi antrian re_do tidak tumbuh, maka itu berarti kepala sekolah tidak dapat mengirim catatan log ke cermin sehingga Anda mungkin ingin melihat konektivitas mungkin, atau antrian broker layanan berurusan dengan transmisi yang sebenarnya.
Dalam skenario khusus ini kami mencatat bahwa semua penghitung tampaknya memiliki nilai aneh, dalam bahwa ada cadangan log yang terjadi dengan ukuran normal, tetapi tidak ada perubahan status, 0 antrian kirim, 0 antrean ulangan, laju kirim datar dan flat tingkat ulang. Ini sangat aneh karena menyiratkan bahwa Monitor DBM tidak dapat merekam nilai apa pun dari mana pun selama periode masalah.
Tinjau log galat SQL Server. Dalam hal ini tidak ada kesalahan atau pesan informasi apa pun, tetapi dalam skenario lain seperti ini, sangat umum untuk kesalahan dalam rentang 1400 yang dilaporkan, contoh yang dapat Anda temukan di tempat lain di blog mirroring saya yang lain, seperti contoh Galat 1413 ini
Tinjau file jejak default - dalam skenario ini saya tidak diberikan jejak default, namun mereka adalah sumber informasi masalah DBM yang fantastis, karena mereka merekam acara perubahan keadaan pada semua mitra. Ini didokumentasikan di sini:
Database Mirroring State Ubah Event Class
Ini sering memberi Anda gambaran yang bagus tentang skenario seperti ketika konektivitas jaringan gagal antara satu atau semua mitra dan kemudian menjadi apa keadaan kemitraan setelahnya.
KESIMPULAN:
Dalam skenario khusus ini saya saat ini kehilangan 2 poin kunci data, tetapi selain itu saya masih bisa membuat hipotesis yang masuk akal pada informasi di atas. Kita tentu dapat mengatakan bahwa pemblokiran disebabkan oleh fakta bahwa DBM diaktifkan karena pemblokir semua menunggu pada jenis tunggu DBMIRROR_DBM_EVENT. Karena kita tahu bahwa kita tidak membanjiri cermin dengan operasi besar yang dicatat dan bahwa penyebaran ini biasanya berjalan dengan bahagia dalam mode ini, kita dapat mengecualikan operasi besar yang tidak biasa. Ini berarti bahwa kami memiliki 2 kandidat potensial pada tahap ini:
Masalah perangkat keras pada konektivitas antara beberapa atau semua mitra.
Kelelahan CPU pada server mirror - hanya tidak bisa mengikuti redos - kelelahan CPU itu sendiri bisa berasal dari proses di luar SQL Server atau di luar kemitraan cermin ini.
Masalah dengan kode mirroring itu sendiri (kita benar-benar membutuhkan beberapa dump memori untuk mengkonfirmasi ini).
Berdasarkan pengalaman yang saya curigai 1 atau 2, tetapi saya selalu berpikiran terbuka tentang 3 juga, kami mencoba untuk mengumpulkan beberapa data sekarang untuk melihat masalah ini secara lebih rinci.
sumber
Jawaban:
Sepertinya Anda mungkin kehabisan port TCP pada SQL Server. Berapa banyak koneksi yang Anda lihat ke server sekaligus?
Waktu tunggu seperti itu pasti akan menyebabkan masalah.
sumber
Bisakah Anda memeriksa Anda
sys.dm_os_schedulers? Secara khusus, apakahwork_queue_countmenyimpang dari 0 untuk waktu yang signifikan? Ini akan mengindikasikan kelaparan pekerja dan akan menjelaskan banyak gejala Anda.sumber
sys.dm_os_schedulerstidak menunjukkan hasil untukSELECT * FROM sys.dm_os_schedulers WHERE work_queue_count > 0;- haruskah saya merekam ini setiap menit?