MigraTI - Soluções em banco de dados

terça-feira, 21 de novembro de 2023

Melhorando o gerenciamento e o desempenho com tabelas particionadas

O particionamento de tabelas é uma técnica que permite dividir uma tabela em várias partições menores. Essa divisão pode ser feita com base em uma ou mais colunas da tabela. As partições podem ser armazenadas em diferentes tablespaces, o que pode melhorar o desempenho e a disponibilidade do banco de dados.

Tipos de particionamento

O Oracle Database oferece quatro tipos de particionamento de tabelas:

  • Range partitioning: as partições são criadas com base em um intervalo de valores. Por exemplo, uma tabela de vendas pode ser particionada por data de venda, com uma partição para cada mês.



  • List partitioning: as partições são criadas com base em uma lista de valores. Por exemplo, uma tabela de clientes pode ser particionada por estado, com uma partição para cada estado.


  • Hash partitioning: as partições são criadas usando um algoritmo de hash. Por exemplo, uma tabela de produtos pode ser particionada por código de produto, com uma partição para cada código de produto.


  • Composite partitioning: as partições são criadas usando uma combinação de dois ou mais tipos de particionamento. Por exemplo, uma tabela de funcionários pode ser particionada por data de admissão e departamento, com uma partição para cada combinação de data de admissão e departamento.






Funcionalidade

O particionamento de tabelas oferece uma série de funcionalidades que podem melhorar o gerenciamento e o desempenho do banco de dados.

Gerenciamento: o particionamento pode facilitar o gerenciamento de tabelas grandes. As partições podem ser criadas, gerenciadas e excluídas de forma independente. Isso pode facilitar as tarefas de manutenção, como a atualização de índices e a reorganização de dados.

Desempenho: o particionamento pode melhorar o desempenho de consultas e operações DML. As consultas que se concentram em um pequeno conjunto de dados podem ser executadas apenas nas partições que contêm os dados relevantes. Isso pode reduzir o tempo de execução das consultas.

Exemplo de funcionalidade

Vamos considerar uma tabela de vendas que contém dados de vendas por mês. Se a tabela não for particionada, todas as consultas que se concentram em dados de vendas de um determinado mês precisarão acessar todos os dados da tabela. Isso pode resultar em um desempenho lento para consultas que se concentram em um pequeno conjunto de dados.

Se a tabela for particionada por mês, as consultas que se concentram em dados de vendas de um determinado mês podem ser executadas apenas na partição que contém os dados relevantes. Isso pode reduzir significativamente o tempo de execução das consultas.

Exemplo de melhoria no desempenho

Vamos realizar um teste para comparar o desempenho de uma consulta que se concentra em dados de vendas de um determinado mês em uma tabela particionada por mês e em uma tabela não particionada.

Para o teste, usaremos uma tabela de vendas com 100 milhões de linhas. A tabela está particionada por mês, com uma partição para cada mês.

CREATE TABLE vendas ( id NUMBER(10) NOT NULL, data_venda DATE NOT NULL, valor NUMBER(10,2) NOT NULL, produto VARCHAR2(100) NOT NULL ) PARTITION BY RANGE (data_venda) ( PARTITION vendas_janeiro VALUES LESS THAN (TO_DATE('2023-02-01', 'YYYY-MM-DD')), PARTITION vendas_fevereiro VALUES LESS THAN (TO_DATE('2023-03-01', 'YYYY-MM-DD')), PARTITION vendas_marco VALUES LESS THAN (TO_DATE('2023-04-01', 'YYYY-MM-DD')), PARTITION vendas_abril VALUES LESS THAN (TO_DATE('2023-05-01', 'YYYY-MM-DD')), PARTITION vendas_maio VALUES LESS THAN (TO_DATE('2023-06-01', 'YYYY-MM-DD')), PARTITION vendas_junho VALUES LESS THAN (TO_DATE('2023-07-01', 'YYYY-MM-DD')), PARTITION vendas_julho VALUES LESS THAN (TO_DATE('2023-08-01', 'YYYY-MM-DD')), PARTITION vendas_agosto VALUES LESS THAN (TO_DATE('2023-09-01', 'YYYY-MM-DD')), PARTITION vendas_setembro VALUES LESS THAN (TO_DATE('2023-10-01', 'YYYY-MM-DD')), PARTITION vendas_outubro VALUES LESS THAN (TO_DATE('2023-11-01', 'YYYY-MM-DD')), PARTITION vendas_novembro VALUES LESS THAN (TO_DATE('2023-12-01', 'YYYY-MM-DD')), PARTITION vendas_dezembro VALUES LESS THAN (MAXVALUE) );

