Вопросы Теги

SQL Server tempdb подсказки по оптимизации для нового сервера?

Короткий ответ

Поскольку отказоустойчивое поведение итератора не гарантируется.

Длинный ответ

Вы получаете это исключение, потому что вы

Плохо: 

// we're using iterator
for (Iterator i = c.iterator(); i.hasNext();) {  
    // here, the collection will check it hasn't been modified (in effort to fail fast)
    String s = i.next();
    if(s.equals("lalala")) {
        // s is removed from the collection and the collection will take note it was modified
        c.remove(s);
    }
}

Хорошо: 

// we're using iterator
for (Iterator i = c.iterator(); i.hasNext();) {  
    // here, the collection will check it hasn't been modified (in effort to fail fast)
    String s = i.next();
    if(s.equals("lalala")) {
        // s is removed from the collection through iterator, so the iterator knows the collection changed and can resume the iteration
        i.remove();
    }
}

Теперь, чтобы перейти к следующему элементу, «почему»: в приведенном выше коде обратите внимание на то, как выполняется проверка модификации - удаление помещает коллекцию как измененную, а следующая итерация проверяет любые изменения и терпит неудачу, если она обнаруживает изменение коллекции. Еще одна важная вещь: ArrayList (не уверенный в других сборниках) делает not проверкой на модификацию в hasNext().

Поэтому могут произойти две странные вещи:

  • Если вы удалите последний элемент во время итерации, ничего не будет выбрано. Это потому, что нет «следующего» элемента, поэтому итерация заканчивается до достижения кода проверки модификации
  • . Если вы удалите второй-последний элемент ArrayList.hasNext() будет также возвращать false, потому что итератор current index теперь указывает на последний элемент (бывший второй по-последнему). Таким образом, даже в этом случае после удаления нет «следующего» элемента

Обратите внимание, что все это соответствует документации ArrayList :

Обратите внимание, что неэффективное поведение итератора не может быть гарантировано, поскольку, как правило, невозможно сделать какие-либо серьезные гарантии при наличии несинхронизированной параллельной модификации. Неуправляемые итераторы бросают ConcurrentModificationException с максимальной эффективностью. Поэтому было бы неправильно писать программу, зависящую от этого исключения, за ее правильность: неудачное поведение итераторов должно использоваться только для обнаружения ошибок.

blockquote>

Отредактировано для добавления:

Этот вопрос дает некоторую информацию о том, почему проверка параллельной модификации не выполнена в hasNext() и выполняется только в next().

]
16
задан splattne 11 December 2008 в 16:57
поделиться

4 ответа

Если бы я должен был выбрать одного человека, которому я доверяю для совета относительно конфигурирования сервера, это был бы Denny Cherry. Он написал статью, объяснив это.

http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1307255,00.html

6
ответ дан 30 November 2019 в 16:19
поделиться

Вот то, что я исследовал меня от множества источников.

для оптимизации tempdb производительности обращают внимание на конфигурацию физического диска, конфигурацию файла, а также некоторые настройки в базе данных.

конфигурация Физического диска

tempdb должен находиться на собственные выделенные физические диски . Это позволяет ему разделять транзакции ввода-вывода от остатка от объемов на SQL Server.

Для перемещения tempdb в новый дисковод используйте ALTER DATABASE. Это - ключевая команда T-SQL для выполнения этой операции. Microsoft предлагает хороший пример в Книгах SQL Server 2005 года Онлайн. Название статьи является ALTER DATABASE (Transact-SQL), и определенный раздел 'G. Перемещение tempdb к новому местоположению'.

tempdb очень база данных высокой записи. Так, массив RAID 5 не является надлежащим местом для него. Необходимо поместить tempdb или на RAID 0 или на массив RAID 10 , поскольку они оптимизированы для приложений высокой записи. Если можно предоставить дополнительный RAID 0 или массивы RAID 10 для каждого физического файла базы данных для tempdb, Вы получите увеличенную производительность.

файлы Базы данных

