Oracle чем занят temp

Обновлено: 03.07.2024

Системная база данных tempdb активно используется базами данных 1С:Предприятие 8.3 для хранения временных таблиц, промежуточных расчетов, версий строк при использовании режима версионирования и прочих временных данных. То есть для задач 1С:Предприятие интенсивность обращений к базе tempdb находится на высоком уровне, поэтому нужно подумать о размещении этой базы на выделенном быстром дисковом устройстве.Подходящими кандидатами на роль диска под tempdb будут выделенные быстрые дисковые RAID-группы уровня RAID1, выделенные накопители SSD или вообще RAM-диск.

В большинстве сценариев рекомендуется разбивать базу tempdb на несколько файлов данных с одинаковом начальным размером (Initial size) от 1GB и больше и увеличенным показателем прироста, например, в 512MB.

При определении количества файлов можно руководствоваться принципом: количество процессорных ядер = количество файлов данных tempdb, но при этом стоит помнить о том, что использование более 8 файлов (даже при количестве ядер более 8) далеко не всегда может иметь положительный эффект. Возможно по этой причине в инсталляторе SQL Server 2016 даже при большом количестве процессорных ядер по умолчанию предлагается 8 файлов tempdb.

Относительно 1С:Предприятие 8.3 можно встретить рекомендацию о том, что общий размер Initial size для всех файлов БД tempdb должен быть от 25% до 40% от размера рабочей БД 1С:Предприятие.

Саму процедуру переноса файлов tempdb на другой диск мы рассматривали ранее в заметке SQL Server 2008 - Перенос файлов БД tempdb на отдельный диск. Эта процедура может использоваться и на новых версиях СУБД, вплоть до SQL Server 2016.

Рассмотрим частный пример распределения файлов tempdb по разным дисковым томам, имеющим разные показатели производительности. В нашем примере имеется два тома NTFS:

R: менее производительный, но больший по объёму диск

Часть файлов данных в файловой группе tempdb, а также файл лога размещены на быстром диске. Файлы данных, расположенные на быстром диске установлены фиксированного размера без возможности авторасширения (исключением здесь является только файл лога). Другая часть файлов данных размещена на менее производительном дисковом томе, но при этом для файлов включено авторасширение.

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

Другие 4 файла данных tempdb окажутся на менее производительном дисковом томе R:

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

К операциям, которые могут вызвать бурный рост tempdb при работе БД 1С:Предприятие 8.3 можно отнести, например, регламентные процедуры с конфигурацией 1С, выполняемые из конфигуратора (обновление конфигурации, перерасчёт итогов и т.п.). Кроме того, активный рост tempdb может вызвать построение в 1С каких-то тяжёлых отчётов с большим количеством данных и за длительные периоды при условии, что код отчётов неоптимален или вообще содержит ошибки. В практической среде при размере БД около 170GB во время построения подобного отчёта мы наблюдали рост tempdb до 350GB. Учитывая эти моменты стоит подумать о полной изоляции файлов tempdb на выделенных дисковых томах, чтобы их возможный бурный рост не смог нарушить функционирования других БД SQL Server.

Используемый в нашем примере дисковый том T: представляет собой RAM-диск, подключенный к серверу SQL Server по методике, описанной в отдельной статье нашего Блога : Организуем RAM-диск для кластера Windows Server с помощью Linux-IO FC Target

Я хотел бы знать, как определить точный запрос или сохраненный процесс, который фактически заполняет журнал транзакций базы данных TEMPDB.

@prasanth Вам нужно будет зарегистрироваться на этом сайте с тем же openid, чтобы внести изменения в ваш вопрос здесь. Это зависит от того, что делает ваш код, и почему он использует базу данных tempdb. План выполнения должен показывать, что он делает, и если вы публикуете реальный код, мы можем помочь улучшить его. @CadeRoux Я думаю, что он пытается идентифицировать запрос (или запросы), не пытаясь выяснить, почему конкретный, известный запрос вызывает проблему. @AaronBertrand, да, но комментарий, кажется, указывает на то, что он хочет лучшие практики для кодирования.

