Mostrando postagens com marcador Oracle Database. Mostrar todas as postagens
Mostrando postagens com marcador Oracle Database. Mostrar todas as postagens

terça-feira, 6 de dezembro de 2016

Novo curso Performance Tuning com Oracle 12c

Nos últimos 3 meses estive trabalhando na elaboração de um curso sobre Performance Tuning em Oracle incorporando os novos recursos disponíveis na versão 12c. A idéia era criar um curso que ensinasse desde a base necessária para o entendimento da arquitetura Oracle até as técnicas mais avançadas para obter o máximo de performance e escalabilidade do ambiente.

Neste curso eu consolidei tanto informações do material oficial de tuning da Oracle (baseado no manual Oracle Database Performance Tuning Guide) como também informações de meus artigos anteriores e uma extensa pesquisa documental nos blogs, artigos e notas dos principais "gurus" do mundo Oracle, como Tom Kyte, Tanel Poder, Maria Colgan, Adrian Billington e outros.

A idéia é explorar a ótica do performance tuning tanto do ponto de vista de SQL, através do entendimento do otimizador baseado em custo (CBO), das coleções de estatísticas e dos principais operadores de acesso, como também explorar o mundo PL/SQL com seus padrões de codificação, estratégias de processamento em massa e principais otimizações.

Este curso já foi realizado em duas turmas e agora estou abrindo a divulgação para que empresas interessadas possam contratá-lo.

Eu disponibilizei a primeira versão deste curso no Slideshare para quem quiser ter uma idéia do material e assuntos abordados. Notem que a versão atual do curso foi revista e ampliada, contendo temas que não foram abordados nesta primeira edição.

Veja o material da primeira edição abaixo:


Mais informações e dados de contato podem ser encontradas no site zlk.net.br.

quinta-feira, 5 de fevereiro de 2015

SAP on Oracle Development Update - 5 de fevereiro de 2015

Roadmap da SAP em base Oracle, atualizado hoje (5 de fevereiro de 2015). Destaques: 

  • Suporte restrito ao 10g expira em Julho. 
  • Rollout do Oracle 12.1.0.2 em 31 de Março. 
  • Suporte ao Exadata X5 
  • Suporte ao Exalogic virtualizado (antes era só bare metal) 
  • Aliás, suporte ao OVM em qualquer x86-64 exceto o ODA (não entendi porque...) 

E o mais importante: eles FINALMENTE "descobriram" que o processamento de dados deve ser feito no BANCO DE DADOS e não na camada de aplicação. Eles estão gradualmente modificando o ABAP para este "novo" paradigma (slide 42).

Fonte:
https://scn.sap.com/docs/DOC-15887

sexta-feira, 2 de janeiro de 2015

Tudo (ou quase tudo) que você queria saber sobre licenciamento Oracle e não tinha para quem perguntar

A escolha da melhor tecnologia para atender as suas necessidades em meio a um mercado tão veloz e competitivo é um grande desafio. Se tratando de software então, não basta escolher o melhor produto, mas também escolher a melhor forma de comprá-lo a fim de maximizar o investimento.
No meu dia-a-dia eu vejo muita dificuldade de gestores de TI em entender os conceitos de licenciamento dos mais diversos fornecedores. Como não existe um padrão de mercado é importante estar atento aos nuances de cada fornecedor para não cair em irregularidades.
A fim de facilitar a vida de clientes e parceiros, vou consolidar neste artigo algumas informações bem relevantes na hora de tomar a decisão para o melhor investimento.

O guia prático de licenciamento da Oracle

Sabendo que os clientes têm dificuldades em entender as regras de licenciamento, a Oracle elaborou um manual de licenciamento, chamado Software Investment Guide (SIG), que contém as explanações básicas sobre as métricas de licenciamento para os diferentes tipos de produtos e cenários. Regras bastante polêmicas de licenciamento como failover, stand by, backup, quantidade de usuários e etc. estão explicadas de forma detalhada e com vários exemplos de aplicações destas regras em cenários semelhantes ao mundo real.
No link abaixo, além do SIG você também vai encontrar uma planilha de controle de inventário de licenças que já vem preparada com as métricas e produtos da Oracle. Seu uso não é obrigatório, mas ajuda bastante quando não há nenhum outro tipo de controle.

Principais pontos sobre licenciamento Oracle

