segunda-feira, 18 de julho de 2011

Componente do Disco

Chunks

O servidor não usa o sistema de arquivo do UNIX para fazer a sua administração de espaço em disco, mas apropriadamente, ele utiliza seus próprios mecanismos de gerenciamento do espaço em disco – mecanismos que são bem melhores adaptados à gerencia de banco de dados do que o sistema de arquivo do UNIX.

É necessário construir um espaço disponível para o servidor. Este espaço é associado em unidades chamadas chunks. Um chunk é uma unidade de espaço continuo que é associado ao servidor para seu uso; o servidor administrará o uso do espaço dentro de cada chunk. Um chunk pode ser um raw device do UNIX.

Paginas

Quando um chunk é associado ao servidor, ele será quebrado em pequenas unidades chamadas paginas. A pagina é a unidade básica de I/O de um servidor Informix. Todos os dados em um servidor são guardados em paginas. Por exemplo, se você quiser guardar uma linha de uma tabela do banco de dados, o dado para esta linha deve ser guardado em uma pagina. Quando o dado é lido do disco para um buffer na shared memory, a pagina inteira na qual este dado esta guardado será lida para dentro do buffer. Uma grande quantidade de dados pode ser guarda em uma única pagina.

Page Size

O tamanho de uma pagina usada por um servidor é determinado quando o porte é feito para uma maquina / sistema em particular. O tamanho mais comum de pagina usado é 2 Kbytes, embora alguns sistemas usem um tamanho de 4 Kbytes.

O tamanho da pagina para um servidor não pode ser alterado. Isto é exceto, para blobpages, as quais são atualmente um tamanho logico de paginas ou um numero que representa um múltiplo do tamanho da pagina do servidor.

Tblspaces

Um tblspace é um termo logico usado para referir-se a uma coleção logica de todas as paginas alocadas para uma determinada tabela ou um fragmento de tabela se sua tabela esta fragmentada.

O espaço representando por um tblspace não é necessariamente continuo, aqui pode haver paginas espalhadas por um chunk, ou pode haver paginas de uma tabela em diferentes chunks.

Para tabelas não fragmentadas, um tblspace residira sempre em um dbspace. Se o dbspace tem somente um chunk associado a ele, então todas as paginas de um tblspace residirão sobre este único chunk. Se o dbspace tem vários chunks associados a ele, as paginas de um tblspace podem residir em qualquer dum dos chunks naquele dbspace.

Para tabelas fragmentadas, cada fragmento tem um tablespace id único. Este numero de tablespace é o partnum na systables do catalogo do sistema, e o campo partn em sysframents.

Dbspaces

dbspace

Um dbspace é uma coleção de chunks. Cada dbspace deve ter no mínimo um chunk associado a ele inicialmente; este é conhecido como primary chunk. Dbspaces podem ter tantos chunks associados a ele quanto necessário. Se você esgotar o espaço em um dbspace particular ( em virtude de que todos os chunks associados a ele estão cheios), você pode adicionar chunks extras a ele.

Banco de dados e tabelas pode ser criados em dbspaces separados. Isto significa que aquela tabela ou banco de dados pode crescer tanto quanto o espaço disponível naquele dbspace. Você não pode controlar em quais chunks dentro de um dbspace um banco de dados serão criados em um device físico em especifico, você de associar somente aqueles chunks residentes no device físico ao dbspace.

Root Dbspace

Cada servidor deve ter no mínimo um dbspace; o root dbspace. Este é onde todas as informações importantes do sistema que controlam o servidor estão localizados.

Agrupamento Logico

dbspaces e tblspaces

Podemos pensar em dbspaces e tblspaces como agrupamentos lógicos de espaço físico.

  • Um dbspace é um agrupamento logico de chunks físicos. Os chunks pode estar em diferentes discos, contudo eles são parte de um mesmo dbspace.
  • Um tblspace é um agrupamento logico de extents. Os extents dentro de um tblspace podem estar em chunks diferentes (e, portanto em discos diferentes).

Tipo de Dado Blob

Bynary Large Objects, BLOBs, são conjuntos de bytes de comprimento e valor indeterminado. Um BLOB pode ser uma imagem ou som digitalizado, um modulo de programa ou um contrato legal.

