Administração de Banco de Dados Informix

Nome: Luana Baptista Vieira da Silva RA: 610201693

Luciana Cristina Gagliardi 610200351
Ricardo Benatti Busato 610201348
Rodrigo Zoilo de Oliveira 610201702
Pós-Graduação: Gerenciamento de Banco de Dados
Disciplina: Instalação de Banco de Dados em Sistemas Operacionais
Prof.: José de Jesús Pérez Alcázar
Arquitetura do Informix
O servidor é composto por três grandes componentes. Os componentes são introduzidos
nas páginas seguintes e discutidos em detalhes nos capítulos posteriores.

O Componente Processo

O componente Processo define o servidor de banco de dados. Os processos que

definem o servidor de banco de dados são conhecidos como virtual processors. Ao
nível do UNIX esses processos são chamados oninit. Cada virtual processor (VP)
pertence a uma classe de virtual processor. Uma classe de VP é um conjunto de
processos responsáveis por um conjunto específico de tarefas.

O Componente Shared Memory

O segundo componente é a shared memory. A shared memory é feita de três porções:

residente, virtual e de mensagem. Este é usado para:

Cópia dos dados em disco em shared memory para acesso mais rápido (porção
residente).

Manutenção e controle dos recursos solicitados pelos processos (porção virtual).

Um mecanismo de comunicação para os processos cliente e servidor falarem entre si
para coordenar suas atividades. (porção mensagem).

O Componente Disco

Seguindo, há o componente disco. Esta é uma coleção de uma ou mais unidades de

espaço em disco designado para o sistema do servidor. Todos os dados nos bancos de
dados, além de toda a informação do sistema necessária para manter o servidor, são
armazenados dentro do componente disco.
A shared memory no servidor é dividida em três porções. Cada uma destas porções é
listada abaixo e explicada em maiores detalhes nos capítulos posteriores.

Os Componentes da Shared Memory

A porção resident - a porção resident contém o buffer pool e outras informações do

sistema. Esta parte da shared memory pode ser configurada para permanecer
residente na memória principal (se esta capacidade é suportada pelo sistema
operacional).

A porção virtual - a porção virtual contém informações sobre as threads e sessões, e
os dados que são usados por elas. Estas informações crescem e diminuem
constantemente, sendo que o servidor de banco de dados é responsável pelo
controle de alocação e liberação de memória nesta porção.

A porção message – a porção message armazena os message buffers que são usados
na comunicação entre o cliente e o servidor quando o método de comunicação é
feito através da shared memory.

2
Physical Log

Outra parte importante da porção resident da shared memory é usada para log buffers. O
physical log é um log especial usado para mecanismos de tolerância a falhas do
servidor. Ele contém before images (apenas a primeira cópia) de dados e páginas de
índices que estão no buffer pool e estão sendo modificadas desde o momento que elas
foram lidas do disco.
De forma a reduzir a quantidade de I/O físico associado com a manutenção deste log, os
buffers são usados na gravação do log; ao invés de gravar cada entrada diretamente no
disco, as entradas são gravadas em um buffer, o qual é transferido para disco mais tarde.
Como o servidor tem o controle sobre quando estes buffers são transferidos para disco,
ele pode garantir que eles serão transferidos quando necessário.

Logical Log

O logical log é um log, ou atualmente uma coleção de logs, em disco que recebe as
entradas DML (Insert, Update, Delete) de banco de dados com log, assim como DDL
para todas as tabelas. Com servidores Informix, o mesmo grupo de logs é
compartilhado por todos os bancos de dados. Transações de diferentes bancos de dados
são intercaladas no interior dos logs de transação.
Como a quantidade de dados gravados nestes logs pode ser grande, para ajudar a reduzir
a quantidade de I/O físico necessário para gravar os dados no disco, o dado é primeiro
colocado em um buffer, o qual será transferido para disco mais tarde. O servidor aloca
três buffers, para uso com os logical logs

Virtual Portion