A Oracle hoje possui uma gama muito vasta de produtos e serviços, que vai muito além da visão tradicional de que a Oracle é uma empresa de banco de dados. Hoje a Oracle possui em seu portfólio produtos que vão desde a camada de aplicação, passando por middleware, banco de dados, virtualização, sistema operacional, servidores e até storage.
Por isso, quando vamos checar a forma de licenciar um produto, precisamos estar atentos que cada linha de produto possui uma forma específica de licenciamento. Como os pontos mais polêmicos são com relação ao licenciamento de banco de dados, é neste tópico que eu vou focar, mas o SIG está aí para falar também sobre os demais produtos.
O primeiro ponto na escolha do software de banco de dados a ser licenciado é a escolha da funcionalidade desejada. Dependendo das necessidades da empresa em termos de negócio uma ou outra tecnologia pode ser mais adequada. O banco de dados Oracle é comercializado de acordo com a disponibilidade destes recursos para atender necessidades especifícias.
A versão mais básica do banco de dados Oracle é a versão Express (também conhecida como XE). O Oracle XE é gratuíto, porém é o que possui menos recursos e têm maiores limitações em termos de hardware. Independente da máquina onde estiver rodando, ele fica limitado a utilizar apenas um núcleo (core) de processador e 1 GB de memória RAM.
O Oracle Standard Edition One (SE1) é a versão comercial entry-level do banco de dados, ele é limitado a rodar num hardware com no máximo 2 (dois) processadores físicos (sockets) e não tem opção de fazer cluster (funcionalidade onde duas ou mais máquinas trabalham em paralelo sobre o mesmo banco de dados).
O Oracle Standard Edition (SE), por sua vez, possui o limite de hardware de até 4 processadores físicos (sockets) e tem a possibilidade de fazer cluster através do Oracle RAC (Real Application Clusters). Note que ao optar por utilizar o RAC, continua valendo o limite de 4 processadores para o cluster inteiro (exemplo: duas máquinas com dois processadores).
Finalmente, o banco Oracle Enterprise Edition (EE) é o produto top de linha desta categoria, contendo inúmeras características que o torna ideal para negócios extremamente críticos e dinâmicos. Somente com o Oracle Enterprise Edition você pode garantir alta disponibilidade e continuidade de negócios com zero perda de dados e downtime zero ou próximo de zero. Logo, ele é adequado para empresas que não podem parar (operam 24x7) e também não podem correr risco de perder os seus dados. Isto é, claro, entre outras características como melhor performance, segurança e escalabilidade.
Em termos de licenciamento, o Oracle Enterprise Edition possui uma métrica diferenciada. O processador do EE é calculado de acordo com o número de núcleos (cores) que a máquina possui, aplicado um fator de conversão que é tabelado. Fica mais fácil de entender na prática:
Vamos pegar como exemplo um servidor padrão de mercado hoje, com dois processadores x86 octa-core (8 cores cada, 16 cores no total). O fator de conversão para x86 é 0,5. Logo, o número de processadores a serem licenciados de banco EE é 16 (total de cores) x 0,5 (fator x86) = 8 processadores. (Note que a mesma máquina em SE1 ou SE necessitaria de 2 (duas) licenças de processador)
Para conhecer todos os fatores de conversão, basta consultar a tabela Oracle Processor Core Factor Table. Hoje, os mais relevantes são: 0,5 para x86 e SPARC e 1,0 para processadores RISC não-Oracle.

Licenciamento por Usuários Nomeados (Named User Plus)

Além do licenciamento por processador, algumas linhas de produtos podem ser licenciadas por usuários nomeados, os chamados Named User Plus. Para a linha de produtos de banco de dados, isto também é possível, desde que se considere as seguintes regras:
  1. Usuários humanos e não-humanos precisam ser contáveis (ex.: 30 sensores + 400 operadores)
  2. Existem quantidades mínimas de usuários que precisam ser respeitadas, que variam por produto. Para os produtos banco de dados SE1 e SE, o mínimo de usuários nomeados é 5 por processador. Para o banco de dados EE, o mínimo é 25 usuários por processador.
  3. Para calcular os mínimos, primeiro calcula-se o número de licenças de processador necessárias para o hardware específico e depois aplicam-se os multiplicadores de cada produto.
  4. Se o número de usuários contados for maior que o mínimo, licencia-se por usuários contados. Se não, licencia-se pelo mínimo calculado.
Considerando a máquina de referência do exemplo acima, 2 processadores físicos com 8 cores cada um, os mínimos respectivos são:
SE e SE1: 2 processadores x 5 usuários = 10 usuários nomeados
EE: 2 processadores x 8 cores x 0,5 (fator x86) x 25 usuários = 200 usuários nomeados

Tópicos Especiais de Licenciamento

