Microsoft SQL Server 2005 para Profissionais de Oracle

Transcrição

1 Microsoft SQL Server 2005 para Profissionais de Oracle

2 Sumário Índice Sumário... 6 Arquitetura de Banco de Dados... 6 Estruturas de Armazenamento Físico e Lógico... 9 Processos de Segundo Plano Particionamento Registros de Transações e Recuperação Automática Arquivos Virtuais de Registro Fazendo Backup de Dados no SQL Server Recursos de Alta Disponibilidade Infra-estrutura e Ferramentas de Gerenciamento Monitoramento e Ajustes Movimento e Ferramentas de Dados Níveis de Transação/Isolamento Conclusão SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts

3 Informações sujeitas a alterações a qualquer momento sem prévio aviso. O cumprimento de todas as leis pertinentes de direitos autorais é de responsabilidade do usuário. Scalability Experts Inc. pode deter as patentes, as solicitações de patentes, as marcas comerciais, os direitos autorais ou outras propriedades intelectuais pertinentes ao objeto deste documento. Salvo expressamente disposto em qualquer contrato de licença escrito da Scalability Experts Inc., o fornecimento deste documento não confere a você qualquer licença em relação a essas patentes, marcas comerciais, direitos autorais ou outras propriedades intelectuais. Copyright 2006 de Scalability Experts Inc. Todos os direitos reservados. Windows, Windows NT, Windows Server 2003, SQL Server 2000 e SQL Server 2005 são marcas registradas ou comerciais da Microsoft Corporation nos Estados Unidos e/ou outros países. Oracle é marca registrada da Oracle Corporation e/ou suas afiliadas. Outros produtos e nomes de empresas e aqui mencionados podem ser marcas comerciais de seus respectivos proprietários. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts

4 Sumário Este white paper explica as principais diferenças entre os bancos de dados Microsoft SQL Server 2005 e Oracle. Ele compara a arquitetura do banco de dados SQL Server e Oracle e fornece informações sobre os mais novos recursos do SQL Server Este documento se destina a profissionais de Oracle que queiram potencializar seu conhecimento em Oracle para gerenciar o SQL Server ou se preparar para migrar um banco de dados Oracle para o SQL Server Outros tópicos discutidos neste white paper incluem backups, segurança de bancos de dados, opções de gerenciamento e opções de alta disponibilidade. Arquitetura de Banco de Dados Em Oracle, um banco de dados se refere ao ambiente Oracle RDBMS inteiro e inclui os seguintes componentes: Processos e buffers (instância) do banco de dados Oracle. Espaço para tabela SYSTEM contendo um catálogo de sistema centralizado, que é composto de um ou mais arquivos de dados. Outros espaços de tabela opcionais como definidos pelo administrador de bancos de dados (DBA), cada qual composto de um ou mais arquivos de dados. Dois ou mais Registros a Refazer online. Registros a Fazer Arquivados (opcional). Arquivos variados (arquivo de controle, Init.ora, Config.ora, e assim por diante). Um banco de dados em Microsoft SQL Server 2005 se refere a um agrupamento físico de objetos de esquema de um banco de dados em um ou mais arquivos físicos. Bancos de dados são classificados em definido pelo sistema e definido pelo usuário dentro do SQL Server Os bancos de dados de sistema consistem dos dados do sistema e também controlam o armazenamento temporário necessário para dados de aplicações. Os dados de aplicações ficam disponíveis em um banco de dados do SQL Server definido pelo usuário. Uma instância do SQL Server pode suportar múltiplos bancos de dados. Aplicações construídas usando o SQL Server podem usar bancos de dados para dividir logicamente a funcionalidade da empresa. Pode haver múltiplas instâncias do SQL Server em um único computador. Cada instância do SQL Server pode conter vários bancos de dados. Cada banco de dados do SQL Server pode suportar grupos de arquivos, que fornecem a capacidade de distribuir fisicamente a disposição dos dados. Um grupo de arquivos do SQL Server categoriza os arquivos do sistema operacional contendo dados de um único banco de dados do SQL Server para simplificar as tarefas dos administradores, tais como o backup. Um grupo de arquivos é uma propriedade de um banco de dados do SQL Server e não podem conter os arquivos do sistema operacional de mais de um banco de dados, embora um único banco de dados possa conter mais de um grupo de arquivos. Depois da criação do banco de dados, grupos de arquivos podem ser acrescentados a ele. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 6

5 Arquitetura de Banco de Dados Figura 1: Espaços de Tabela do Oracle e bancos de dados do SQL Server comparados. O Microsoft SQL Server também instala os seguintes bancos de dados por padrão: O bando de dados padrão um modelo para todos os bancos de dados de usuários recém-criados e tempdb. O banco de dados tempdb é similar a um espaço de tabela temporário do Oracle no sentido de que é usado para armazenamento de trabalho e operações de classificação. Diferentemente do espaço de tabela temporário do Oracle, os usuários podem criar tabelas temporárias que são automaticamente excluídas quando o usuário encerra a sessão. O banco de dados msdb que suporta o Agende do SQL Server (SQL Server Agent) e suas tarefas agendadas, alertas, e informações de replicação. Os bancos de dados AdventureWorks e AdventureWorksDW são bancos de dados de amostra para fins de testas e treinamento que podem ser instalados opcionalmente. Para mais informações sobre os bancos de dados padrão, consulte os Livros Online do SQL Server. Nota: Você pode fazer o download e instalar os Livros Online do SQL Server sem instalar o SQL Server site Livros Online é um recursos abrangente para o SQL Server que inclui documentação detalhada, amostras de código e tutoriais. Catálogos de Sistema de Banco de Dados Cada banco de dados Oracle é executado em um catálogo centralizado de sistema, ou dicionário de dados, que reside no espaço de tabela SYSTEM. Cada banco de dados do Microsoft SQL Server 2005 mantém seu próprio catálogo, que contém informações relacionadas a: Objetos de banco de dados (tabelas, índices, procedimentos armazenados, visualizações, triggers, e assim por diante). Restrições. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 7

