Привет
Есть сервак HP, Xeon с WinServer 2003 Ent. sp1
RAM 2 GB, винты сказевые ..
На нем крутится БД ~1GB, на ASA 9.0.2.3302 в режиме 24*7
Есть репликация через FTP с периодичностью 2 минуты.

В последнее время (месяца два) сервак начал глючить: в дневную смену,
когда нагрузка на сервер максимальная, сервер БД уходит отключку, клиенты теряют соединение,
подключиться невозможно, но консоль сервера работает - он там через некоторое время пишет типа:
Disconnected SharedMemory client's AppInfo: HOST=PC;OS=Windows XP Build 2600 Service Pack 2;PID=0xc64;THREAD=0xcd0;EXE=...
т.е. отсоединяет всех кто был до этого подцеплен.
При нажатии кнопки Shutdown - сервак перестает отвечать и остается висеть в процессах
Помогает только ручное снятие процесса или перезагрузка сервака, что мне ессно не нравится :(

Локализовать не смог. Периодичности нету, т.е. может и через день проскачить,
а может недели через две. Пару раз менял новые билды - не помогло.
Программу вроде сильно не менял, из железок меняли винт по гарантии.
Ед. есть пара прокси таблиц (MSSQL2000), которые читаю и записаваю, но делается это каждый день.
Если кто сталкивался с подобной проблемой подскажите пожалуйста.

Заранее спасибо!

то что убрали я в курсе, и скорее всего из-за:

9.0.2 Critical Bug fixes
Build #3319 - Engineering Case #432545

там как раз из-за проблем с подзапросами
посмотри может это как раз про твое :)

авторА с чем связано "Disconnected SharedMemory client's", почему не TCPIP? Обычно sharedmemory это связь клиента с сервером на одной машине. Тогда почему дальше написано, что WINDOWS XP, ведь на машине стоит Win2003, как указывалось.?
Это я неправильно написал "типа",
строку "Disconnected .." я привел в качастве примера, взял со своей машины, а не точную стоку с сервака. Там есть TCPIP и SharedMemory (dbRemote запускается на серваке).

авторНасколько я знаю, это сообщение связано с тем, что убивают
клиента (или связь с ним), а сервер в это время может делать откат большой
транзакции от этого клиента, и то что вы хотите от него, чтоб он мгновенно
выгрузился он воспринимает как пожелание, а не как приказ. Вполне может
быть, что сервер и не виснит вовсе, посмотрите системным монитором на
процессы АСА, на операции с диском, наверняка АСА подает признаки жизни.
в данном случае это, скорее всего, говорит о том что не только клиенты теряют сервак, но и сервер теряет клиентов (при том что сетка работает). Монитором смотрел 100% бездействия системы на протяжени минут 10, поэтому однозначно - висяк. Может это связано с сеткой (сетевым оборудованием), но как сказал - сетка работает, да по SharedMemory с этой машины клиентов не пускает ???

iLLerВопрос: не пускает клиента с машины-сервера на АСА-сервер ДО нажатия на кнопку "Shutdown", или ПОСЛЕ? Если после, то это логично, новых клиентов сервер уже не обслуживает, но завершает работы текущих, поэтому не отзывается.
Монитором каким смотрели? "Perfomance monitor"? Или просто "task manager'ом"? Нужно первым, и смотреть действия процесса сервера, чтение/запись в ОЗУ/диск, сетевую активность. Честно, я ни разу не видел зависа, вот вываливаться - это пожалуйста. Если используются прокси-таблицы, то вполне может быть что висит заблокированный коннект сервера, так что он не висит, а ждет.
Я не отрицаю что я дурак, но те такой чтоб пытаться коннектится после нажатия кнопки "Shutdown", и ругаться на то что не пускают :)
"Perfomance monitor" - как если Sybase Central к БД не цепляется ?

я протранслировал лог БД после такого падения, с "Include uncommited transactions", в итоге в конце файла получил
--COMMIT-1035-02020057324
COMMIT WORK
go
--ROLLBACK-1002-02020059835
ROLLBACK WORK
go
--ROLLBACK-1005-02020059835
ROLLBACK WORK
go
--ROLLBACK-1009-02020059835
ROLLBACK WORK
go
--ROLLBACK-1010-02020059835
ROLLBACK WORK
go
--ROLLBACK-1011-02020059835
ROLLBACK WORK
go
--ROLLBACK-1012-02020059835
ROLLBACK WORK
go
--ROLLBACK-1013-02020059835
ROLLBACK WORK
go
--ROLLBACK-1019-02020059835
ROLLBACK WORK
go
--ROLLBACK-1020-02020059835
ROLLBACK WORK
go
--ROLLBACK-1023-02020059835
ROLLBACK WORK
go
--ROLLBACK-1029-02020059835
ROLLBACK WORK
go
--ROLLBACK-1030-02020059835
ROLLBACK WORK
go
--ROLLBACK-1031-02020059835
ROLLBACK WORK
go
--ROLLBACK-1033-02020059835
ROLLBACK WORK
go
--ROLLBACK-1035-02020059835
ROLLBACK WORK
go
--ROLLBACK-1036-02020059835
ROLLBACK WORK
go
--ROLLBACK-1048-02020059835
ROLLBACK WORK
go
--ROLLBACK-1049-02020059835
ROLLBACK WORK
go
--ROLLBACK-1054-02020059835
ROLLBACK WORK
go
--ROLLBACK-1055-02020059835
ROLLBACK WORK
go
--ROLLBACK-1058-02020059835
ROLLBACK WORK
go
--ROLLBACK-1060-02020059835
ROLLBACK WORK
go
--ROLLBACK-1061-02020059835
ROLLBACK WORK
go

если без этой галочки, то просто
--COMMIT-1035-02020057324
COMMIT WORK
go

интересно вот что, если я правильно понимаю, в строке --ROLLBACK-XXXX-ZZZZZZZZ
XXXX- это id сессии
ZZZZZZZZ - это смещение
но почему у всех ROLLBACK одинаковое смещение, или так и должно быть для uncommited transactions?
Подскажите бестолковому.