РЕДАКТИРОВАТЬ

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

Вы можете изменить inner join on sys.dm_exec_requests на a left outer join , тогда вы будете возвращать строки для сеансов, которые в данный момент не выполняют активно запросы.

В запросе Мартина размещены .

. идентифицирует session_id s с активными транзакциями, которые занимают пространство журнала, но вы не обязательно сможете определить фактический запрос, вызвавший проблему, поскольку, если он не выполняется сейчас, он не будет зафиксирован в приведенном выше запросе для активные запросы. Вы можете быть в состоянии реактивно проверить самый последний запрос, используя, DBCC INPUTBUFFER но он может не сказать вам, что вы хотите услышать. Вы можете выполнить внешнее объединение аналогичным образом, чтобы захватить активно работающих пользователей, например

Вы также можете использовать DMV sys.dm_db_session_space_usage для просмотра общего использования пространства по сеансам (но, опять же, вы не сможете получить действительные результаты для запроса; если запрос неактивен, то, что вы получите, может не быть фактическим виновником).

Имея все эти запросы в вашем распоряжении, вы сможете определить, кто использует tempdb и как, особенно если вы поймали их в действии.

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

Временное табличное пространство, в противоположность тому, что можно предположить из его наименования, существует в базе данных постоянно, как и все прочие табличные пространства, такие как System и Sysaux. Однако данные во временном табличном пространстве имеют временный характер и существуют только на протяжении существования сеанса пользователя. Oracle использует временные табличные пространства в качестве рабочих областей для выполнения таких задач, как операции сортировки при выполнении запросов пользователей, и операции сортировки при создании индексов. Oracle не позволяет пользователям создавать объекты во временном табличном пространстве.

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

На заметку! СУБД Oracle Database пишет все данные программы в локальной области (PGA) порциями по 64 Кбайт, поэтому советуют создавать табличные пространства с размерами экстентов, кратными 64 Кбайт. Для крупных хранилищ данных и баз данных, поддерживающих системы принятия решений, которые интенсивно используют временные табличные пространства, рекомендуется размер экстента в 1 Мбайт.

Самый первый оператор после запуска экземпляра базы Oracle, который использует временное табличное пространство, создает сегмент сортировки, разделяемый всеми операциями сортировки в экземпляре. Когда вы останавливаете базу данных, она освобождает этот сегмент. Вы можете запросить представление V$SORT_SEGMENT, чтобы просмотреть выделение и освобождение места для этого сегмента сортировки. Увидеть, кто в данный момент использует сегмент сортировки, можно, опросив представление V$SORT_USAGE.Используйте представления V$TEMPFILE и DBA_TEMP_FILES, чтобы ознакомиться с подробностями о временных файлах, выделенных в данный момент временному табличному пространству.

Как упоминалось ранее, вы должны использовать конструкцию TEMPFILE при указании файлов, входящих в любое временное табличное пространство. С вашей точки зрения нет разницы между конструкцией DATAFILE, которая указывается для постоянного табличного пространства, и конструкцией TEMPFILE, специфицируемой для временного табличного пространства. Однако Oracle различает эти два типа файлов. Временные файлы содержат мало или вообще не содержат данных повторного выполнения, ассоциированных с ними.

Создание временного табличного пространства

Вы создаете временное табличное пространство точно так же, как и постоянное,лишь с тем отличием, что указываете конструкцию TEMPORARY в операторе CREATE TABLESPACE и подставляете эту конструкцию TEMPFILE вместо DATAFILE. Вот пример:

Конструкция SIZE во второй строке указывает размер файла данных и, как следствие, размер временного табличного пространства — 500 Мбайт. В приведенном операторе конструкция AUTOEXTEND ON приведет к автоматическому увеличению размера временного файла и вместе с ним — размера временного табличного пространства. По умолчанию все временные табличные пространства создаются с экстентами унифицированного размера — 1 Мбайт. Тем не менее, можно указать конструкцию UNIFORM SIZE,чтобы задать другой размер, как показано в следующем операторе:

В приведенном операторе конструкция EXTENT MANAGEMENT необязательна.Конструкция UNIFORM SIZE специфицирует специальный размер экстента в 16 Мбайт вместо 1 Мбайт по умолчанию.

Совет. При выделении места временному табличному пространству применяйте конструкцию TEMPFILE вместо DATAFILE.

Обычно принято создавать одно временное табличное пространство (именуемое, как правило, Temp) для каждой базы данных, но вполне можно иметь и несколько временных табличных пространств, входящих в группу временных табличных пространств,если база данных нуждается в выполнении интенсивных операций сортировки.Чтобы уничтожить данные во временном табличном пространстве по умолчанию,необходимо сначала воспользоваться командой ALTER TABLESPACE для создания нового табличного пространства по умолчанию в базе данных. Предыдущее временное табличное пространство по умолчанию затем можно уничтожить подобно любому другому.

На заметку! Oracle рекомендует устанавливать в качестве временного табличного пространства по умолчанию управляемое локально временное табличное пространство с унифицированным размером экстента в 1 Мбайт.

Изменение временного табличного пространства

С помощью команды ALTER TEMPORARY TABLESPACE можно выполнять различные задачи управления временным табличным пространством, включая добавление временного файла для его увеличения. Вот пример того, как можно увеличить временное табличное пространство:

Аналогичным образом можно использовать команду ALTER TABLESPACE для изменения размера временного файла:

Для уничтожения временного файла и удаления соответствующего файла операционной системы служит следующий оператор:

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

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

Сокращение временных табличных пространств

Иногда может понадобиться увеличить временное табличное пространство, чтобы вместить данные очень крупного задания, которое интенсивно использует это временное табличное пространство. После завершения такого задания можно сократить это временное табличное пространство, используя конструкцию SHRINK SPACE в операторе ALTER TABLESPACE. Вот пример:

Конструкция SHRINK SPACE уменьшит временные файлы до минимального размера,который составляет около 1 Мбайт. С помощью конструкции KEEP можно задать минимальный размер для временных файлов, как показано ниже:

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

Если запросить представление V$TEMPFILE, можно будет увидеть следующее:

База данных сократит один из двух временных файлов вплоть до 1 Мбайт, а другой — только на 1 Мбайт, оставив в нем нетронутыми 999 Мбайт пространства. Если ваша цель — сократить определенный временный файл до заданного минимума, можете сделать это, указав имя временного файла, который нужно сократить:

Приведенный выше оператор ALTER TABLESPACE сокращает только указанный временный файл до размера, заданного в конструкции KEEP. Остальные временные файлы из табличного пространства TEMP остаются нетронутыми. Конструкция KEEP в приведенном выше операторе гарантирует, что временный файл, который был специфицирован, сохранит 500 Мбайт пространства. Следующий пример демонстрирует, как сократить отдельный временный файл, не указывая сохранившегося пространства:

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

Временное табличное пространство по умолчанию

Когда вы создаете пользователей базы данных, то должны назначить каждому временное табличное пространство по умолчанию, в котором они будут выполнять свои временные работы, подобные сортировке. Если не указать явно пользователю его временное табличное пространство, для этих целей применяется табличное пространство System, что может привести к высокой степени фрагментации этого табличного пространства, помимо его заполнения и торможения всей деятельности базы данных.Избежать таких нежелательных ситуаций можно, создав временное табличное пространство по умолчанию (default) для базы данных при ее создании с помощью конструкции DEFAULT TEMPORARY TABLESPACE. Oracle затем будет использовать это временное табличное пространство по умолчанию для всех пользователей, кому таковое не будет назначено явно. Создание временного табличного пространства по умолчанию будет продемонстрировано в моей новой статье, где пойдет речь о создании новой базы данных Oracle.

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

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

