[ОТВЕТИТЬ]
07.04.2009 08:44
ismailovrr-pinokio
 
В Базе Данных версии 8i, после выполнения разного рода DML операций над объектами data-файл
данных становиться большого размера, не хватает место на жестком диске.
Следовательно, возникает желание уменьшить его.
Например таким образом:

alter database datafile '/oracle/oradata/kaztes /users01.dbf' resize 1000M

Oracle соответвенно выдает ошибку:

ORA-03297: file contains used data beyond requested RESIZE value

В Enterprise Manager Console Oracle показывает по данному data-файлу,
что он имеет свободное пространство dba_free_space показывает что
места в этом файле очень достаточно. Можно посмотреть конечно что
находится наверху файла примерно таким вот образом :

select file_name, segment_name, segment_type, owner from dba_extents s,

(select max(block_id) maxblock, file_id from dba_extents group by file_id) b,

dba_data_files f where

s.block_id = b.maxblock and s.file_id = b.file_id and f.file_id = s.file_id

order by file_name

-- Мной Найдено в интернете.
Этот скрипт показывает, какие объекты занимают последние экстенты файла.
Теперь вопрос что с ними делать. Логично перенести их куда нибудь в другое
место и попробовать заново уменьшить размер дата файла. То есть если это индекс,
то нужно перестраивать его в другое табличное пространство в другой data-файл например?
Cуществуют ли такие пакеты Oracle, которые сами высвобождают свободные блоки и
переставляют их опять же в текущий data-файл миную операции переноса объектов в другое место?
P.S. Проблема актуальна для версии Oracle 9i тоже. Если есть какие то наработки очень жду ответа.
07.04.2009 08:50
Radik
 
Вот, озадачились, просим помощи...
07.04.2009 08:54
Mtirt
 
Иногда помогает команда coalesce. Но далеко не всегда...
07.04.2009 09:56
ismailovrr-pinokio
 
Век живи-век учись. Поробуем почитаем coalesce.
07.04.2009 10:02
ismailovrr-pinokio
 
*170 - смайлик для тех кто работает c Oracle в течении 4 лет и не знает проблем ... где же они эти индивиды *107
07.04.2009 10:10
OlegON
 
Не надо coalesce. Желание "уменьшить" очень неправильное. Рекомендую перетащить индексы в другое табличное пространство, на другом диске. После чего перетащить таблички в другое табличное пространство, пересоздать это ТП, вернуть таблички обратно, прибить то ТП, куда временно таблички перемещались.
07.04.2009 10:49
ismailovrr-pinokio
 
И все же

alter tablespace users coalesce

что же делает это чудо команда?

Подскажите... Очень заинтриговали.
07.04.2009 10:58
OlegON
 
Просто объединит соседние пустые экстенты (например два рядом по 20Мб, станет один 40Мб). Если не удалял ничего масштабно - не поможет толком. Да и если PCTINCREASE <> 0 - оно выполняется автоматом.
07.04.2009 11:04
ismailovrr-pinokio
 
Спасибо за ответы.
alter tablespace users coalesce - прочитал про это действо.
Похоже на дефрагментацию табличного пространства.
Но место не освободиться.
Можно конечно через экспорт и импрот попробовать уменьшить.
Только вот у меня дата файлы c табличным пространстом USERS
размером по 30 Gb оба. Это мне нужно примерно 60*2=120 свободного места. Дефицит места на сервке для таких операций мало.
Думать еще раз думать.*43 Век живи век учись.
07.04.2009 11:14
OlegON
 
Не понятно, что ты хочешь сделать. Уменьшать базу - неблагодарное занятие. Главное, что практически бессмысленное. Если хочешь, могу с базой помочь.
07.04.2009 11:31
isi
 
Человек спрашивает как уменьшить, а не про обоснованность данного процесса

Цитата:
ismailovrr-pinokio Можно конечно через экспорт и импрот попробовать уменьшить.
Только вот у меня дата файлы c табличным пространстом USERS
размером по 30 Gb оба. Это мне нужно примерно 60*2=120 свободного места. Дефицит места на сервке для таких операций мало.
Думать еще раз думать.*43 Век живи век учись.
Не понял как ты так посчитал, во вторых при экспорте выгружаются только данные и т.д. но не индексы (которые как правило раза в 1,5-2 больше данных занимают) они будут создаваться при импорте заново,
следовательно если у тебя база 60 гигов (+ ты говоришь у тебя много пустого места), то выгрузка будет в районе 10-15 Гигов (к тому же экспортировать можно в сжатом виде), это что касается импорта/экспорта

Второй вариант тебе правильно подсказывают про alter table move / datafile resize, этот вариант хорош для больших БД, когда простои при imp/exp превышают по времени разумные пределы

Другие методы тебе не помогут (упустим тонкости)

Для 10 можно настроить при определенных условиях автоматическое управление размером, но я так понимаю специфика требует оставатся на oracle 8 - 9