Os cenários de licenciamento descritos acima vão cobrir a maioria dos casos que encontramos no dia-a-dia. No entanto, a medida que precisamos fazer usos mais avançados do software a complexidade da solução aumenta e as regras precisam ser extendidas para contemplar esta nova complexidade. Dois tópicos muito quentes são o licenciamento de disaster recovery e o licenciamento de ambientes virtualizados.
Com relação ao disaster recovery (DR), entendemos por isso um ambiente onde exista o banco de dados Oracle instalado pronto para assumir a carga do ambiente de produção caso ocorra um evento que indisponibilize o mesmo. Ou seja, é um conjunto de hardware e software adicional que através de alguma forma de replicação mantém uma cópia do banco de dados para eventos de desastres ou outros tipos de paradas, sejam estas planejadas ou não planejadas. Todo servidor onde houver o software da Oracle instalado precisa ser licenciado logo, sim, é preciso licenciar o site DR.
Uma pergunta muito comum é: posso licenciar o site de produção por processador e o DR por usuário? A resposta é não. Independente do tipo de replicação utilizado, se a finalidade é DR, os servidores precisam obrigatoriamente seguir a mesma métrica. Agora se estivessemos falando de ambientes distintos, como por exemplo, produção e homologação ou QA, aí sim, neste caso pode ser licenciado produção por processador e homologação por usuários. Para esclarecer de uma vez por todas as regras de licenciamento de sites de disaster recovery, backup, etc, incluindo esta e outras regras, o documento oficial é o Licensing Data Recovery Environments.
Sobre o tema de virtualização, gostaria de destacar que é preciso tomar muito cuidado com este tópico, em especial para não ficar irregular. Todo processador que roda o código Oracle precisa ser licenciado. Isso fica bem fácil de entender vendo um servidor bare metal, onde todo o processamento fica disponível para o banco de dados e com isso toda a máquina precisa ser licenciada. Agora, em ambientes virtualizados, nem sempre temos o controle sobre quais processadores vão executar quais tarefas, podendo elas estar distribuidas em múltiplos servidores em momentos distintos - a exemplo da tecnologia de live migration. Nestes casos, farms de VMs, onde o banco pode estar executando hora em uma máquina, hora em outra, é necessário licenciar TODA a farm de VMs. Sim, toda. Mesmo que você esteja usando só 2 processadores de cada vez.
Existem exceções a esta regra? Sim. Quando a tecnologia de virtualização tem a capacidade de fazer o chamado hard partitioning ou "CPU pin", ou seja, fixar a execução da VM em um determinado core ou grupo de cores, como se efetivamente estivéssemos "fatiando" uma máquina. Note que não são todas as tecnologias de virtualização que suportam isso, e mesmo que as que suportam, precisam ser homologadas pela Oracle para que o licenciamento seja válido. Esta regra pode ser vista na íntegra no documento Partitioning (não confundir com a option de banco Partitioning, este partitioning se refere a divisão de uma máquina física em máquinas virtuais menores).
A documentação completa sobre os tópicos especiais (além dos dois previamente citados) pode ser encontrada no site da Oracle, na seção Specialty Topics.

Palavras Finais

Ok, talvez meu título tenha sido (um pouco) enganatório. Mas o objetivo era chamar a atenção para estes tópicos de licenciamento que são bastante polêmicos e muito comuns de encontrarmos no dia-a-dia. Vale lembrar também que regras de licenciamento são muito dinâmicas e podem variar ao longo dos anos, então por este motivo fiz questão de apontar sempre as referências oficiais, assim mesmo que este texto algum dia fique desatualizado, aí estão os links para a consulta do material direto na fonte.

terça-feira, 30 de dezembro de 2014

Princípios Básicos de Segurança da Informação

Eu lembro que na minha infância costumava se falar muito aquele ditado popular "tempo é dinheiro". Talvez porque naquela época as coisas eram bem mais difíceis... os meios de transportes não eram tão evoluídos (viajar de avião, por exemplo, era uma fortuna), os meios de comunicação idem (telefones fixos custavam o preço de um carro novo e celulares eram aparatos de filmes de ficção científica), então se gastava muito tempo para realizar algumas tarefas que hoje são triviais. A tecnologia encurtou as distâncias e tornou viáveis uma infinidade de novas possibilidades. Hoje mandamos uma mensagem de um lado para o outro do mundo em segundos, quando antes levava meses.
Não obstante, hoje, tempo ainda é dinheiro. Mas talvez mais importante que isso, na era digital, informação é dinheiro. Vivemos num mundo de empresas cada vez mais dependentes de tecnologia, e sobretudo, de seus dados. Devido a toda essa evolução tecnológica encurtando as distâncias, a informação consegue fluir muito rápido e, quando se trata de uma informação crítica para o negócio, é preciso fazer de tudo para que ela não encontre um caminho rápido até as mãos da concorrência.
Na prática, no entanto, vejo muitas empresas não tomarem as devidas precauções com a segurança. O problema, na maioria dos casos, é que uma falha de segurança tem geralmente proporções intangíveis, ou seja, não é possível delimitar um impacto financeiro e nem mesmo dar a certeza de que um dia vai acontecer. Quando se trata de segurança, sempre estamos falando no conceito de risco. Fazer um investimento para mitigar um risco (em contrapartida a uma certeza), não costuma ser muito simples de justificar, exceto quando as companhias já vivenciaram um problema antes.
Outro motivo que tende a minimizar os investimentos em segurança é a própria falta de conhecimento dos profissionais sobre as ferramentas disponíveis no mercado e sobre as regulamentações e normas existentes no setor. O restante deste artigo vou me dedicar a estes dois aspectos.

