Menu de navegação

[AnakimParticipante]

Tenho uma tabela que está crescendo considerávelmente e existem dados nela que podem ser apagados. Estou pensando em tomar a seguinte decisão:

1- Criar um Job para rodar toda segunda executando uma procedure;
2- Criar uma procedure que irá ter a regra do expurgo;

Na procedure terei um delete em cima da tabela, isso poderá gerar algum tipo de problema? Essa seria a melhor solução para diminuir o número de dados na tabela e com isso manter a performance?

Desde já agradeço a ajuda de todos.

[rmanParticipante]

1 – Que tipos de dados são esses que podem ser apagados ?

2 – Quantas linhas serão apagadas a cada segunda ?

Dependendo dos tipos de dados, é fazer o backup dos dados, e remove lo da base de produção, caso alguém solicite os dados, você poderá atender a solicitação, se você simplesmente apagar, terá que se justificar…

Outro ponto é, banco de dados foi desenvolvido justamente para guardar dados, então se o problema é espaço, é necessário rever os recursos físicos da sua estrutura…

[felipegParticipante]

[quote=”Anakim”:1v73d205]Tenho uma tabela que está crescendo considerávelmente e existem dados nela que podem ser apagados. Estou pensando em tomar a seguinte decisão:

1- Criar um Job para rodar toda segunda executando uma procedure;
2- Criar uma procedure que irá ter a regra do expurgo;

Na procedure terei um delete em cima da tabela, isso poderá gerar algum tipo de problema? Essa seria a melhor solução para diminuir o número de dados na tabela e com isso manter a performance?

Desde já agradeço a ajuda de todos.[/quote]

Olá,

Então, se você precisa apagar apenas uma parte da tabela essa é a única opção, se for a tabela inteira melhor um truncate 😉 .

Passe a procedure de delete para que possamos analisar, pois acho que o único cuidado seria em relação a volume de dados deletados x commit x UNDO.

Você tem uma idéia do montante de dados que será eliminado a cada execução?

Sobre fragmentação (devido ao volume e limpeza frequente de dados) não se preocupe, pois, do Oracle 10g em diante o default para tablespaces é “locally managed” o que impede esse tipo de situação.

PS: No domingo faça um backup dessa tabela, talvez você precise no futuro 😉

Espero ter ajudado!
Atenciosamente,
Felipe.

[AnakimParticipante]

O backup do banco de dados é feito, esqueci de mencionar.

A quantidade de registros a serem apagados é por volta de 5 milhões.

Eu não posso dar um truncate na tabela porque eu preciso manter alguns dados online.

Em relação aos dados que ficam neste banco dependendo da data alguns já não são necessários, ou seja, não é preciso manter os dados na tabela, porque eu posso puxar os dados de uma outra base ou do próprio backup do banco.

E quando os dados muito antigos são pedidos, que acontece muito raramente, eu tenho tempo para subir um bkp e fazer a pesquisa necessária.

Segue a procedure como solicitado:

CREATE OR REPLACE PROCEDURE QUEUE_PURGE() AS
BEGIN
DELETE FROM QUEUE WHERE ID_QUEUE IN(
SELECT ID_QUEUE FROM QUEUE WHERE TO_CHAR( DATE_INSERTED, 'YYYYMMDD' ) <= TO_CHAR( (SYSDATE - 7), 'YYYYMMDD' );
);

END QUEUE_PURGE;

Não entendi muito bem esta pergunta:

1 – Que tipos de dados são esses que podem ser apagados ?

É em relação aos tipos de daos da tabela? Se sim segue a DDL da mesma:

CREATE TABLE "GATEWAY_SMS"."QUEUE"
(
"ID_QUEUE" NUMBER NOT NULL ENABLE,
"ID_SMS" NUMBER NOT NULL ENABLE,
"ID_LOT" NUMBER,
"MSISDN" NUMBER NOT NULL ENABLE,
"PROCESSED" NUMBER(2,0) DEFAULT 0 NOT NULL ENABLE,
"PROCESSED_BEGIN" TIMESTAMP (6),
"PROCESSED_END" TIMESTAMP (6),
"TOTAL_PROCESSED_SERVER" NUMBER,
"DATE_INSERTED" TIMESTAMP (6) DEFAULT SYSTIMESTAMP NOT NULL ENABLE,
"STATUS" NUMBER(2,0)

[AnakimParticipante]

Esqueci de mencionar que esta tabela sofre muito insert, update e select. O expurgo seria em uma hora em que o sistema quase não estaria funcionando.

[felipegParticipante]

[quote=”Anakim”:3ksn7p9v]Esqueci de mencionar que esta tabela sofre muito insert, update e select. O expurgo seria em uma hora em que o sistema quase não estaria funcionando.[/quote]

Bom, as minhas perguntas foram respondidas.

Acho que está tudo certo, só falta um commit na sua procedure, ou no bloco que irá chamar a mesma ok?

Verifique também se nenhum job ou procedimento fora do horário utiliza esta tabela.

Aconselho a você rodar esse sujeito “na mão” (fora do horário, padrão dba 8) ) antes de criar o job e se possível (o melhor dos mundos) testar em um ambiente parecido que não seja o de produção, melhor ainda.

Atenciosamente,
Felipe.

[rmanParticipante]

Creio que assim o custo do DELETE seja menor.


CREATE OR REPLACE PROCEDURE QUEUE_PURGE() AS
BEGIN
DELETE FROM QUEUE WHERE TO_CHAR( DATE_INSERTED, 'YYYYMMDD' ) <= TO_CHAR( (SYSDATE - 7), 'YYYYMMDD' );
);
END QUEUE_PURGE;


[IshiiParticipante]

Olá,

Desculpem-me intrometer assim na conversa, mas tenho dois pontos a perguntar que não ficam claros para mim (considerando que estou ficando cada vez mais conservador por conta da idade…)

1) Por que há uma tabela que contém dados que podem ser deletados depois de um certo tempo e qual a previsão de crescimento diário/mensal em Gb com relação ao BD total, ou seja, qual o impacto desse crescimento no total?
2) Se realmente for necessário esse processo, acho que menor custo seria:
a) criar uma tabela temporária via create table …as select … where
b) truncate na tabela origem
c) insert da tabela temporária na tabela truncada (considerando que os dados a serem mantidos serão em menor quantidade que os que devem ser expurgados) e depois dropar essa tabela temporária
d) Empacotar e deixar agendado para execução conforme resultado do item 1

[]s Ishii
ps: Lembrem-se o Tuning deve ocorrer primeiro na Regra de Negócio e se não for mesmo possível, então usar os recursos do BD…

[AnakimParticipante]

Fiz a alteração na query como sugerido pelo rman, muito obrigado, nem tinha me tocado que estava complicando.

Só mais 2 dúvidas esse delete nesta tabela não pode gerar tuplas mortas? O oracle se encarrega de remover a “sujeira”?

[felipegParticipante]

[quote=”Ishii”:1pqw5axn]Olá,

Desculpem-me intrometer assim na conversa, mas tenho dois pontos a perguntar que não ficam claros para mim (considerando que estou ficando cada vez mais conservador por conta da idade…)

1) Por que há uma tabela que contém dados que podem ser deletados depois de um certo tempo e qual a previsão de crescimento diário/mensal em Gb com relação ao BD total, ou seja, qual o impacto desse crescimento no total?
2) Se realmente for necessário esse processo, acho que menor custo seria:
a) criar uma tabela temporária via create table …as select … where
b) truncate na tabela origem
c) insert da tabela temporária na tabela truncada (considerando que os dados a serem mantidos serão em menor quantidade que os que devem ser expurgados) e depois dropar essa tabela temporária
d) Empacotar e deixar agendado para execução conforme resultado do item 1

[]s Ishii
ps: Lembrem-se o Tuning deve ocorrer primeiro na Regra de Negócio e se não for mesmo possível, então usar os recursos do BD…[/quote]

Conservador? Brincadeira né Ishii, foi uma observação muito boa.

E mesmo se a quantidade de dados a serem eliminados for menor é só inverter os filtros para receber os dados a serem excluídos e dropar a tabela temporária direto, correto?

Novamente obrigado pela postagem, é justamente as observações de alto nível de vocês que me levaram a participar mais ativamente do fórum 😉

Atenciosamente,
Felipe.

[felipegParticipante]

[quote=”Anakim”:336ys5nj]Fiz a alteração na query como sugerido pelo rman, muito obrigado, nem tinha me tocado que estava complicando.