A virtual portion pode crescer:

Por causa da natureza das informações armazenadas na porção virtual da shared
memory, a quantidade de shared memory usada pelo servidor varia dependendo da
atividade. Em momentos de grande atividade, mais shared memory pools são criados, e
os pools existentes podem ser expandidos. Se mais espaço for necessário para a porção
virtual, segmentos adicionais de shared memory são acrescentados automaticamente.
Uma vez que os segmentos de shared memory são alocados para o servidor, eles
somente podem ser liberados pelo administrador executando o utilitário onmode ou
mudando o servidor para o modo off-line.

Discos

Você pode pensar em dbspaces e tblspaces como agrupamentos lógicos de espaço

físico.

Um dbspace é um agrupamento lógico de chunks físicos. Os chunks podem estar em
diferentes discos, contudo eles são parte de um mesmo dbspace.

Um tblspace é um agrupamento lógico de extents. Os extents dentro de um tblspace
podem estar em chunks diferentes (e, portanto em discos diferentes).

3
Data Caching

Quando uma database server quer acessar alguma data, ela deve achar a page onde
aquela data está alocada.Uma vez que a page está sendo situada, aquela page é lida do
disco dentro de um dos buffers no shared memory buffer pool. Uma vez que esta page
está no buffer pool, nenhum outro usuário que queira ler a data naquela page pode fazê-
lo desta forma sem ter que re lê-lo do disco; as pages no shared memory buffer pool são
divididas por todo o server processes.
A leitura de pages do disco dentro do shared memory buffers é conhecida como data
caching. Se a data na page é modificada por um servidor (durante um INSERT,
DELETE, ou UPDADE, por exemplo), ela é modificada diretamente no buffer. Isto
quer dizer que todo server process terá acesso imediato para a data modificada.Os
buffers modificados em shared memory serão copiados de volta para o disco mais tarde.

Checkpoint

Como pages são lidas dos discos dentro de shared memory buffers e então modificadas
nestes buffeus, as pages dos discos e as cópias destas pages no shared memory buffers
tornam-se fora do sync. É necessário, nesta ocasião, para ressincronizar estes dois de
modo que eles estejam iguais. Esta ressincronização é executada por um eventual
sistema conhecido como um checkpoint. Durante um checkpoint, todas as pages no
shared memory buffers tem que ser modificadas e copiadas de volta para o disco. Este
trabalho é executado por um dos virtuais processors. Quando o checkpoint está
terminado, todas as pages no shared memory buffers estão novamente iguais como as
pages do disco.

Point of Recovery

Estes checkpoints equilibram todo o servidor como um recovery point. Se o sistema

poderia arruinar-se, nenhuma troca feita pela pages em shared memory está refletida na
situação destas pages no disco. Não sabemos, de qualquer modo, que somente aquelas
trocas feitas deste o último checkpoint não estão refletidas no disco. O automatic
recovery mechanisms do servidor protege recuperando estas trocas feitas desde o ultimo
checkpoint.

4
Gerenciamento de Modos
O server tem as seguintes operações de modes:
Off-Line mode É quando o server não está pesquisando o todo. Nenhum shared
memory está alocado.
Initialization mode É um mode interino que ocorre quando o server é inicializado e
movendo do mode Off-Line para mode Quiescent
Quiescent mode É quando os processos oninit estão pesquisando, recursos shared
memory são alocados, mas o sistema não segue acesso de uso
database. Somente o administrador (login informix) pode acessar
o server.
On-Line mode É quando o sistema está em movimento e pesquisando e
disponível para usos database para acessar. Este é o normal mode
de operação do server.
Shutdown mode É quando o sistema está em movimento e pesquisando, e os
fluxos de uso estão acessando o sistema, mas nenhum novo uso
está seguindo-os.
Recovery mode É quando o sistema está executando Fast Recovery, ou
recuperando de um sistema archive (recolocação). Fast Recovery
ocorre durante a troca do Off-Line para Quiescent mode. O
procedimento de recolocação levará algum tempo, dependendo do
tamanho do sistema a ser recolocado.