6 Arquitetura de Banco de Dados Usuários e permissões. Tipos de dados definidos pelo usuário. Objetos de Esquema Arquivos usados pelo banco de dados. Definição de replicação Definições de instantâneo As informações do nível do sistema para uma instância do SQL Server 2005 são gravadas pelo banco de dados mestre. As informações gravadas incluem o seguinte: Nomes de bancos de dados e a localização primária de arquivos para cada banco de dados. Contas de login do SQL Server. Mensagens do sistema. Valores de configuração de banco de dados. Servidores remotos e/ou ligados um recurso no SQL Server 2005 que permite a você executar comandos em fontes de dados OLEDB em servidores remotos (inclusive Oracle). Informações de atividade atual. Informações de extremidade extremidades são meios de implementar interfaces baseadas no protocolo TCP para implementação de certos recursos incluindo serviços de Web em HTTP, Agenciador de Serviços (Service Broker), espelhamento de Bancos de Dados. Procedimentos armazenados no sistema. No SQL Server 2005, os objetos de sistema não são armazenados no banco de dados mestre, mas em um banco de dados oculto, chamado banco de dados de recurso. O catálogo do sistema é usado no SQL Server 2005 para recuperar informações de metadados sobe objetos em um banco de dados. Os catálogos de sistema são acessíveis ao usuário como visualizações do catálogo. Para monitorar a saúde de uma instância de servidor, diagnosticar problemas e ajustar o desempenho, as Visualizações Dinâmicas de Gerenciamento do SQL Server 2005 (SQL Server 2005 Dynamic Management Views) podem ser usadas. As visualizações dinâmicas de gerenciamento no SQL Server 2005 são semelhantes às visualizações V$_ no Oracle, que são usadas para monitoramento de desempenho. Como o espaço de tabela SYSTEM no Oracle, o banco de dados mestre do SQL Server deve estar disponível para acessar qualquer outro banco. Assim, a proteção contra falhas é importante fazendo-se o backup do banco de dados mestre depois de qualquer mudança significativa no banco de dados. Administradores de bancos de dados também podem espelhar os dados que compõem o banco de dados mestre. Para informações detalhadas sobre o catálogo do sistema e visualizações Dinâmicas de Gerenciamento, procure Catálogo de Sistema e Visualizações Dinâmicas de Gerenciamento nos Livros Online. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 8

7 Arquitetura de Banco de Dados Estruturas de Armazenamento Físico e Lógico O Oracle RDBMS é composto de espaços de tabela, que por sua vez são compostos de arquivos de dados. Arquivos de dados de espaço de tabela são formatados em unidades internas chamadas blocos. O tamanho do bloco é definido pelo DBA quando o banco de dados do Oracle é criado pela primeira vez. Quando um objeto é criado no espaço de tabela do Oracle, o usuário pode especificar seu espaço em unidades chamadas extensão (extent) (extensão inicial, próxima extensão, extensões mínima e máxima). Se nenhum tamanho de extensão for explicitamente definido, uma extensão padrão é criada. Uma extensão do Oracle varia em tamanho e deve conter uma cadeia de pelo menos cinco blocos contíguos. O SQL Server utiliza um tamanho de página fixo de 8 KB que é a unidade básica de E/S. Para gerenciar melhor as páginas, o SQL Server as organiza em grupos de oito que são fisicamente contíguas umas às outras, chamadas extensões. Embora a ES seja realizada uma página por vez, o espaço é gerenciado em termos de extensões. Cada página pertence a um objeto e é de um tipo (dados, índice, GAM, IAM, etc.), mas uma extensão pode pertencer a múltiplos objetos (até oito). Uma extensão que tenha oito páginas pertencendo ao mesmo objeto é chamada de Extensão Uniforme; caso contrário é chamada de extensão mista. Embora uma linha não possa ultrapassar uma página (8060 bytes página menos espaço do cabeçalho), o SQL Server 2005 pode mover dados para a unidade ROW_OVERFLOW_ALLOCATION. Extensões vivem dentro de um grupo de arquivos. O diagrama a seguir oferece uma comparação gráfica de como os blocos e extensões no Oracle são mapeados para páginas e extensões no SQL Server. 2K 2K 2K 2K 8K 8K 8 K 8K block block bl ock 6 x 2K block = 12K page page pa ge page 2K 2K 2K EXTENT 8 pages = 2K 8K 8 K 8K 1 EXTENT block block bl ock block 12K + 16K = 28K page page page (8 x 8K = 64K) 2K 2K 2K 2K SEGMENT 8K 8K 8 K 8K block block block block (Table/Index) page page pa ge page 2K block 2K 2K 2K bl ock block blo ck 2K 2 K 2K 2 K block bl ock block blo ck 2K block 2K block 2 K 8 x 2K 2K = 16K 2 K bl ock EXTENT block blo ck 2 K 2K 2 K bl ock block blo ck 8K page 8K page 8K page 8K page 8K page 8K page 8K page 8K page 8 K pa ge 8K page 8 K 8K pa ge page 8 pages = 8 K 8K 1 EXTENT pa ge page (8 x 8K = 64K) 8 K 8K pa ge page 2K 2 K 2K 2 K 8K 8K 8 K 8K block block block block page page page page 64K + 64K = 128K HEAP/INDEX Oracle SQL Server Figura 2: Comparando páginas e extensões do Oracle e SQL Server. O SQL Server usa grupos de arquivos no nível do banco de dados para controlar a disposição física de tabelas e índices. Grupos de arquivos são recipientes lógicos de um ou mais arquivos, e os dados contidos em um grupo de arquivos são preenchidos proporcionalmente através de todos os arquivos pertencentes ao grupo. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 9