На заметку! Для временного табличного пространства использовать конструкцию AUTOALLOCATE нельзя. По умолчанию все временные табличные пространства создаются с локально управляемыми экстентами унифицированного размера. Размер экстента по умолчанию составляет 1 Мбайт, как и для всех других табличных пространств, но при желании можно задать другой размер экстента при создании временного табличного пространства.

Группы временных табличных пространств

Крупные транзакции иногда могут приводить к переполнению временного пространства. Задачи, связанные с объемными сортировками, особенно включающие таблицы с несколькими разделами, приводят к значительной нагрузке на временные табличные пространства, от чего может пострадать производительность. В Oracle Database 10g была введена концепция группы временных табличных пространств, которая позволяет использовать временные табличные пространства в разных сеансах.

Ниже перечислены некоторые из основных характеристик группы временных табличных пространств.

  • Группа временных табличных пространств должна состоять минимум из одного табличного пространства. Ограничений на максимальное их количество не существует.
  • Если вы удалите все члены группы временных табличных пространств, группа также будет автоматически удалена.
  • Группа временных табличных пространств имеет то же самое пространство имен,что и временные табличные пространства, являющиеся частью группы.
  • Имя временного табличного пространства не может совпадать с именем любой из групп табличных пространств.
  • При назначении временного табличного пространства пользователю можно применять имя группы временных табличных пространств вместо имени конкретного табличного пространства. Имя группы можно также использовать, назначая временное табличное пространство по умолчанию для всей базы данных.

Преимущества групп временных табличных пространств

Использование группы временных табличных пространств вместо обычного одиночного временного табличного пространства обеспечивает следующие преимущества.

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

Создание группы временных табличных пространств

Когда вы назначаете первое временное табличное пространство в группу, то тем самым автоматически создаете группу. Чтобы создать группу табличных пространств, просто специфицируйте конструкцию TABLESPACE GROUP в операторе CREATE TABLESPACE,как показано ниже:

Приведенный оператор SQL создаст новое временное табличное пространство temp01 вместе с новой группой табличных пространств по имени tmpgrp1. Oracle создает новую группу табличных пространств, поскольку здесь при создании нового временного табличного пространства указана ключевая конструкция TABLESPACE GROUP.

Можно также создать группу временных табличных пространств, специфицируя ту же конструкцию TABLESPACE GROUP в команде ALTER TABLESPACE, как показано ниже:

Приведенный оператор заставит Oracle создать новую группу по имени tmpgrp1, поскольку ранее не существовало группы табличных пространств с таким именем.

Если вы специфицируете пару кавычек ('') вместо имени группы табличных пространств, вы тем самым неявно указываете Oracle не включать данное временное табличное пространство в группу. Вот пример:

Приведенный оператор создает временное табличное пространство по имени temp02,которое является обычным временным табличным пространством, не относящимся ни к одной группе временных табличных пространств.

Если полностью пустить конструкцию TABLESPACE GROUP, будет создано обычное временное табличное пространство, также не относящееся ни к одной из групп:

Добавление табличного пространства к группе временных табличных пространств

Как показано в предыдущем разделе, с помощью команды ALTER TABLESPACE можно добавить временное табличное пространство в группу. Можно также изменить группу, к которой относится данное табличное пространство, используя команду ALTER TABLESPACE. Например, можно указать, что табличное пространство temp02 принадлежит группе tmpgrp2, выполнив следующую команду:

При этом база данных создаст новую группу по имени tmpgrp2, если такой группы еще не существовало.

Установка группы в качестве табличного пространства по умолчанию для базы данных

Вы можете использовать группу временных табличных пространств в качестве временного табличного пространства базы данных по умолчанию. Если выполнить показанный ниже оператор, то все пользователи, не имеющие временного табличного пространства по умолчанию, смогут использовать любое табличное пространство из группы tmpgrp1 в качестве временного табличного пространства по умолчанию:

Приведенный оператор ALTER DATABASE назначает все табличные пространства из группы tmpgrp1 в качестве временных табличных пространств по умолчанию для всей базы данных.

Назначение групп временных табличных пространств при создании или изменении пользователей