Regulamentação

As normas que regem o domínio da segurança da informação estão consolidadas na série ISO 27000. Em linhas gerais, a série 27000 especifica a uma estrutura para gerenciamento de segurança da informação para qualquer organização, seja esta pública ou privada, de pequeno ou grande porte.
A ISO/IEC 27000 propriamente dita constitui uma visão geral da família 27000, além de definir um glossário dentro do escopo da Tecnologia da Informação e da gestão da segurança da informação, para melhor entendimento das demais normas que constituem o conjunto.
A ISO/IEC 27002:2007 é a norma de Segurança da Informação, que por motivos históricos muitas vezes é referenciada por ISO/IEC 17799:2005, a sua numeração anterior. Ela foi publicada originalmente em 2000, sendo então uma cópia fiel do padrão britânico (BS 7799-1:1999), e passou por uma revisão em 2005 para se adaptar ao mercado internacional.

Objetivos de Segurança

A segurança da informação estabelece alguns princípios básicos que precisam ser “forçados” para garantir a proteção dos dados. Estes princípios, também conhecidos como atributos, objetivos ou propriedades (entre outros), regem o foco das políticas de segurança e as funcionalidades que as ferramentas de tecnologia dispõe para controla-los.
O coração da segurança da informação costuma ser definido pela tríade clássica: confidencialidade, integridade e disponibilidade. A medida que o estudo desta área foi evoluindo, diversos autores e comitês propuseram princípios adicionais. A ISO/IEC 27002:2007 define, além da tríade clássica, os princípios da autenticidade e da irretratabilidade (ou não repúdio). Resumidamente, os 5 princípios regem sobre os seguintes aspectos:
  • Confidencialidade: o acesso a informação deve ser permitido apenas as entidades autorizadas.
  • Integridade: a informação deve ser preservada da forma como o seu proprietário a definiu e/ou modificou, durante todo o seu ciclo de vida, sendo protegida contra modificações não autorizadas ou não detectadas.
  • Disponibilidade: a informação deve estar acessível aos usuários autorizados ao seu acesso sempre que necessário.
  • Autenticidade: garantia de que a informação é genuína e que os sujeitos autorizados que a modificaram, ao longo do seu ciclo de vida, são realmente quem dizem ser (e não um terceiro impersonando um sujeito autorizado).
  • Irretratabilidade (não-repúdio): é a impossibilidade de negar a autoria de uma transação realizada anteriormente sobre um determinado conjunto de dados

Políticas de Segurança

Para cumprir com os objetivos de segurança é necessário ter uma política de segurança bem definida. Conforme a RFC 2196 – Site Security Handbook – uma política de segurança é uma declaração formal das regras as quais as pessoas que possuem acesso a informações e tecnologia de uma organização devem respeitar. O principal propósito de uma política de segurança é informar aos usuários, equipe e gerentes de suas obrigações para proteger os bens da companhia, sejam estes bens informações ou tecnologia.
A política deve especificar os mecanismos pelos quais estes requisitos são cumpridos. Para que a política seja eficiente, todos os procedimentos precisam ser documentados e estarem prontamente disponíveis a todos os atores, cada qual com o seu papel muito bem definido. Além disso, ferramentas precisam ser implementadas para garantir as regras e sansões precisam ser definidas onde as ferramentas não conseguem proteger o bem automaticamente.
Note que, neste processo, grande ênfase é dada ao papel das pessoas. Em contrapartida, as ferramentas têm um papel importante, porém não tem valor se não forem operadas e implementadas corretamente. Nada vale um sistema de segurança em uma empresa onde, por exemplo, para não esquecer a senha o funcionário deixa um post-it com suas senhas coladas no monitor. Sim, isso acontece.
Mas de qualquer forma, as ferramentas de tecnologia desempenham um papel fundamental no controle da informação e na garantia de que as propriedades básicas sejam asseguradas. Sem a tecnologia apropriada, hoje, é impossível manter o controle do volume de informações que transitam entre os mais diversos sistemas que compõem a infraestrutura das empresas.

