Ringkasan
Ketika Anda menggunakan pengandar SQL Server ODBC, SQL Server penyedia OLE DB, atau penyedia terkelola System.Data.SqlClient, Anda dapat menonaktifkan koneksi penggabungan dengan menggunakan antarmuka pemrograman aplikasi masing-masing (api). Ketika Anda menonaktifkan penggabungan, tekanan pada dasar SQL Server jaringan Perpustakaan dapat meningkat apabila aplikasi seringkali membuka dan menutup sambungan. Artikel ini menjelaskan pengaturan TCP/IP tertentu yang Anda mungkin harus menyesuaikan kondisi ini.
Informasi lebih lanjut
Mematikan penggabungan dapat menyebabkan pengandar jaringan SQL Server dasar untuk dengan cepat membuka dan menutup sambungan soket baru ke komputer yang menjalankan SQL Server. Anda mungkin harus mengubah pengaturan soket TCP/IP asali untuk sistem operasi dan komputer yang menjalankan SQL Server untuk menangani tingkat tekanan yang lebih tinggi.
Perhatikan bahwa hanya artikel ini membahas pengaturan yang mempengaruhi SQL Server jaringan Perpustakaan saat Anda menggunakan protokol TCP/IP. Mematikan penggabungan juga dapat menyebabkan masalah yang berkaitan dengan tekanan dengan protokol SQL Server lain seperti bernama pipa, tetapi artikel ini membahas topik ini. Artikel ini ditujukan bagi pengguna lanjut saja. Jika Anda tidak memahami topik di artikel ini, Microsoft menganjurkan bahwa Anda melihat buku baik tentang soket TCP/IP.
Perhatikan bahwa Microsoft sangat menyarankan Anda untuk selalu menggunakan penggabungan dengan pengandar SQL Server. Menggunakan penggabungan sangat meningkatkan keseluruhan kinerja pada sisi klien dan SQL Server sisi saat Anda menggunakan pengandar SQL Server. Menggunakan penggabungan juga jauh mengurangi lalu lintas jaringan untuk komputer yang menjalankan SQL Server. Sebagai contoh, uji contoh yang digunakan 20.000 SQL Server sambungan membuka dan menutup dengan penggabungan diaktifkan digunakan sekitar 160 paket jaringan TCP/IP, Total 23,520 byte aktivitas jaringan. Dengan penggabungan dinonaktifkan, uji sampel sama dihasilkan 225,129 paket jaringan TCP/IP, Total 27,209,622 byte aktivitas jaringan.
Perhatikan bahwa ketika Anda melihat ini tekanan TCP/IP soket masalah terkait dengan perpustakaan jaringan SQL Server, Anda mungkin menerima salah satu atau lebih dari pesan galat berikut saat Anda mencoba untuk menyambung ke komputer yang menjalankan SQL Server:
SQL Server tidak ada atau akses ditolak
Batas waktu kedaluwarsa
Kesalahan jaringan Umum
Penyedia TCP: Hanya satu penggunaan setiap soket alamat (protokol jaringan alamat/port) biasanya diizinkan.
Perhatikan bahwa Anda juga dapat menerima pesan galat spesifik ini apabila terjadi masalah lain dengan SQL Server; Misalnya, Anda mungkin menerima pesan galat ini jika komputer jauh yang menjalankan SQL Server dimatikan, jika komputer jauh yang menjalankan SQL Server tidak mendengarkan soket TCP/IP, jika konektivitas jaringan ke komputer yang menjalankan SQL Server rusak karena kabel jaringan dicabut, atau jika Anda mengalami masalah resolusi DNS. Pada dasarnya apa pun yang dapat menyebabkan klien gagal untuk membuka soket TCP/IP ke komputer yang menjalankan SQL Server juga dapat menyebabkan pesan galat. Namun, dengan masalah terkait tekanan soket, masalah terjadi sewaktu-waktu tekanan naik dan turun. Komputer mungkin berjalan selama jam kerja dengan tidak ada kesalahan, maka kesalahan terjadi satu atau dua kali, dan komputer kemudian berjalan selama beberapa jam dengan tidak ada kesalahan. Selain itu, apabila Anda mengalami masalah ini, Umum konektivitas ke SQL Server bekerja satu instan, gagal berikutnya, kemudian bekerja lagi instan berikutnya. Dengan kata lain, biasanya terjadi masalah terkait tekanan soket sporadis, tetapi sebenarnya masalah konektivitas jaringan dengan SQL Server biasanya terjadi sporadis.
Dua masalah utama terkait tekanan biasanya terjadi ketika Anda menonaktifkan penggabungan saat Anda menggunakan protokol SQL Server TCP/IP: Anda dapat kehabisan anonim Port pada komputer klien, atau Anda dapat melebihi WinsockListenBacklog Setelan bawaan di komputer yang menjalankan SQL Server.
Untuk informasi tambahan tentang Port anonim, klik nomor artikel di bawah ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
319502 PRB: 'WSAEADDRESSINUSE' pesan galat saat Anda mencoba untuk menyambung melalui Port anonim setelah Anda meningkatkan batas sambungan IMAP
Menyesuaikan pengaturan MaxUserPort dan TcpTimedWaitDelay
Perhatikan bahwa pengaturan MaxUserPort dan TcpTimedWaitDelay berlaku hanya untuk komputer klien yang cepat membuka dan menutup sambungan ke komputer jarak jauh yang menjalankan SQL Server dan yang tidak menggunakan sambungan penggabungan. Sebagai contoh, pengaturan ini berlaku di server layanan informasi Internet (IIS) yang merupakan layanan sejumlah besar permintaan HTTP masuk dan yang membuka dan menutup sambungan ke komputer jarak jauh yang menjalankan SQL Server dan yang menggunakan protokol TCP/IP dengan penggabungan dinonaktifkan. Jika penggabungan diaktifkan, Anda tidak harus menyesuaikan pengaturan MaxUserPort dan TcpTimedWaitDelay .
Ketika Anda menggunakan protokol TCP/IP untuk membuka sambungan ke komputer yang menjalankan SQL Server, SQL Server jaringan Perpustakaan dasar membuka soket TCP/IP ke komputer yang menjalankan SQL Server. Ketika membuka soket ini SQL Server jaringan perpustakaan tidak mengaktifkan opsi soket TCP/IP SO_REUSEADDR . Untuk informasi selengkapnya tentang pengaturan soket SO_REUSEADDR , lihat topik "Setsockopt" di Microsoft Developer Network (MSDN).
Perhatikan bahwa SQL Server jaringan Perpustakaan khusus tidak mengaktifkan opsi soket SO_REUSEADDR TCP/IP untuk alasan keamanan. Ketika SO_REUSEADDR diaktifkan, pengguna jahat dapat pembajakan port klien ke SQL Server dan menggunakan kredensial yang menyediakan klien untuk mendapatkan akses ke komputer yang menjalankan SQL Server. Secara default, karena SQL Server jaringan perpustakaan tidak mengaktifkan opsi soket SO_REUSEADDR , setiap kali Anda membuka dan menutup soket melalui Perpustakaan jaringan SQL Server di sisi klien, soket memasuki keadaan TIME_WAIT empat menit. Jika Anda dengan cepat membuka dan menutup sambungan SQL Server melalui TCP/IP dengan penggabungan dinonaktifkan, Anda dengan cepat membuka dan menutup soket TCP/IP. Dengan kata lain, setiap sambungan SQL Server memiliki satu soket TCP/IP. Jika Anda dengan cepat membuka dan menutup soket 4000 kurang dari empat menit, Anda akan mencapai maksimum Setelan bawaan untuk klien Port anonim, dan upaya sambungan soket baru gagal hingga ada serangkaian TIME_WAIT soket waktu habis.
Pada sisi klien, Anda mungkin harus meningkatkan MaxUserPort dan TcpTimedWaitDelay pengaturan yang dibahas di Q319502 saat Anda memiliki penggabungan dinonaktifkan. Pengaturan untuk nilai yang ditentukan oleh berapa banyak koneksi SQL Server akan membuka dan menutup terjadi pada sisi klien. Anda dapat memeriksa berapa banyak klien port yang dalam keadaan TIME_WAIT dengan menggunakan alat Netstat pada komputer klien. Jalankan alat Netstat dengan bendera -n sebagai berikut, dan menghitung jumlah soket klien ke alamat SQL Server IP yang berada dalam keadaan TIME_WAIT. Dalam contoh ini, alamat IP komputer jauh yang menjalankan SQL Server adalah 10.10.10.20, alamat IP komputer klien adalah 10.10.10.10 dan tiga dibuat sambungan dan dua koneksi berada dalam keadaan TIME_WAIT:
C:\>netstat -n
Active Connections
Proto Local Address Foreign Address State
TCP 10.10.10.10:2000 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2001 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2002 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2003 10.10.10.20:1433 TIME_WAIT
TCP 10.10.10.10:2004 10.10.10.20:1433 TIME_WAIT
Jika Anda menjalankan netstat -n dan Anda melihat bahwa mendekati 4000 sambungan ke alamat IP komputer target yang menjalankan SQL Server sedang dalam keadaan TIME_WAIT, dapat keduanya menambah pengaturan default MaxUserPort dan mengurangi tataan TcpTimedWaitDelay sehingga Anda tidak menjalankan dari Port anonim klien. Misalnya, Anda dapat menetapkan pengaturan MaxUserPort 20.000 dan menetapkan pengaturan TcpTimedWaitDelay 30. Pengaturan TcpTimedWaitDelay yang lebih rendah berarti bahwa soket menunggu dalam keadaan TIME_WAIT waktu kurang. Pengaturan MaxUserPort yang lebih tinggi berarti bahwa Anda dapat memiliki lebih banyak soket dalam keadaan TIME_WAIT.
Perhatikan bahwa jika Anda menyesuaikan setelan MaxUserPort atau TcpTimedWaitDelay , Anda harus memulai ulang Microsoft Windows untuk tataan baru diterapkan. Pengaturan MaxUserPort dan TcpTimedWaitDelay adalah untuk setiap komputer klien yang berbicara dengan komputer yang menjalankan SQL Server melalui soket TCP/IP. Pengaturan ini tidak memiliki efek jika mereka berada di depan komputer yang menjalankan SQL Server kecuali Anda membuat sambungan soket TCP/IP lokal ke komputer lokal yang menjalankan SQL Server.
Catatan Jika Anda menyesuaikan setelan MaxUserPort , kami menyarankan Anda untuk memesan port 1434 untuk digunakan oleh layanan SQL Server Browser (sqlbrowser.exe). Untuk informasi selengkapnya tentang cara melakukannya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
812873 cara memesan kisaran port sementara di komputer yang menjalankan Windows Server 2003 atau Windows 2000 Server
Menyesuaikan setelan WinsockListenBacklog
Untuk informasi tambahan tentang pengaturan registri SQL Server khusus ini, klik nomor artikel di bawah ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
154628 INF: SQL log 17832 dengan beberapa permintaan sambungan TCP\IP
Ketika SQL Server jaringan Perpustakaan didengarkan soket TCP/IP, SQL Server jaringan Perpustakaan menggunakan mendengarkan Winsock API. Parameter kedua untuk mendengarkan API adalah jaminan simpanan yang diizinkan untuk soket. Jaminan simpanan ini mewakili panjang maksimum antrian tertunda sambungan pendengar. Apabila panjang antrian melebihi panjang maksimum, SQL Server jaringan Perpustakaan segera menolak upaya sambungan soket TCP/IP yang lain. Selain itu, SQL Server jaringan Perpustakaan mengirimkan paket ACK + RESET.
Menggunakan SQL Server 2000 default mendengarkan jaminan simpanan pengaturan 5. Ini berarti bahwa komputer yang menjalankan SQL Server lolos 5 nilai untuk parameter jaminan simpanan mendengarkan Winsock API ketika mendengarkan API mengatur protokol TCP/IP mendengarkan benang pada komputer yang menjalankan SQL Server. Anda dapat mengatur kunci registri WinsockListenBacklog untuk menentukan nilai yang berbeda untuk melewati untuk parameter ini. Mulai di SQL Server 2005, Perpustakaan jaringan melewati nilai SOMAXCONN sebagai jaminan simpanan pengaturan untuk mendengarkan API. SOMAXCONN memungkinkan penyedia Winsock untuk menetapkan nilai maksimum yang wajar untuk pengaturan ini. Oleh karena itu, kunci registri WinsockListenBacklog tidak lagi digunakan atau diperlukan di SQL Server 2005.
Jaminan simpanan pengaturan bekerja sebagai berikut: misalnya layanan sembarang mendengarkan permintaan soket TCP/IP yang masuk. Jika Anda menetapkan pengaturan jaminan simpanan ke 5 dan banyak permintaan sambungan soket terus-menerus streaming di, Layanan mungkin tidak dapat merespons permintaan yang masuk secepat mereka masuk. Pada titik ini, lapisan soket TCP/IP antrian permintaan ini masuk dalam antrian jaminan simpanan, dan layanan dapat kemudian tarik permintaan dari antrian ini dan menangani permintaan sambungan soket masuk. Setelah antrian mengisi, lapisan soket TCP/IP segera menolak permintaan soket tambahan apa pun yang datang dengan mengirimkan paket ACK + RESET kembali ke klien. Peningkatan meningkatkan ukuran antrian jaminan simpanan jumlah tertunda sambungan soket permintaan lapisan soket TCP/IP antrian sebelum permintaan ditolak.
Perhatikan bahwa pengaturan WinsockListenBacklog khusus untuk SQL Server. SQL Server mencoba membaca pengaturan registri ini saat pertama kali memulai layanan SQL Server. Jika tidak ada pengaturan, default 5 digunakan. Jika ada pengaturan registri, SQL Server membaca pengaturan dan menggunakan nilai yang disediakan sebagai pengaturan jaminan simpanan saat WinSock API mendengarkan disebut sebagai untaian mendengarkan soket TCP/IP yang ditetapkan di dalam SQL Server.
Untuk menentukan apakah Anda menjalankan ke masalah ini, Anda dapat menjalankan jejak Monitor jaringan pada komputer yang menjalankan SQL Server atau klien dan Cari permintaan sambungan soket segera ditolak dengan ACK + RESET. Jika Anda memeriksa TCP/IP paket pada Monitor jaringan, Anda melihat paket seperti berikut ketika masalah ini terjadi:
Frame: Base frame propertiesETHERNET: EType = Internet IP (IPv4)
IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No Options
TCP: Control Bits: .A.R.., len: 0, seq: 0-0, ack:3409265780, win: 0, src: 1433 dst: 4364
TCP: Source Port = 0x0599
TCP: Destination Port = 0x110C
TCP: Sequence Number = 0 (0x0)
TCP: Acknowledgement Number = 3409265780 (0xCB354474)
TCP: Data Offset = 20 bytes
TCP: Flags = 0x14 : .A.R..
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....1.. = Reset the connection
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 0 (0x0)
TCP: Checksum = 0xF1E7
TCP: Urgent Pointer = 0 (0x0)
Perhatikan bahwa sumber port 0x599, atau 1433 di desimal. Ini berarti bahwa paket berasal dari khas komputer yang menjalankan SQL Server dan yang sedang berjalan pada default port 1433. Perhatikan juga kolom pengakuan signifikan dan bendera Reset sambungan ditetapkan. Jika Anda sudah terbiasa dengan Menyaring jejak Monitor jaringan, Anda dapat menyaring nilai TCP bendera oleh 0x14 heksadesimal untuk melihat hanya ACK + RESET paket di jejak Monitor jaringan.
Perhatikan bahwa Anda juga dapat melihat serupa ACK + RESET paket jika komputer yang menjalankan SQL Server tidak dijalankan sama sekali atau komputer yang menjalankan SQL Server tidak diawasi untuk protokol TCP/IP, jadi melihat ACK + RESET paket tidak pasti konfirmasi bahwa Anda mengalami masalah ini. Jika WinsockListenBacklog terlalu rendah, beberapa sambungan upaya menerima menerima paket dan beberapa koneksi segera menerima paket ACK + RESET dalam jangka waktu yang sama.
Perhatikan bahwa dalam kasus yang sangat jarang terjadi, Anda mungkin harus menyesuaikan setelan ini bahkan jika penggabungan diaktifkan pada komputer klien. Misalnya, jika banyak komputer klien berbicara dengan satu komputer yang menjalankan SQL Server, sejumlah besar upaya sambungan masuk bersamaan mungkin terjadi pada waktu tertentu meskipun penggabungan diaktifkan.
Catatan Jika Anda menyesuaikan setelan WinsockListenBacklog , Anda tidak harus me-restart Windows untuk pengaturan ini diterapkan. Hanya berhenti dan restart layanan SQL Server untuk pengaturan diterapkan. Pengaturan registri WinsockListenBacklog ini hanya untuk komputer yang menjalankan SQL Server. Tidak memiliki efek pada komputer klien yang berbicara ke SQL Server.
