Назад | Перейти на главную страницу

Недавно настроенный MSSQL2008, TIME_WAIT, но НЕ УСТАНОВЛЕН?

Windows 2008 R2, стандартная. Нет локального файрвола на нем. Новая установка, потому что в старом SQL2000 одновременно умирают два диска (или это может быть рейд-контроллер?). К счастью, у меня были свежие резервные копии.
Базы данных были восстановлены, и был применен SP2 для SQL2008.

Я вижу, что различные хосты пытаются установить сеанс, но (клиентские) сайты не работают, и я не вижу ожидаемых установленных сеансов. Wirehark показывает полное трехстороннее рукопожатие. Поскольку это клиентские машины подключаются, я не могу войти в систему и перезапустить пулы приложений.

Что, черт возьми, могло быть причиной этого?

No.     Time        Source                Destination           Protocol Info
  1 0.000000    1.2.5.127         1.2.6.133         TCP      desktop-dna > ms-sql-s [SYN] Seq=0 Win=65535 Len=0 MSS=1380 SACK_PERM=1

Frame 1: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Cisco_31:5e:09 (00:26:0b:31:5e:09), Dst: Vmware_b7:00:05 (00:50:56:b7:00:05)
Internet Protocol, Src: 1.2.5.127 (1.2.5.127), Dst: 1.2.6.133 (1.2.6.133)
Transmission Control Protocol, Src Port: desktop-dna (2763), Dst Port: ms-sql-s (1433), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
  2 0.000123    1.2.6.133         1.2.5.127         TCP      ms-sql-s > desktop-dna     [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1

Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Vmware_b7:00:05 (00:50:56:b7:00:05), Dst: Cisco_31:5e:09 (00:26:0b:31:5e:09)
Internet Protocol, Src: 1.2.6.133 (1.2.6.133), Dst: 1.2.5.127 (1.2.5.127)
Transmission Control Protocol, Src Port: ms-sql-s (1433), Dst Port: desktop-dna (2763), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
  3 0.000884    1.2.5.127         1.2.6.133         TCP      desktop-dna > ms-sql-s [ACK] Seq=1 Ack=1 Win=65535 Len=0

И netstat

TCP    1.2.6.133:1433     1.2.2.98:26895     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26912     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26918     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26931     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2736     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2737     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2738     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2739     TIME_WAIT       0

Изменить: похоже, это базы данных master / msdb / model, которые нельзя восстановить из-за несоответствия версий.

Вы смотрите на это на основании отчетов о сбоях или потому, что сетевая трассировка выглядит забавно?

Если вы можете получить одновременный захват на сервере и затронутом клиенте, это расскажет вам больше.

Возможные причины успешного трехстороннего рукопожатия, но ничего после этого:

  • Механизм разгрузки TCP включен, и сетевая карта работает в режиме дымохода
    • (TOE- использование netsh int tcp sh gl чтобы проверить, считает ли ОС, что разгрузка TCP выключена или включена, но учтите, что драйвер сетевой карты должен также включите его, чтобы он работал)
    • Только что заметил запись VMWare в трассировке; TOE пока не работает на виртуальных машинах.
  • Проблемы MTU между сервером и клиентом
  • Сервер не отвечает, или
  • Клиент никогда не отправляет начальную команду

Проблема заключалась в том, что основная база данных не могла быть импортирована, поэтому, по сути, не было восстановлено никаких логинов.