INSERT INTO vendas (id, data_venda, valor, produto) VALUES (1, TO_DATE('2023-01-01', 'YYYY-MM-DD'), 100.00, 'Notebook'); INSERT INTO vendas (id, data_venda, valor, produto) VALUES (2, TO_DATE('2023-01-02', 'YYYY-MM-DD'), 200.00, 'Celular'); INSERT INTO vendas (id, data_venda, valor, produto) VALUES (3, TO_DATE('2023-02-01', 'YYYY-MM-DD'), 300.00, 'TV');


select * from vendas 
where data_venda between to_date('2023-01-01', 'YYYY-MM-DD') 
and to_date('2023-01-31', 'YYYY-MM-DD');

A consulta retornará todas as linhas da tabela vendas que foram vendidas em janeiro de 2023.

Executaremos a consulta duas vezes: uma vez na tabela particionada e outra vez na tabela não particionada.

Os resultados do teste são os seguintes:

Tabela

Tempo de execução (s)

Particionada

0,002

Não particionada

0,022

Como podemos ver, a consulta na tabela particionada é executada 10 vezes mais rápido do que a consulta na tabela não particionada.

Claro que o exemplo é pequeno mas já da para mostrar o quão é importante essa feature.

Manutenção Simplificadas:

Exclusões com Precisão Cirúrgica

Imagine que precisamos excluir transações mais antigas de janeiro por exemplo. Com tabelas particionadas, essa tarefa é simplificada e eficiente.

alter table vendas drop partition vendas_janeiro;

 Backup/Recover Eficiente:

Imagine fazer backup apenas de um pedaço de sua tabela:

expdp directory=MIGRA dumpfile=vendas_janeiro.dmp tables=vendas:vendas_janeiro logfile=exp_vendas_janeiro.log

Ou recuperar o pedaço da tabela:

impdp directory=MIGRA dumpfile=vendas_janeiro.dmp table_exists_action = append logfile=imp_vendas_janeiro.log

Conclusão

O particionamento de tabelas é uma técnica poderosa que pode melhorar o gerenciamento e o desempenho do banco de dados. Ao particionar tabelas, os administradores de banco de dados podem facilitar o gerenciamento de dados grandes e melhorar o desempenho de consultas e operações DML.


sexta-feira, 18 de agosto de 2023

GUOB Tech Day 2023 - Visão geral

 

Como foi o GUOB Tech Day 2023


No último sábado, 12/08/2023, participei do meu primeiro evento sobre banco de dados, a 12ª edição do GUOB Tech Day em São Paulo. O evento reuniu profissionais Oracle em um encontro enriquecedor, com palestrantes nacionais e internacionais compartilhando conhecimentos teóricos e práticos.

No meu blog, gostaria de compartilhar a rica experiência que tive no recente workshop. Foi um evento repleto de conhecimento valioso que expandiu minha compreensão em diversas áreas. Desde o início, a abertura das palestras com Sandesh Rao discutindo o Oracle Database 23c estabeleceu um tom promissor.

Guob Tech Day 2023 - Zero Downtown Migration

 

No último sábado dia 12/08/2023 estive participando do grande evento GUOB Tech Day 2023 em São Paulo na FIAP, evento qual proporciona um grande encontro de usuários de tecnologia Oracle do Brasil, com palestrantes Nacionais e Internacionais. Com a intenção de disseminar conhecimento, especialistas de destaque na área compartilharam suas vivências, abordando tanto aspectos teóricos quanto práticos.

Dentre todas as excepcionais palestras, uma que me chamou a atenção, talvez por ser a novidade do momento, foi a de “Como elegir el mejor método para migrar base de dados Ompre a la Nube” apresentada pela Rita Nuñez que apresentou toda sua vasta experiência na área.

