Работал MS SQL 2000 чуть более года - всё ОК, а потом….

В одном инстансе было, да и есть сейчас, три базы. На другой машине стоят несколько серверов приложений (АПП) которые периодически вызывают хранимые процедуры, но иногда и напрямую селекты и апдейты. Связь между АПП и СУБД организованна через Ntwdblib.dll. Работала эта система чуть более года - всё ОК. Базы периодически, в процессе разработки дорабатывались – вставлялись новые процедуры, добавлялись/удалялись таблицы и т.п., но вот примерно месяц назад началось. Стали периодически вылетать АПП Ntwdblib.dll на обращения выдаёт NULL и кранты, после парирования путем обработки критических ситуаций через некоторое время происходит фатальный глюк в самой Ntwdblib.dll.
Проведенные исследования показали, что всяческие DBCC – не помогают, НО!!! всё приходит в норму после банальной перезагрузки машины или SQL-сервиса. Такого хватает примерно на сутки, в течении которых замечается постоянное ухудшение-задержка выполнения процедур, выборки небольшие и данные постоянно (раз в месяц) ужимаются.
Выполнение
DBCC PROCCACHE показывает что переменная «num proc buffs active», постоянно растет и через сутки приближается к миллиону, хотя может это ни причем?
Пока видится единственное решение – сгенерировать скрипты на всю БД, !полностью! переинсталлировать всю СУБД и т.д. Но это очень гемморойно, может кто подскажет, как выйти из этого положения?

a. Нельзя ли пояснить, что означает длинная фраза:
--------------------------------------------------------------------------------
Стали периодически вылетать АПП Ntwdblib.dll на обращения выдаёт NULL и кранты, после парирования путем обработки критических ситуаций через некоторое время происходит фатальный глюк в самой Ntwdblib.dll.
--------------------------------------------------------------------------------
Под вылетать я имел ввиду "обычный" сбой после которого приложение закрывается.
Под парированием обработкой критической ситуацией -> _try {} catch(...){...}

>Распишите, пожалуйста, подробнее что есть АПП, что означает фраза Ntwdblib.dll на обращения выдаёт NULL и т.д.
Все ошибки, сбои и т.п. пишуться в лог (конечно в нашей интерпритации), но тем не меее
выдержка 1
Ошибка dbcancel' при обработке пакета от '193.125.199.29,1768'
15.05.102 20:54:51 pSql==NULL:Operating-system error: (null)
15.05.102 20:54:51 SQL - Ошибка : 'File:'x:\projects\...\server©onnection\база данных\sql.cpp'
Line:564
выдержка 2

16.05.102 03:01:39 pSql==NULL:Operating-system error: (null)
16.05.102 03:01:39 pSql==NULL:Operating-system error: (null)
16.05.102 03:01:39 Csql(E) 2(9856):: 'File:'x:\projects\...\server©onnection\база данных\sql.cpp'
Line:612
В скобках номера ошибок, которые возвращаються Ntwdblib.dll, все подобные сбои ловяться исключительно с помощью
_try {} catch(...){...}


>b. Какие именно команды DBCC (кроме proccache) Вы использовали и для чего?
Дело в том, что это работало год с хвостиком - без проблем.
И все изменения таблиц и т.п. не затрагивали АПП.

>c. Нельзя ли привести журнал Windows (Event Log), если в нем есть хоть что-то о работе SQL Server'а. То же самое >касается журнала SQL Server'а.
Вот выдержка на примерное время сбоя (который удалось парировать):
2002-05-16 03:00:22.90 backup Database backed up: Database: ST3, creation date(time): 2001/03/14(02:49:00), p
2002-05-16 03:01:32.25 spid107 Invalid buffer received from client..
2002-05-16 03:01:32.25 spid107 Error: 17805, Severity: 20, State: 3
2002-05-16 06:00:09.48 backup Database backed up: Database: ST0, creation date(time): 2001/03/14(02:46:22), p
А в журнале Windows (Event Log) та-же инфа, только с иконками.

>d. Опишите, пожалуйста, в общих чертах Ваше Приложение (какого типа процедуры и т.п.)
В принципе если ли-бы были изменения АПП, после которых все началось, то можно, наверное грешить на приложение, а так...
А если в краце, то написанно на VC++, вызываемые процедуры, если возвращают значения, то делают это через select.
Как было сказанно всё общение с БД идет через Ntwdblib.dll.
DeadLock-ов нет, после появления всех проблем SQL был полностью пропачен, но без толку...

