Файл журнала Tempdb должен быть на другом диске, чем файлы данных для лучшей производительности?
Попробуйте следующее:
select s.username, s.sid, p.spid
from v$session s join v$process p on addr=paddr
where s.username = 'USER2';
Используя значение spid от вышеупомянутого запроса, войдите в систему сервера и дайте следующую команду от командной строки DOS:
orakill YOURSID spid
YOURSID является SID экземпляра базы данных, с которым Вы имеете дело.
orakill часто работает, когда инструментам GUI не удается уничтожить процессы. Вот хороший обзор orakill. Отметьте причину № 1 использованием orakill - это могло бы объяснить, почему Вы не можете использовать свой инструмент GUI:
Изменить системный оператор не очистит блокировок, которые существуют. Вместо этого сессия останется связанной, пока она не испытает таймаут, затем сессия уничтожается, и блокировки выпущены. Команда orakill уничтожит поток и блокировки немедленно.
Обновление:
Можно также попробовать:
select sid, serial#, program from v$session;
alter system kill session ',' immediate;
хотя я не протянул бы много надежды...
Я никогда не волновался об этом. Смотря на сайт MS, это говорит, что вход для tempdb минимизирован. Это может, вероятно, быть надуманный вопрос для Вас. И конечно, это не хорошая идея преждевременно оптимизировать - т.е. прежде, чем протестировать Вашу текущую среду при реалистической загрузке. Нет никакой единственной лучшей практики для конфигураций SQL для всех условий.
Мы говорим о двоичном журнале транзакций или просто файле журнала приложения простого текста? Общая лучшая практика для рабочих нагрузок базы данных должна сохранить Ваши журналы транзакций на другом физическом диске от Вашего хранилища данных; это сохраняет последовательные записи последовательными на журнале транзакций и улучшает уровень удачного обращения в кэш относительно обоих объемов путем уменьшения маслобойки кэша.
Традиционное представление состоит в том, что пользовательские файлы данных баз данных должны быть на одном диске, пользовательских файлах журнала баз данных на другом диске (это - диск, который действительно должен иметь быстрые задержки), и TempDB на отдельном диске. Кроме изоляции их друг от друга, журналы и файлы данных имеют совсем другие характеристики IO.
Вещи, измененные с появлением SAN, поскольку администраторы SAN обычно давали DBAs, вырезали части больших блоков диска - различия в производительности не были так очевидны.
Виртуализация изменила вещи далее, поскольку DBA, возможно, думал, что он разделил свои файлы данных от его журналов от его TempDB, но администратор VM поместил все те различные "диски" на тот же физический диск - в мире VM, те диски являются просто файлами.
Мое представление состоит в том, что все еще хорошо сохранить файлы данных, файлы журнала и файлы TempDB отдельными - если один из них чрезмерно увеличивается в размерах, Вы, надо надеяться, заставляете немного больше времени фиксировать его - и это не удалит все.
Если можно сделать это, лучшая практика должна все еще разделить файлы данных и файлы журнала - и если можно разделить TempDB также, то большой. Некоторые приложения, особенно с помощью Read Зафиксированная Изоляция Снимка, используют TempDB в большой степени.
Да, вам лучше разместить файлы журнала и данных TempDB на разных дисках. как обычно, мы помещаем файлы данных для всех БД и файлы журналов всех БД на отдельные диски, поскольку транзакции записываются в оба файла одновременно. так что та же концепция применима и к файлам TempDB.