Menu de navegação

[rmanParticipante]

Boa tarde!

Hoje é meu primeiro dia como DBA, e tenhos as seguintes tarefas para desempenhar:
– Migração de tabelas entre tablespace
– Tuning de sql

Para a migração pesquisei e encontrei os seguintes passos:

◦Migrar tabelas com o comando:
ALTER TABLE nome_da_tabela MOVE TABLESPACE nome_do_novo_tablespace;

◦Migrar índices com o comando:
ALTER INDEX nome_do_indice REBUILD TABLESPACE nome_do_novo_tablespace;

◦Migrar LOBs com o comando:
ALTER TABLE nome_da_tabela MOVE LOB(nome_da_coluna_lob)
STORE AS (nome_do_novo_tablespace);

◦ Recriar os índices.
ALTER INDEX IndexName REBUILD COMPUTE STATISTICS;

Preciso migrar 65 tabelas para um novo tablespace…

1 – Posso fazer a migração com o banco em produção ?
2 – Existe alguma precaução que devo tomar antes do procedimento ?

Para o tuning de sql, pra mim, qualquer orientação e bem vindo. Alguém já precisou fazer esse tipo de trabalho ? Existe algum guia que eu possa seguir, ou material para estudar ?

[leandrolbsParticipante]

Quanto a migração ao meu ver está 100%. Em termos de executar em produção, fiz uns testes aqui com tabelas principais e não afetou, depende muito da quantidade de requisições.. ou algo assim…

Quanto a Tuning SQL deixo pro pessoal… mas sei que deve adotar padrões de escrita das consultas, e seguir uma logica de chaves nas condições das consultas… alem de claro evitar FrankSteins…

[burgaParticipante]

Qual a versão do banco que você está usando? Um primeiro passo, mais basicão mas que pode ajudar, se tiver usando o 10g ou versão mais recente, é você verificar os advisors do proprio EM. As vezes ele pode apontar pra algum índice faltando, etc.

Seria uma boa você olhar as diferenças entre o RBO e CBO, uma leitura fácil e boa pra começar é o oracle one-on-one do Tom Kyte (http://www.amazon.com/Expert-One-One-Oracle-Thomas/dp/1590592433).

Aqui no blog do Hudson também tem coisas interessantes em relação às diferenças entre os processamentos de JOINS <a href="https://profissionaloracle.com.br/blogs/hudson/“>HASH, MERGE, NESTED LOOPS

No blog do Regis também tem sobre a utilização de Índices (https://profissionaloracle.com.br/blogs/regisaraujo/).

Também tem bastante material sobre HINTS pela web que você pode procurar.

Se você sair fuçando no material que o pessoal disponibiliza aqui no próprio grupo, você vai encontrar várias informações legais, e a partir daí vai começar a ter uma idéia de como iniciar o tunning de uma consulta.

Abraços,

[rmanParticipante]

Burga,

A versão do banco é Oracle Database 10g Release 10.2.0.4.0 – 64bit Production.

Estou estudando o pacote DBMS_SQLTUNE, posso confiar nas recomendações sugeridas por ele ? Ou nem sempre ele acerta ?

Burga e leandrolbs

Obrigado pela atenção.

[burgaParticipante]

Nunca confie 100%. Apesar de se ruma ferramenta “da hora” 8) é claro que você tem que ter o discernimento de aplicar ou não as recomendações no seu ambiente. E se realmente você acabar optando por aplicar as recomendações, o melhor a fazer é sempre aplicar uma a uma, e entre elas sempre rodar novamente a analise do SQL, pois uma mudança que você fizer pode afetar o restante das recomendações.

Ele te ajuda bastante a indicar um caminho, e em boa parte das recomendações você vai ver que dá pra aplicar. Mas confiar 100% não dá, ainda mais no 10g.

[rmanParticipante]

Tenho uma tabela que deve ter uns 1 bilhão de registros, tabela grande mesmo, o SELECT que eu fiz teste tem filtro em cima de campo DATA, o DBMS_SQLTUNE sugeriu criar um indice. Analisando que a tabela tem todos os dias do ano, e cada dia deve ter mais de mil registros. Usar indice no campo data é uma boa ideia ?

[burgaParticipante]

O select só tem filtro na data? em relação a ter mais de mil registros em cada data não faz muita diferença. O que importa é a porcentagem em relação ao total e não o número de registros. Normalmente, compensa criar índice se a consulta vai retornar até 10% dos registros da tabela.

[rmanParticipante]

[quote=”burga”:3neroyxo]O select só tem filtro na data? em relação a ter mais de mil registros em cada data não faz muita diferença. O que importa é a porcentagem em relação ao total e não o número de registros. Normalmente, compensa criar índice se a consulta vai retornar até 10% dos registros da tabela.[/quote]

Não, o SELECT tem diversos filtros, que envolvem de diversas tabelas.

Sim, concerteza vai retornar menos que 10%.

Acho que exagerei um pouco, o total de registro na tabela é 1943103, e retornará 60 mil

Ah esqueci de mencionar, o filtro de data é um BETWEEN. Sempre será dados de 2 meses.

[Autor]

Posts