Если под явными симптомами мем.ликов понимать постоянный рост памяти занимаемым процессом, то в принципе рост очень небольшой есть. Используемая память резко вырастает примерно в течении минут 5-10, а потом когда увеличится, когда уменьшиться, но это если судить по "боевому опыту" вообще - особенность виндов. Но вот еще одна особенность, при переключении АПП на тестовую БД(на др. машине, правда на ней нельзя работать долго, в силу технологии разработки и целосности данных и т.п.) всё работает - ОК, НО!, когда мы на запасную машину, перенесли бэкапом всю базу - траблы перенеслись тоже! Такое ощущение, что переносяться какие-то хвосты.
А к вопросу о DBCC делалось следующее, может и с избытком:
1. Запуск с командной строки
2. Из Qwery аналайзера запускался следующий батч:
-- ########## SET SINGLE_USER ###############
ALTER DATABASE msdb SET SINGLE_USER
ALTER DATABASE BD0 SET SINGLE_USER
ALTER DATABASE BD1 SET SINGLE_USER
ALTER DATABASE BD3 SET SINGLE_USER

-- ########## CHECKFILEGROUP ###############
USE master DBCC CHECKFILEGROUP WITH ALL_ERRORMSGS
USE msdb DBCC CHECKFILEGROUP WITH ALL_ERRORMSGS
USE BD0 DBCC CHECKFILEGROUP WITH ALL_ERRORMSGS
USE BD1 DBCC CHECKFILEGROUP WITH ALL_ERRORMSGS
USE BD3 DBCC CHECKFILEGROUP WITH ALL_ERRORMSGS

-- ########## master ###############

DBCC CHECKALLOC('master', REPAIR_ALLOW_DATA_LOSS)
DBCC CHECKALLOC('master', REPAIR_REBUILD)
DBCC CHECKCATALOG( 'master')
DBCC CHECKDB('master', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS
DBCC CHECKDB('master', REPAIR_REBUILD) WITH ALL_ERRORMSGS
DBCC SHRINKDATABASE('master')

-- ########## msdb ###############

DBCC CHECKALLOC('msdb', REPAIR_ALLOW_DATA_LOSS)
DBCC CHECKALLOC('msdb', REPAIR_REBUILD)
DBCC CHECKCATALOG( 'msdb')
DBCC CHECKDB('msdb', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS
DBCC CHECKDB('msdb', REPAIR_REBUILD) WITH ALL_ERRORMSGS
DBCC SHRINKDATABASE('msdb')


-- ########## BD0 ###############

DBCC CHECKALLOC('BD0', REPAIR_ALLOW_DATA_LOSS)
DBCC CHECKALLOC('BD0', REPAIR_REBUILD)
DBCC CHECKCATALOG( 'BD0')
DBCC CHECKDB('BD0', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS
DBCC CHECKDB('BD0', REPAIR_REBUILD) WITH ALL_ERRORMSGS
DBCC SHRINKDATABASE('BD0')

-- ########## BD1 ###############
DBCC DBREINDEX('BD1.dbo.TABLE_1')
... тут перечисление таблиц
DBCC DBREINDEX('BD1.dbo.TABLE_N')

DBCC CHECKALLOC('BD1', REPAIR_ALLOW_DATA_LOSS)
DBCC CHECKALLOC('BD1', REPAIR_REBUILD)
DBCC CHECKCATALOG( 'BD1')
DBCC CHECKDB('BD1', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS
DBCC CHECKDB('BD1', REPAIR_REBUILD) WITH ALL_ERRORMSGS
DBCC SHRINKDATABASE('BD1')

-- ########## BD3 ###############
DBCC DBREINDEX('BD3.dbo.TABLE_1')
... тут перечисление таблиц
DBCC DBREINDEX('BD3.dbo.TABLE_N')

DBCC CHECKALLOC('BD3', REPAIR_ALLOW_DATA_LOSS)
DBCC CHECKALLOC('BD3', REPAIR_REBUILD)
DBCC CHECKCATALOG( 'BD3')
DBCC CHECKDB('BD3', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS
DBCC CHECKDB('BD3', REPAIR_REBUILD) WITH ALL_ERRORMSGS
DBCC SHRINKDATABASE('BD3')

-- ########## SET MULTI_USER ###############
ALTER DATABASE msdb SET MULTI_USER
ALTER DATABASE BD0 SET MULTI_USER
ALTER DATABASE BD1 SET MULTI_USER
ALTER DATABASE BD3 SET MULTI_USER

но что абидна то - всегда 0 ошибок!

размер = 272896 от 03.04.96 5:00
версия = 6.50.201

Все паки и фиксы были поставленны - толку нет.
17.05 поставил
Ntwdblib.dll с размером 274489 и версией 8.00.194 от 06.08.00 02:51
Перекомпилиировал все приложения с соответствующим Ntwdblib.lib
набираю статиску, но пока видимого улучшения не наблюдаеться.