Menu de navegação

[AnakimParticipante]

Existe a possibilidade de renomear uma tabela? Se sim, qual o impacto que isso gera?

[rmanParticipante]

Você pensou em criar uma nova tabela com o nome desejado, copiar as linhas para a nova tabela, criar as CONSTRAINTS, depois remover a tabela antiga ? Não precisa nada disso.

Pulo do gato:


ALTER TABLE RENAME TO ;


Ou pulo do gato ninja:


RENAME TO ;


Segue um exemplo prático:


CREATE TABLE PAI (
PAI_ID NUMBER,
NOME VARCHAR(32)
);

ALTER TABLE PAI ADD CONSTRAINT PK_PAI PRIMARY_KEY(PAI_ID);

CREATE TABLE FILHO (
FILHO_ID NUMBER,
PAI_ID NUMBER,
NOME VARCHAR(32)
);

ALTER TABLE FILHO ADD CONSTRAINT PK_FILHO PRIMARY_KEY(FILHO_ID);

ALTER TABLE FILHO ADD CONSTRAINT FK_PAI_FILHO FOREIGN KEY(PAI_ID) REFERENCES PAI(PAI_ID);

INSERT INTO PAI (PAI_ID, NOME) VALUES (1, 'JOAO');
INSERT INTO PAI (PAI_ID, NOME) VALUES (2, 'PEDRO');
INSERT INTO PAI (PAI_ID, NOME) VALUES (3, 'AUGUSTO');
INSERT INTO PAI (PAI_ID, NOME) VALUES (4, 'JONAS');
INSERT INTO PAI (PAI_ID, NOME) VALUES (5, 'MANUEL');
COMMIT;

INTO FILHO(FILHO_ID, PAI_ID, NOME) VALUES(1, 1, 'LUCAS');
INSERT INTO FILHO (FILHO_ID, PAI_ID, NOME) VALUES (2, 1, 'MARIANA');
INSERT INTO FILHO (FILHO_ID, PAI_ID, NOME) VALUES (3, 2, 'JOANA');
INSERT INTO FILHO (FILHO_ID, PAI_ID, NOME) VALUES (4, 2, 'MARCOS');
INSERT INTO FILHO (FILHO_ID, PAI_ID, NOME) VALUES (5, 4, 'ANTONIO');
COMMIT;

ALTER TABLE PAI RENAME TO FATHER;

RENAME FILHO TO SON;

DROP TABLE SON;

DROP TABLE FATHER;


O melhor de tudo, nem precisa se preocupar com as CONSTRAINTS.

[IshiiParticipante]

Olá,

Inclusive é esse o conceito do Flashback, primeiro ocorre um rename do objeto para o BIN$¨ e depois o drop efetivamente…

[]s Ishii

[rmanParticipante]

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

Inclusive é esse o conceito do Flashback, primeiro ocorre um rename do objeto para o BIN$¨ e depois o drop efetivamente…

[]s Ishii[/quote]

Interessante, isso eu não sabia.

[AnakimParticipante]

Valeu pelas dicas rman, era isso que eu estava procurando.

Fiz um teste e vi que a tabela é renomeada, mas as constraints não.

Pesquisando na documentação da Oracle achei este comando para renomeação de index:

alter index COLUMN2_PK rename to TEST_3_COLUM2_PK;

Teria mais algum?

[rmanParticipante]

@Anakim

Você precisa verificar o que tem nesta tabela.

Verifique:

• Primary Key
• Trigger
• Sequence

Realmente o nome das CONSTRAINTS não são alteradas, quando disse para não se preocupar com as CONSTRAINTS, quis dizer que as referencias serão mantidas, não necessitando cria-las de novo.

[AnakimParticipante]

Teria algum problema em renomear a tabela e criar uma nova tabela com o nome da mesma que foi renomeada? Poderia ficar algum lixo ou alguma coisa que possa interferir na performance da tabela?

Desculpem a ingnorância só estou querendo me certificar que não farei droga. 😉

[rmanParticipante]

@Anakim

Poderia explicar o contexto do problema?

Qual é a necessidade de renomear a tabela, e criar outra com o mesmo nome ?

[AnakimParticipante]

