Отбрасывание SQL Server 2005 возражает от DB на восстановлении?
Это зависит
Это - уравновешивание. Если Ваша таблица читается интенсивная, с не много обновлений или удаляет затем значение по умолчанию (который равняется 100), должен быть в порядке.
Если Ваша таблица является очень интенсивной записью с большим количеством обновлений, то значение ниже 80 могло бы быть более соответствующим.
Нет никакой волшебной формулы для этого материала. (AFAIK, если там сообщен мне) Лучшая вещь сделать, имеют тестовую среду, имеют некоторую рабочую нагрузку для тестирования. Внесите изменения и посмотрите, как Ваша база данных работает с рабочей нагрузкой.
Вот то, что я думаю, произошел, это основано на догадке в Вашем теге вопроса осиротевшего пользователя, таким образом, я могу быть неправым.
- Ваша база данных, замененная от принципала до зеркала.
- серверу базы данных на зеркале (теперь принципал) не написали сценарий входа в систему из основного устройства, но вместо этого это было создано как новый вход в систему. Это означало бы, что sid's не соответствовал, таким образом, были проблемы с пользователем, входящим в систему после обработки отказа.
- Зафиксировать проблему с логином
sp_change_users_login 'Update_One'выполненный должен был устранить проблему входа в систему. Это изменило бы пользователя sid в базе данных для соответствия sid входа в систему на сервере базы данных. - База данных заменена снова. Теперь, вход в систему sid на сервере базы данных больше не соответствует. Что сделать? использовать
sp_change_users_loginснова решить проблему.
Что должно было произойти:
логины от принципала, которые используются в базе данных, которая участвует в зеркальном отражении, заданы сценарием (как г-н denny предложенный) к зеркалу. Самый легкий способ сделать это должно использовать sp_help_rev_login, можно также использовать задачу логинов передачи SSIS.
sid для логинов сервера базы данных видим в sys.server_principals. sid для пользователей базы данных находится в sys.database_principals. Проверьте их, чтобы гарантировать, что нет соответствия мисс.
-
1Я покупаю это для входа в систему. Но, почему ТРИГГЕР отсутствовал бы? Что, если бы триггер был создан пользователем с пропавшими без вести sid, это отбросило бы те находящиеся в собственности объекты? – Matt Rogish 2 December 2009 в 17:58
-
2can' t объясняют недостающий триггер. Но я могу сказать Вам с уверенностью, что SQL-сервер только отбросит триггеры, чтобы досадить Вам. It' s не ошибка! что-то это you' ре, не знающее, продолжается. Можно ли предоставить больше информации? Что делал триггер? – Nick Kavadias 2 December 2009 в 18:06
-
3OH! Триггер вставляет от зеркальной базы данных до незеркальной базы данных по ОСНОВНОМУ. Я don' t даже думают, что дб существует на обработке отказа.... Интересно, вызывают ли tha twould проблемы? – Matt Rogish 2 December 2009 в 18:10
-
4проблемы да. удалите триггер, нет. Некоторый другой процесс может идти здесь на это you' ре, не знающее – Nick Kavadias 2 December 2009 в 18:26
-
5Я can' t предполагают, что любой процесс отбросил бы триггер - у нас есть обычная репликация передачи журналов, зеркальное отражение дб и задания резервного копирования. Не много другого обслуживания – Matt Rogish 2 December 2009 в 22:51
Зеркальному серверу когда-либо создавали вход в систему? Если не необходимо будет написать сценарий входа в систему от основной системы так, чтобы SIDs соответствовали.
-
1Зеркальный сервер никогда не имел вход в систему, но почему это будет проблемой на основном устройстве – Matt Rogish 3 September 2009 в 20:31
-
2Это shouldn' t быть. SQL Server wouldn' t автоматически отбрасывают вход в систему. Почему isn' t вход в систему на зеркале? Если логины don' t существуют на обоих серверах затем приложения или пользователи can' t входят в систему, когда база данных находится на том сервере. – mrdenny 4 September 2009 в 03:46
-
3
Пользователь вероятен в зеркальной базе данных, просто не sync'd к входу в систему. Если бы пользователь был там, когда Вы устанавливаете зеркальное отражение, даже если бы вход в систему не существовал, то SQL Server не отбросил бы его. это там.
Если бы Вы добавили его позже, то это преодолело бы зеркало. Не вход в систему, но СОЗДАТЬ ПОЛЬЗОВАТЕЛЬ был бы передан.
Это было наше стороннее приложение поставщика, отбрасывающее триггер как часть их приложения. Безумный.
Триггер отсутствует, потому что кто-то отбрасывает его. Период. Никакое преступление не предназначило, но если Вы - один из администраторов, и Вы не знаете, где принципалы сервера находятся и почему принципалы базы данных могут быть осиротевшими после обработки отказа, затем я не могу положить, что Вы знаете почему триггер dissapears.
Используйте административную трассировку по умолчанию для обнаружения, кто отбросил триггер и когда. Если Вы удачливы, файл трассировки еще не был переработан. Набор на месте контролирует для отслеживания изменения, происходящие на сервере с этого времени. Для администраторов это не должно быть 'удивление' когда триггер dissapears. И не, Вы не можете обвинить продукт.