Вопросы Теги

Тайм-аут SQL Server на первой попытке

немного вне темы, но связанный с тем, что сказано здесь: ".. извините это был я, кто неправильно понял. Явление вовремя журналов пригождается для менее используемых баз данных, которые я получаю, обращается к понедельнику от разработчика, который говорит, что удалил набор строк в таблице в прошлый четверг, могу я возвращать их для него. Я люблю разработчиков".

Вопрос: Вы не можете только сделать восстановления момента времени с полным резервным копированием ночи четверга или не не выполнимы по некоторым причинам?

9
задан 10 September 2010 в 17:50
6 ответов

Я думаю, что нашел решение, по крайней мере, в моем случае, это работает. Я использую имя экземпляра, и это автоматически подразумевает динамический порт для сервиса SQL-сервера. Я изменил настройки от динамического до порта фиксации и затем открыл брандмауэр на том порте.

Менеджер конфигурации SQL Server-> Конфигурация сети SQL Server-> Протоколы для 'InstanceName'-> TCP/IP-> Свойства-> IP-адреса-> IP Все->

Здесь Вы видите две опции:

  • Динамические порты TCP: 51250 (случайным образом сгенерированный)
  • Порт TCP: пустой - я поместил здесь 1433, и затем я открыл брандмауэр (в случае, если он не был уже открыт). Можно поместить любой порт, который Вы хотите (я поместил 1433, потому что это был единственный экземпляр. В случае нескольких экземпляров необходимо выбрать для каждого экземпляра различный порт и затем открыть их в брандмауэре),

Сценарий привык для легкого Вашу задачу открытия портов, которые я загрузил с MS, и я воспроизвожу его здесь (комментарии находятся на немецком языке, но они должны быть очевидными):

@echo =========  Ports des SQL-Servers  ===================
@echo Aktivieren von Port 1433 für die SQLServer-Standardinstanz
netsh firewall set portopening TCP 1433 "SQLServer" 
@echo Aktivieren von Port 1434 für dedizierte Administratorverbindungen
netsh firewall set portopening TCP 1434 "SQL-Administratorverbindung" 
@echo Aktivieren von Port 4022 für den konventionellen SQL Server-Service Broker  
netsh firewall set portopening TCP 4022 "SQL-Service Broker" 
@echo Aktivieren von Port 135 für Transact-SQL-Debugger/RPC 
netsh firewall set portopening TCP 135 "SQL-Debugger/RPC" 
@echo =========  Ports für Analysedienste  ==============
@echo Aktivieren von Port 2383 für die SSAS-Standardinstanz
netsh firewall set portopening TCP 2383 "Analysedienste" 
@echo Aktivieren von Port 2382 für den SQL Server-Browserdienst
netsh firewall set portopening TCP 2382 "SQL-Browser" 
@echo =========  Verschiedene Anwendungen  ==============
@echo Aktivieren von Port 80 für HTTP 
netsh firewall set portopening TCP 80 "HTTP" 
@echo Aktivieren von Port 443 für SSL
netsh firewall set portopening TCP 443 "SSL" 
@echo Aktivieren des Ports für die Schaltfläche 'Durchsuchen' des SQL Server-Browserdiensts
netsh firewall set portopening UDP 1434 "SQL-Browser" 
@echo Zulassen von Multicast-/Broadcastantwort auf UDP (Aufzählung der Browserdienste OK)
netsh firewall set multicastbroadcastresponse ENABLE
6
ответ дан 2 December 2019 в 22:32

Мое лучшее предположение здесь - то, что у Вас есть AUTO_CLOSE, включенный для базы данных. Это означает, что база данных должна вращаться, когда Вы соединяетесь, который является тем, что вызывает inital тайм-аут.

Второе предположение - то, что это может быть связанное разрешение сетевых имен. Так это takse слишком долго для разрешения имени хоста в первый раз (широковещательной передачей, возможно?), но затем кэшируется на последующих попытках подключения. Что Вы используете для разрешения хоста? это находится в DNS? Попытайтесь изменить строку подключения, чтобы быть в IP, формате порта. т.е. 192.168.100.100,1433

Можно также попытаться работать ipconfig /flushdns после успешной попытки подключения и видят, получаете ли Вы затем то же поведение. Изворотливое обходное решение должно поместить поиск в Ваш Файл hosts, но необходимо зафиксировать его правильно.

2
ответ дан 2 December 2019 в 22:32

Отключите брандмауэр. Испытательная сеть (ping). Осуществите сниффинг сетевого трафика к SQL-серверу (используйте wireshark),

0
ответ дан 2 December 2019 в 22:32

Можно ли попытаться выполнить SQL Profiler, прежде чем Вы будете соединять впервые или с VS или с SSMS, и видеть то, что происходит на SQL Server?

Кроме того, Вы проверили журналы событий, чтобы видеть, регистрируется ли что-нибудь?

0
ответ дан 2 December 2019 в 22:32

Чувствует себя подобно съемке общим планом в темном износе повязки на глаза, но он мог бы помочь. Существует староватый поток, законченный на форумах Microsoft SQL Developer, описывающих, что надеется быть той же проблемой, наряду с возможной фиксацией. Его сервер выполняет Windows Server 2008, но мог бы быть важен для Вашего Win7, настроенного также.

Поток:

http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/58bd9c4d-0572-4567-8e32-82a7fd600022

От потока:

Да, я решил эту проблему.

Мой Windows Server 2008 был настроен для отклонения SASL LDAP, связывает (см. предупреждение 2886).

Так как я настроил свой сервер для не отклонения такого, связывает, корректная работа соединений SQL-сервера 2008 года.

Вы могли посмотреть на базу знаний Microsoft 935834 для получения информации об изменении LDAP подписание настроек (не может связаться с ним, поскольку я - новый пользователь).

Надежда это помогает!

2
ответ дан 2 December 2019 в 22:32

I только что стали свидетелями этой первой попытки задержки соединения с длительной паузой на свежем SQL Server 2017.

Чтобы решить эту проблему, я добавил отсутствующее правило для исполняемого файла приложения SQL Serverв Брандмауэр Защитника Windows. Для этого ознакомьтесь с исчерпывающей документацией Microsoft по этому вопросу

О том, как брандмауэр Windows разрешает успешные входящие соединения при некоторых вторичных попытках подключения к SQL Server, ранее было определено предыдущее правило входящего трафика, оно остается загадка.

0
ответ дан 1 October 2020 в 10:52

Теги

Похожие вопросы