Tipos de Controles na Tecnologia de Informação

Nos voltando agora para a tecnologia da informação, podemos classificar os mecanismos que temos para atuar sobre a segurança da informação em dois níveis básicos de controle: o controle preventivo, ou seja, os mecanismos que temos para prevenir que uma ação mal intencionada seja efetuada e, o controle reativo, aquele que nos permite agir mediante uma falha de segurança.
Quando entramos a fundo nas regulamentações de mercado no que tange a tecnologia, é comum encontrarmos a divisão do controle da TI em dois domínios: o domínio das aplicações e o domínio geral, que seria correspondente ao domínio da infraestrutura.
O domínio das aplicações é regido pelo acesso dos usuários aos aplicativos corporativos. Geralmente as próprias aplicações possuem algum tipo de controle para que apenas usuários autorizados tenham acesso às informações, porém algumas ferramentas específicas de TI tendem a melhorar este controle fornecendo algumas facilidades, como por exemplo, o Single Sign-On (SSO) ou outras modalidades de gerenciamento de acesso e controle de chaves.
Logo, no domínio das aplicações consideramos um risco o acesso de pessoas não autorizadas pela própria camada de aplicação, seja pela incorporação de uma identidade (ex.: roubo de senha, personificação ou fraude) ou por uma falha no controle de acesso (ex.: um funcionário demitido com credenciais ainda válidas).
No domínio geral, ou infraestrutura, os pontos de risco são mais amplos. Pensando em segurança da informação, o objeto mais crítico é o banco de dados, onde todas as informações das aplicações estão armazenadas. Como pontos chave para falhas de segurança temos desde a comunicação entre os servidores de banco de dados e de aplicação (camada de rede), o acesso direto aos dados (via sistema operacional), o acesso irrestrito de usuários privilegiados e, finalmente, a exposição indevida de dados críticos a desenvolvedores de sistema.
Permitam-me elaborar um pouco sobre cada um deles, e as maneiras de proteger-se contra cada um destes riscos:
1) Comunicação entre aplicação e banco de dados: toda e qualquer comunicação entre computadores está sujeita ao que chamamos de “sniffing” ou “packet capture”, entre outros termos, que nada mais é a interceptação das informações transmitidas de ponto a ponto por um software terceiro. Uma forma de se proteger deste tipo de ataque é através da criptografia, pois assim mascaramos os dados transmitidos de uma ponta a outra e sem a chave o terceiro não consegue decodificar a mensagem.
2) Acesso direto aos dados: semelhante ao item anterior, se os dados são armazenados “planos” (sem criptografia), não importa quantas camadas de segurança e autenticação você coloque, uma pessoa com acesso a uma cópia do banco de dados pode acessar todas as informações contidas nele com um grau moderado a leve de dificuldade. Imagine o cenário onde, por exemplo, que o “motoboy” que vai levar as fitas de backup para o cofre perde uma destas fitas ou é roubado. Ou um sysadmin mal-intencionado faz uma cópia dos datafiles do banco. A criptografia também é a solução para estes problemas.
3) Acesso irrestrito de usuários privilegiados: administradores de banco de dados (DBAs) geralmente são profissionais com o mais alto nível de acesso em uma infraestrutura de banco de dados. Isto se deve a própria característica do trabalho, pois, eles devem ter o poder tanto de criar como, literalmente, destruir o banco. Mas deveriam eles ter acesso às informações contidas no banco? Não necessariamente. Por exemplo, um DBA não deveria ter acesso a uma tabela de salários em um sistema de RH. Na prática, muitos têm. A forma de controlar isso depende muito de banco para banco.
4) Exposição de dados críticos a desenvolvedores de sistemas: também de nada adianta tomar todas as precauções com a segurança - criptografia, controle de acesso e limitação de usuários privilegiados - se deixamos os dados de produção completamente expostos no ambiente de desenvolvimento. É muito comum criarmos massas de dado para desenvolvimento e testes a partir dos dados de produção, mas nestes ambientes secundários os mecanismos de segurança são mais relaxados ou inexistentes. Em decorrência disso, qualquer desenvolvedor com acesso direto ao banco pode ter acesso a dados que jamais deveria ter conhecimento. Aí mais uma vez para ilustrar uso o exemplo do sistema de RH, onde o salário de todos os funcionários está exposto. Mas não só isso, poderiam ser informações estratégicas de negócio da própria empresa ou de uma empresa cliente. Um risco este que pode ser mitigado através da estratégia de mascaramento de dados, descaracterizando os dados sensíveis de maneira irreversível, mas mantendo suas características relacionais para que testes permaneçam válidos.

A tecnologia Oracle voltada para a segurança

Como especialista em Oracle eu não poderia deixar de indicar as tecnologias que a Oracle tem para endereçar cada uma destas necessidades.
Para trabalhar com controle no domínio das aplicações, a Oracle dispõe da suíte deIdentity Management (IDM). Esta é uma suíte completa que inclui produtos para controle de acesso, gestão de identidade, single sign-on, governança, serviços de diretório, mobile e etc.
Já para trabalhar no domínio geral, a Oracle conta com algumas opções de banco para atuar tanto no controle preventivo como reativo. De modo geral estes produtos são comercializados como options do banco Oracle Database Enterprise Edition (DBEE) ou como packs para o Enterprise Manager. Alguns destes produtos, no entanto, podem ser utilizados em conjunto com outros bancos de dados que não são Oracle.
Para trabalhar com criptografia de banco de dados (data files e backup), a ferramenta é chamada de Transparent Data Encryption (TDE), sendo comercializada como option do Oracle Database Enterprise Edition com o nome de Advanced Security. Para criptografia de rede, entre banco de dados e aplicação, até junho de 2013 este recurso também fazia parte da option Advanced Security, porém desde então agora ela faz parte da funcionalidade padrão do banco de dados Oracle Database Enterprise Edition.
O controle de usuários privilegiados, considerando o banco de dados Oracle Enterprise Edition, pode ser feito através da option Database Vault. O objetivo desta option é assegurar que os usuários privilegiados (DBAs e SYSDBAs) continuem com os seus “super poderes” administrativos, porém não tenham acesso a dados sensíveis.
Finalmente, para trabalhar com o mascaramento dos dados de produção na hora de replicar o ambiente para desenvolvimento, a ferramenta da Oracle é um pack do Enterprise Manager 12c chamado de Data Masking and Subsetting. Este pack é capaz não só de descaracterizar os dados como também exportar apenas um subconjunto dos dados de produção mantendo sua integridade referencial, mas reduzindo os requisitos de espaço na base de dados de desenvolvimento. Um fato interessante é que esta ferramenta é multi-banco, ou seja, não funciona apenas em bancos de dados Oracle.
Todas as ferramentas acima trabalham no conceito de controle preventivo. Para fechar o raciocínio dos tipos de controle e suas soluções faltou comentar sobre o controle reativo. A ferramenta que dispomos para tratar este tipo de controle é chamada de Audit Vault, um repositório de informações de auditoria isolado dos ambientes que monitora e totalmente desenvolvido com as melhores práticas de segurança para que não haja alteração dos dados auditados. O princípio é que, no advento de uma falha de segurança, hajam informações disponíveis para rastrear a origem da falha e punir com as devidas sanções os responsáveis. O Audit Vault, assim como o Data Masking, é uma ferramenta que pode ser usada também em bancos não-Oracle, incluindo SQL Server, DB2 e outros.

Palavras Finais

Espero com este artigo ter conseguido mostrar um pouco do mundo da segurança da informação e as possíveis vulnerabilidades as quais as empresas estão sujeitas no dia a dia. Como minha especialidade é Oracle, tomei a liberdade também de mostrar algumas das ferramentas dentro do nosso portfólio podem ser utilizadas para atacar os pontos de risco citados no artigo. De maneira alguma o meu objetivo foi ser exaustivo na descrição destas ferramentas, mas sim dar uma visão geral do que está disponível no mercado.
Caso haja mais interesse em conhecer o portfólio de segurança da Oracle, fiquem a vontade para entrar em contato. Estarei a disposição para esclarecer quaisquer dúvidas que por ventura possam aparecer.
E para finalizar, vale lembrar aquilo que eu comentei anteriormente sobre política de segurança e ferramentas. De nada adianta investir em ferramentas top de linha se não houver uma mudança de cultura corporativa, afinal segurança é um conceito extremamente dependente das pessoas. Para que uma política de segurança funcione corretamente, não basta ter as ferramentas corretas, mas também é preciso treinar as pessoas e deixar muito claro através de políticas, papéis e sanções o que cabe a cada um fazer.

sexta-feira, 30 de maio de 2014

Erro silencioso na instalação do client 11.2.0.4 x64 para Windows 7

Eu estou montando um ambiente de testes com algumas máquinas virtuais rodando Oracle 11.2.0.4 e me deparei com um erro estranho ao instalar o Oracle client x86-64 no Windows 7: o instalador simplesmente fecha após o termino da checagem de pré-requisitos sem mensagem alguma.