Eu tenho uma tabela que cresceu muito, já tentei fazer o expurgo nela e demora muito e a minha janela de manutenção é muito pequena, então, a ideia for renomear a tabela e manter uma manutenção períodica nela.

Não sei se é a melhor solução, você teria alguma sugestão?

[rmanParticipante]

@Anakim

Que dados são esses que é permitido expurgar ? São logs ?

Como é feito o expurgo ? DELETE ? TRUNCATE ?

Existe a possibilidade de compactar e particionar a tabela.

[AnakimParticipante]

São dados antigos, que já foram para o backup. O expurgo ainda não foi feito, mas a ideia seria dar um truncate na tabela de tempos em tempos.

Em relação ao particionamento eu sei que existe essa possibilidade o problema que a nossa versão não tem particionamento, infelizmente.

Agora em relação a compactar a tabela eu não entendo muito, teria algum ganho usando essa solução?

[rmanParticipante]

@Anakim

Eu lembrava de uma discussão sobre expurgar tabela, eu ia te passar o tópico… surpresa, o tópico é seu 😆

https://profissionaloracle.com.br/module … highlight=

Eu ainda não entendo por que expurgar os dados, banco de dados foi feito justamente para guardar dados, expurgar os dados seria um workaround, para solucionar o problema é adquirir novos discos. Ou reavaliar o que está sendo gravado, se realmente há necessidade.

Outro detalhe, banco de dados a tendencia é crescer pro infinito. 😯 . Não adianta remar contra a maré.

Se o problema é o tamanho do backup, adote uma estrategia como o backup incremental.

Verifique no OEM (Oracle Enterprise Manager) o que o advisor de segmento diz sobre essa tabela, geralmente a recomendação é compactar.

[AnakimParticipante]

Sim rman eu usei a estratégia do post que você falou em outro banco.

A minha tabela atualmente está com 283 milhões de registros e a tendência é crescer cada vez mais, aqui na emrpresa (como mecionei no outro post) trabalhamos com mensagens SMSs e com cobrança destes serviços e coisas do tipo, então, diariamente a minha tabela cresce muito.

Estes sistemas aonde eu tenho que ter uma performance elevada os dados são válidos para o mesmo dia, ou seja, o dado de ontem não vale para muita coisa, só para pesquisa.

E eu posso tirar estes mesmos dados de outros bancos, que ficam como um dw.

Estava fazendo uma análise no banco e vi que estou tendo problema de user i/o, descobri que tem outro banco nesta máquina, um postgres e isso está interferindo e muito no meu sistema.

A primeira medida foi pedir para tirar este outro banco da máquina e a segunda vai ser rodar o adivisor depois que este banco mudar de máquina.

A ideia do expurgo é pq eu tenho que manter esse sistema funcionando com uma performance altíssima, pq todos as cobranças da nossa empresa passam por ele, então, não posso deixar uma query ficar lenta porque a tabela está muito grande.

Até agora o que eu já expus aqui, você teria alugma outra sugestão? 🙂

Só lembrando, eu não tenho particionamento neste banco, infelizmente…

[rmanParticipante]

@Anakim

O fato de a tabela ser grande não necessariamente a consulta terá um desempenho ruim. As consultas que devem ser rápidas, retornam apenas 1 linha ? Neste caso um índice bem aplicado resolve isso. Mas se o que deve ser rápido é o relatório diário/semanal/mensal de cobrança que retorna mais de 10% da tabela, índice vai piorar a situação.

São quantas consultas a serem analisadas ?

É importante conhece as regras de negócio da aplicação. Isso ajuda a tomar decisões.

[AnakimParticipante]

As regras eu conheço bem. Tem uma tabela que sofre muito insert, update e select, e é nesta tabela que eu estou querendo fazer o expurgo, porque ela está muito grande, como informei antes.

Geralmente os selects retornam por volta de 200 a 500 linhas, esses selects acontecem durante o dia todo, porque são os clientes que vão ser impactados, deste banco nós não tiramos relatório.

Eu já criei um índice nesta tabela a um tempo atrás, mas como ela está grando o banco vem reclamando um “pouco” deste indice.

[Autor]

Posts