Só mais 2 dúvidas esse delete nesta tabela não pode gerar tuplas mortas? O oracle se encarrega de remover a “sujeira”?[/quote]

Anakim, desculpe, mas não entendi sua pergunta.

Não existe, até onde sei, uma recycle bin para linhas de tabela, o único lugar pra onde elas vão irá depender da sua configuração (Undo retention, Flashback e Archives) e apenas para fins de recuperação.

Atenciosamente,
Felipe.

[EmersonmartinsParticipante]

Na minha concepção como são muitos dados e o delete pode impactar na performance do Banco de Dados..Concordo com o ISHI.

Ao invés de executar um delete você poderia criar a tablela através do Create table com o SELECT informando seus parâmetros de inclusão..E até poderia renomear essa tabela ou depois fazer um backup dessa tabela se por acaso quisesse manter os dados para futuras solicitações..

Depois disso você poderia até truncar..sem problemas…

Emerson Martins
Analista de Banco de Dados

[rmanParticipante]

Vale lembrar que o TRUNCATE é um comando DDL que possui COMMIT automatico…

Cuidado ao fazer os testes, o ROLLBACK não vai trazer os dados de volta… 😯

[AnakimParticipante]

Desculpa pela demora na respota, mas é porque eu estava fazendo o levantamento do crescimento da tabela, conforme pedido.

Em relação a pergunta que eu fiz sobre o delete gerar tuplas mortas foi baseado na experiência que tive com o PostgreSQL.

A tabela hoje em dia cresce em média 700 mil registros por dia, e em disco 70 megas.

Daqui a uns 2 meses essa tabela passará a crescer em média 1.5 milhão de registros por dia e provavelmente em disco irá crescer 140 megas.

Sei que parece meio estranho poder deletar os registros desta tabela, mas a regra de negócio me permite fazer isso, porque esses registros podem ser tirados de outro banco.

Essa tabela sofre muito insert, update e select como falei anteriormente. O medo era fazer um delete nela e acabar ferrando a performance na hora de retoranar, inserir ou atualizar os dados.

Lendo a sugestões de vocês gostei em fazer o truncate na tabela, em relação a perda dos dados sempre se tem backup. Mas eu tenho um problema esse sistema não pode ficar parado e a ideia mais interessante de se fazer é renomear a tabela e criar uma nova.

A solução de renomear poderia me gerar algum impacto, como perder algum dado na hora da criação da tabela? Alguém teria algum script de como fazer esse processo da maneira mais eficiente?

[felipegParticipante]

[quote=”Anakim”:t5bzwgz4]Desculpa pela demora na respota, mas é porque eu estava fazendo o levantamento do crescimento da tabela, conforme pedido.

Em relação a pergunta que eu fiz sobre o delete gerar tuplas mortas foi baseado na experiência que tive com o PostgreSQL.

A tabela hoje em dia cresce em média 700 mil registros por dia, e em disco 70 megas.

Daqui a uns 2 meses essa tabela passará a crescer em média 1.5 milhão de registros por dia e provavelmente em disco irá crescer 140 megas.

Sei que parece meio estranho poder deletar os registros desta tabela, mas a regra de negócio me permite fazer isso, porque esses registros podem ser tirados de outro banco.

Essa tabela sofre muito insert, update e select como falei anteriormente. O medo era fazer um delete nela e acabar ferrando a performance na hora de retoranar, inserir ou atualizar os dados.

Lendo a sugestões de vocês gostei em fazer o truncate na tabela, em relação a perda dos dados sempre se tem backup. Mas eu tenho um problema esse sistema não pode ficar parado e a ideia mais interessante de se fazer é renomear a tabela e criar uma nova.

A solução de renomear poderia me gerar algum impacto, como perder algum dado na hora da criação da tabela? Alguém teria algum script de como fazer esse processo da maneira mais eficiente?[/quote]

Anakim,

O comentado não foi a atividade de renomear uma tabela mas sim criar uma nova tabela temporária (Create table as select …where) com os dados que você queira manter, seguido de truncate na tabela origem, inserção do dados da tabela temporária de volta na tabela original e exclusão da tabela temporária.

Atenciosamente,
Felipe.

[Autor]

Posts