В твоем случае я бы все таки воспользовался через imp/exp
07.04.2009 11:56
deucel
 
Можно подключить внешний диск (например по USB)
создать на нем табличное пространство REORG (не забыть про квоту)
Код:
ALTER USER "SUPERMAG"  QUOTA UNLIMITED ON "REORG"
перенести туда таблицы и индексы (выполнять под SUPERMAG)
Код:
DECLARE
   sql_stmt   VARCHAR2 (100);
BEGIN
   FOR c_rec IN (SELECT table_name
                   FROM all_tables
                  WHERE owner = 'SUPERMAG')
   LOOP
      sql_stmt := 'ALTER TABLE ' || c_rec.table_name || ' MOVE TABLESPACE REORG';

      EXECUTE IMMEDIATE sql_stmt;
   END LOOP;
END;
/

DECLARE
   sql_stmt   VARCHAR2 (100);
BEGIN
   FOR c_rec IN (SELECT index_name
                   FROM all_indexes
                  WHERE owner = 'SUPERMAG')
   LOOP
      sql_stmt := 'ALTER INDEX ' || c_rec.index_name || ' REBUILD TABLESPACE REORG';

      EXECUTE IMMEDIATE sql_stmt;
   END LOOP;
END;
/
но учти, переносится не все (старые таб. пространства не удалять)

и соотв. нужно будет перенести все назад (исправить в скрипте)
для индексов - таб. пространство INDX
для таблиц - таб. пространство USERS
после - собрать в адм. модуле полную статистику.
(не забыть убрать квоту)
Код:
ALTER USER "SUPERMAG"  QUOTA 0 K ON "REORG"
Не забыть удалить таб. пространство REORG , потом можно отключить внешний диск.
07.04.2009 12:54
baggio
 
при всем уважении... ребята не надо никаких USB!
этож очень большая вероятность потери ... имхо...
07.04.2009 13:22
Radik
 
Снова здравствуйте. Хочу еще от себя добавить, что это не супермажная база...
07.04.2009 14:10
kadr
 
Цитата:
baggio при всем уважении... ребята не надо никаких USB!
этож очень большая вероятность потери ... имхо...
а разве перед глобальными операциями над базой не полагается делать архив, это был офф.
Цитата:
Radik Снова здравствуйте. Хочу еще от себя добавить, что это не супермажная база...
Приложение, хранящее и работающее с данными в Oracle, не имеет значения.
Не будем вдаваться в подробности зачем хочешь уменьшить свободное место в табличных пространствах, методы уже описаны, либо
alter table move <имя нового ТП>
alter index rebuild <Имя нового ТП>
либо экспорт/импорт.
В первом варианте потребуется временно столько же свободного места сколько занято в табличных пространствах, для второго не потребуется. В первом варианте если есть в таблицах поля LOB, то такие таблицы не перенесутся по команде move их нужно будет переносить отдельно, во втором варианте всё должно выгрузиться и загрузиться, реально при экспорте получается файл раза в 3-4 меньше, чем реально занятое место в БД (не путать с выделенным, т.е. общим размером датафайлов)
10.04.2009 10:15
ismailovrr-pinokio
 
*43 Спасибо за идеи...будем пробовать пересторить индексы в другое таб. простарнство. Старый добрый REBUILD INDEX. Exp/Imp в данном случае не подходит потому что данные под экспорт слишком большиие, а Linux на котором крутится Oracle древний такой он не может работать с файлами больше 2Gb/ Вообщем я встрял ребята. Встрял *43 Век живи век учись ЭХ.
10.04.2009 12:40
OlegON
 
exp/imp позволяют бить на несколько файлов.
10.04.2009 12:53
kadr
 
и ещё умеет ждать пока место освободят на диске
10.04.2009 15:26
ismailovrr-pinokio
 
exp/imp позволяют бить на несколько файлов! - Хорошее предложение СПАСИБО *64 может это и выход из положения. В конце тунеля виден свет! В восьмерке набираю exp help=y . Смотрю help.... видно нужно в filesize указать размеры файл экспорта и Oracle будет разбивать на куски экспорт. Опять же это предположение. Опыт - золото, теория - серебро!*64
20.04.2009 15:20
кубышкин
 
может не по теме есть интересный момент таблицы и индексы SYSTEM не смотря на то что им предписанно размещение в табличном пространстве SYSTEM разбросанны по USERS ?
Каким образом их можно в кучку собрать ? получается хрень дата файл занят этими ометками и ресайзу не поддается
ибо куски лежат в самом конце
о забыл версия 8.1.6
20.04.2009 15:29
OlegON
 
Не раскиданы. Доказывай скриптами и их выводом.
20.04.2009 15:46
кубышкин
 
да точно олег спасибо за щелбан!
верно ривые руки у меня :) запрос не правильный написал
извеняюсь попровлю отпишусь
Опции темы


Часовой пояс GMT +3, время: 17:37.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.