Alterando o Modo do Servidor

ONINIT

A utilidade oninit deve ser usada para trocar as operações modes do server de seu
sistema linha de comando. Os argumentos para utilidade oninit são:
Sem argumentos Traz o server do Off-Line para On-Line mode
-s Traz o server do Off-Line para Quiescent mode
-i Inicializa o root dbspace
-p Não procura para e deleta tables temporariamente durante a
inicialização shared memory
-y Automaticamente responde yes para alguns alertas.
Geralmente, o argumento -i deveria ser usado somente ao primeiro tempo que você
constrói seu exemplo. Ele é documentado aqui deste modo para você poder estar atento
de seus perigos.

Se você quer que o server seja trazido on-line quando sua máquina é rebooted, coloque
o comando oninit, com nenhum argumento, em seu sistema starup file (/etc/rc sob
muitas maquinas UNIX).

ONMODE

A utilidade onmode deve ser usada para trocar as operações de mode do server das
linhas de comando do sistema. Os argumentos disponíveis para trocar o server modes
via a utilidade onmode são:
-k Executa um Immediate-Shutdown e traz o sistema do
Quiescent para o Off-Line mode.

5
-m Traz o sistema de Quiescent para On-Line mode
-s Executa um Graceful-Shutdown
-u Executa um Immediate-Shutdown
-y Automaticamente responde sim para alguns alertas. Deve ser
usado em combinação com outra opção.
Há muitos argumentos para a utilidade onmode que não estão relatados para a operação
mode. Esses argumentos serão cobertos em capítulos mais tarde.

Utilitário de Monitoração

Há várias utilidades para monitorar o server ativamente.

O System Monitoring Interface (SMI)

A utilidade onstat

A utilidade oncheck
Muitas das opções são usadas para debugging somente pelo suporte técnico Informix
As opções que podem ser usadas por monitoramento e propósitos sintonizando são
detalhados nos capítulos seguintes.

ONSTAT

A utilidade onstat lerá a estrutura server shared memory e reportará o conteúdo de

shared memory no instante que ele é pesquisado. Isto significa que o conteúdo do
shared memory pode estar trocando como eles estão sendo impressos (como nenhuma
memória olhando é feita de onstat).
A utilidade onstat imprime os conteúdos de várias tabelas internas. (ou data estruturas)
mantidos em shared memory. Ele não imprime os conteúdos do buffer pool. Desde que
essas tabelas mantém impressões de toda atividade no server, este tributo dá uma boa
pintura do que está indo sob o sistema ao tempo que ele é pesquisado.
Geralmente, onstat não faz disk I/O; ele lê do shared memory sozinho (há umas poucas
opções que lerão do arquivo disco). Porque ele coloca nenhum cadeado nos recursos
shared memory, ele não impacta a execução do server.

ONCHECK

A utilidade oncheck é usada para reparo index e data page corrupção sob o disco. Ela
pode também ser usada para examinar outras datas estruturas sob o disco no server. Ela
também tem a funcionalidade para seguir você para imprimir relatório contendo
informações sobre várias datas estruturas sob disco e seus usos.
A utilidade oncheck pode somente trabalhar no mesmo computador como o server ela
está checando; ela não suporta network ou operações distribuídas.
Alguns comandos oncheck (-pt ou –pT) coloca uma shared lock sob a tabela ele está
processando. Esta prevenirá outros usuários de updating a tabela. Para muitas tabelas
grandes, examinando cada data e index page poderia levar um longo tempo.

As Opções -c e -p

A sintaxe e opções para a utilidade oncheck são mostradas nas páginas seguintes.
Atenção que há duas opções primárias, -c e –p, e que essas opções primárias têm elas
próprias sub-opções. As -c opções indica que certas coisas deveriam ser checadas. As
opções –p indicam que certas coisas deveriam ser checadas e imprimidas para a tela.

