Fala Pessoal,
Estamos nos aproximando do GUOB desse ano, como a maioria já sabe esse é o único evento TÉCNICO de Oracle do Pais.
É o melhor local para renovar idéias, ficar por dentro das novidades, rever conhecidos e amigos.
Eu estarei lá pelo 3º ano seguido.
Evento mais que recomendado, para quem não esta em São Paulo e ta pensando se vale a pena ir, não pense , faça a inscrição e compre a sua passagem, e para quem esta em São Paulo não tem a menor desculpa para não ir.
Abraços !
Mundo do Banco de Dados
Soluções, noticías e informações sobre Banco de dados.
quinta-feira, 20 de junho de 2013
quarta-feira, 27 de março de 2013
Oracle In-Memory Database Cache
Nesse artigo vamos apresentar o timesten database e mostrar sua funcionalidade que é o timesten in memory cache database. Nessa primeira parte vamos instalar o timesten criar algumas estruturas realizar o cachê de algumas tabelas. No próximo artigo irei explicar melhor os conceitos apresentados aqui e um benchmarking.
Oracle TimesTen In-Memory Database (TimesTen) é utilizado para o gerenciamento de dados em tempo real na camada da aplicação; Utilizamos ele como armazenamento em cache para armazenar tabelas acessadas com frequência de um servidor de banco de dados Oracle para a camada da aplicação(cachê) mantendo a consistência dos dados armazenados; e um componente de replicação de dados transacionais para garantir a alta disponibilidade entre camadas.
Escrevi esse artigo no portal do GPO, para continuar lendo acesse:
segunda-feira, 10 de setembro de 2012
Mudando a Prioridade do Processo VKTM no Oracle 11G R2
Fala Pessoal,
Tive um problema recente com o processo VKTM em um ambiente linux(RED HAT) virtualizado.
Esse Processo tem a seguinte descrição segundo a documentação:
VKTM is responsible for providing centralized time tracking
• wall-clock time (updated every second)
• reference-time counter (updated every 20 ms)
Ele é utilizado pelo scheduler.
Porém ele tem um consumo altíssimo de CPU .
No meu ambiente ele consumia 13% de CPU
13.2 19414 oracle ora_vktm_opscgold RR
Dando um trace no processo verifiquei que ele chama a função gettimeofday mais de 100 vezes por segundo.
[root@orarac1 ~]# strace -p 6723
Process 6723 attached – interrupt to quit
gettimeofday({1323711237, 10495}, NULL) = 0
gettimeofday({1323711237, 10555}, NULL) = 0
nanosleep({0, 10000000}, {1323711237, 10495}) = 0
gettimeofday({1323711237, 21947}, NULL) = 0
gettimeofday({1323711237, 21999}, NULL) = 0
nanosleep({0, 10000000}, {1323711237, 21947}) = 0
gettimeofday({1323711237, 10495}, NULL) = 0
gettimeofday({1323711237, 10555}, NULL) = 0
nanosleep({0, 10000000}, {1323711237, 10495}) = 0
gettimeofday({1323711237, 21947}, NULL) = 0
gettimeofday({1323711237, 21999}, NULL) = 0
nanosleep({0, 10000000}, {1323711237, 21947}) = 0
Estudando mais afundo verifiquei que esse processo(VKTM) e o (LMS) são os únicos que rodam em RR (Roud Robin) alta prioridade de CPU , comentando tambem pelo kerry osborne
Esse processo estava realmente prejudicando a performance do ambiente e como era um ambiente de teste no meu caso foi melhor diminuir a prioridade dele e colocalo em TS (SCHED_NORMAL) .
Para mudar a prioridade de um processo basta alterar o parâmetro não documentado.
_high_priority_processes
Então alterei meu ambiente da seguinte forma
alter system set “_high_priority_processes”=’LMS*’ scope=spfile;
Após isso o consumo de CPU caiu drasticamente, porém é valido ressaltar que essa mudança provavelmente ira causar problemas no scheduler e algumas outras anomalias.
Mas no meu caso, no meu ambiente foi melhor assim, já passou 2 meses e a melhora foi significativa.
Abraços !!
segunda-feira, 30 de julho de 2012
Integrando o Oracle Database com o NoSQL Database MongoDB
Integrando as soluções para problemas de relatórios em bases transacionais
Bases de dados cada vez maiores, grande número de usuários concorrendo por dados e relatórios cada vez mais complexos gerando particionamento de tabelas, visões materializadas e etc. Tem horas que é preciso escalar o banco de dados e dividir transações de relatórios e nessa hora entram em discussão as perguntas, pode? Como? Quanto?
Escrevi esse artigo a convite da equipe do GPO para continuar lendo, acesse :
http://www.profissionaloracle.com.br/gpo/artigo/banco-de-dados/61-integrando-o-oracle-database-com-o-nosql-database-mongodb
http://www.profissionaloracle.com.br/gpo/artigo/banco-de-dados/61-integrando-o-oracle-database-com-o-nosql-database-mongodb
Abraços !!
Marcadores:
apache,
database,
escalar,
jmeter,
mongodb,
nosql,
nosql database,
nosql e mongodb,
nosql e oracle,
oracle,
oracle and mongodb,
performance,
php
quarta-feira, 23 de maio de 2012
O mito do “apagão de talentos”
Fala Pessoal,
Acabei de ler um post muito interessante sobre o suposto “apagão de talentos”, tenho visto cada vez mais esse suposto apagão se referir a area de banco de dados e eu discordo muito disso, esse post excelente do Fabio Luiz retrata perfeitamente a minha visão sobre o assunto, vale a pena dar uma lida.
http://blog.jumping.com.br/2012/05/o-mito-do-apagao-de-talentos/?goback=%2Egde_148535_member_117679150
Abraços !
Acabei de ler um post muito interessante sobre o suposto “apagão de talentos”, tenho visto cada vez mais esse suposto apagão se referir a area de banco de dados e eu discordo muito disso, esse post excelente do Fabio Luiz retrata perfeitamente a minha visão sobre o assunto, vale a pena dar uma lida.
http://blog.jumping.com.br/2012/05/o-mito-do-apagao-de-talentos/?goback=%2Egde_148535_member_117679150
Abraços !
Marcadores:
apagão de talentos,
profissional oracle,
talentos,
vida profissional
segunda-feira, 21 de maio de 2012
Muitos Índices em uma Tabela
Fala pessoal vou falar de um assunto
que sempre gera alguma discussão nos ambientes em que esse assunto foi
levantado
Ultimamente tenho percebido certo
padrão dizendo que nenhuma tabela pode ter mais de seis índices ou sete índices
em alguns clientes. Então algumas instruções SQL podem executar bem, mas algumas podem
não executar tão bem assim e se precisarmos de mais índices não podemos
adicionar porque já existem 6 índices então algum teria que morrer para criar
mais.
Entendendo que muitas vezes alguns
índices podem ser redundantes, podemos pensar no índice IDX_OMT_NAME_ID_01 em
(COL1, COL2), IDX_OMT_NAME_ID_02 em (COL1, COL2,COL3), e IDX_OMT_NAME_ID_03 em (COL1,
COL2,COL3,COL4).
Nesses casos é comum que alguns DBAs pensem em dropar os primeiros dois índices porque eles são redundantes, ou seja, eles têm as mesmas colunas principais e na mesma ordem, como IDX_OMT_NAME_ID_03.
Mas dropar índices redundantes pode causar problemas com a seleção de uma tabela de condução de um join. (No post sobre métodos de join eu falo sobre tabelas de condução ou driving tables).
Quando temos muitos índices em uma
tabela, não vamos obter um impacto grande em questões de desempenho isso se
estamos falando de sistemas OLTP, porque apenas algumas linhas são processadas uma única transação, e o impacto de vários índices de em
uma atualização geralmente não é tão grande se comparado a ao desempenho de uma
consulta.
Agora um número alto de índices em
uma tabela pode ser extremamente prejudicial para ambientes com grande número
de processos batch de atualização, ou seja com um número alto de insets,
updates e deletes.
Veja um leve comparativo:
Quantidade Linhas
|
Quantidade de Índices
|
Tempo
|
1000
|
0
|
00:00:00.41
|
10000
|
0
|
00:00:02.99
|
10000
|
1
|
00:00:05.88
|
10000
|
3
|
00:00:07.82
|
20000
|
5
|
00:00:59.69
|
Da para imaginar o problema quando
temos uns 8 índices de uma tabela com alguns GB de tamanho, e inserindo mais
alguns GB em um processo batch.
Um workaround para esse problema é
dropar on índices antes da execução da batch e recriar os mesmos após a
execução . Com opções como NOLOGGING e PARALLEL é possível reconstruir
um índice com mais velocidade, porém mesmo com esses recursos o trabalho de
reconstruir um índice pode demorar as vezes mais que o próprio processo batch
se for o caso.
Minha experiência me diz que o melhor
é não criar regras em relação a um número especifico de índices que uma tabela
possa ter, porque literalmente cada caso é um caso.O melhor é sempre analisar a
relação de custo e beneficio de um novo índice e o Oracle nos ajuda bastante
porque podemos usar recursos como o ALTER INDEX MONITORING USAGE para monitorar
e verificar a eficiência e uso dos índices.
sexta-feira, 11 de maio de 2012
Como converter Oracle DB para MongoDB
Fala Pessoal,
Tenho pesquisado e estudado bastante as soluções NoSQL depois que grandes empresas passaram a integrar essa tecnologia como solução de escalabilidade para seus problemas. Discordo totalmente da visão de alguns profissionais os quais acreditam na total substituição dos bancos relacionais pelos NoSQL, isso para mim é sonho de programador que nunca soube escreve uma linha em SQL.
Mas acredito que é uma grande solução que pode ser integrada em quase todos os negócios junto com um banco relacional e outras soluções de cache e motor de busca, gerando assim escalabilidade, exemplos de arquitetura que integram as duas tecnologias como facebook e twitter mostram isso claramente.
Usando como base a idéia do Jean Nascimento que criou um conversor de MySQL para MongoDB.
que esta disponivel no link :
http://imasters.com.br/artigo/17078/mongodb/como-converter-mysql-para-mongodb
Tive a idéia de criar um conversor de Oracle para MongoDb utilizando o PHP.
O MongoDB é uma aplicação de código aberto, de alta performance, sem esquemas, orientado a documentos. Foi escrito na linguagem de programaçãoC++. Além de orientado a documentos, é formado por um conjunto de documentosJSON. Muitas aplicações podem, dessa forma, modelar informações de modo muito mais natural, pois os dados podem ser aninhados em complexas hierarquias e continuar a ser indexáveis e fáceis de buscar. (Font Wikipedia)
Eu já vinha testando o MongoDB ha algum tempo e realmente é rápido e simples, não vejo sentido em benchmarks com um bancos relacionais pois acredito que em focos diferenciados. Acredito que o MongoDB é excelente para tudo o que não precisa ser relacional.
No link do Jean Nascimento acima tem a explicação para quem deseja instalar o MongoDB.
Segue o Link do conversor:
http://code.google.com/p/sql-hudson/downloads/list
Tenho pesquisado e estudado bastante as soluções NoSQL depois que grandes empresas passaram a integrar essa tecnologia como solução de escalabilidade para seus problemas. Discordo totalmente da visão de alguns profissionais os quais acreditam na total substituição dos bancos relacionais pelos NoSQL, isso para mim é sonho de programador que nunca soube escreve uma linha em SQL.
Mas acredito que é uma grande solução que pode ser integrada em quase todos os negócios junto com um banco relacional e outras soluções de cache e motor de busca, gerando assim escalabilidade, exemplos de arquitetura que integram as duas tecnologias como facebook e twitter mostram isso claramente.
Usando como base a idéia do Jean Nascimento que criou um conversor de MySQL para MongoDB.
que esta disponivel no link :
http://imasters.com.br/artigo/17078/mongodb/como-converter-mysql-para-mongodb
Tive a idéia de criar um conversor de Oracle para MongoDb utilizando o PHP.
O MongoDB é uma aplicação de código aberto, de alta performance, sem esquemas, orientado a documentos. Foi escrito na linguagem de programaçãoC++. Além de orientado a documentos, é formado por um conjunto de documentosJSON. Muitas aplicações podem, dessa forma, modelar informações de modo muito mais natural, pois os dados podem ser aninhados em complexas hierarquias e continuar a ser indexáveis e fáceis de buscar. (Font Wikipedia)
Eu já vinha testando o MongoDB ha algum tempo e realmente é rápido e simples, não vejo sentido em benchmarks com um bancos relacionais pois acredito que em focos diferenciados. Acredito que o MongoDB é excelente para tudo o que não precisa ser relacional.
No link do Jean Nascimento acima tem a explicação para quem deseja instalar o MongoDB.
Segue o Link do conversor:
http://code.google.com/p/sql-hudson/downloads/list
Marcadores:
convert_oracle_mongodb,
converter,
converter_oracle_mongodb,
migrate oracle to mongodb,
mongodb,
mysql,
nosql,
oracle,
oracle for mongodb,
php,
sql
Assinar:
Postagens (Atom)