Qualquer coisa que você pode guardar em um arquivo de um computador você pode guardar um um BLOB.

O limite teórico para o tamanho deles é de 2 gigabytes; este tamanho é baseado no maior valor que pode ser armazenado em inteiro de 4-bytes.

Ha dois tipos de BLOBs: TEXT e BYTE. O tipo de dado TEXT é usado para armazenar textos ASCII como memorandos capítulos de manuais e documentos de negócios. O tipo de dado BYTE é usado para arquivar qualquer classe de dado binário, como planilhas, módulos de programas de carga, e imagens e sons digitalizados.

Blobspace

Um blobspace é uma entidade logica que representa uma coleção de espaços físicos na forma de chunks.

Cada blobspace deve ter no mínimo um chink associado a ele; o qual é conhecido como o primary chunk. Blobspaces podem ter tantos chunks associados a ele quanto for necessário.

Colunas BYTE e TEXT podem ser colocadas em blobspace separados. Isto significa que os dados destas colunas blob serão guardados naquele blobspace. Você não pode controlar em qual chunk, dentro de um blobspace o dado blob será guardado. Um servidor pode ter tantos blobspaces quanto queria. Qualquer blobspace pode conter dados blob de diferentes colunas de diferentes tabelas, mesmo de diferentes banco de dados. O blobspace forma um conjunto de espaço de armazenamento que pode ser usado por qualquer coluna blob no servidor.

Todos os arquivos de blobs em um único blobspace, mesmo que estes estejam em tabelas diferentes , usarão o mesmo tamanho de blobpage. Cada blobspace arquiva um dado blob usando o mesmo tamanho de blobpage. Você pode ter vários blobspaces, e cada blobspace pode ter um diferente tamanho de blobpage do que os outros.

 

Mirroring (Espelhamento)

Mirroring é um processo de replicação de dados automático. O servidor permite a escolha de Mirroring ao nível de dbspaces ou blobspaces. Em casos quando há requerimentos para segurança e disponibilidade, o disco mirroring é um dos vários aspectos para escolher. Sem o disco mirroring, o retorno de uma queda de um disco geraria:

  • Torna o dado indisponível para o usuário.
  • Substituição do hardware que teve a falha.
  • Restauração de fitas de backup.
  • Rollback de alguns logs de transação.

Com o disco mirroring, a recuperação pode ser completada sem nenhuma interrupção para a disposição de dados.

A escolha para o mirror de disco é feita quando o servidor esta sendo inicializado (initialize). Apesar disso, mirror de dbspaces ou blobspaces individuais, pode ser feito a qualquer momento.

Quanto um dbspaces ou blobspace é espelhado, ambos, primary chunk e mirror chunk são especificados nas criações do espaço ou sempre que um novo chunk precisar ser adicionado. As escritas feitas para o primary chunk e para o mirror chunk são assíncronas. As leituras são separadas entre o primary e o mirror chunk para o aumento de performance.

Logical Logs

Dentro dos limites de um servidor,  uma certa quantidade do espaço do disco será reservada para o logical logs.

O logical logs são coleções de paginas continuas de um disco que são usadas para registrar transações arquivadas para o servidor. Estas transações registradas são usadas para mapear todas as mudanças que são feitas no database server. Toda mudança no banco esta registrada no logical log. Cada servidor deve ter no mínimo três logical logs.

Physical Log

O servidor tem um log especial que é usado para propósitos de recuperação automática. Este log é chamado de physical log. O physical log é uma coleção de paginas continuas sobre o disco.

Quando uma pagina tem que ser lida dentro de um shared memory buffer, e um usuário quer modificar dados naquela pagina, antes que a mudança seja feita, uma copia da pagina em sua forma original é gravada no physical log. Esta copia de pagina é conhecida como before image. Somente a primeira mudança para uma pagina em um buffer ocasionará um before image para ser gravada no physical log. Outras mudanças subsequentes para aquela mesma pagina não causarão before images adicionais para serem escritas no physical log. Estas before images serão usados por um mecanismo automático de recuperação.

Nenhum comentário:

Postar um comentário