6
O Processo de BACKUP e RESTORE
O server oferta três utilidades para executar archiving, logical log backup e restore
activities. Você deveria escolher qual utilidade é melhor para você e usá-la
exclusivamente.
A utilidade ontape é uma utilidade simples que oferta básico archive, log backup e
restore capability. Ele tem um comando linha interface somente. Ontape deve ser
executado pelo informix login.
A utilidade On-Archive oferta a completo tape-management system tão bem como
extra segurança e opções de reabilitação. Por causa de extras aspectos, ON-Archive
requer uma grande quantidade maior preparação pre-archiving do que uma utilidade
ontape.
A utilidade ON-Bar foi introduzida com IDS 7.21. ON-Bar trabalha em conjunção com
um armazém administrador e pode, por essa razão, suportar todos os artifícios que o
administrador armazém suporta. Em adição para aspectos abasteceu de On-Archive,
ON-Bar inabilita você para recolocar um exemplo para um específico poin-in-time.
Indiferente da utilidade selecionada, o administrador backup e recoloca processos é o
mesmo para todas três utilidades. Neste módulo, nós examinaremos o processo de
archiving e recolocação de um exemplo Informix Dynamic Server.
As três utilidades são mutuamente exclusivas. Um archive feito por uma utilidade não
pode ser recolocado usando outras utilidades.

O Que é Um Archive?

Um archive ou backup é o processo copiando cada todo ou algum subset do server

dbspaces, blobspaces, e arquivos logical logs para um secundário armazém de locação,
também disco,tape, ou optical artifício. O backup process assegura que uma consistente
imagem de data é criada igual enquanto o sistema está em uma on-line, multi-user mode
recebendo ongoing transações.
Dependendo upon o archiving utilidade selecionada, você deve estar apto para backup
um avulso objeto, múltiplos objetos, ou o conjunto exemplo. A capacidade para backup
individual dbspaces ou grupos de dbspaces segue máxima flexibilidade para encontrar
reclamação de negócios. Desde que dbspaces pode conter múltiplas databases, uma
avulsa database, uma avulsa tabela, ou igual uma avulsa divisão de uma tabela, dbspace
backups abastece igual e melhor do que tabela level granulariry para backups e
recolocações.
Com a introdução de ON-Bar in IDS 7.21, nova terminologia foi introduzida. O termo
storage space refere para algum disco espaço que é usado para guardar IDS data, se ele
é um dbspace ou blobspace. Em adição, a palavra archive e backup, quando referindo
para espaços armazém, são sinônimos. Neste módulo, nós usaremos o termo archive
quando referindo para o archive de dbspaces e blobspaces. Nós usaremos o termo
backup para referir para o backing up de logical logs.

Archives Incrementais

O server abastece três diferentes levels de archiving ou backing up data: eles são
encaminhados para como level-0, level-1 e level-2 archives.

7
Level –0
Uma level-0 archive contem uma cópia de toda data no server system ou especificado
dbspace(s) no estado em qual ele existiu ao tempo do archive estava iniciado. Um level-
0 está no baseline archive.
Se discos e outras médias estão completamente destruídos e precisa ser realocada, você
precisa de um archive level-0 de todos os espaços armazem e relevante logical log para
recolocar data completamente.
Level-1
Um archive level-1 contem uma cópia de todas as datas no server system ou especificar
dbspace(s) que tem trocado desde o último level-0 archive,no estado no qual ele existiu
ao tempo que o archive era iniciado.
Level-2
Um archive level-2 contem uma cópia de toda data no server system que tem trocado
desde o ultimo level-1 ou level-0 archive, qualquer que ocorreu mais recentemente, no
estado em qual ele existiu ao tempo que o archive era iniciado.

O Que é Um Backup de Logical Logs?

Um logical log backup é um processo copiando os contentos de um arquivo logical log