Когда вы создаете новых пользователей, вы можете назначать им группы временных табличных пространств вместо одного временного табличного пространства. Вот пример:

Создав пользователя, можно также применить оператор ALTER USER, чтобы изменить группу табличных пространств, которую он будет использовать. Вот оператор SQL,который делает это:

Просмотр информации о группах табличных пространств

Для управления группами временных табличных пространств в базе данных можно использовать новое представление словаря данных DATA_TABLESPACE_GROUPS. Ниже показан пример простого запроса к этому представлению, который отображает имена всех групп табличных пространств:

Чтобы найти соответствие между табличными пространствами и группами, к которым они принадлежат, можно также воспользоваться представлением DBA_USERS. Вот пример:

Системная база данных tempdb активно используется базами данных 1С:Предприятие 8.3 для хранения временных таблиц, промежуточных расчетов, версий строк при использовании режима версионирования и прочих временных данных. То есть для задач 1С:Предприятие интенсивность обращений к базе tempdb находится на высоком уровне, поэтому нужно подумать о размещении этой базы на выделенном быстром дисковом устройстве.Подходящими кандидатами на роль диска под tempdb будут выделенные быстрые дисковые RAID-группы уровня RAID1, выделенные накопители SSD или вообще RAM-диск.

В большинстве сценариев рекомендуется разбивать базу tempdb на несколько файлов данных с одинаковом начальным размером (Initial size) от 1GB и больше и увеличенным показателем прироста, например, в 512MB.

При определении количества файлов можно руководствоваться принципом: количество процессорных ядер = количество файлов данных tempdb, но при этом стоит помнить о том, что использование более 8 файлов (даже при количестве ядер более 8) далеко не всегда может иметь положительный эффект. Возможно по этой причине в инсталляторе SQL Server 2016 даже при большом количестве процессорных ядер по умолчанию предлагается 8 файлов tempdb.

Относительно 1С:Предприятие 8.3 можно встретить рекомендацию о том, что общий размер Initial size для всех файлов БД tempdb должен быть от 25% до 40% от размера рабочей БД 1С:Предприятие.

Саму процедуру переноса файлов tempdb на другой диск мы рассматривали ранее в заметке SQL Server 2008 - Перенос файлов БД tempdb на отдельный диск. Эта процедура может использоваться и на новых версиях СУБД, вплоть до SQL Server 2016.

Рассмотрим частный пример распределения файлов tempdb по разным дисковым томам, имеющим разные показатели производительности. В нашем примере имеется два тома NTFS:

R: менее производительный, но больший по объёму диск

Часть файлов данных в файловой группе tempdb, а также файл лога размещены на быстром диске. Файлы данных, расположенные на быстром диске установлены фиксированного размера без возможности авторасширения (исключением здесь является только файл лога). Другая часть файлов данных размещена на менее производительном дисковом томе, но при этом для файлов включено авторасширение.

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

Другие 4 файла данных tempdb окажутся на менее производительном дисковом томе R:

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

К операциям, которые могут вызвать бурный рост tempdb при работе БД 1С:Предприятие 8.3 можно отнести, например, регламентные процедуры с конфигурацией 1С, выполняемые из конфигуратора (обновление конфигурации, перерасчёт итогов и т.п.). Кроме того, активный рост tempdb может вызвать построение в 1С каких-то тяжёлых отчётов с большим количеством данных и за длительные периоды при условии, что код отчётов неоптимален или вообще содержит ошибки. В практической среде при размере БД около 170GB во время построения подобного отчёта мы наблюдали рост tempdb до 350GB. Учитывая эти моменты стоит подумать о полной изоляции файлов tempdb на выделенных дисковых томах, чтобы их возможный бурный рост не смог нарушить функционирования других БД SQL Server.

Используемый в нашем примере дисковый том T: представляет собой RAM-диск, подключенный к серверу SQL Server по методике, описанной в отдельной статье нашего Блога : Организуем RAM-диск для кластера Windows Server с помощью Linux-IO FC Target

Читайте также: