Menu de navegação

[Anônimo]

Estou com a base do Oracle 10Xe estourada… 4.2Gb
Nos testes que fiz ela suportou 7000000 de registros de uma tabela.
Então fui na tabela e exclui 3500000… e o bando não diminuiu.
Tentei fazer a compactação pelo gerenciamento do Server… e nada.
Fiz um Export da base… deletei o banco… criei outro… e fiz o import e ele voltou a ficar com 4.2.

Alguem pode me dizer como compactar a base manualmente… ou algum procedimento para ele remover os espaços dos registros deletados??

[IshiiParticipante]

Olá,

Na verdade apenas excluir e refazer o Banco e o import não mudam o espaço utilizado. Será necessário nessa tabela em questão analisar os espaços como pct_free e os datatypes…

Cada criação de tabela já é feita uma alocação de espaço (initial) e na mesma deve ser considerado os datatypes (por exemplo char(200) ocupa mais espaço que varchar2(200) …) além disso há o pct_free da tabela. Já foi colocado em outro post uma dúvida sobre Volumetria Inicial do Oracle…que eu me lembre os materiais das versões do Oracle 8 ou até 7.3 falavam sobre esse assunto de armazenamento com mais detalhes vou ver se acho algo e coloco como artigo aqui no GPO…

No mais, reveja esses parâmetros antes da Importação e já na criação da tabela…

[]s Ishii

[diegolenhardtParticipante]

É como o Ishi disse, no momento do export acho que tem um parametro para que ele não leve o valor do Initial (KB) da tabela,
crie a tabela na mão e nos parametros coloque o Initial como o abaixo e veja se resolve,

create table teste (a number (6))
tablespace USERS
pctfree 10
initrans 1
maxtrans 255
storage
(
Initial 64K
minextents 1
maxextents unlimited
);[/b]

[Anônimo]

A maioria dos campos são varchar2…

Mas isso não resolve de imediato… então apelei para o modo “burro”… exportei todos os 3500000 via script…
Apaguei a base e recriei ela zerada…
Executei o script… e a base ficou com 2.1Gb

Mas como fazer isso direto?!?!? sem precisar desse trabalho burro?!!??

[diegolenhardtParticipante]

Após o delete, voce teria que mover a tabela pra outra tablespace para que os dados sejam realocados nos datafiles, depois você consegue dar um resize no datafile da tablespace, ai sim vai diminuir o tamanho do banco


ALTER DATABASE DATAFILE 'F:oradataliveMydb02.ora' RESIZE 1G


[vieriParticipante]

faça o export com o parametro :
compress=n

e faça o import novamente!!

[Anônimo]

Fiz o export com o compress=n e continuou a mesma coisa.

[Anônimo]

tente :

alter table tab_x enable row movement;

alter table tab_x shrink space cascade ;

alter database datafile ‘caminho/arquivo’ resize 1G;

[David SiqueiraParticipante]

Boa VDrago,
EU faria o mesmo, no 10g essas novas features ajudam muito quando se tem um banco fragmentado.

Com isso você reorganiza seus dados dentro da sua tablespace e consequentemente conseguira fazer um resize da mesma liberando assim o espaço que antes estava como excedente.

Experimente usar o ENABLE ROW MOVMENT e o SHRINK SPACE , que tem várias opções, COMPACT, CASCADE etc.

Veja o que mais se adapta a sua necessidade e implemente.

Boa Sorte.

Ats

[vieriParticipante]

cara tem algum objeto preso no final da tablespace…

crie uma nova e movimente este objeto pra lá !!

[juliano_sfParticipante]

Cara, eu sei que não tem sentido, mas isso parece um BUG

Já aconteceu comigo esse erro. Eu fiz SHRINK, rebuild de indices, truncate, o escambau e continuava dando esse erro. Só resolveu quando eu dropei a tabela e depois tive que importar ela novamente.

Porém, tenho procedimentos de limpeza com shrink que funcionam bem. Só depois que estourou o espaço que nada passou a funcionar.

Abraço,

[vieriParticipante]

não é BUG é porque a tabela está criada(initial extent) no final da tablespace,
e vc só irá tirar ela de lá removendo ou movendo.

Não é BUG !!

[juliano_sfParticipante]

[quote=”vieri”:20t61nsi]não é BUG é porque a tabela está criada(initial extent) no final da tablespace,
e vc só irá tirar ela de lá removendo ou movendo.

Não é BUG !![/quote]

Bom, no meu caso a tabela tinha 400MB, sabendo que com EXTENT MANAGEMENT AUTO AUTOALLOCATE os extents vão de 64k a 8MB, não vejo sentido em, após o truncate, o extent inicial da tabela ficar no final da tablespace. Em detalhes, o que ocorreu foi o seguinte:
– tentei importar um DUMP no mesmo banco, em outro esquema, e, no meio do import, deu erro de limite de 4GB
– então, eu dropei o novo usuário (import), fiz o truncate em uma tabela grande (400MB) e, então, tentei importar novamente o dump. Deu erro no mesmo ponto.
– então, eu dropei a tabela que eu tinha truncado, e o import funcionou beleza.

Se alguém consegue encontrar uma explicação, iria ajudar bastante.
Obrigado,

[vieriParticipante]

quando vc trunca ela, a tabela continua na mesma posição internamente no datafile, quando vc remove vc exclui essa marcação e consequentemente desce também a Hight Water mark.

[juliano_sfParticipante]

Bom, que eu saiba o truncate desaloca todos os extents da tabela, descendo também o HWM. O que não desce o HWM seria o DELETE.

http://mennan.kagitkalem.com/OnDeleteTr … racle.aspx

“But when you truncate a table, a DDL operation, oracle moves back the HWM”

Então, o TRUNCATE deveria liberar o espaço, mas no caso não liberou. Até porque os objetos não precisam ser gravados no final da tablespace existindo espaço livre no meio da tablespace, correto?

Ainda não entendi como isso é possível, sem ser por um BUG… alguma outra idéia?

[Autor]

Posts