Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo SQL Magazine 62 - Fragmentação no SQL Server 2005
Artigo publicado Revista SQL Magazine 62.
SQL Server
Fragmentação no SQL Server 2005 – Parte 1
Este artigo apresenta um pequeno projeto de distribuição de dados envolvendo as unidades de uma instituição de ensino. O foco da distribuição se refere ao cadastramento de inscrições para o vestibular, onde os candidatos se inscrevem para o vestibular de uma determinada localidade (por meio de um site localizado no servidor da FATEC Indaiatuba) e o sistema armazena os dados da inscrição na instância do SQL Server correspondente, isto é, quando um candidato se inscreve para o vestibular da FATEC Indaiatuba, os dados serão armazenados no servidor local. De outra forma, quando um candidato se inscreve para o vestibular da FATEC Sorocaba (usando o mesmo site da FATEC Indaiatuba), os dados serão armazenados no servidor localizado na cidade de Sorocaba e assim por diante.
Para esse sistema, simulamos em laboratório sete unidades da FATEC, ou seja, o sistema reconhece sete instâncias diferentes do SGBD (SQL Server 2005) como se estivessem dispersos por diversas cidades do estado de São Paulo. O artigo está dividido em duas partes: a primeira apresenta alguns conceitos de distribuição e os scripts usados na elaboração do projeto; a segunda apresenta um roteiro para a elaboração de um software, codificado em Java, que acessa o sistema distribuído. A Figura 1 ilustra o projeto de distribuição entre as instâncias do SQL Server.
Em nosso projeto, a distribuição dos dados será realizada por meio da fragmentação. A fragmentação é um processo de criar fragmentos (pedaços) de uma tabela. Em outras palavras, uma mesma tabela é dividida em fragmentos e cada fragmento pode ser armazenado em um local diferente. Na verdade, a mesma tabela é criada nas diferentes instâncias do SGBD e cada tabela mantém uma parte dos dados, ou seja, a união dos dados presentes em cada uma das instâncias irá compor o conjunto total dos dados. Para o SGBD, não existe diferença entre uma tabela e um fragmento, já que o fragmento é a própria tabela. Como veremos ao longo deste artigo, a fragmentação utilizada nesse artigo foi a horizontal, ou seja, cada fragmento representa um conjunto de registros da tabela.
Figura 1. Distribuição entre as instâncias do SQL Server
Definição de Banco de Dados Distribuídos
Banco de Dados Distribuídos (BDD) se refere a uma coleção de vários bancos de dados logicamente inter-relacionados e distribuídos por uma rede de computadores. Existem dois tipos de BDD, os homogêneos e os heterogêneos. Os homogêneos são compostos por apenas um tipo de Sistema Gerenciador de Banco de Dados (SGBD), por exemplo, vários servidores SQL Server. Esse artigo apresenta um exemplo de sistema distribuído homogêneo, pois no caso todas as instâncias serão do SQL Server 2005. Os heterogêneos são compostos por mais de um tipo de SGBD, ou seja, em um mesmo ambiente distribuído pelo menos um dos SGBDs é diferente em relação aos demais. Os SGBDs que suportam distribuição são conhecidos como SGBDD (Sistema Gerenciador de Banco de Dados Distribuídos). O próximo tópico apresenta algumas características dos SGBDDs.
Principais características de um SGBDD
De acordo com Date (2004), um SGBDD deve conter diversas características para ser considerado como tal. Os itens seguintes abordam essas características de forma resumida.
1. Autonomia local: cada nó participante de um sistema distribuído (cada SGBDD) deve ser independente dos outros nós e prover mecanismos de segurança, bloqueio, acesso, integridade e recuperação após falha;
2. Independência de um nó central: um SGBDD não deve depender de um nó central. Se a dependência ocorrer, o sistema fica menos robusto, já que possui um único ponto de falha. Isso afetaria todos os outros nós. Um nó central pode acarretar perda de desempenho do sistema, já que tende a ficar muito “carregado”;
3. Operação contínua: um sistema distribuído não deve necessitar desativação. As operações de backup e a recuperação devem ter suporte on-line. As operações devem ser rápidas o bastante para não afetarem o funcionamento do sistema (backup incremental, por exemplo);
4. Transparência e independência de localidade: os usuários do sistema não precisam ter ciência do local onde os dados estão armazenados. Para o usuário, os dados devem ser vistos como se fossem locais.
5. Independência de fragmentação: as tabelas do sistema de banco de dados distribuído podem estar fragmentadas e localizadas fisicamente em diferentes nós, de forma transparente para o usuário. Usuários e aplicações não devem saber que as tabelas estão armazenadas em nó diferente do nó onde são feitas as operações. A fragmentação pode ser horizontal (fragmentação em linhas) ou vertical (fragmentação em colunas). Maiores detalhes serão apresentados na continuidade deste artigo;
6. Independência de replicação: dados replicados em vários nós da rede, de forma transparente. Assim como nas regras de independência de localização e fragmentação, a independência de replicação é projetada para livrar os usuários de preocupações relacionados com o local onde os dados estão armazenados. No caso da replicação, os usuários e as aplicações não precisam saber que réplicas de dados são mantidas e sincronizadas automaticamente pelo SGBDD;
7. Processamento de consultas distribuído: o desempenho de uma consulta deve ser independente do local onde a mesma é executada. O SGBDD deve possuir um otimizador que possa selecionar não apenas o melhor caminho para o acesso a um determinado nó da rede, mas também otimizar o desempenho de uma consulta distribuída, levando em conta a localização dos dados, utilização de CPU e I/O e ainda o tráfego da rede;
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Sérgio Furgeri
Possui graduação em Análise de Sistemas pela Universidade Metodista de Piracicaba (1991) e dois mestrados: Ciência da Informação pela Pontifícia Universidade Católica de Campinas (2006) e em Gerenciamento de Sistemas de Informação pela Pontifícia Universidade Católica de Campinas (1999). Atualmente ...
