|
|||
 |
|
Начинающим
 HOWTO Отсоединение и присоединение файлов баз данных Часто в процессе эксплуатации SQL Server возникает необходимость в простом методе копирования какой-либо базы данных. Такая необходимость может быть вызвана переносом базы данных на другой сервер либо созданием резервной копии. Конечно для этого существуют другие специализированные меоды, однако данный метод отличает простота его использования. Итак рассмотрим его (на примере SQL Server 2000): 1. Отсоединение базы данных Данное действие необходимо выполнить, чтобы сервер разблокировал вашу базу данных. Без отсоединения базы данных, скопировать ее файлы данных не удастся. Отсоединение базы невозможно, если есть хотя бы один работающий в ней пользователь или если данная база включена в процесс репликации. Само отсоединение производится довольно просто. Для этого можно использовать два метода: Enterprise Manager (EM) или Transact-SQL(T-SQL). В первом случае, встаньте на нужную базу, вызовите контекстное меню и выберите пункт меню All Tasks-Detach Databes. В диалоге нужно проверить статус базы, можно отключить существующие соединения. Во втором случае используется следующая хранимая процедура: sp_detach_db [ @dbname = ] 'dbname'[ , [ @skipchecks = ] 'skipchecks' ] Для нее нужно указать имя базы данных, а также необязательный параметр, который отвечает за обновление статистики. З.Ы. Отсоединить базы данных master, msdb, tempdb таким образом не удастся. После отсоединения базы данных можно копировать ее файлы и производить другие действия. 2. Присоединение базы данных После того как вы отсоединили базу данных, ее можно снова присоединить. Также данное действие бывает полезным в случае краха сервера - серевер не функционирует однако файлы баз остались. Как и отсоединение это действие можно производить двумя методами с помощью EM либо с помощью T-SQL. В первом случае из контекстного меню элемента Databeses нужно выбрать пункт All Tasks-Attach Databes. Во-втором случае используется хранимая процедура: sp_attach_db [ @dbname = ] 'dbname' , [ @filename1 = ] 'filename_n' [ ,...16 ] В списке файлов должен содержаться, по крайней мере, первый файл базы данных (в котором содержится информация об остальных файлах). Лог файл указывать не обязательно, однако рекомендуется, если в базе не происходило никаких сбоев. Максимальное количество присоединяемых файлов 16. Если их больше используйте комманду SQL CREATE DATABASE с опцией FOR ATTACH. Если вы присоединяете базу с другого сервера, то может оказаться полезной следующая процедура, восстанавливающая пользователей в новой базе. Если на данном серевере список пользователей идентичен, то ее необходимо выполнить, чтобы восстановить список пользователей друго серевера. Автоматически это не происходит, так идентификаторы пользователей, которые хранятся в таблице sysusers отличаются от аналогичных на новом сервере. Сама процедура состоит из одной комманды: USE <ваша_бд> К сожалению данный скрпит нужно выполнять для каждого пользователя по отдельности, указывая соответствующее имя учетной записи (логина). Либо, если у вас функционирует старый сервер, вы можете получить таблицу соответствий имя_логина - имя_пользователя, и потом, цепляясь к ней, выполнить скрипт для всех сразу (если сервер "сдох", можно такую таблицу набить вручную, что даже лучше чем выполнять скрипт по отдельности). З.Ы. Для SQL Serever 7.0 нужно соблюдать правило соответствия кодовой страницы и порядка сортировки, в присоединяемой базе данных они должны быть такми же как и на сервере. Для SQL Server 2000 похоже это не обязательно (если я не прав - поправьте). Потерянные проводки что это такое и как с ними бороться Потерянные проводки - это такие "нехорошие" проводки, которые "отбиваются" от своих документов в результате чего возникают проблемы с созданием новых документов (проводок). Выражаться это может по разному. Мне известна следующая ситуация: при проведении документа возникает ODBC ошибка: ".... duplicate keys ...". Происходит это из-за того, что при попытке вставки новой проводки система (SQL Server) находит "нехорошую" проводку (поскольку 1С-ом создан индекс, проверяющий уникальность ключей) и выдает ошибку. Из-за чего возникают такие проводки. Причин этому несколько: сбой SQL Server во время проведения (отемены проведения) документа, сбой 1С (более вероятно), сбой железа (в том числе ошибки при передаче данных по сети — такой пример мне известен), старый релиз 1С. Скорее всего проведение (отмена проведения) документа запрограммировано не в одной транзакции, либо запрограммировано неверно (это вероятней всего в старых релизах). То есть, например, при отмене проведения документа ему ставится признак отмены проведения, однако вследствии какого-то сбоя такой признак не проставляется проводкам. Могут быть и другие причины. Для того чтобы найти(а потом и удалить) такие проводки написан следующий скрипт. Его автор Лапин Александр — специалист одного из наших промышленных предприятий, где я раньше работал и где уже почти 2 года (по сей день) работает целая команда, имеющая большой опыт внедрения 1С + SQL Server 6.5. Сам скрипт: -- есть проводки по непроведенным документам
SELECT * FROM _1sentry (nolock)
WHERE docid IN (SELECT iddoc FROM _1sjourn (nolock) WHERE closed=0)
-- есть проводки, но нет соответствующих документов
SELECT * FROM _1sentry (nolock)
WHERE docid NOT IN (SELECT iddoc FROM _1sjourn (nolock))
-- есть проводки, но нет соответствующих операций
SELECT * FROM _1sentry (nolock)
WHERE docid NOT IN (SELECT docid FROM _1soper (nolock))
-- есть операции, но нет соответствующих документов
SELECT * FROM _1soper (nolock)
WHERE docid NOT IN (SELECT iddoc FROM _1sjourn (nolock))
-- проверка правильности заполнения DATE_TIME_DOCID в _1sentry
SELECT _1sentry.DATE_TIME_DOCID,_1sjourn.DATE_TIME_idDOC FROM _1sentry (nolock), _1sjourn (nolock)
WHERE _1sentry.DOCID=_1sjourn.idDOC AND
_1sentry.DATE_TIME_DOCID<>_1sjourn.DATE_TIME_idDOC
-- проверка правильности заполнения APPCODE в _1Sjourn
SELECT * FROM _1Sjourn(NOLOCK)
WHERE appcode<32 AND IDDOCDEF<>1356 AND
iddoc IN (SELECT docid FROM _1sentry (nolock))
|