para secundário médio armazém. O logical logs guarda gravações de checkpoint,
administrativas atividades assim como requerimentos DDL, e atividades de transações
para o database no server exemplo. Cada server exemplo tem um finito número de
logical logs. O server usa o logical logs em um método circular. Gravações são escritas
para o arquivo logical log seriamente. Quando o primeiro log enche-se, o server começa
escrevendo para o segundo log, e assim por diante. Quando todos os logs tiverem sido
usados, o server começará escrevendo para o primeiro log novamente. Antes do server
poder reusar um log, ele deve ser backed up.
Igual se nenhum dos databases no server exemplo usa transações logging, o logical logs
deveria ser backed up.

Como Executar o Backup de Logical Log

Há dois métodos que você pode usar para back up seu logical logs. Você pode
explicitamente iniciar um logical log backup, ou você pode usar contínuos logical log
backups:

Um automatic ou on-demand backup é explicitamente iniciado, e backs up todos
lotados logical logs e então parar o processo sob o corrente log. Se você escolheu
para usar este método ele é grandemente recomendado para executar frequente
logical log backups.

Um contínuo backup é melhor adaptado quando você tem separada gravação
artifício para seu archive e logical log backups. Neste cenário, uma gravação
artifício pode ser dedicada para executar contínuos logical logs backups. Com este
método, o logical log é backed up tão logo quanto ele tornar-se cheio.
Recolocando muitas gravações logical log é lento comparado para recolocando pages de
um archive. Você quer minimizar o número de log gravações necessárias para roll
desenvolver durante uma recolocação de executando frequente archives de seu
dbspaces.

8
Restauração Física e Lógica

O restore process é dividido dentro de dois componentes: o physical restore e o logical

restore. O physical restore é o processo de recolocamento do dbspace e blospace
archived com um level-0, level-1 e level-2 archive. O logical restore é o processo de
recolocamento do server system para o tempo de falha usando transações achadas sob
fitas de logical log backup. O logical restore ocorre depois do physical restore.

Restauração Cold e Warm Restore

O restore process é dividido dentro de dois componentes: o physical restore e o logical

restore.
O physical restore é o processo de recolocamento do dbspace e blospace archived com
um level-0, level-1 e level-2 archive.
O logical restore é o processo de recolocamento do server system para o tempo de falha
usando transações achadas sob fitas de logical log backup. O logical restore ocorre
depois do physical restore.

9
Replicação
High Availability Data Replication (HDR)

Em versões anteriores a versão IDS 7, Informix adaptou a tecnologia HDR, a qual é

totalmente integrada dentro do servidor de banco de dados. HSR é muito fácil
configurar e administrar e não requer qualquer hardware ou software adicional para
automaticamente se proteger de falhas no servidor ou disco. HDR mantém duas
instancias similares nos servidores. Se o servidor primário sofre algum problema de
crash tonando-o indisponível, o servidor secundário se torna primário. O servidor
secundário suporta acesso de leitura nos dados, permitindo os administradores de B.D
realizar um balanceamento da carga de trabalho.

Enterprise Replication (ER)

Enterprise Replication (ER) prove replicação dos dados através de múltiplos servidores
Informix independente. ER pode também ser usado para replicar tabelas
individualmente ou subconjuntos de tabelas. É diferente do HDR, desde que o HDR
requer uma replica dos dados – incluindo tabelas e schemas de banco de dados. ER é
designada para suportar múltiplos servidores com topologia complexa.

10
Remote Standalone Secondary (RSS) Servers

O Remote Standalone Secondary servers estende o HDR permitindo múltiplas cópias do

banco de dados em ambos locais remotos e local. Os servidores secundários, tal como
HDR, pode ser acessada pelo client das aplicações. Os logical logs são transmitidos
continuamente do servidor primário e aplicados para o banco de dados no servidor RSS.

Shared Disk Secondary (SDS) Servers

SDS servers acessa o mesmo disco físico como servidor primário. Eles provem o
aumento da disponibilidade e escalabilidade sem a necessidade para manter múltiplas
copias do banco de dados.

11