Dada a atualidade do cenário, em que a adoção de bancos de dados em nuvem está em constante ascensão, considero essencial que todo Administrador de Banco de Dados (DBA) esteja familiarizado com as abordagens mais eficazes para conduzir tais migrações.

Dentre várias opções, o que mais me chamou atenção foi a ferramenta gratuita da Oracle “Zero Downtown Migration (ZDM)”. Zero Downtime Migration oferece um processo robusto, flexível e retomável de migração. Ele integra a Arquitetura de Máxima Disponibilidade Oracle (MAA) e suporta o Oracle Database 11g Release 2 (11.2.0.4) e versões posteriores do banco de dados.

Features do Oracle Flashback

 

No dia 12/08/2023, participei do meu primeiro evento sobre banco de dados. Ocorreu na cidade de São Paulo a 12ª edição do evento GUOB Tech Day, no qual proporciona um grande encontro de profissionais Oracle.

Irei abordar nesse blog a palestra que mais me chamou atenção, sobre as features do Oracle Flashback. A palestra foi passada pelo profissional Tércio Costa e demonstra um método alternativo para recuperação de dados.

As features do Oracle Flashback nos permitem visualizar como os dados eram antes de um determinado tempo, antes de serem modificados, podendo nos salvar em possíveis corrupções ou perca de dados.

Todos os valores que as features do Oracle Falshback buscam, são consultados da tablespace Undo e do Redo Log. Ambos armazenam os arquivos modificados de seu banco de dados.

Tendo isso em mente, devemos nos atentar em efetuar a manutenção corretamente da tablespace Undo, pois quanto maior ela for, mais registros que podem ser recuperados estaram disponíveis.

terça-feira, 15 de agosto de 2023

GUOB Tech Day 2023 - Melhorando o Desempenho no Oracle Database

Dicas e Insights da Palestra


Na palestra sobre Oracle Database e otimização de desempenho que participei, adquiri insights valiosos sobre como abordar problemas de lentidão do sistema e melhorar a eficiência do banco de dados. Neste blog, compartilharei as principais abordagens e dicas discutidas na palestra para ajudar você a enfrentar desafios semelhantes.

Um dos pontos-chave abordados foi a importância de identificar a origem do problema de desempenho. Muitas vezes, os usuários relatam que o sistema está lento e culpam o banco de dados. No entanto, é essencial investigar mais a fundo. Perguntas como "Quando começou a lentidão?" e "Que parte específica está afetada?" podem fornecer pistas importantes para resolver o problema.


quarta-feira, 12 de maio de 2021

ORA-00604: error occurred at recursive SQL level 1 | ORA-00942: table or view does not exist

 Cliente estava com problemas em sua atualização, a atualização travava em uma tabela padrão do sistema onde ele adicionava duas colunas e depois apagava outras.

Ao tentar dropar uma coluna o erro abaixo aparecia, conforme:


SQL> ALTER TABLE R152PEN DROP(DTHTRA, CODERR);
ALTER TABLE R152PEN DROP(DTHTRA, CODERR)
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist

A tabela estava certa, com as colunas, meu primeiro teste foi verificar o case sensitive, mas também não resolveu.

quinta-feira, 9 de julho de 2020

0x851A001A - Wait on the Database Engine recovery handle failed

Servidor: Windows server 2012 R2 Foundation
Controlador de dominio - SQL-Server Express Edition (2014, 2017)

Ao instalar o SQL-Server o mesmo apresenta o erro abaixo:


Wait on the Database Engine recovery handle failed. Check the SQL Server error log for potential causes.

No Erro ele vai te dar uma pasta de logs para entrar, abra essa pasta e veja o arquivo summary.txt.

Nele você encontrará a linha:
SQLSVCACCOUNT: NT Service\MSSQLSERVER

Para resolver, desisntale o SQL-Server e recomece a instalação, siga todos os passos normalmente até chegar em "server configuration"


Troque o usuário para "NT AUTHORITY\NETWORK SERVICE" e siga com os proximos passos da instalação normalmente.

Só trocar o usuário nos services não irá funcionar.

Grato.