Após investigar um pouco na internet acabei descobrindo que mais pessoas tiveram problemas similares e parece estar relacionado com o ambiente JRE que vem embutido no instalador. A solução para mim foi utilizar um parâmetro do executável do setup para escolher outro ambiente JRE:

C:\oracle\winx64_11g_client>setup -jreLoc c:\sqldeveloper\jdk

No caso, utilizei a JDK que vem embutida na última versão do SQL Developer (4.0.2) e aí a instalação funcionou normalmente. Cabe aqui pontuar que testei outras duas JREs que eu tenho instaladas na mesma máquina (1.6.0-71 e 1.7.0-51) e nenhuma das duas funcionou. Como eu não sou especialista em java não sei o que exatamente fez a diferença, mas fica aí o alerta e o workaround.

quinta-feira, 27 de junho de 2013

Utilizando a compressão de índices no Oracle

Eu preparei recentemente este test case para mostrar o funcionamento da compressão de índices para um de nosso clientes e achei interessante compartilhá-lo, pois eu sei que esta é uma feature que é muito pouco utilizada por aqui e isso se deve de maneira geral pela falta de conhecimento de sua existência ou do seu funcionamento.

Também devemos levar em conta que é muito comum encontrarmos na prática bancos onde a área alocada para índices é igual ou até mesmo maior que a área de dados. Empregando a compressão de índices conseguimos em média uma economia de 20% de área de storage. Se colocar isso dentro de um contexto onde hoje busca-se reduzir custos ao máximo, aumentar a longevidade do hardware, reduzir o TCO, obter uma melhor performance... não existe motivo para não utilizar uma tecnologia que está ali a disposição que pode auxiliar em todos estes quesitos.

Além de mostrar como a compressão funciona, a idéia é criar uma metodologia para automatizar a seleção dos candidatos, pois o próprio Oracle consegue nos dar todas as informações que precisamos com relação ao melhor nível de compressão que podemos obter.

Primeiro vamos comentar algumas caracteristicas básicas:
  • A compressão de indices é uma feature padrão do Oracle, não necessita de licenciamento especial, estando inclusive habilitada no Oracle standard.
  • Esta compressão se baseia na compressão de repetições dentro da estrutura da arvore binária, portanto é altamente dependente da ordem das colunas
  • Em função da característica acima, indices que começam com uma coluna única não conseguem ser comprimidos
Para estimar a compressão de um indice existe uma metodologia bem prática. Vamos por partes.

O comando ANALYZE INDEX ... VALIDATE STRUCTURE popula uma view chamada INDEX_STATS. Esta view sempre irá conter um indice por vez, ou seja, cada vez que você executar o VALIDATE STRUCTURE seu conteúdo é apagado e populado com os dados do indice solicitado.

Estamos interessados em duas colunas desta view: OPT_CMPR_COUNT e OPT_CMPR_PCTSAVE. OPT_CMPR_COUNT é o número ideal de colunas que deve ser especificado no momento da compressão. OPT_CMPR_PCTSAVE é o ganho esperado com a compressão utilizando o número recomendado de colunas.

Uma vez determinado o número de colunas, para executar a compressão é bem simples:

ALTER INDEX ... REBUILD COMPRESS n

Onde ‘n’ é o número de colunas indicado por OPT_CMPR_COUNT.

Considerando isso que foi dito acima, eu criei uma package que possui duas procedures: uma para analisar todos os indices do usuário atual e a outra para executar a compressão de acordo com o indice recomendado. O test case completo está em anexo (pronto para rodar com um @ do sqlplus), vou comentando abaixo:

Primeiro vou criar uma tabela com 1.000.000 linhas para servir de massa de dados:

create table t(pedido primary key, produto, cliente, dt_pedido) as
select rownum            pedido,
       mod(rownum, 1000) produto,
       mod(rownum, 100)  cliente,
       sysdate + mod(rownum, 100) dt_pedido
  from dual connect by level <= 1000000;

Note que com essa sintaxe eu garanto que todo pedido é unico (numero sequencial) e que tenho 1000 produtos distintos e 100 clientes.

Em seguida vou criar uma série de indices, tentando imitar as características de uma aplicação convencional:

create index t_idx1 on t(pedido, produto, cliente);
create index t_idx2 on t(produto, cliente);
create index t_idx3 on t(produto, cliente, dt_pedido);
create index t_idx4 on t(cliente, produto, pedido);
create index t_idx5 on t(cliente);

Com o modelo pronto, vou criar agora as ferramentas para trabalhar com a compressão. Como a view INDEX_STATS é volátil, eu vou criar uma cópia dela chamada IDX_STATS:

create table idx_stats as
select * from index_stats;

Depois criamos a package responsável pela estimativa e compressão:

create or replace package pkg_idx_compress as

  procedure idx_compress_analyze;
  procedure idx_compress_execute(pctsave number default 10);

end pkg_idx_compress;
/

create or replace package body pkg_idx_compress as

procedure idx_compress_analyze as
begin
  for r in (select user as owner,
                   index_name
              from user_indexes)
  loop
    execute immediate 'analyze index ' || r.owner || '.' || r.index_name || ' validate structure';
    insert into idx_stats select * from index_stats;
  end loop;
  commit;
 
end idx_compress_analyze;

procedure idx_compress_execute(pctsave number default 10) as
begin
  for r in (select user as owner, name, opt_cmpr_count from idx_stats where opt_cmpr_pctsave >= pctsave)
  loop
    execute immediate 'alter index ' || r.owner || '.' || r.name || ' rebuild compress ' || r.opt_cmpr_count;
  end loop;
 
end idx_compress_execute;

end pkg_idx_compress;
/

Note que a procedure idx_compress_analyze simplesmente chama a ANALYZE INDEX VALIDATE STRUCTURE uma vez para cada indice do usuário e guarda uma cópia da informação na tabela IDX_STATS. A procedure idx_compress_execute irá varrer a tabela IDX_STATS em busca de indices que tenham uma estimativa de melhoria maior ou igual a 10%, ou o valor especificado.

Tendo todas as ferramentas na mão podemos analisar o cenário antes e depois da compressão:

SQL> select table_name, index_name, bytes / 1024 as kbytes
  2    from user_indexes  ui,
  3         user_segments us
  4   where ui.index_name = us.segment_name;

TABLE_NAME                     INDEX_NAME          KBYTES
------------------------------ --------------- ----------
T                              T_IDX4               26624
T                              SYS_C0012678         17408
T                              T_IDX1               26624
T                              T_IDX2               20480
T                              T_IDX3               29696
T                              T_IDX5               16384

6 linhas selecionadas.

Executando a estimativa:

SQL> exec pkg_idx_compress.idx_compress_analyze;

Procedimento PL/SQL concluído com sucesso.

SQL> select user as owner,
  2         name as index_name,
  3         opt_cmpr_count,
  4         opt_cmpr_pctsave
  5    from idx_stats;

OWNER      INDEX_NAME      OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- --------------- -------------- ----------------
DANI       SYS_C0012678                 0                0
DANI       T_IDX1                       0                0
DANI       T_IDX2                       2               38
DANI       T_IDX3                       3               57
DANI       T_IDX4                       2               29
DANI       T_IDX5                       1               21

6 linhas selecionadas.

Note que tanto o indice SYS_C0012678 (que é a nossa PK) como o indice T_IDX1 que possui a coluna pedido como primeira coluna tem estimativa zero. Isso se deve ao fato da questão da repetição que eu falei. Os demais apresentam bons indices de compressão esperados em função da grande quantidade de repetição.

Agora, vendo o resultado na prática:

SQL> exec pkg_idx_compress.idx_compress_execute;

Procedimento PL/SQL concluído com sucesso.

SQL> select table_name, index_name, bytes / 1024 as kbytes
  2    from user_indexes  ui,
  3         user_segments us
  4   where ui.index_name = us.segment_name;

TABLE_NAME                     INDEX_NAME          KBYTES
------------------------------ --------------- ----------
T                              T_IDX4               18432
T                              SYS_C0012678         17408
T                              T_IDX1               26624
T                              T_IDX2               13312
T                              T_IDX3               13312
T                              T_IDX5               13312

6 linhas selecionadas.

No fim das contas houve uma pequena diferença com relação ao estimado, mas dá para ver que a compressão indicada foi bem eficiente.

Claro que trata-se de um caso artificial, mas na minha vida de DBA eu já utilizei estratégias similares com bons resultados. Inclusive esse procedimento pode ser feito online.

Para finalizar, segue o trecho do manual que trata de compressão de indices (extraido de http://docs.oracle.com/cd/E11882_01/server.112/e17118/statements_1010.htm):

key_compression

Specify COMPRESS to enable key compression, which eliminates repeated occurrence of key column values. Use integer to specify the prefix length (number of prefix columns to compress).

  • For unique indexes, the range of valid prefix length values is from 1 to the number of key columns minus 1. The default prefix length is the number of key columns minus 1.
  • For nonunique indexes, the range of valid prefix length values is from 1 to the number of key columns. The default prefix length is number of key columns.
Oracle Database compresses indexes that are nonunique or unique indexes of at least two columns. If you want to use compression for a partitioned index, then the index must have compression enabled at the index level.
Specify NOCOMPRESS to disable key compression. This is the default.

Restriction on Key Compression You cannot specify COMPRESS for a bitmap index.