8 Se grupos de arquivos não forem definidos e usados, objetos de banco de dados são dispostos em um grupo de arquivos padrão que é implicitamente definido durante a criação de um banco de dados. Os grupos de arquivos permitem que você: Distribua e particione grandes tabelas em múltiplos arquivos para melhorar a taxa de transferência de E/S. Armazene índices em arquivos diferentes de suas respectivas tabelas, para melhorar a taxa de transferência de E/S e a concorrência de disco e também para particionar esses índices. Armazenar colunas de texto, ntext, e imagens (grandes objetos) em arquivos separados da tabela. Dispor objetos de banco de dados em eixos específicos de disco. Fazer backup e restaurar tabelas individuais ou conjuntos de tabelas dentro de um grupo de arquivos. Além disso, o SQL Server 2005 possui dois tipos de tabelas temporárias, usuário e global. A tabela temporária usuário é identificada por um único sinal de número (#) e é criada no banco de dados TEMPDB. Quando a conexão que criou a tabela temporária usuário é encerrada, a tabela é excluída. A tabela temporária global é identificada por dois sinais de número (##) e também é criada no banco de dados TEMPDB. Diferentemente da tabela temporária usuário será conservada até ser manualmente excluída ou até que o servidor seja reiniciado, quando o banco de dados TEMPDB (e todos os objetos dentro dele) são excluídos. Isso difere do Oracle, que suporta somente tabelas temporárias globais embora a funcionalidade faça sobreposições. Para mais informações, consulte Arquitetura de Banco de Dados Físico nos Livros Online do SQL Server. Arquivos de Dados em Disco Segmentos do tipo Oracle não são necessários para a maioria das instalações do Microsoft SQL Server. Em vez disso, o SQL Server pode distribuir, dados mais eficientemente com soluções de RAID baseado em hardware ou em software disponíveis através da infra-estrutura de administração de disco ou a partir de software de terceiros. Embora o RAID de software seja suportado, soluções de RAID de hardware são altamente recomendadas por seus desempenho e resistência superiores. A configuração de RAID recomendada para o SQL Server é RAID 1+0 (espelhamento de um conjunto distribuído) ou RAID 1 (espelhamento) para os arquivos de dados. O RAID 1+0 é consideravelmente mais caro para implementar, mas oferece o maior desempenho e proteção contra falhas. O RAID 5 (conjuntos distribuídos com paridade) pode ser implementado para arquivos de dados do SQL Server que sejam usados principalmente para operações de leitura. Operações de arquivos de registro de transações são seqüenciais em natureza, portanto o RAID 1 é a recomendação típica. Apenas alguns sistemas exigirão a distribuição de dados de registro para desempenho a menos que o sistema tenha taxas muito altas de operações de gravação. Assim, espelhar os arquivos de registro para proteção contra falhas usualmente é adequado contanto que o disco possa suportar o número de operações de E/S exigidos pela aplicação. Maiores detalhes sobre a arquitetura do registro de transações do SQL Server são discutidos na seção abaixo, em Registros de Transações e Recuperação Automática. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 10

9 Processos de Segundo Plano O SQL Server 2005 também usa vários diferentes processos em segundo plano para gerenciar eficientemente os recursos do computador. Um exemplo são os pontos de verificação (checkpoints). O SQL Server gera pontos de verificação automáticos periodicamente em cada banco de dados. Os pontos de verificação eliminam dados e páginas de registro sujos do cache do buffer do banco de dados atual, minimizando o número de modificações que tem de ser atualizadas durante uma recuperação. Outro processo em segundo plano é chamado Lazywriter e é único em cada instância. O processo lazywriter hiberna por um intervalo de tempo e então desperta para fazer uma varredura do cache do buffer onde verifica o tamanho da lista do buffer livre. Se a lista do buffer livre estiver abaixo de um determinado ponto (dependendo do tamanho do cache), o processo lazywriter executa a varredura do cache do buffer para reclamar páginas não usadas e gravar páginas sujas que não tenham sido consultadas recentemente, enquanto páginas freqüentemente consultadas permanecem na memória. Se o lazywriter for usado em um servidor com capacidade de NUMA, um processo do lazywriter será gerado para cada nó de NUMA de uma instância. Enquanto o SQL Server 2005 fez o LazyWriter para controlar somente páginas de dados na memória do buffer, outro thread chamado ResourceMonitor (Monitor de Recurso) foi introduzido para controlar o comportamento do resto dos caches e assistentes de memória. Sua função é reagir dinamicamente a pressões de memória internas e externas. O thread de segundo plano do ResourceMonitor não permite que a memória de cache geral ultrapasse 70% do Pool de Buffers. Se o mecanismo de predição do SQL Server detectar tal possibilidade, o ResourceMonitor entra em execução e reduz os caches. Além disso, o ResourceMonitor não permitirá que nenhum cache individual seja maior que 50% do Pool de Buffers. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 11

10 Particionamento Particionamento O particionamento no SQL Server permite um gerenciamento mais eficiente de grandes tabelas no banco de dados. Visualizações Particionadas fazem parte do SQL Server há anos, mas os recursos de Particionamento de Tabelas e Índices, novos no SQL Server 2005, facilitam implantar o particionamento horizontal de tabelas e índices relacionados. Embora não seja exigido geralmente pela maioria dos bancos de dados, há alguns benefícios significativos quando se particionam tabelas muito grandes (acima de dezenas de milhões de linhas). Eles incluem: Gerenciamento melhorado várias operações de gerenciamento são mais fáceis e rápidas de executar em tabelas particionadas. Por exemplo, dados podem ser carregados ou descarregados por partições, depois adicionados ou removidos de uma tabela particionada existente. O particionamento permite que os usuários lidem com apenas porções voláteis dos dados que são geralmente um pequeno subconjunto da tabela em vez de a tabela inteira. Isso é também um benefício significativo para usuários que possuem cenários de janela deslizante em que porções dos dados precisam ser removidas ou arquivadas periodicamente para que somente os dados ativos sejam mantidos no banco de dados principal. Desempenho melhorado com a capacidade de desempenhar operações exigentes em recursos como carregar grandes volumes de dados ou executar operações de gerenciamento de índices contra grandes tabelas offline e em pedaços menores, o desempenho geral do sistema é mantido. Por exemplo, embora reconstruir um índice possa ser feito online com o SQL Server 2005, fazer isso com uma tabela muito grande consome uma quantidade considerável de recursos. Com uma tabela particionada, os usuários podem reindexar somente a(s) porção(ões) volátil(eis), deixando as partições estáticas intocadas. Isso consome significativamente menos recursos do sistema, como memória. Custo reduzido tabelas particionadas também permitem a disposição fácil de partições específicas em dispositivos de armazenamento designados. Por exemplo, uma grande tabela que acompanhe informações financeiras, dados históricos que não mudam mais (mantidos apenas para acesso de leitura) podem ser mantidos em armazenamento de baixo custo com recursos mínimos de recuperação rápida. Os dados atuais podem ser guardados em armazenamento de alto desempenho com redundância e recursos de recuperação rápida. Isso pode resultar em significativas economias em custo em sistemas que precisam armazenar dados históricos por muitos anos para fins contábeis ou de conformidade com normas de controle. O SQL Server 2005 atualmente suporta o particionamento de faixas e outros esquemas são planejados para suporte futuro. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 12

11 Processos de Segundo Plano Registros de Transações e Recuperação Automática O Oracle RDBMS executa recuperação automática sempre que é iniciado. O Oracle confirma que o conteúdo dos arquivos de espaço de tabela esteja coordenado com o conteúdo dos arquivos de registro a refazer online. Se não estiver, o Oracle aplica o conteúdo dos arquivos de registro a refazer online (atualiza), e então remove qualquer transação não comprometida encontrada nos segmentos de reversão. Se o Oracle não puder obter as informações de que precisa a partir dos arquivos de registro a refazer online, consulta os arquivos de registro a refazer arquivados. O Microsoft SQL Server 2005 também executa recuperação automática de dados verificando cada banco de dados no sistema sempre que são iniciados. O SQL Server primeiro verifica o banco de dados mestre e em seguida lança threads para recuperar todos os outros bancos de dados no sistema. O mecanismo automático de recuperação verifica o registro de transações para cada banco de dados do SQL Server. Se o registro de transações contiver quaisquer transações não-comprometidas, elas são revertidas. O mecanismo de recuperação então verifica o registro de transações para transações comprometidas que ainda não tenham sido gravadas no banco de dados. Se encontrar alguma, ele as executa novamente, atualizando. Cada registro de transação do SQL Server possui a funcionalidade combinada de um segmento de reversão do Oracle e um registro a refazer online do Oracle. Cada banco de dados possui seu próprio registro de transações que grava todas as mudanças no banco de dados e é compartilhado por todos os usuários do banco de dados. Quando uma transação começa e ocorre uma modificação de dados, um evento BEGIN TRANSACTION (assim como o evento de modificação) é gravado no registro. Esse evento é usado durante a recuperação automática para determinar o ponto inicial da transação. Conforme cada instrução de modificação de dados é recebida, as mudanças são gravadas no registro de transações antes de serem gravadas no banco de dados. O SQL Server possui um mecanismo automático de ponto de verificação que assegura que as transações completadas sejam gravadas regularmente no arquivo de registro de transações a partir do cache de disco do SQL Server. Um ponto de verificação grava no banco de dados qualquer página em cache que tenha sido modificada desde o último ponto de verificação. A anotação dessas páginas em cache, conhecidas como páginas sujas, no banco de dados assegura que todas as transações completadas sejam gravadas no disco. Esse processo encurta o tempo necessário para a recuperação de uma falha de sistema, como queda de energia. Essa configuração pode ser alterada modificando-se o intervalo de recuperação usando-se o SQL Server Management Studio ou o procedimento Transact-SQL sp_configure armazenado no sistema. Arquivos Virtuais de Registro Internamente, os registros de transação são desmembrados em pedaços menores chamados arquivos virtuais de registro (VLFs - virtual log files). Os VLFs são a unidade de truncamento para o registro de transações. O propósito dos VLFs é permitir o gerenciamento mais fácil e automático do registro de transações. Quando um VLF não contém mais entradas de registro para transações ativas, pode ser truncado e o espaço fica disponível para registrar novas transações. O menor tamanho para um arquivo virtual de registro é 256 KB. O tamanho mínimo para uma transação é 512 KB, que fornece dois VLFs de 256 KB. O número e tamanho dos arquivos virtuais de registro em um registro de transações aumentam conforme o tamanho do arquivo de registro aumenta. Conforme os registros são gravados, o fim do registro cresce de um arquivo virtual de registro para o seguinte. Se houver mais de um arquivo físico de registro para um banco de dados, o fim do registro cresce através de cada SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 13

12 arquivo virtual de registro em cada arquivo físico antes de voltar para o primeiro arquivo virtual de registro no primeiro arquivo físico. Uma vez que todos os arquivos de registro estiverem cheios, o registro começará a crescer automaticamente (se configurado para permitir auto-crescimento). O tamanho e número de VLFs que você terá dependem bastante do tamanho que o pedaço tem quando é adicionado ao registro de transações. Se você adicionar um novo pedaço ao registro de transações de 20 MB (através de auto-crescimento ou crescimento manual), então o número de VLFs adicionados é 4. Se adicionar um pedaço maior que 64 MB, mas menor que 1 GB, acrescentará 8 VLFs. Se adicionar mais de 1 GB, acrescentará 16 VLFs. Em geral, a maioria dos registros de transação terá 20 ou 30 VLFs mesmo 50 seria razoável, dependendo do tamanho total do registro. Contudo, em muitos casos o que acontece é que ocorrências excessivas de autocrescimento podem fazer com que um número excessivo de VLFs seja adicionado às vezes resultando em centenas de VLFs. VLFs excessivos adicionam overhead a atividades como registros de transações, backups de registros, desempenho de leitor de registros, e triggers. A regra prática geral é evitar auto-crescimento freqüente através da pré-alocação do tamanho do registro de transações de modo que não haja a probabilidade da ocorrência de auto-crescimento. O recurso de auto-crescimento do SQL Server (disponível para arquivos de dados e de registro) é projetado como uma rede de segurança no caso de uso significativo de armazenamento não-planejado. Ele não é destinado a substituir o planejamento e implantação de capacidade de armazenamento. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 14

13 Fazendo Backup de Dados no SQL Server 2005 Fazendo Backup de Dados no SQL Server 2005 Como o Oracle, o Microsoft SQL Server 2005 oferece várias opções para backup de dados, incluindo: Backups Completos Backups Diferenciais Completos Backups Parciais Backups Diferenciais Parciais Backups de Arquivo e de Grupos de Arquivos Backups de Registros de Transação Todos os backups podem ser realizados enquanto o banco de dados está em uso, permitindo sejam feitos backups em bancos de dados de alta disponibilidade. As estruturas de processamento de backup e de dados internos do SQL Server maximizam sua taxa de transferência de dados com efeitos mínimos no rendimento das transações. Tanto o Oracle como o SQL Server requerem um formato específico para arquivos de backup. No SQL Server, esses arquivos são chamados de dispositivos de backup e são criados usando o SQL Server Management Studio ou o procedimento armazenado Transact-SQL sp_addumpdevice. Embora backups possam ser realizados manualmente, recomenda-se que você use o SQL Server Management Studio e/ou o Assistente de Plano de Manutenção (Maintenance Plan Wizard) para programar backups periódicos ou backups baseados na atividade do banco de dados. Cada opção de backup é discutida em detalhes abaixo. Backup Completo Um backup completo (também conhecido como backup do banco de dados) copia todo o banco de dados, incluindo parte do registro de transações (para que o backup completo possa ser recuperado). Um backup completo é uma representação do banco de dados no momento da conclusão com sucesso do backup. Desenvolver uma estratégia de backup que combine backups completos com backups parciais do registro de transações permite a recuperação do banco de dados para um ponto específico no tempo. Um backup completo pode ser executado a partir da tarefa Backup no SQL Server Management Studio ou usando-se a instrução BACKUP DATABASE. Como outros métodos de backup, o backup completo também pode ser agendado usando-se o Agente do SQL Server (SQL Server Agent) ou através do Assistente de Manutenção de Banco de Dados (Database Maintenance Wizard). Backup Diferencial Completo Depois de um backup completo, fazer o backup de alterações incrementais do banco de dados pode ser realizado usando-se um backup diferencial completo. O backup diferencial completo pode ser implementado usando-se a tarefa SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 15

14 de backup do SQL Server Management Studio e também se usando a instrução BACK UP DATABASE WITH DIFFERENTIAL. A opção Diferencial faz somente o backup de alterações incrementais do banco de dados. Assim, o backup ocupa menos espaço e leva menos tempo para terminar que um backup completo. Contudo, são necessários um backup completo e um diferencial para recuperação. Backup Parcial O backup parcial é um recurso aperfeiçoado no SQL Server Ele consiste em cada arquivo no Grupo de Arquivos Primário padrão e todos os Grupos de Arquivos de leitura/gravação e arquivos de somente leitura específicos que são determinados usando-se o comando Backup. O backup parcial é um novo recurso introduzido no SQL Server 2005 para dar mais flexibilidade ao procedimento de backup em bancos de dados do SQL Server. É um modelo ideal para fazer o backup de porções de gravação intensiva de um banco de dados. Backup Diferencial Parcial Backups diferenciais parciais são usados somente com backups parciais. Um diferencial parcial contém somente as extensões alteradas no grupo de arquivos primário e em grupos de arquivos de leitura-gravação no momento da gravação. Se apenas alguns dos dados capturados por um backup parcial tiverem mudado, usar um backup diferencial parcial permite que o administrador de banco de dados habilite a criação de backups menores e mais rápidos. Contudo, restaurar a partir de backups diferenciais levará mais tempo, e será mais complexo, do que restaurar a partir de um backup parcial, já que dois arquivos de backup separados são restaurados. Backup de Arquivo, backup de Grupo de Arquivos Um backup de arquivo ou de grupo de arquivos copia um ou mais arquivos de um banco de dados especificado individualmente, permitindo que uma cópia de segurança de banco de dados seja feita em unidades menores: no nível do arquivo ou do grupo de arquivos. Isso pode aumentar a velocidade de recuperação em algumas instâncias permitindo que o usuário restaure somente arquivos danificados sem restaurar o resto do banco de dados. Por exemplo, somente o disco em falha precisa ser restaurado em um banco de dados com vários arquivos localizados em vários discos. Backup de registro de transações Os registros de transações no SQL Server 2005 são associados com bancos de dados individuais. A configuração padrão do SQL Server 2005 permite que o registro de transações cresça automaticamente conforme necessário. O registro crescerá até utilizar todo o espaço em disco disponível ou até alcançar o tamanho máximo configurado. É melhor evitar encher o registro de transações em um ambiente do SQL Server. Se o registro de transações estiver cheio, modificações nos dados dentro daquele banco podem sofrer um impacto. Outros bancos de dados não são afetados. Os registros de transações podem ser copiados usando-se a instrução BACKUP LOG ou usando-se a tarefa Backup no SQL Server Management Studio. Na conclusão bem-sucedida de um backup do registro de transações, a porção copiada é truncada e disponível para uso por novas transações. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 16

15 Componentes de Configuração de Rede Um banco de dados pode ser restaurado para um determinado momento aplicando-se backups de registro de transações ou backups diferenciais para um backup completo do banco de dados. Uma restauração de banco de dados sobrescreve os dados com as informações contidas nos backups. Restaurações podem ser realizadas usando-se o SQL Server Management Studio ou a instrução RESTORE DATABASE. O SQL Server 2005 suporta restaurações online. Componentes de Configuração de Rede O Serviços de Rede do Oracle (Oracle Net Services) suporta conexões em rede entre servidores de bancos de dados Oracle e seus clientes. Ele se comunica com o protocolo de fluxo de dados Substrato Transparente de Rede (TNS - Transparent Network Substrate), e permite que os usuários executem vários diferentes protocolos de rede sem escrever código especializado. Com o Microsoft SQL Server, a comunicação do cliente com um servidor suporta primariamente dois componentes que incluem o seguinte: Protocolo de Rede no Cliente e no Servidor Cliente Nativo do SQL Server (SNAC - SQL Server Native Client) Esta é uma nova tecnologia introduzida no SQL Server 2005 que combina as funções do OLEDB e do ODBC para SQL Server em uma biblioteca nativa. O cliente nativo suporta Bibliotecas de Rede e extremidades de TDS (fluxo de Dados Tabular - Tabular Data stream) para múltiplos protocolos no SQL Server. O TDS é o protocolo interno de transferência de dados cliente/servidor no SQL Server. O SNAC é carregado com a instalação do SQL Server 2005 e não exige instalação separada. Ele pode ser instalado separadamente em máquinas que não tenham o SQL Server instalado, mas requer acesso ao SQL Server. Figura 3: Comparando os componentes de rede do Oracle e do SQL Server A configuração do SNAC também pode ser realizada depois da instalação do SQL Server usando-se o Gerenciador de Configuração do SQL Server (SQL Server Configuration Manager). SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 17

16 Modelo de Segurança do SQL Server Modelo de Segurança do SQL Server Esteja você tentando mapear suas habilidades e conhecimentos em Oracle para SQL Server ou migrar aplicações de Oracle para o Microsoft SQL Server 2005, é importante entender como o SQL Server implementa segurança e funções de banco de dados. Esta seção descreve a arquitetura e recursos de segurança do SQL Server e os mapeia para equivalentes do Oracle onde apropriado. Segurança de Rede O Microsoft SQL Server 2005 pode usar Secure Sockets Layer (SSL) para criptografar dados transmitidos por uma rede entre uma instância do SQL Server e uma aplicação cliente. A criptografia de SSL é realizada dentro da Biblioteca de Rede de Cliente SQL Nativo (SQL Native Client Net-Library) e se aplica a todos os protocolos inter-computadores suportados pelo SQL Server A criptografia de SSL trabalha com instâncias do SQL Server em execução em um computador que ao qual tenha sido atribuído um certificado de uma autoridade de certificação pública. O computador em que a aplicação está sendo executada deve ser configurado para confiar na autoridade raiz do certificado. (A criptografia com um certificado auto-assinado é possível e descrita na seção seguinte, mas um certificado auto-assinado oferece apenas proteção limitada.) A criptografia de Biblioteca de Rede é implementada usando a API de Secure Sockets Layer. O nível de criptografia, 40 bits ou 128 bits, depende da versão do sistema operacional Windows nos computadores da aplicação e do banco de dados. Contas de Login Uma conta de login permite ao usuário acesso a uma Instância do SQL Server e a suas opções administrativas. Permite conexão à instância, mas não contém privilégios de acesso a dados. Uma conta de login é tipicamente mapeada para um nome de usuário de banco de dados. O acesso a dados e/ou funções administrativas é controlado através de nomes de usuário. Existe uma conta de login de convidado que permite aos usuários efetuar o login no SQL Server e visualizar somente bancos de dados com acesso permitido a convidados. Contudo, de acordo com as práticas de segurança recomendadas, a conta de convidado não é configurada por padrão e deve ser criada manualmente se preciso. Nome de Usuário de Banco de Dados Cada conta do Windows ou login do SQL Server deve estar associado com um nome de usuário em cada banco de dados que o usuário for autorizado a acessar, ou o banco de dados deve ter o acesso de convidado habilitado. Nomes de usuário de banco de dados são definidos por membros da função fixa do banco de dados db_owner (proprietário do banco de dados) ou db_accessadmin (administrador de acesso a bancos de dados), e são armazenados na tabela sys.database_principals encontrada em todos os bancos de dados. O SQL Server 2005 suporta dois tipos de nomes de login que são gerenciados e autenticados usando-se diferentes métodos; autenticação do Windows e autenticação do SQL Server authentication. Autenticação do Windows SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 18

17 Modelo de Segurança do SQL Server Um DBA pode especificar que contas de login do Windows podem ser usadas para se conectar a uma instância do SQL Server Usuários registrados no Windows usando essas contas podem se conectar ao SQL Server 2005 sem terem de especificar um login e senha de banco de dados separados. Quando usa a Autenticação do Windows, o SQL Server 2005 usa os mecanismos de segurança de NLM ou Kerberos para validar conexões de login, e conta com as credenciais de segurança do Windows do usuário. Os usuários não precisam entrar com IDs de login ou senhas para o SQL Server 2005 porque suas informações de login são tiradas diretamente da conexão de rede confiável. A autenticação do Windows é semelhante em funcionalidade à opção IDENTIFIED EXTERNALLY (Identificado Externamente) associada com contas de usuário do Oracle. Autenticação do SQL Server Um DBA também pode definir uma conta de login de banco de dados separada. O usuário deve especificar sua conta de login e senha quando tenta se conectar ao SQL Server O login do banco de dados não tem relação com o login do Windows do usuário. A autenticação do SQL Server é similar à opção IDENTIFIED BY PASSWORD (Identificado por Senha) associada com contas de usuário do Oracle. Modos de Autenticação Com os dois métodos de autenticação, o SQL Server 2005 oferece dois modos para autenticar usuários. DBAs podem escolher o modo mais apropriado com base nos requisitos e restrições da aplicação ou do sistema: 1. Modo de Autenticação do Windows (também conhecido como Segurança Integrada em versões anteriores do SQL Server) Neste modo, o SQL Server 2005 permite somente conexões que usam a Autenticação do Windows. Usuários não poderão efetuar o login usando uma ID de login do SQL Server. 2. Modo Misto neste modo, conexões podem ser feitas usando a Autenticação do Windows ou a Autenticação do SQL Server. Usuários podem se conectar ao SQL Server usando tanto sua conta de login do Windows (se tiverem recebido permissão) ou uma conta de login válida do SQL Server. Para mais informações sobre esses mecanismos de segurança, consulte os Livros Online do SQL Server. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 19

18 Modelo de Segurança do SQL Server Grupos, Funções, Esquemas e Permissões O SQL Server e o Oracle usam permissões para impor segurança de banco de dados. As permissões de nível de instrução do SQL Server são usadas para restringir a capacidade de se criar novos objetos de banco de dados (semelhante às permissões de nível de sistema do Oracle). O SQL Server também oferece permissões de nível de objeto. Como no Oracle, a propriedade de nível de objeto é atribuída ao criador do objeto e é intransferível. Permissões de nível de objeto devem ser concedidas a outros usuários do banco de dados antes que eles possam acessar o objeto. Membros da função fixa de servidor sysadmin, das funções fixas de banco de dados db_owner e ou db_securityadmin também podem conceder permissões de objetos de um usuário a outros usuários. Permissões podem ser concedidas, negadas ou revogadas em qualquer item que pode ser protegido do SQL Server. Conceder permissões específicas a um principal (logins, usuários ou funções) permite que o principal execute tarefas específicas. Revogar aquela permissão retira a capacidade de o principal executar as tarefas. Negar coloca um bloqueador explícito em um item protegível que impede que um principal execute ações específicas contra o item e sempre tem prioridade sobre todas as outras permissões. Por exemplo, se o usuário JOE pertencer à função SUPERUSUÁRIO (SUPERUSER) e a essa função tiverem sido concedidas permissões de seleção, inclusão, atualização e exclusão na tabela contatos, JOE será capaz de executar aquelas quatro tarefas na tabela contatos, pois herdou as permissões da função SUPERUSUÁRIO (SUPERUSER). Contudo, se NEGAR (DENY) for definido explicitamente contra o usuário JOE na tabela contatos para as quatro ações, JOE não será capaz de executar nenhuma das ações já que NEGAR sempre tem prioridade. As permissões de nível de instrução e de objeto do SQL Server podem ser concedidas diretamente a contas de usuário do banco de dados. Contudo, geralmente é mais fácil administrar permissões a funções do banco de dados. As funções do SQL Server são usadas para conceder e revogar privilégios a grupos de usuários de bancos de dados (muito parecido com o Oracle). Funções são objetos de banco de dados associados com um banco específico, Existem algumas funções de servidor fixas associadas com cada instalação, que se aplicam a todos os bancos de dados. Um exemplo de função de servidor fixa é sysadmin. Grupos do Windows também podem ser adicionados como logins do SQL Server, assim como usuários do banco de dados. Permissões podem ser concedidas a um grupo ou a um usuário do Windows. Um banco de dados pode ter qualquer quantidade de funções ou grupos do Windows. A função padrão pública é sempre encontrada em todos os bancos de dados e não pode ser removida. A função pública opera de maneira muito parecida com a conta PUBLIC no Oracle. Cada usuário do banco de dados pode ser membro de uma variedade de funções além da pública. Um usuário ou grupo do Windows também pode ser membro de várias funções, também está sempre na função pública. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 20

19 Modelo de Segurança do SQL Server Usuários do Banco de Dados e a Conta de convidado No Microsoft SQL Server, um login de usuário deve ser autorizado para usar um banco de dados e seus objetos. Um dos seguintes métodos pode ser usado por uma conta de login para acessar um banco de dados: A conta de login pode ser especificada como um usuário do banco de dados. A conta de login pode usar uma conta de convidado no banco de dados. Um login de grupo do Windows pode ser mapeado para uma função de banco de dados. Contas individuais do Windows que são membros daquele grupo podem então se conectar ao banco de dados. Membros das funções db_owner ou db_accessadmin, ou a função de servidor fixa sysadmin criam as funções de conta de usuário do banco de dados. Uma conta pode incluir vários parâmetros: a ID de login do SQL Server, nome de usuário do banco de dados (opcional), e até um nome opcional de função. O nome de usuário do banco de dados não tem de ser o mesmo da ID de login do usuário. Se um nome de usuário de banco de dados não for fornecido, a ID de login do usuário e o nome de usuário do banco de dados são idênticos. Se um nome de função não for fornecido, o usuário do banco de dados é somente membro da função pública. Depois de criar o usuário do banco de dados, a este podem ser atribuídas tantas funções quantas necessárias. Contudo, é altamente recomendado que aos usuários seja atribuído o número mínimo de funções necessárias para executarem suas tarefas, conforme o princípio de privilégios mínimos para sistemas seguros. Membros das funções db_owner ou db_accessadmin também podem criar uma conta de convidado. A conta de convidado permite que qualquer conta de login do SQL Server válida acesse um banco de dados mesmo sem uma nova conta de usuário do banco de dados. Por padrão, a conta de convidado herda quaisquer privilégios que tenham sido atribuídos à função pública; entretanto, esses privilégios podem ser alterados para serem maiores ou menores que aqueles da função pública. A conta de usuário convidado existe por padrão em todos os bancos de dados mas está desabilitada. Você precisa habilitá-la explicitamente para permitir conexões. Uma conta de usuário ou de grupo do Windows pode receber acesso a um banco de dados, assim como o login do SQL Server pode. Quando um usuário do Windows que é membro de um grupo se conecta ao banco de dados, recebe as permissões atribuídas ao grupo do Windows. Se um membro de mais de um grupo do Windows receber acesso ao banco de dados, terá os direitos combinados de todos os grupos de que participa. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 21

20 Modelo de Segurança do SQL Server A Função sysadmin Membros da função de servidor fixa sysadmin do Microsoft SQL Server têm permissões similares àquelas de um DBA de Oracle. No SQL Server, a conta de login de Modo de Autenticação do SQL Server de SA é membro dessa função por padrão, assim como o são os membros do grupo local de Administradores se o SQL Server estiver instalado em um computador baseado no Windows. Um membro da função sysadmin pode adicionar ou remover usuários e grupos do Windows, assim como logins do SQL Server. Membros dessa função tipicamente têm as seguintes responsabilidades: Instalar o SQL Server. Configura servidores e clientes. Criar bancos de dados.* Estabelecer direitos de login e permissões de usuário.* Transferir dados para dento e para fora de bancos de dados do SQL Server.* Fazer o backup de e restaurar bancos de dados.* Implementar e manter a replicação. Agendar operações autônomas.* Monitorar e ajustar o desempenho do SQL Server.* Diagnosticar problemas no sistema.* As tarefas assinaladas com um asterisco (*) podem ser delegadas a outras funções de segurança ou usuários. Um membro da função de servidor fixa sysadmin pode acessar qualquer banco de dados e todos os objetos (inclusive dados) em uma determinada instância do SQL Server. Como no Oracle, existem vários comandos e procedimentos de sistema que podem ser emitidos somente por membros da função sysadmin. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 22

21 Modelo de Segurança do SQL Server A Função db_owner Embora o banco de dados do Microsoft SQL Server seja similar em uso a um espaço de tabela do Oracle, é administrado de maneira diferente. Cada banco de dados do SQL Server é um domínio administrativo autônomo. A cada banco de dados é atribuído um proprietário de banco de dados (dbo). Esse usuário é sempre membro da função de servidor fixa db_owner. Outros usuários também podem ser membros da função db_owner. Qualquer usuário que seja membro dessa função pode gerenciar as tarefas administrativas relacionadas com seu banco de dados (diferente do Oracle, no qual um DBA gerencia as tarefas administrativas de todos os espaços de tabela). Essas tarefas administrativas incluem: Gerenciar o acesso ao banco de dados. Alterar opções do banco de dados (somente leitura, único usuário, e assim por diante). Fazer backup de e restaurar o conteúdo do banco de dados. Conceder e revogar permissões ao banco de dados. Criar e excluir objetos do banco de dados. Membros da função db_owner têm permissão para fazer qualquer coisa dentro de seu banco de dados. Na maioria, os direitos atribuídos a essa função são separados em várias funções de banco de dados fixas, ou podem ser concedidos a usuários do banco de dados. Não é necessário ter privilégios de sysadmin por todo o servidor para se ter privilégios de db_owner em um banco de dados. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 23

22 Modelo de Segurança do SQL Server Esquemas O SQL Server 2005 suporta um novo recurso chamado esquemas. Um esquema é um conjunto de entidades de banco de dados que formam um único espaço para nome. Um espaço para nome é um conjunto no qual todos os elementos possuem um nome exclusivo. Isso ajuda a criar uma separação lógica entre o usuário da aplicação e os objetos do banco de dados. A separação de usuários do banco de dados dos esquemas oferece vários benefícios a administradores e desenvolvedores como listado abaixo: Vários usuários podem possuir um único esquema através de participação em funções ou em grupos do Windows. Isso estende a funcionalidade familiar, permitindo que funções e grupos possuam objetos. Excluir usuários do banco de dados é bastante simplificado, pois não exige renomear os objetos contidos no esquema daquele usuário. Proprietários de esquema também podem ser alterados sem impacto no código existente da aplicação. Assim, não é mais necessário revisar e testar aplicações que se refiram explicitamente a objetos contidos no esquema depois da exclusão do usuário que os criou. Vários usuários podem compartilhar um único esquema padrão para resolução uniforme de nomes. Esquemas padrão compartilhados permitem aos desenvolvedores armazenar objetos compartilhados em um esquema criado especificamente para uma determinada aplicação, em vez de no esquema do DBO. Permissões em esquemas e objetos contidos em esquemas podem ser gerenciados com um maior grau de granularidade do que em versões anteriores. Esquemas aumentam o nível de granularidade no qual as permissões são gerenciadas. Permissões podem ser concedidas para que um usuário específico gerencie e seja proprietário de objetos dentro de um esquema, em comparação com o banco de dados inteiro. Por exemplo, o Usuário 1 pode receber permissões para modificar os objetos no esquema Vendas dentro de um banco de dados, mas será impedido de modificar objetos no esquema inventário dentro do mesmo banco de dados. Criptografia de Dados O SQL Server 2005 suporta nativamente todos os requisitos de infra-estrutura de criptografia nativamente dentro do banco de dados e é totalmente integrado com uma infra-estrutura principal de gerenciamento. O SQL Server protege os dados com criptografia hierárquica e infra-estrutura chave de gerenciamento. Cada camada protege a camada abaixo, usando uma combinação de certificados, chaves assimétricas ou simétricas. Esse recurso funciona com o Windows Server 2003 ou posterior. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 24

23 Modelo de Segurança do SQL Server Figura 4: Criptografia de dados do SQL Server Cada instância do SQL Server possui uma Chave-Mestra de Serviço, criada automaticamente durante a instalação, que é criptografada com uma API de Proteção a Dados (usando credenciais da conta de serviço do SQL Server) fornecida pelo sistema operacional subjacente do Windows Server Seu propósito principal é proteger os dados do sistema, como senhas usadas em configurações de nível de instância tais como servidores encadeados ou cadeias de conexão. A Chave-Mestra de Serviço também é usada para proteger cada uma das Chaves-Mestras do Banco de Dados (protegidas adicionalmente por uma senha fornecida quando uma Chave-Mestra do Banco de Dados é criada). Dentro de cada banco de dados, sua chave-mestra serve como base para criar certificados ou chaves simétricas, que podem ser aplicadas subseqüentemente para proteger dados diretamente ou para aumentar ainda mais a hierarquia de criptografia (i.e., pela criação de chaves simétricas). A criação, armazenamento, e outras tarefas de gerenciamento de certificados e chaves podem ser manejadas internamente dentro do SQL Server, sem recorrer a recursos do sistema operacional ou de produtos de terceiros. A encriptação e decodificação são fornecidas por pares de funções complementado umas às tais outras como EncryptByCert() e DecryptByCert(). Para mais detalhes sobre criptografia de dados, consulte os Livros Online do SQL Server. SQL Server 2005 para Profissionais de Oracle 2006 Scalability Experts 25