очистка журнальных таблиц
Модераторы: m0p3e, edward_K, Модераторы
-
- Постоянный гость
- Сообщения: 69
- Зарегистрирован: 21 авг 2005, 19:37
- Откуда: Ukraine, Kharkov
- Контактная информация:
очистка журнальных таблиц
Удалил старые данные средствами галактики
support-журнализация-сервис-чистка журнала
, но в табличных пространствах oracle место не освободиось
если удалять через sql - truncate, то место освобождается.
Подскажите в чем различия этих способов.
если удалять всю информацию из журнальных таблиц, то оба способа должны привести к одному и тому же результату, а на практике наоборот? или я не прав?
support-журнализация-сервис-чистка журнала
, но в табличных пространствах oracle место не освободиось
если удалять через sql - truncate, то место освобождается.
Подскажите в чем различия этих способов.
если удалять всю информацию из журнальных таблиц, то оба способа должны привести к одному и тому же результату, а на практике наоборот? или я не прав?
email: slavik@ib.com.ua
-
- Постоянный гость
- Сообщения: 69
- Зарегистрирован: 21 авг 2005, 19:37
- Откуда: Ukraine, Kharkov
- Контактная информация:
тогда куда же удаляются записи из журнальных таблиц галактикой?oiko писал(а):truncate сжимает оракловую таблицу удаляя из нее физически не используемое место Галактика об этом не знает.
использование coalesce для табличных пространств не помогает.
или галактика переписывает данные при удалении из одних таблиц в другие, поэтому место и не освобождается?
email: slavik@ib.com.ua
Difference between DELETE and TRUNCATE
TRUNCATE will remove all rows of data from a table. DELETE can be used to remove all rows of data from a table or to remove selected rows of data from a table.
TRUNCATE doesn't use any rollback or undo segments. The TRUNCATE operation cannot be reversed, but the DELETE operation can be rolled back.
TRUNCATE will usually execute much quicker than DELETE.
No ON DELETE triggers are fired by the TRUNCATE actions.
TRUNCATE can be used to reclaim all extents except for the INITIAL extent. You can keep all extents with the REUSE STORAGE clause. These operations are not available with the DELETE statement.
TRUNCATE will remove all rows of data from a table. DELETE can be used to remove all rows of data from a table or to remove selected rows of data from a table.
TRUNCATE doesn't use any rollback or undo segments. The TRUNCATE operation cannot be reversed, but the DELETE operation can be rolled back.
TRUNCATE will usually execute much quicker than DELETE.
No ON DELETE triggers are fired by the TRUNCATE actions.
TRUNCATE can be used to reclaim all extents except for the INITIAL extent. You can keep all extents with the REUSE STORAGE clause. These operations are not available with the DELETE statement.
пишу из дому, по ентому синтаксис может иметь кучу ошибок, но суть постараюсь донести
truncate это принципиально другой механизим в отличии от delete
при truncate просто блоки данных помечаются как свободные (почти как форматирование, но без возможности восстановления)
с журналами боролись долго и всякими спосабами
способ 1 (делитом)
ночью запускается процедура
которая в цикле делает
declare
j_nrec char(16);
i integer;
cursor c1 as
select nrec (или еще что нить) from gal.x$journal
where "поле с датой" < (sysdate-"количество дней хранения журнала")
begin
open c1;
i:=0;
loop
c1 fetch into j_nrec
exit when c1 notfound;
delete from gal.x$journal t1
where t1.nrec=j_nrec
i:=i+1;
if i=50 then
coommit;
i:=0;
end if ;
end loop;
commit;
end;
способ 2 (транкейтом)
select 'TRUNCATE TABLE GAL.'||tablename||' ;'
from all_tables
where owner='GAL'
and tablename like 'J$%'
в результате получите чудный скрипт, который оттранкейтит все таблицы журнализации если его запустить. Не забудте в конец скрипта добавить trucate table gal.x$journal
второй способ более быстрый, первый более корректный (ИМХО)
но первый начнет задыхаться когда записи в журналах начнут измеряться несколькими миллионами
truncate это принципиально другой механизим в отличии от delete
при truncate просто блоки данных помечаются как свободные (почти как форматирование, но без возможности восстановления)
с журналами боролись долго и всякими спосабами
способ 1 (делитом)
ночью запускается процедура
которая в цикле делает
declare
j_nrec char(16);
i integer;
cursor c1 as
select nrec (или еще что нить) from gal.x$journal
where "поле с датой" < (sysdate-"количество дней хранения журнала")
begin
open c1;
i:=0;
loop
c1 fetch into j_nrec
exit when c1 notfound;
delete from gal.x$journal t1
where t1.nrec=j_nrec
i:=i+1;
if i=50 then
coommit;
i:=0;
end if ;
end loop;
commit;
end;
способ 2 (транкейтом)
select 'TRUNCATE TABLE GAL.'||tablename||' ;'
from all_tables
where owner='GAL'
and tablename like 'J$%'
в результате получите чудный скрипт, который оттранкейтит все таблицы журнализации если его запустить. Не забудте в конец скрипта добавить trucate table gal.x$journal
второй способ более быстрый, первый более корректный (ИМХО)
но первый начнет задыхаться когда записи в журналах начнут измеряться несколькими миллионами
-
- Постоянный обитатель
- Сообщения: 130
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: Ухта, Республика Коми
- Контактная информация:
А чем не устраивает стандартное галактическое сжатие журнала? да долго идет, часа полтора-два, но мы запускаем в 4 утра когда вбазе никого нет. Сейчас держим журнал 45 дней, что в полне приеслимо с учетом того, что бэкапы храним помесячно. На моей практике были случаи, когда для расследований приходилось поднимать базы двух летней давности, причем нужны были и журналы.
GAL 9.1, Oracle 11.2