Oracle чем занят temp
It appears that Oracle’s temporary tablespace is still a mystery to some, possibly because it’s not managed in the same way as a conventional tablespace. Extents are allocated and re-used so space management looks nothing like that for a traditional tablespace. Because of that space errors are managed differently. Let’s look at how to manage a temporary tablespace and what tools are at the DBA’s disposal.
Starting with version 8.1.5 Oracle has provided a ‘true’ temporary tablespace where extents are allocated and assigned to sessions as they are needed. The extents are never dropped while the database is running so a properly utilized temporary tablespace will always have 0 ‘free’ space. In this sense ‘free’ means unallocated, and everything in the temporary tablespace will be allocated but that doesn’t mean it’s being used. This is why conventional space management has no place in the temporary tablespace.
So how IS the temporary tablespace managed? It’s done through several V$ views:
V$TEMPFILE V$TEMPSTAT V$TEMP_EXTENT_MAP V$TEMP_EXTENT_POOL V$TEMP_SPACE_HEADER V$TEMPSEG_USAGE (Oracle 9i and later releases) V$SORT_USAGE (Oracle 8.1.7, 8.1.6 and 8.1.5)
V$TEMP_EXTENT_MAP reports all of the allocated extents in the temporary tablespace:
The most helpful views to manage temporary tablespaces are V$TEMP_EXTENT_POOL and V$TEMPSEG_USAGE/V$SORT_USAGE. V$TEMP_EXTENT_POOL lists not only the allocated extents, it also reports on all used extents in a temporary tablespace by tempfile:
V$TEMPSEG_USAGE (or, if you prefer, V$SORT_USAGE) shows the temporary segment usage, by user, for all tablespaces:
[In 10.2.0.4 and later releases V$SORT_USAGE and V$TEMPSEG_USAGE have the same definition, with V$SORT_USAGE provided simply for backward compatibility.]
Temporary tablespace usage monitoring is a simple task of querying V$TEMPSEG_USAGE (V$SORT_USAGE, if that is preferred) over time:
Remember that such monitoring will produce no actionable data; unless the database is reporting errors allocating temp space the DBA really has nothing to do.
If you’d like to know how many extents are allocated and actually used per datafile the following query will produce a fairly useful report:
Again, no action needs to be taken based on such a report; it’s merely for informational purposes.
Who’s using your temp space, what queries are they executing and how much of that space is each one consuming? That’s also a fairly easy task to complete:
The V$TEMP_SPACE_HEADER view provides a less granular view of the consumed and available space; it lists the allocated and non-allocated space in the tempfiles, by file. Keep in mind that allocated does not mean used; there will likely be large differences between what V$TEMP_SPACE_HEADER reports and what V$TEMPSEG_USAGE provides.
I will quote myself (from somewhere else on the web) with regard to proper sizing of temporary tablespaces: “So how much space do you need in your temporary tablespace? That would depend upon how active your system is, how many concurrent active sessions there are, the size of the transactions and how much disk space you have. It isn’t a disgrace to increase your TEMP tablespace size over time as usage patterns, number of users and data volumes change. Oracle will also inform you that the temporary tablespace needs to be increased by issuing ORA-01652 errors (unable to extend temp segment by 128 in tablespace TEMP, for example). [ORA-01652 errors can occur for ANY tablespace in the database, and the affected resource will be listed in the error text: “ORA-01652: unable to extend temp segment by 128 in tablespace SYSTEM” indicates that the SYSTEM tablespace is needing to be increased. Again, ANY tablespace in the database can be listed in an ORA-01652, not just the TEMP tablespace. And the transaction which threw the error was rolled back because of it, thereby freeing the space it had already consumed when the error condition was encountered. An interesting side note: simply because an ORA-01652 error is displayed for a non-temporary tablespace doesn’t mean that there are temporary objects created there as when tables/indexes are created or extended the extents allocated are listed as temporary until the DDL completes at which time the created extents are given their ‘permanent’ object name. When regular tablespaces throw this error then there is insufficient space to extend tables and/or indexes and inserts/updates will fail. So, when an ORA-01652 error appears look carefully at the tablespace listed in the error text as it may not be a temporary tablespace issue.] The number reported in an ORA-01652 error is in blocks, not bytes, so you’ll need to convert that using the db_block_size value to know how many bytes the temporary tablespace needed to complete the transaction generating the error. There is no ‘rule of thumb’ to size a temporary tablespace because such rules usually create situations where the only tool becomes a hammer and every task ends up as a nail, and more often than not, you hit that thumb with the only ‘tool’ you’ve been given.”
DBA_TEMP_FILES will tell you how large the temporary tablespace is:
It can also report which files are associated with your temporary tablespace:
If you want, or need, to decrease the size of your TEMP tablespace you need to shut the database down, open it in restricted mode, resize the tempfile (or tempfiles) smaller then shutdown and startup the database. Adding space isn’t nearly as involved, as a simple ‘alter database tempfile resize ;’ increases the space.
What happens if the temporary tablespace doesn’t exist or isn’t available? Oracle will display this:
If you see this error message check to see if the temporary tablespace exists and is online. Correct any issues you find (create the missing tablespace or put the tempfiles back online).
If the tablespace exists but no tempfiles are assigned to it (which can occur after a database restore/recover from a backup) then Oracle reports:
So, the task is simply to issue ‘alter temporary tablespace … add tempfile …’ commands to make the tablespace no longer empty.
Managing the temporary tablespace isn’t rocket science, but it does differ (sometimes considerably) from the ‘normal’ tablespace management procedures employed for regular data files. Knowing that a ‘full’ temporary tablespace is not an issue (remember that segments are allocated then reused) can make the task a bit easier as Oracle will tell you (with ORA-01652 errors) if you’ve run out of space. Which means the DBA can spend time on useful tasks, like password resets.
Oracle FAQ определяет временное табличное пространство следующим образом:
временные табличные пространства используются для управление пространством для сортировки базы данных операции и для хранения глобальных временная таблица. Например, если вы объединение двух больших таблиц и Oracle невозможно выполнить сортировку в памяти, пространстве будет выделено во временное пространство для сортировки операция.
Это здорово, но мне нужно больше деталей о том, что именно использует пространство. Благодаря большинство запросов выполняют некоторую сортировку, поэтому мне нужно сузить ее до исполняемого файла клиента, целевой таблицы или инструкции SQL.
по сути, я ищу подсказки, чтобы сказать мне более точно, что может быть не так с этим (довольно большое приложение). Любой ключ может быть полезен, если он более точен, чем"сортировка".
Я не уверен, какая именно информация у вас уже есть, но с помощью следующего запроса укажет, какая программа/пользователь/сеансы и т. д. В настоящее время использует ваше временное пространство.
Как только вы узнаете, какой сеанс наносит ущерб, посмотрите на выполняемый SQL, и вы должны быть на правильном пути.
одно эмпирическое правило заключается в том, что почти любой запрос, который занимает больше секунды, вероятно, использует некоторое временное пространство, и это не только те, которые связаны с порядком BYs, но и:
- GROUP BYs (сортировка GROUPBY до 10.2 и хэш GROUPBY от 10.2 и далее)
- хэш-соединения или объединения
- глобальные временные таблицы (очевидно)
- перестроение индексов
иногда используемое пространство в временных табличных пространствах не освобождается Oracle (bug/quirk) поэтому вам нужно вручную удалить файл из табличного пространства, удалить его из файловой системы и создать другой.
спасибо Майклу Ошеа за его ответ,
но если у вас есть Oracle RAC несколько экземпляров, вам понадобится это .
и это скрипт для генерации операторов kill: Пожалуйста, просмотрите, какие сеансы вы будете убивать .
Как мы можем уменьшить табличное пространство temp в oracle? И почему он увеличивается так сильно, как до 25 Гб, поскольку в базе данных есть только одна схема для приложения, а размер табличного пространства данных-2 ГБ, а размер табличного пространства индекса-1 ГБ.
О Боже Мой! Посмотрите на размер моего временного места за столом! Или. как сократить временные табличные пространства в Oracle.
Да я запустил запрос, чтобы узнать, насколько велика моя временная табличная область:
первый вопрос, который вы должны задать: почему Временное табличное пространство является настолько большим. Возможно, вы знаете ответ на этот вопрос. Это может быть связано с большой запрос, который вы просто запускаете с видом, который был ошибкой (я сделал это не раз.) Может быть из-за других исключительных обстоятельств. Если это в этом случае все, что вам нужно сделать, чтобы очистить, - это сжать временное пространство и идти дальше по жизни.
но что, если вы не знаете? Прежде чем вы решите сжать вас, возможно, потребуется сделать некоторые исследование причин большого табличного пространства. Если это происходит на регулярная основа тогда возможно, что вашей базе данных просто нужно столько места.
представление динамической производительности
может быть очень полезно при определении причины.
может быть, вы просто не заботитесь о причине, и вам просто нужно уменьшить его. Это твой третий день на работе. Данные в базе данных только 200MiB если данные и временное табличное пространство 13GiB - просто сожмите его и двигайтесь дальше. Если она снова вырастет, мы посмотрим на причину. Тем временем я . места на диске и мне просто нужно больше пространства.
давайте посмотрим на сокращение его. Это будет зависеть мало на какой версии Oracle вы работаете и как было настроено временное табличное пространство.
Oracle сделает все возможное, чтобы вы не допустили каких-либо ужасных ошибок поэтому мы просто попробуем команды, и если они не сработают, мы уменьшимся в новый способ.
сначала попробуем сжать файл данных. Если мы сможем это сделать, то вернемся. пространство и мы можем беспокоиться о том, почему оно выросло завтра.
хорошо. Это не сработало. Как насчет этого?
если вы находитесь в 11g (Maybee в 10g тоже), это он! Если это работает, вы можете чтобы вернуться к предыдущей команде и дать ей еще несколько попыток.
Ok. Вернемся к серьезным вещам. Если временное табличное пространство, которое вы хотите сжать ваш по умолчанию временное табличное пространство, вам придется сначала создать новое временное tablespace, установите его как временное табличное пространство по умолчанию, затем отбросьте ваше старое временное табличное пространство по умолчанию и воссоздайте его. Послесловия падение создана вторая временная таблица.
надеюсь, одна из этих вещей поможет!
параметры управления табличными пространствами стали намного лучше по сравнению с версиями, начинающимися с 8i. Это особенно верно, если вы используете соответствующие типы файлов для временного табличного пространства (т. е. локально управляемые tempfiles).
таким образом, это может быть так же просто, как эта команда, которая сократит ваше табличное пространство до 128 Мег.
документация Oracle online довольно хороша. узнайте больше.
редактировать
похоже, что OP имеет более раннюю версию базы данных. В более ранних версиях мы должны изменять размер отдельных файлов данных. Итак, прежде всего, найдите имена файлов. Один или другой из этих запросов должен это сделать.
затем используйте этот путь в этой команде:
вы должны были написать, какую версию Oracle вы используете. Скорее всего, вы используете что-то другое, чем Oracle 11g, поэтому вы не можете сжать временное табличное пространство.
1) alter database tempfile '[your_file]' resize 128M; , который, вероятно, не
2) удалить и пересоздать табличное пространство. Если временное табличное пространство, которое вы хотите сжать, является временным табличным пространством по умолчанию, вам может потребоваться сначала создать новое временное табличное пространство, установить его как временное табличное пространство по умолчанию, а затем удалить старое временное табличное пространство по умолчанию и воссоздать его. После этого отбросьте вторую временную таблицу, созданную. 3) для Oracle 9i и выше вы можете просто удалить tempfile(Ы) и добавить новый(ы)
все описано здесь в деталях.
он будет увеличиваться, потому что вам нужно временное пространство для хранения, возможно, из-за декартового продукта или большой операции сортировки.
представление динамической производительности V$TEMPSEG_USAGE поможет диагностировать причину.
Если это не поможет:
- создать новое табличное пространство
- переключиться на новое временное табличное пространство
- подождите, пока старое табличное пространство не будет использоваться
- удалить старое табличное пространство
Я не беспокоюсь о сбросе альтернативной температуры в случае, если мне нужно снова вернуть хранилище в будущем.
Наблюдается рост tempdb, как лучше проанализировать причину роста tempdb(к примеру какие события выбрать в Profiler) ?
Или из за чего может наблюдаться рост tempdb?
Сейчас установил ограничение по размеру tempdb , во избежание проблем.
Важная деталь размер tempdb не меняется, когда пользователи в базах не работают.
(1) как-то написал сложный запрос и место на диске закончилось, файлик вырос до 90 гигов)) Пришлось шринкать!
Посмотрите что за доработки были и оптимизируйте запросы.
Еще как вариант обновление БД было. Но файлик вырос потом должен сдуваться, если сервер на рестарт агентов поставили.
(3)Скорее всего это не запросы. Перевел все базы в автономный режим (т.е. базы 1С вообще никаких операций не выполняют), перезапустил SQL , размер tempdb не поменялся, хотя по идее он по идее должен вернуться к минимальному значению. Или в любом случае нужно выполнять DBCC SHRINKDATABASE ?
(10) я не помню какие конкретно действия могут привести к автоматическому уменьшению. Шринк точно поможет!
(1) Посмотреть топ длительных запросов, либо топ нагружающих запросов по операциям чтения+записи, затем настроить ТЖ, с фильтром по запросу, и отловить его контекст
(4)Скорее всего это не запросы. Перевел все базы в автономный режим (т.е. базы 1С вообще никаких операций не выполняют), перезапустил SQL , размер tempdb не поменялся, хотя по идее он по идее должен вернуться к минимальному значению.
(14) видимо, кто-то или что-то поменяло этот размер. У меня один раз такое было. Причину тогда не понял.
Саму проблему предлагаю разделить на 2 части:
1. Как заставить ms sql уменьшать размер tempdb
2. Выяснить причину роста tempdb
По п.1 - создайте регл. задание, которое будет делать шринк tempdb с указанием начального размера и запускайте его раз в 15 минут + указать предельный объём temdb (это у вас уже сделано)
по п. 2 - основная причина это временные таблицы и сортировки, это нормальное поведение ms sql при работе с 1С, так как 1С очень любит временные таблицы как у казали коллеги в комментариях. На kb.1c.ru есть статья "Методика выявления транзакций, приводящих к значительному потреблению tempdb" почитайте, примените на практики советы разработчиков 1С и скорее всего выясните причину. Но не факт что удастся от неё избавиться)
(1)Происходят частые падения сессий sql в которых делаются временные таблицы, таблицы остаются не удаленными. После перезагрузки сервера база не сжимается, сервер видит что она не пустая и пропускает пересоздание. Нужно про анализировать саму базу и по ней вычислить виновника раздувания.
Кривой запрос, кладущий во временную таблицу большое количество записей. Соответственно в профайлере нужно ловить запросы на INSERT большого количества записей (детали подсказать не могу)
При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы.
Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п.
Вы ни от каких проблем не избавились. Получите ошибку в 1с - не возможно увеличить tempdb, во время работы.
Причиной увеличения размера базы данных TEMPDB, как правило, является невозможность автоматической очистки журнала транзакций и повторного использования свободного пространства в базе данных TEMPDB из-за наличия активных транзакций, использующих объекты этой базы данных. Основные причины, вызывающие длительную блокировку работы этих механизмов базы данных TEMPDB, заключаются в следующем:
"Большие" транзакции, использующие TEMPDB, выполнение которых занимает большой промежуток времени.
Сетевые ошибки, из-за которых Microsoft SQL Server не получает уведомление о потере сетевого подключения. Если клиентская рабочая станция зависает, перезагружается, или будет выключена во время исполнения определяемой пользователем транзакции, то Microsoft SQL Server будет считать, что клиент продолжает работу, и выполняющаяся клиентская транзакция будет по-прежнему активна. Время обнаружения подобной ситуации зависит от настроек параметров сетевого протокола, используемого Windows . Например, при использовании протокола TCP/IP это время составляет 2 часа.
Если для завершения активных транзакций не хватает места в базе данных, Microsoft SQL Server автоматически увеличивает размер TEMPDB на величину, заданную в параметрах этой базы данных (по умолчанию - 10% от текущего размера).
При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п. Эта служебная БД весьма нагружена и её ускорение сулит нам серьезный выигрыш в производительности. Давайте же поместим её в RAM.
Для начала посмотрим на метрики, какой же прирост производительности может быть получен от использования RAM-диска.
Безусловно, данный тест является синтетическим и не отражает реальный профит(который будет ниже), но разница в цифрах является весьма показательной.
При использовании RAM-диска у нас всегда будет возникать одна проблема - что будет, если размер tempDB выйдет за пределы RAM-диска?
Эта проблема решается весьма просто - MSSQL позволяет создавать дополнительные файлы данных и логов, в том числе для tempDB.
Таким образом общие рекомендации сводятся к следующему:
Первый файл данных tempDB - на RAM-диске, фиксированного размера (я ставлю 75%) от размера RAM-диске. Отключен autogrowth.
Первый файл логов tempDB - на RAM-диске, фиксированного размера (я ставлю 25%) от размера RAM-диске. Отключен autogrowth.
Второй файл данных tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Второй файл логов tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Таким образом, при росте размера tempDB и выходе его "из берегов" RAM-диска он просто расширится на медленные диски.
Чтобы сжать дополнительные файлы БД, если tempDB выросла в их размеры, настраивается простенький план обслуживания на ночь:
P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.
Специальные предложения
Эх! А я-то думал, что в статье будет описано, как именно сделать на сервере RAM-диск.
Какой понадёжнее, какой подешевле и т.п.
(5) Да не. Разобраться с установкой там легко.
Просто пишу свой отзыв о статье.
Я рассчитывал на сравнительный анализ ПО для RAM-дисков, а статья оказалась о другом. :)
(8) а теперь 2 тыщи домашняя версия и чуть больше 3к - коммерческая. Для организации копейки, так-то.
(4) Интерес скорее вызывает не столько цена, сколько опыт эксплуатации.
У вас это на рабочей базе/базах?
И нормально работает?
Плюсанул за разнесение по файлам для решения проблемы переполнения.
Вроде банальная штука, но почему-то никогда в голову не приходила. Правда и вопрос этот всерьез не рассматривал.
(9) Хм. И за счет чего ожидается прирост, если файлики рядом лежат?
Да и выставлять степень параллелизма в единицу - тоже спорный совет. Это радикально замедляет формирование тяжелых отчетов.
ЗЫ. Почитал про разбиение tempdb - это скорее прикрытие возможного узкого места (при большом количестве конфликтов при мультипоточном доступе к файлу), чем кнопка "турбо". Т.е. может и не иметь никакого эффекта.
(15) Правильно ли я понял Ваш вопрос - за счёт чего возникает прирост производительности после перемещения tempDB в RAM. Верно?
(16) Нет. Вопрос касался разделения tempdb на несколько файлов на одном и том же диске. Вопрос был не к вам.
Но если знаете точный ответ - буду благодарен. И актуальна ли эта рекомендация для RAID 5 и выше.
(9) Конечно знаю. Но в данной ситуации рекомендация разбивать неприменима. Нужно ли объяснить, почему?
(9) Не правильно давать ссылку на "перепосты", а не на первоисточник.
Плохо, что для 1С-ников истина по SQL на сайте 1С, а не на MSDN ((((
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков. Без тестов производительности статья ни о чем. Разбивать TempDB на несколько файлов - описано в настройках MS SQL от 1С, вероятно закрытие месяца от этого и ускорилось.
(12) Я не являюсь экспертом по SQL, но насколько мне известно есть куча настроек (хеширование, статистика), которые отвечают за скорость работы с данными, ХРАНЯЩИМИСЯ НЕПОСРЕДСТВЕННО в базе (файле MDF). Но эти настройки (ИМХО) не ускоряют работы с файлами TempDB, которые (источник этой информации указать не могу) не планировались в роли оперативного хранилище здоровенных массивов информации, как сейчас их использует платформа 1С.
MS SQL при построении плана запроса рассчитывает необходимое количество памяти и, если ошибается, то начинает задействовать tempdb. Это легко увидеть, если в профайлере получить планы запросов. Там, где стоит желтый восклицательный знак, там внутри как раз и пишет, что был задействован tempdb. Часто такое происходит на процедурах сортировки.
Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?
Да, конечно от статьи ждал большего. Хотелось бы анализа причин, прироста производительности. Ну, простите меня, не ведующего, ну не могу я понять, почему если от SQL сервера откусить несколько десятков гигабайт памяти и сделать на них RAM-диск, то операции на этом сервере станут выполнять ЗАМЕТНО быстрее (и уж тем более в общем случае, а не как у автора - в частном случае закрытия месяца).
Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти. Понятно, что если будут обрабатываться достаточно большие таблицы - они будут выгружаться на диск (при этом будет дублирование - часть данных наборов страниц будет в оперативном кеше и на диске). Но насколько же это будет в общем случае критично? Чтобы лишать SQL сервер гибко управлять всей своей свободной памятью, ради того, чтобы достаточно большая часть была всегда выделена под RAM диск с temdb - которая, скорее всего, в 90% не будет использована и на половину (а что будет использовано ещё и будет частично повторно кешировано в буфере SQL Server - неэффективно расходуя оперативную память на свои копии данных)! Так как SQL Server и всё-равно будет стараться держать временные таблицы в оставшейся у него оперативной памяти и выгружать их RMA-tempdb (причём выполняя объёмную пересылку данных между блоками памяти самым не производительным способом - через кучу посредников и между изолированными доменами приложений) в одну и в другую сторону только по мере необходимости (нехватки памяти, которая как раз и будет вызвана тем, что её попросту недодали SQL Server'у).
На мой взгляд RAM-диск для базы - это больше экстремальное экспериментирование, чем реальное предложение по ускорению! Вы вот так насоветуете админам - а они на своих серверах с 64Gb оперативной памяти, при базе(ах) объёмом боле 1Tb (с самой большой базой около 100Gb) и temdb, который у них при закрытии месяца пухнет свыше 100Gb возьму и выделять под RAM-tempdb минимум 16Gb (а кто-то и все 32Gb) и тем самым у них просядет обычная работа с данными рабочих баз на 25% (условно) в обычном режиме (а в пике ещё больше), а скорость работы с temdb (в часы макс нагрузки) увеличится ну максимум на 20% (и это в пике) - будет ли это реальной панацеей? Большой вопрос! Очень большой!
Тут в статье нужно было писать про исследования, которые должны были предварять такие вот серьёзные перераспределения ресурсов. Показывать где и как возникают узкие горлышки использования temdb. Обосновывать (с конкретными доводами тестов) когда и почему стоит отнимать буферную память от SQL сервера и отдавать её temdb.
И главное, в чём будет реальный экономический выигрыш - от того, что сервер будет требовать больше очень недешёвой серверной оперативной памяти, нежели - как альтернатива - просто разместить temdb на хорошем (тоже не дешёвом, но это пока с памятью не сравнить) серверном SSD диске - с высоким IOPS (лучше всего модели для PCI-ex, а не SAS/SATA; ну или хотя бы в слот M.2 - но это только на современных матерях) , и низким коэффициентом снижения производительности от числа полной перезаписи. Тут важна скорость - надёжность не так важна - это же не для хранения рабочей базы данных.
Вот тогда от статьи был бы толк.
Ну а если помещать в RAM tempdb - то я был начал только с лога temdb - который только пишется (и перезаписывается) в simple rec. mode, ему не требуется хранить большие объёмы дублирующихся данных. А данные временных таблиц - пусть SQL Server сам размещает в доступной ему буферной памяти, и выгружает на физ диск (лучше SSD), когда памяти уж совсем не хватает (а если это часто -то лучше 100 раз задуматься о том, чтобы её нарастить - ведь если её не хватает, от её перераспределения её больше не станет).
Вообще, прежде чем переходить на RAM - лучше сначала освоить перенос temdb на другой диск - если Ваш tempdb находится в том же RAID массиве что и диски рабочей базы - то задумайтесь сначала об этом, крайне негативном факторе - вынесите tempdb на отдельный RAID массив, да хотя бы просто на отдельный диск (два диска : данные и лог) и Вы сразу почувствуете прирост скорости, особенно в пиковой нагрузке! А уж если вы выберите для temdb PСI-ex SSD диски - то, наверняка, дальнейшее желание переносить их на RAM у Вас уже пропадёт!
akR00b; shaykhelov; Macter178; dabu-dabu; Tyler Durden; Brawler; szhukov; Starik; vvp117; GreenDragon; d4rkmesa; akim2040; Quantum777; alest; shtinalex; smallbuk; Dragonim; Rusmus; strrike; lohmatik; CSiER; mickey.1cx; nyam-nyam; mivari; kolya_tlt; MrWonder; AnderWonder; rintik; + 28 – 1 Ответить
Читайте также: