Я могу измениться, живая База данных SQL от Авторастут безопасно?
Существует много способов сделать VoIP, и кажется, что каждый поставщик оборудования теперь обеспечивает оборудование для него.
Выберите свои конечные точки. В настоящее время мы выполняем VIOP в офисе, но мы используем поставщика POTS, после того как мы поражаем край офиса. В какой-то момент мы посмотрим на соединение с внешним поставщиком VoIP, но у нас есть действующий контракт для окончания сначала. Большинство систем может даже сделать соединение POTS и VoIP, если Вы хотите обработку отказа
Говорите с поставщиком SIP, они должны смочь дать Вам хорошие оценки на том, сколько пропускной способности было бы необходимо на основе того, сколько параллельных вызовов необходимо работать
Посмотрите на свои опции Hardware. Все от Avaya до Звездочки выполняют voip теперь. Мы купили систему Switchvox у Digium (Производители звездочки) и были довольны ею.
Да. Можно увеличить mdf начальный размер, и SQL Server вырастит файл к тому размеру. Довольно безопасно сделать это на живой базе данных, хотя выбирают спокойное время! Необходимо найти, что увеличение размера очень быстро. Я просто вырастил тестовую базу данных с 128 МБ до 4 ГБ, и потребовалось 2 секунды.
Начальный размер 4 ГБ кажется разумным, учитывая текущий размер базы данных. Если у Вас есть большое дисковое пространство, почему бы не установить рост на что-то высоко, например, 2 ГБ или даже 4 ГБ? Рост базы данных в больших инкрементах уменьшает физическую фрагментацию mdf файла.
Вам не нужна еженедельная проверка, поскольку SQL Server будет просто продолжать выращивать файл. Просто удостоверьтесь, что у Вас не заканчивается дисковое пространство.
МЛАДШИЙ
PS я только что видел ответ Aaron. Я отличаюсь от него по этому, у меня нет проблемы с авторостом базы данных. Однако Вы хотите установить параметры автороста для предотвращения большого количества маленьких увеличений. 10% являются значением по умолчанию, и я думаю, что это является слишком маленьким для большинства баз данных.
PPS тот размер журнала выглядит немного большим. База данных установлена на "Полный вход", и раз так действительно ли Вы уверены, что база данных сохраняется? Если размер файла журнала выходит из-под контроля, можно использовать "dbcc shrinkfile" для сокращения его. См. Книги Онлайн для деталей.
-
1renniej - Взгляните на переходящий по двум ссылкам. Авторост может привести к значительным задержкам если Вы don' t включили мгновенную инициализацию файла, и даже если Вы сделаете то она приведет к фрагментации физического диска. Как лучшая практика, необходимо отключить авторост. blogs.msdn.com/sqlserverstorageengine/archive/2006/06/13/… sql-server-performance.com/Community/forums/p/24508/137168.aspx – Aaron Alton 25 June 2009 в 16:15
-
2Я должен согласиться с Renniej, самая большая проблема I' ve видят с авторостом, когда it' s устанавливают слишком маленький, таким образом, это происходит несколько раз подряд. Это может быть большим хитом производительности. Фрагментация файла является только проблемой на DAS. Устройство хранения данных SAN won' t быть затронутым. – Jim B 25 June 2009 в 17:11
-
3Если Ваш database' s модель восстановления полно затем, необходимо запланировать регулярные резервные копирования журнала транзакций вместо того, чтобы пытаться уменьшить журнал. – SuperCoolMoss 25 June 2009 в 17:40
-
4Ре SuperCoolMoss' комментарий, необходимо сделать полное резервное копирование или резервное копирование журнала сначала для усечения журнала (или журнал резервного копирования с усеченным, только если Вы абсолютно должны). Это усекает журнал, но won' t уменьшают .ldf файл. Вам нужен dbcc shrinkfile для этого. NB dbcc shrinkfile вряд ли сделает много, если Вы не усечете журнал сначала. – John Rennie 25 June 2009 в 19:23
-
5Спасибо за большой ответ - я увеличил размер файла, и воспринятый Ваш совет для автовыращивания, которое будет увеличено. Кажется, работает отлично. – aSkywalker 4 July 2009 в 07:25
Как своевременный - я просто записал, что сообщение в блоге журнала о точно этой проблеме вчера - проверяет его в Importance управления размером файла данных. Сводка:
- измерьте файлы данных первоначально для составления текущего размера, по крайней мере, плюс рост года, если это возможно,
- включите мгновенную инициализацию файла, если Вы можете (примечание: это только влияет на файлы данных, файлы журнала всегда должны обнуляться),
- ВСЕГДА имейте, автостановятся включенными - я полностью и полностью не соглашаются с любым, кто говорит противоположное. Это должно всегда идти для чрезвычайных ситуаций, когда Ваш контроль перестал работать (если ошибка SCOM не предотвращает Вас имеющий его на - см. статью для объяснения),
- набор авторастет до фиксированного, соответствующего размера
- Не полагайтесь авторастут. Использование файла монитора и вручную растет. Монитор для автовыращивает случай в чрезвычайных ситуациях
- никогда никогда не уменьшайтесь, если можно избежать его. Мои сообщения в блоге имеют сценарий, который показывает Вам почему.
- Ваш файл журнала кажется слишком большим. Контроль эта другая Важность сообщения в блоге надлежащего управления размером журнала транзакций для некоторых полезных советов.
Надеюсь, это поможет!
-
1Paul, я запустил скрипт из Вашего блога и достаточно уверенной 98%-й фрагментации. Однако простой переиндекс уменьшил фрагментацию для обнуления снова. Есть ли некоторый долгосрочный вред, который не исправляет переиндекс? – John Rennie 25 June 2009 в 19:55
-
2
-
3@John - да - но переиндекс выращивает базу данных снова для создания новой копии индекса, побеждая целую цель уменьшения. Даже если Вы выполняете ИНДЕКС DBCC INDEXDEFRAG/ALTER... РЕОРГАНИЗУЙТЕ, это генерирует тонну больше журнала транзакций для отмены эффектов уменьшения. @Jeff В первом сообщении в блоге, на которое ссылаются выше, there' s ссылка на сообщение в блоге на уменьшении.Попробуйте. – Paul Randal 29 June 2009 в 20:31
-
4I' m с Paul. Всегда имейте это на, управляйте своим пространством и вырастите его соответственно. Не уменьшайтесь если it' s чрезвычайная ситуация. Удержите достаточно свободного пространства для обработки регулярных потребностей, включая переиндексацию. – Steve Jones 15 July 2009 в 01:03
aSkywalker, используйте Силу или альтернативно смотрите на статью Paul Randal для 'ненамеренного DBAs' здесь: