Добрый день, может кто сталкивался с моей проблемой или подкинет свежую идею.
Дано:
В связке терминального сервера с 1С:Предприятием 7.7 р25 и сервера под SQL 2005, в режиме монопольного обмена постоянно происходит событие, приводящее к ошибке 1С "База не может быть открыта в монопольном режиме".
Ранее, когда сервер БД работал под управлением SQL 2000, проблема также существовала, но проявлялась в значительной степени реже.

Предположения:

Дело в том, что сам по себе механизм семёрки, при распаковке очередного архива, пришедшего с другого узла, переводит базу в режим multi_user и любая попытка подключения (вроде бы даже прошедшая в то время, когда база была в режиме single_user) приводит к упомянутой ошибке.

Попытки:
Была попытка создания задания для Агента SQL сервера по автообмену с предшествующим переключением в single_user, но получился облом: 1с, само собой, не может попасть в базу.

Урезать права пользователя, под которым 1с заходит в SQL до db_datawriter: облом. 1с может попадать в базу, только с правами dbo. На данный момент, подключается под sa.

Отключение пользователям возможности запуска 1с на время монопольного обмена. Облом. На сервере собирается статистика с помощью ReportManager, могут читаться данные из базы из других учётных систем, ОЛАПы итд.

Вопрос: Как удержать гарантированный однопользовательский режим для определённого процесса на неизвестный период времени?

Заранее всех благодарю за участие и советы.

Модератор: Тема перенесена из форума "Microsoft SQL Server".

Поправка к вопросу:
Как удержать гарантированный однопользовательский режим для определённого процесса на время его работы?

Пока искал на форуме ответы, нашёл рекомендации по подключению семёрки к 2005 SQL. Нашел такие:
Модель восстановления для базы - simple

Отключить автосжатие - по умолчанию оно отключено.

После того, как изменил модель восстановления, обмен 2 дня работает отлично - попытка входа в базу во время монопольного обмена не приводит к ошибке обменщика "невозможно открыть базу в монопольном режиме"
Неужели модель восстановления помогла решить проблему? Как она может влять на работу базы?

автор1) нет
2) никак
Так и есть, это не помогло (удивительно:)). Может кто даст подсказку, в каком направлении искать?

Решение проблемы оказалось проще. Блокировка базы осуществлялась фоновым процессом, выполняющим очистку таблиц от удаленных записей (GHOST CLEANUP), который в SQL является системным и запускается автоматически когда у него появляется такая возможность (по документации, если база не заблокирована, то через каждые 15 секунд). Решением проблемы в данном случае является отключение этого системного процесса на время монопольных обменов. Для отключения выполняется команда T-SQL:
DBCC TRACEON(661,-1)
для включения
DBCC TRACEOFF(661, -1)
для проверки статуса
DBCC TRACESTATUS
где 661 - флаг (trace flag) отключения именно этого процесса, -1 - признак глобального отключения процесса

Также предлагаю прописать перед монопольным обменом задание убивающее все подключения к базе, которые исходят не от процесса 1cv7.exe, т.е. те, которые возвращает:

Select spid from master..sysprocesses where dbid=DB_ID('test_sql') and program_name<>'1CV7'


Так-то

Всем спасибо ):

Сергей84,
Подробнее ситуацию опишешь?

Сергей84,

прочитай сообщение выше (25 ноя 08, 15:36) - это конкретный и полный ответ по проблеме

Сергей84,

Ну, само прочтение мало чем поможет, нужно ещё что-нибудь сделать.
Что делали, что не получается?