Burlando o restart inicial da instalação do SQL-Server (qualquer edição)

    É muito comum termos de instalar um sql-server em um ambiente que já esta em produção e ja logo de cara ele pede um restart, ai precisamos solicitar ao cliente um horário para restartar.

    Muitas vezes o cliente libera sem problemas, mas algumas vezes só depois das 18, atrapalhando o projeto.

Nesse caso o que fazer? Tem como burlarmos este restart? - Tem sim.

Tela que solicita o restart.


Pos então vamos a Mágica.

Abra o regedit, e navegue pelos seguintes diretórios:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager 
Abra esta pastinha e procure o item "PendingFileRenameOperations" ele é um item REG_Multi_SZ.

Ao encontra-lo, apague-o.

Feche o REGEDIT e clique em Re-Run no seu instalador do SQL-Server.

Qualquer duvida deixe seu comentário. 


quarta-feira, 27 de dezembro de 2017

Valor Inválido especificado para o parâmetro EXPIREDATE. (SQL-SERVER)

   Estávamos recebendo alguns erros no backup de um cliente e ao efetuar um backup manual recebemos o seguinte erro:


Pois bem, nosso primeiro passo é verificar a data do servidor e a data do SQL-Server.

Para coletar a data do SQL-Server:

SELECT GETDATE();

Visto que neste caso o cliente estava com 10 a 15 minutos atrasados do horário padrão.

Alteramos o tempo de expiração do backup, conforme:


   Para corrigir o problema, podemos usar duas soluções. Corrigir o horário do servidor, que resolveria o problema na raiz, ou aumentar o valor de tempo de expiração.

Como neste caso não era possível alterar a data do servidor, apenas aumentamos o EXPIREDATE para "1"


terça-feira, 29 de agosto de 2017

Guob Tech Day 2017



No sábado, dia 5 de agosto de 2017, ocorreu em São Paulo, capital, o 8º. GOUB Tech Day, também conhecido como OTN TOUR Latin America.
Evento realizado pela comunidade Oracle em toda a América Latina, onde Brasil, Argentina, México entre outros países, participam.
Com o objetivo de compartilhar conhecimento, os maiores e mais renomados profissionais da área, apresentaram suas experiências, trazendo conteúdo teórico e prático.
Entre os nomes que se apresentaram no dia estão Alex Zaballa, Mike Dietrich e Craig Shallahamer.
Zaballa com suas inúmeras certificações, apresentou aos participantes um dos assuntos mais importantes do momento: Cloud.
Mostrando algumas das principais formas de migração de bancos On-Premisses para a Oracle Cloud.
Mike com sua experiencia como gerente de produtos de upgrade e migração da Oracle, nos trouxe um excelente conteúdo sobre atualização de versão para Oracle 12.2 e uma das novidades mais inusitadas, não teremos mais versões com builds, ou seja, não teremos mais versões 12.3, 12.3.0.1, mas sim, teremos versões enumeradas como Oracle 18, Oracle 19.

O principal motivo da Oracle ter realizado esta alteração foi por crer que as corporações tendem a não atualizar seus databases para as versões de builds iniciais como 11.1, e deixando apenas para versões 11.2, por exemplo.
No novo conceito, não haverá versão inicial e versão final, e sim versões estáveis e prontas para uso.

Craig, diretor e fundador do OraPub, nos trouxe um exemplo pratico e complexo do uso do ASH, Active Session History, para identificar problemas de concorrência.

O que muitos chamaram de "O maior GUOB de todos os tempos", também trouxeram nomes novos como Franky Faust Weber (nosso amigo que veio de Blumenau e tem um grande futuro no mundo Oracle), Fernando Simon entre outros profissionais com assuntos diversos, que vão de rootkits à Grid Infrastructure.

Como conclusão, fica o sentimento de um excelente evento, com excelentes conteúdos que agregaram e muito para o conhecimento das tecnologias e novidades do mundo Oracle.
Também fica o sentimento de grandes profissionais unidos tentando disseminar conhecimento, sem a percepção de concorrência, mas sim de um conjunto agregando para um todo.

Que venham os próximos, com certeza estaremos lá.

Post Criado por Jone Jarouj