(por Joel Menezes)
Auditar a nossa documentação de backup baseadas nas políticas de backup adotadas por nossos clientes, me fez refletir sobre esse assunto tão negligenciado por gestores de TI e não menos valorizado por técnicos responsáveis pela salvaguarda desses ativos tão importantes e cruciais para continuidade dos negócios das empresas que são as suas bases de dados.
A noção de Contingencia nos dias de hoje vem tomando um rumo diferente da sua origem que aconteceu basicamente nos tempos dos ambientes de Mainframes que tinham elevadas despesas de manutenção, esse plano descrevia as seqüências de restauração ou substituição dos componentes envolvidos em falhas, com o foco na redução do seu tempo de parada.
O Plano de Contingencia por ser um conjunto de atividades alternativas devem ser previamente planejados com foco na manutenção das atividades de negocio das empresas sem que sofram risco de serem interrompidas, independentemente da falha que venha ocorrer.
O plano de contingência deve ser levado a sério pelos altos executivos da empresa, pois segundo Sêmola (2003, p.99) “… de cada cinco empresas que possuem interrupção nas suas operações por uma semana, duas fecham as portas em menos de três anos”. Pode-se observar que o Plano de continuidade é uma premissa básica para o desenvolvimento sólido de uma organização. Vale lembrar que mesmo fazendo parte dos planos de recuperação de desastres e continuidade, a contingência não garante continuidade, garante apenas que serão encontrados meios de planejar de acordo com as necessidades e limitações existentes.
O setor de Tecnologia da Informação tem grande importância para o desenvolvimento do país, onde este depende diretamente do avanço tecnológico para seu crescimento. Hoje, qualquer empresa depende diretamente dos computadores para guardar seus dados e informações que possuem valores incalculáveis. A perda de informações digitais pode decretar a falência de uma empresa por mais conceituada que esta seja.
A origem das paradas não planejadas está sempre associada a desastres como enchentes, furacões, terrorismo e incêndios, mas há muitas outras origens para estes tipos de ocorrências que não são catastróficas, como por exemplo a perda de um arquivo de um banco de dados, o que também pode até levar uma empresa à falência.
Os problemas de segurança hoje se multiplicam de forma alarmante segundo Beal (2005, p. 91) “No caso de uma rede conectada à Internet, a mera segurança física dos equipamentos conectados já não garante nenhuma proteção: os recursos da rede deixam de estar num endereço físico para pertencer ao chamado “ciberespaço”, ambiente virtual criado pela rede mundial de computadores, e precisam ser protegidos contra quebra de segurança causada por ameaças externas (invasões, ataques de negação de serviço etc.) e internas (erros,abusos de privilégio, fraudes etc.).”
É importante saber que para se ter um sistema mais seguro é necessário um acompanhamento minucioso desse sistema. É preciso se estabelecer regras, personalizadas para cada empresa, cada situação conforme Sêmola (2003, p.105) “Estabelece padrões, responsabilidades e critérios para o manuseio, armazenamento, transporte e descarte das informações dentro do nível de segurança estabelecido sob medida pela e para a empresa; por tanto, a política deve ser personalizada”.
O ataque terrorista ocorrido em 11 de Setembro de 2001 demonstra um exemplo de como a administração de sobrevivência de negócios pode ser falha, em caso de má elaboração do plano de contingência. Por volta de 85 empresas simplesmente deixaram de existir, pois os seus respectivos centros de backup estavam localizados na torre vizinha e os autores do plano não pensaram que ambas pudessem cair ao mesmo tempo. Caso o backup estivesse em outra localidade, muito provavelmente tais empresas estivessem com suas atividades retomadas nos dias atuais.
Os administradores devem estar conscientes de que o investimento em um plano de continuidade de negócios é muito útil e um dia pode ser extremamente necessário, em alguns casos, vital.
Os estágios do plano de continuidade e sobrevivência mostram a necessidade de uma integração mais ampla desses fatores e evidenciam a ligação que há entre os fatores tecnológicos e organizacionais da empresa.
Para se fazer uma analise de impacto nos negócios é preciso analisar os processos da empresa para se ter uma idéia de como os aspectos de segurança podem se relacionar com tais processos. A política da empresa deve ser analisada, riscos devem ser identificados, falhas internas, operações críticas, tempo de resposta da recuperação de processos etc. Tudo isso deve estar referenciado no manual prático do plano de contingência da empresa.
O plano de continuidade de negócios e o sistema de sobrevivência são dois conceitos muito parecidos. É fato que a preocupação com a segurança tem aumentado em vários setores da indústria, mas isso cabe aos responsáveis pela organização tomar medidas cabíveis ao ramo em que atuam. Pesquisas devem ser feitas, e regras implementadas em todos os setores da empresa com o objetivo de reduzir ao máximo as vulnerabilidades existentes.
Segundo Beal (2005, p. 172) “Compreender claramente as características da organização, sua estrutura, suas capacidades, objetivos, estratégias, restrições legais de atuação e natureza dos ativos de informação, em termos de seus valores tangíveis e intangíveis, é fundamental para que se possam definir critérios adequados para avaliar os riscos e selecionar as melhores alternativas entre as medidas de proteção para reduzi-los.”
Qualquer impacto na geração de receitas por conta de paradas na produção pode ocasionar perdas significativas no faturamento e, principalmente na reputação da indústria para com o mercado. Assim o emprego dos Planos de Continuidade de Negócios e de Recuperação de Desastres é essencial para garantir a existência da empresa.
Não podemos nos enganar ao afirmar que backup do site, contingencia externa de servidores e banco de dados, sistema de armazenagem de primeira linha(storage) garantem a continuidade dos negócios, pois NÃO garantem. Todo esse processo de negócios realizados pelas empresas e que devem estar protegidos de interrupções, são por pessoas executados e pessoas precisam de orientação pontual, planejada e especifica, sem isso, não se garante a continuidade dos negócios da empresa somente por ela possuir bons sistemas de backup ou equipamentos de primeira linha.
Não há sistema perfeito nem segurança perfeita, mas muitas são as formas de contingência que podem ser adotadas e farão a grande diferença quando o imprevisto já estiver previsto.
Joel Chagas Menezes é Administrador de Empresas, pós-graduado em Qualidade e Governança de TI e faz parte do corpo docente da graduação da UNIFACS além de trabalhar com bancos de dados há mais de 20 anos. Como sócio da Polo-iT, atua na Gerência de Suporte e é o responsável pela gestão da qualidade nos processos do DBA Center.
(por Marcelo Medrado)
Em todos estes anos trabalhando com bancos de dados, havia sempre um questionamento recorrente sobre qual o melhor SGBD do mercado. E o mais engraçado é que, da mesma forma que se observa conversas sobre times de futebol, bandas prediletas e religião, sempre existem opiniões que tangem ao fanatismo ao se defender o seu “banco de dados predileto”.
Mesmo evoluindo minha carreira juntamente com o Oracle há várias versões, confesso que me esforço para não ser xiita em nenhum momento e sempre me mantenho informado sobre os seus concorrentes. Vejo que o mercado evoluiu bastante e hoje nós já possuímos diversos “players” que não só fazem bonito como já incomodam os gigantes Oracle, DB2 e MS SQLServer.
Dos SGBDs que me aprofundei mais, gostaria de fazer um paralelo entre os dois bancos de dados mais usados no mundo: Oracle 10g e MS SQLServer 2005.
“Mas pera lá, por que você não está comparando o Oracle 11g com o SQL 2008?”, podem me perguntar alguns. A resposta é simples: Por que o parque instalado de bancos Oracle 10g e MSSQL 2005 é muito superior ao do seus irmãos mais “modernos”. Da mesma forma, as colocações feitas aqui são baseadas na percepção empírica de como as tão divulgadas funcionalidades de cada um deles funcionam de verdade na vida real.
É importante ressaltar que eu pretendo pontuar vantagens reais em relação aos dois produtos. Não farei nenhum tipo de comparação sobre características pouco aproveitadas como a possibilidade de se poder criar 32.000 colunas no Oracle contra “somente” 1024 do SQLServer 2005 (apesar de quê tenho uma curiosidade mórbida de descobrir se alguém, por algum motivo, trocou o seu SGBD por não conseguir satisfazer seus desejos masoquistas se criar tabelas com mais de 1024 colunas). Da mesma forma, partirei do princípio que esta comparação envolve ambientes de tamanho médio com máquinas low-end pois não só a limitação do sistema operacional da Microsoft como a própria estrutura do seu banco de dados não permite que o mesmo seja executado em ambientes maiores, com servidores high-end e aplicações extremamente complexas e críticas. Vamos aos tópicos:
Concorrência, Locks e Versionamento
Um dos grandes saltos do SQL Server 2005 em relação às versões anteriores foi o trabalho feito em relação à concorrência no acesso às informações. Uma das grandes reclamações pré-2005 era justamente sobre falta de eficiência neste quesito. Na prática, metade dos problemas de qualquer grande base em SQL Server 2000 se resumia a locks.
Nesta nova versão, o SGBD da Microsoft adotou um novo nível de isolamento chamado “Snapshot Isolation”. Trocando em miúdos o MS SQLServer (finalmente) agora tem a capacidade de criar versionamento de linha - um recurso que garante que se crie uma fotografia do banco no início de uma transação independente dos inserts, deletes e updates até que a mesma chegue ao fim.
No Oracle, não existe tal funcionalidade porém este comportamento pode ser simulado através do Flashback Database e também de consultas baseadas em timestamp, que são capazes de trazer informações como elas “eram” num tempo passado (obviamente, respeitando-se os limites parametrizáveis de retenção).
Ambas as bases agora trabalham com locks em todos os níveis - tabela, linha e coluna - porém o SQL Server 2005 possui uma controversa funcionalidade que permite que se habilite uma forma de consultar dados ainda não efetivados de outras transações.
Reorganização Online de Dados e Índices
Historicamente, o MSSQL Server possuía poucas possibilidades de reorganização em comparação aos seus grandes concorrentes DB2 e Oracle. Basicamente, índices podiam ser reorganizados, sempre com a necessidade de um lock exclusivo. A partir da versão analisada, o SQL já permite reorganização de índices sem a geração de locks, mesmo gerando um overhead de processamento razoável.
O Oracle já possui diversas funcionalidades relacionadas à reorganização de tabelas e índices. Na prática, pode-se mover uma tabela inteira no Oracle sem bloqueá-la gerando um pequeno lock apenas no momento da finalização do processo. Além disso, o Oracle 10g trouxe a possibilidade de se compactar/reorganizar tabelas movendo os blocos de forma contígua e liberando o espaço final, reduzindo fragmentação e espaço utilizado na tablespace.
Estratégias de Backup, Manutenção e Recovery
É impressionante a simplicidade de se executar tarefas no MSSQL Server 2005. Digo, com propriedade, que quem já está acostumado à dureza das scripts complexas em diferentes plataformas necessárias ao Oracle vai se sentir “nas nuvens” ao criar uma rotina de backup e manutenção no Management Studio do SGBD da Microsoft. As rotinas são criadas em forma de fluxo, como num diagrama gerado no Visio, onde você diz graficamente o que você quer, como você quer e como a rotina deve se comportar de acordo com o status de execução de cada tarefa. Simplesmente Perfeito. Em compensação, as possibilidades de backup me pareceu insuficiente para todos os cenários existentes e demasiadamente frágil.
Diferente do Oracle, não existe uma separação completa entre logs e dados, estes logs não podem ser movidos ou armazenados pois se acumulam num grande arquivo e não há a possibilidade de se manter backups redundantes. Em outras palavras, ao se fazer um backup FULL de sua base de dados, automaticamente os anteriores são invalidados. As estratégias de backup incremental são bem eficientes e úteis e satisfazem qualquer necessidade de bancos pequenos a médios. Para piorar o quadro, não existe nenhuma metodologia de exportação lógica de informações, possibilitando a restauração de uma única tabela ou usuário.
O Oracle, por sua vez, possui inúmeras possibilidades de backup diferentes. Desde as metodologias de backup físico online (cópia dos datafiles e criação de backupsets) até as diferentes formas de se gerenciar estas estruturas (automaticamente, através da flash_recovery_area que faz a gestão automática da retenção dos arquivos ou manualmente, através de scripts manuais gerenciados pelo DBA). Para alívio de alguns (e desespero de outros) as rotinas de backup na versão 10g podem ser configuradas através do Database Console, ferramenta web de administração que reúne diversas funcionalidades.
Em se tratando de recuperação, o MSSQL Server 2005 possui maior flexibilidade pois cada banco de dados possui informações de consistência próprios o que permite que bancos diferentes sejam recuperados de backups diferentes (feitos em momentos diferentes, inclusive). Por outro lado, existem diversas técnicas de recuperação (além de parâmetros não-documentados) que fazem qualquer cenário de catástrofe recuperável bastando que se mantenha uma estratégia de backup eficiente.
A ferramenta de exportação de dados lógicos do Oracle também é um show à parte: Ela possibilita que você gere um arquivo contendo todas as informações lógicas necessárias para se restaurar a base de dados inteira, em plataformas e arquiteturas diferentes.
Ambas as bases oferecem funcionalidades à parte: Anexar bases avulsas (MSSQL), transportar tablespaces entre arquiteturas diferentes (Oracle), Voltar toda uma base de dados a um momento específico do tempo (Oracle), Migrar planilhas do Excel e bases do Access de forma transparente (MSSQL), entre outras. A cada nova versão, mais flexível se tornam as técnicas de movimentação de dados.
Espelhamento
O SQL Server 2005 possui uma nova modalidade de espelhamento Ativo-Passivo semelhante ao Oracle Dataguard, através de aplicação de logs de transação. A sua simplicidade e eficiência impressionam até aos fans mais inveterados da Oracle pois pode ser implementado com alguns bocados de cliques. Para que o failover seja automático, é necessário criar uma terceira instância, chamada de forma nada criativa de “testemunha”. Este terceiro membro, tem a “nobre missão” de monitorar as bases e controlar automaticamente quem está ativo e quem está inativo/sincronizando.
No Oracle, o Dataguard faz as honras, com sua complexidade e sofisticação colocando à prova o conhecimento de qualquer DBA (de fato, existe uma certificação Oracle somente para esta funcionalidade). Ele não só faz o simples espelhamento de instância no modo ativo-passivo como pode ser usado como base para relatórios e outras diversas funcionalidades que seriam dignas de um post exclusivo neste blog.
Desenvolvimento
Confesso que fui surpreendido com o poder da linguagem Transact SQL (ou T-SQL para os íntimos) embarcada no MSSQL Server 2005. Ela não só possui todos os requisitos para se desenvolver qualquer tipo de programação estruturada nas procedures e funções como também possui uma compatibilidade nativa com toda a estrutura .NET possibilitando a escrita de procedimentos diversas linguagens (como C# e Visual FoxPro) de forma transparente. Da mesma forma, pode-se utilizar todas as APIs do Windows dentro das procedures e funções, algo que somente um SGBD e um sistema operacional com mesmo “pai e mãe” poderiam proporcionar. Funcionalidades como TRY/CATCH (comparável ao EXCEPTION do PL/SQL do Oracle), operadores relacionais, PIVOT, ROW_NUMBER e várias outras funções de ranking de linha. Existe também um suporte nativo ao XML que deixa o XML DB do Oracle com inveja.
O Oracle, por sua vez, vem evoluindo desde a versão 8i no quesito “funções analíticas” e hoje existem quase 100 funções suficientemente poderosas para enfrentar a facilidade do T-SQL. Ironicamente, até hoje o Oracle ainda não implementou a função PIVOT, disponível apenas na utilização de pacotes especiais na option OLAP, instalada separadamente.
Funcionalidades Exclusivas do Oracle 10g
LogMiner:
Esta funcionalidade provê uma forma de extrair todas as DMLs e DDLs executadas na base de dados historicamente, através dos logs de transação. É muito utilizado em auditorias, replicação ou criação de scripts de rollback. Apesar do MSSQL Server 2005 não ter algo semelhante, existem ferramentas de terceiros que podem interpretar os arquivos de log. Da mesma forma uma funcionalidade avançada chamada DDL Notification Event permite que eventos sejam disparados sempre que DDLs e DMLs sejam executados.
Flashback Query:
Outra fantástica funcionalidade do Oracle 10g que permite que consultas sejam feitas num cenário de tempo anterior ao atual. Isso quer dizer que pode-se consultar dados que estavam na tabela X na noite anterior. Da mesma forma, pode-se habilitar a recuperação de um objeto deletado, da mesma forma que se faz na lixeira do Windows. É o Oracle Recycle Bin.
Auditoria:
Com novas extensões do parâmetro AUDIT_TRAIL, todas as queries executadas podem ser auditadas incluindo as bind variables. No MSSQL Server, somente o SQL Trace pode fornecer alguma informação desta natureza mas não mostra bind variables e gera um grande overhead na performance do banco de dados.
Funcionalidades Exclusivas do MSSQL Server 2005
Identity:
Uma das funcionalidades mais úteis que o Oracle NÃO POSSUI é o campo identity numa tabela. Campos assim têm a capacidade de auto-incrementar a primary key de forma prática e simples. As sequences do Oracle são extremamente úteis e poderosas mas geram grandes sobrecargas de administração em ambientes mais complexos. Na prática, a única forma de simular isto no Oracle é criando triggers de auto-incremento.
Notification Services:
Esta funcionalidade possibilita a implementação de sistemas de notificação que disponibilizam, de forma personalizada, informações em tempos determinados, para qualquer dispositivo. Esta informação pode incluir alerta de reposição de estoque, alerta de produto indisponível e qualquer outra informação “consultável” no banco de dados. O fato dele ser integrado com o Windows possibilitando executar DLLs, e softwares, enviar e-mails e SMSs faz do Notification Services uma ferramenta poderosa.
Reporting Services:
É um serviço de geração de relatórios capaz de criar belos PDFs e com uma excelente IDE. Apesar do Reporting Services não chegar aos pés do Oracle Reports rodando sobre o Oracle IAS, o fato dele estar integrado ao SGBD é uma vantagem considerável.
Resumo da Ópera
Não subestime o poder das funcionalidades do MSSQL Server 2005. Trata-se de um banco de dados amadurecido e robusto que possui diversos atrativos ligados à simplicidade da administração, usabilidade e interface superiores e a praticidade de estar intrísecamente ligado ao sistema operacional.
Infelizmente, a comparação termina por aí. Testes atuais mostram que o Oracle possui performance semelhante ao MSSQL 2005 em plataformas Windows e seu desempenho cresce exponencialmente em plataformas UNIX e arquiteturas RISC. A possibilidade muito superior de customização de memória e parâmetros relacionados a I/O, uso de blocos de leitura e escrita, cursores e processos fazem do Oracle um banco de dados muito mais completo e robusto, portanto que se pague o preço referente ao seu custo.
Que me desculpem os DBAs Xiitas, mas eu não consigo visualizar um cenário onde existam requisitos técnicos que façam o MSSQL SQLServer uma escolha melhor para um ambiente. Notem que eu disse “requisitos técnicos”. A utilização de tecnologia Microsoft em todo parque, o conhecimento prévio da tecnologia, a limitação técnica da infraestrutura de servidores, a integração com o .NET e o custo menor de administração fazem do MSSQL Server 2005 uma excelente opção.
A Polo-iT hoje oferece administração de bases de dados Oracle e SQL Server, por um custo x benefício inigualável com monitoramento reativo e pró-ativo 24x7.
Qual deles você escolhe?
Marcelo Medrado é DBA Oracle há 9 anos além de trabalhar com dimensionamento de hardware e desenvolvimento de aplicações. Como sócio da Polo-iT, atua no DBA Center prestando consultoria a clientes Oracle e SQLServer e faz parte do núcleo de desenvolvimento das ferramentas de monitoria de bancos de dados da empresa.