Вы должны иметь один физический файл на ядро процессора в сервере . Так, если у Вас есть двойная микросхема, двухъядерный сервер, у Вас должно быть четыре физических файла базы данных для базы данных tempdb. При добавлении большего количества файлов базы данных важно настроить файлы в тот же начальный размер и с теми же настройками роста . Тем путем SQL Server запишет данные через файлы максимально равномерно.

размер файла Базы данных

размер базы данных tempdb может влиять на производительность системы. Например, если размер, который определяется для tempdb, является слишком небольшим, часть обрабатывающей систему загрузки может быть завязана дружбу авторост tempdb к размеру, требуемому поддерживать рабочую нагрузку каждый раз, когда Вы перезапускаете экземпляр SQL Server. Можно избежать этих издержек путем увеличения размеров tempdb файла данных и файла журнала.

Определение соответствующего размера для tempdb в продуктивной среде зависит от многих факторов включая существующую рабочую нагрузку и функции SQL Server, которые используются. Microsoft рекомендует проанализировать существующую рабочую нагрузку путем выполнения следующих задач в тесте SQL Server среда:

  1. Набор авторастут на для tempdb (в тестовой среде!) .
  2. Выполняют отдельные запросы или файлы трассировки рабочей нагрузки и контролируют использование пространства tempdb.
  3. Выполняют операции ведения индексов, такие как восстановление индексов и контролируют пространство tempdb.
  4. Использование использование пространства оценивает от предыдущих шагов для предсказания общего использования рабочей нагрузки; скорректируйте это значение для спроектированного параллельного действия, и затем установите размер tempdb соответственно.

Минимальные рекомендации размера для tempdb следующие: 

   Envir. Size  DB Size (MB)  Log Size (MB)
   -----------  ------------  -------------
   Small                1024            256
   Medium               5120           1024
   Large               10024           2048

настройки Database

можно далее увеличить tempdb производительность на [1 158] отключение статистики автоматического обновления , который сохранит tempdb некоторая работа. Можно также установить автоматический, создают опцию статистики ко лжи .

Правовая оговорка: Настройки должны быть изменены с осторожностью. В зависимости от вида загрузки Вы помещаете на своем tempdb, изменение настроек могло неблагоприятно повлиять на производительность системы.

Для достижения оптимальной tempdb производительности следуйте инструкциям и рекомендациям, предоставленным в Оптимизация tempdb Производительность .

, Как контролировать tempdb использование?

Выполнение из дискового пространства в tempdb может вызывать значительные разрушения в продуктивной среде SQL Server и может предотвратить приложения, которые работают от завершающихся операций.

можно использовать sys.dm_db_file_space_usage динамическое представление управления для контроля дискового пространства, которое используется этими функциями в tempdb файлах. Кроме того, для контроля действия выделения или освобождения страницы в tempdb на сессии или уровне задачи можно использовать sys.dm_db_session_space_usage и sys.dm_db_task_space_usage динамические представления управления.

Эти представления могут использоваться для идентификации выполнения больших запросов, временных таблиц или табличных переменных, которые используют большое tempdb дисковое пространство. Существует также несколько счетчиков, которые могут использоваться для контроля свободного пространства, которое доступно в tempdb и также ресурсах, которые используют tempdb.

Ссылки:

31
ответ дан 30 November 2019 в 16:19
поделиться

Из того, что я читал, лучше помещать tempDB на свой собственный физический диск (или массив). Для максимальной скорости Вы могли вставить на набеге 0 массивов. Однако, если один из дискового сбоя, сервер БД станет недействующим. Если Вы хотите больше дублирования, помещаете его на набег 10 массивов. Реальный ключ, кажется, разделяет его от других баз данных, потому что может быть такое действие в TempDB.

то, Как далеко Вы идете действительно, зависит от других баз данных по серверу и делают ли они большую работу с Временными таблицами, и т.д.

я ничего не услышал о нескольких файлах на основе количества центральных процессоров или ядер.

2
ответ дан 30 November 2019 в 16:19
поделиться

См. также эту регистрацию журнал транзакций RAID SQL Server, который содержит обсуждение расположения сервера, которое затрагивает некоторые проблемы вокруг tempdb.

2
ответ дан 30 November 2019 в 16:19
поделиться
Другие вопросы по тегам:

Похожие вопросы: