Из коллекции дурацких ситуаций
Apr. 21st, 2003 03:39 pmЗасада No 740:
База данных Oracle, находится в production-режиме 24x7 (с часовым технологическим перерывом).
В результате активной работы команды оптимизаторов производительности ERP-системы, которая крутится на этом оракле, файлы данных разрослись до неимоверных размеров, после удаления разного рода статистик, временных данных и прочая-прочая-прочая они ещё и пролупустые.
Есть желание оптимизировать расположение данных и размеры файлов в соответствии с политикой штатного использования, но нет возможности - система уже запущена в production, а с экспортом-импортом 50 Гб в час не уложиться, тем более - с перестроением индексов.
Так и будет база жить 100-гигабайтным уродом, занимая 80% файловой системы...
База данных Oracle, находится в production-режиме 24x7 (с часовым технологическим перерывом).
В результате активной работы команды оптимизаторов производительности ERP-системы, которая крутится на этом оракле, файлы данных разрослись до неимоверных размеров, после удаления разного рода статистик, временных данных и прочая-прочая-прочая они ещё и пролупустые.
Есть желание оптимизировать расположение данных и размеры файлов в соответствии с политикой штатного использования, но нет возможности - система уже запущена в production, а с экспортом-импортом 50 Гб в час не уложиться, тем более - с перестроением индексов.
Так и будет база жить 100-гигабайтным уродом, занимая 80% файловой системы...
no subject
Date: 2003-04-21 10:21 am (UTC)На самом деле, я дибиэйствую уже года 4, в основном как раз в области performance tuning-а.
Просто с задачей уменьшения размеров tablespace до сих пор не сталкивался. А вот внутренние механизмы Оракла знаю лучше многих сертифицированных специалистов...