terça-feira, 29 de setembro de 2009

O que é Logical Log ?

A ideia do Logical Log é manter um historico das operações e alterações dos dados do servidor desde o tempo de armazenamento da ultima copia de segurança do dbspace, então o servidor de banco de dados gera registros de logs. O Banco de Dados armazena os registros de log no Logical Log, um arquivo circular que é composto de tres ou mais arquivos logicos de log. Chama-se Logical Log, porque os registros de log representa operações logicas do servidor de banco de dados, ao contrario das operações fisicas. A qualquer momento, a combinação de um backup de uma dbspace e os backup de logical log contem uma copia completa do seu servidor de banco de dados.
Como Administrador do banco de dados, voce deve configurar e gerenciar os logical logs. Por exemplo, se voce não fizer os backups de logical logs regularmente, os logical logs serão preenchidos e o servidor de banco de dados suspendera os processos.

Estas responsabilidades incluem as seguintes tarefas:
  • Escolher um local apropriado para os logical logs;
  • Acompanhamento do status dos arquivos de logical logs;
  • Atribuir um espaço de armazenamento adequado em disco para o logical logs;
  • Alocação de arquivos de logs adicionais, sempre que necessarios;
  • Backup dos logical logs para uma midia;
  • Gerenciamento dos logging de blobspace e sbspace;
Localização dos Arquivos de Logical-Log
Quando o servidor de banco de dados inicializa os "disk space", ele coloca os logical logs e os physical-logs no root dbspace. Voce não tem controle sobre esta ação. Para melhorar o desempenho (especificamente, para reduzir os numeros de gravações no root dbspace e minimizar a contenção) , mover os arquivos de Logical-Logs para fora do root dbspace para um dbspace em um disco ou uma outra partição que não seja compartilhada com tabelas ativas ou o physical logs.
Para melhorar o desempenho ainda mais, separe os arquivos de Logical-Logs em dois grupos e armazena-los em dois discos separados. Por exemplo, se voce possui seis arquivos logical-logs voce pode locar os arquivos 1, 3 e 5 no disco 1 e os arquivos 2, 4 e 6 no disco 2. Esta disposição melhora o desempenho porque nunca a mesma unidade de disco tem que lidar com gravações do logical log atual, ou seja ha um balanceamento de I/O em disco.

Os arquivos de Logical-Logs contem informações criticas e deve ser espelhado para o maximo de proteção dos dados. Se voce mover os arquivos de Logical-Logs para um dbspace diferente, planeje para iniciar um espelhamento desse dbspace.

Idendificação dos Logical-Logs
Cada arquivo de Logical-Log, se backupeado para uma midia ou não, tem um numero de identificação exclusivo (unique ID). A sequencia começa com 1 para o primeiro Logical-Log preenchida apos a inicialização do dbspace . Quando o arquivo de Logical-Log atual torna-se completa (100%) o servidor de banco de dados muda-se para o proximo arquivo de Logical-Log e incrementa um numero de ID unico para o novo arquivo de Log + 1. Arquivos de Logs que foram recentementes adicionados ou marcados para exclusão tem o numero de ID unico de 0.

O atual espaço em disco alocado para cada arquivo de registro logico tem um numero de identificação conhecido como o numero de arquivo de Log. Por exemplo, se voce configura seis arquivos de Logical-Logs, esses arquivos leva um numero de registro de um a seis. Os numeros de registros podem estar fora de sequencia. Como os Logical-Logs são backapeados e liberados, o servidor de banco de dados reutiliza esses espaços.

Flags de Status do Logical-Log
Todos os arquivos  de Logical-Log possuem uma flag de status na primeira posição:
Added (A), Deleted (D), Free (F), ou Used (U). Abaixo possiveis combinações dos Flags:

A - - - - - -  > Arquivo de Log foi adicionado, e esta disponivel, mas ainda não foi utilizado;
D - - - - - -  > Se voce eliminou um arquivo de Log com as flags U-B, ele sera marcado como deletado. Esse arquivo de Log é eliminado e seu espaço e liberado para reutilização quando voce rodar um backup de nivel-0 de todos os dbspace.
F - - - - - -  > Arquivo de Log esta livre e disponivel para uso;
O arquivo de Log livre é liberado imediatamente após o backup de nivel-0, todas as transações dos Logical-Logs são fechadas e as atualizações mais antigas são carregadas em disco.
U - - - - - -  > Arquivo de Log foi usado mas não backepeado;
U-B - - - -  > Arquivo de Log foi backepeado mas ainda necessario em caso de restore. ( Arquivos de Logs são liberados quando não é mais necessario para recuperação.)
U-B- - - L  > Arquivo de Log foi usado mas ainda necessario em caso de restore. Contem o ultimo registro de CheckPoint;
U - - -C- -  > O servidor de Banco de Dados esta enchendo o arquivo de Log;
U - - -C-L  > Arquivo de Log atual contem o ultimo registro de checkpoint;


Tamanho do Logical-Log
Decidir a quantidade de arquivos de Logical-logs e tamanho que voce quer. Se voce alocar espaço em disco mais do que o necessario, o espaço é desperdiçado. Se voce não atribuir espaço em disco suficiente, o desempenho pode ser afetado.  Considere os seguintes pontos sobre o tamanho e o numero de arquivos de Logical-logs:
  • O tamanho minino para um arquivo de Logical Logs é de 200 kilobytes;
  • O tamanho maximo para paginas de Logical Logs é de 1048576 paginas (equivalente a 0x100000).
  • Arquivos de logs menores significa que voce pode levar mais tempo de recuperação em caso de um recover se os discos que contenham os logs cair. Se o Continuous Log Backup é definido, os arquivos de Logs são automaticamentes copiados assim que cheios.
  • Use arquivos de Logs maiores quando muitos usuarios estão escrevendo nos logs ao mesmo tempo.
Numeros de Arquivos de Logical-Logs
Quando voce pensar em numeros de Arquivos de Logical-Logs considere os pontos abaixo:
  • Voce sempre deve ter no minino 3 arquivos de Logs e no maximo 32767. O numero de arquivos de Logs depende do tamanho desses logs.
  • O Numero de arquivos de logs afeta a frequencia dos backups desses logs;
  • O numero de arquivos de logs afeta a taxa de recuperação de arquivos em Blobspace e blobpages;

segunda-feira, 28 de setembro de 2009

O utilitário Ontape

O utilitário ontape tem muitas características que facilitam o archive de seu sistema, o backup de seu logical log e restore. O ontape fornece as seguintes características:
  • Archive do sistema, de modo que no evento de uma falha, você possa recriar o sistema a partir dos archives.
  • Archives incrementais, para fornecer um ambiente de archive flexível para planejar um archive schedule (programado) que satisfaça a necessidade de seu sistema.
  • Definição de dispositivos de fitas separados, assim você pode executar backups de logical logs sem competir com o archive.
  • Opção de backup continuo de logical logs, que possibilita executar o backup de logical logs assim que eles tiverem cheios.
  • Restaura o sistema ao nível de dbspace.
Opções do Ontape:
Existem quatro opções primarias no ontape. Elas incluem:
  • A opção -s para executar um archive
  • A opção -r para executar um restore
  • A opção -a para executar um backup dos logical logs
  • A opção -c para executar backup continuo dos logical logs
As opções -l e -p são usadas somente para replicação de dados. Essas opções executam operações separadas de physical restore e logical restore que são requeridas quando estiver recriando o segundo servidor na replicação de dados.
As opções -A, -B, -N e -U podem ser usadas para trocar o modo de logging do banco de dados.

Dados do Archive
Com o ontape, os dados são copiados da seguinte forma:
  1. Primeiro, o servidor envia uma pagina de controle que contem a lista dos dbspaces incluídos no archive, o nível do archive, o timestamp do archive, e informação do logging.
  2. Próximo, as system reserved pages do root dbspace são enviadas para o archive.
  3. Se o archive for de nível 0, então a seção que contem informações sob os logical logs que contem transações abertas no momento do checkpoint do archive é enviada para o archive.
  4. Se seu sistema contem blobspaces, eles serão os próximos a serem copiados.
    Se existem paginas de before-image do physical log nas tabelas temporárias, elas são anexadas. Cada seção blobspace tem uma fita de controle de pagina que contem um mapeamento dos chunks dentro do blobspace sendo copiado. A alocação de Blobpage é suspensa no inicio do archive ate o blobspace ser copiado. Somente a porção utilizada da blobpage é copiada, não a pagina inteira.
  5. Finalmente, os dbspaces são copiados em uma ordem particular. Se há paginas de before-image do physical log nas tabelas temporárias, elas são anexadas.
    Cada seção dbspace tem uma fita de controle de pagina que contem um mapeamento dos chunks dentro do blobspace sendo copiado. Paginas não ocupadas no momento do checkpoint do archive, não são copiadas.
  6. Quando a ultima pagina do ultimo chunk é escrita, uma trailer page é fixada marcando o final do archive.
Realizando um Archive
Para usar o ontape, você deve ser o usuário informix.
Para executar um archive, execute ontape -s. Este comando executara um archive completo do sistema de todos os dbspaces. O Servidor inicia um dialogo requisitando que você coloque uma fita no dispositivo de fita, e o dispositivo deve estar on-line antes de você apertar enter (você será questionado novamente se o servidor não conseguir abrir o dispositivo especificado)

Realizando um Backup de Log
Você pode usar a opção -a do ontape para executar periodicamente backups dos logical logs para a fita; ou você pode usar a opção -c para executar um backup de cada logical log assim que ele estiver cheio. A opção -c implicara na execução continua do ontape, e necessita de um terminal dedicado e um dispositivo de fita em ordem para a função. Ele não pode ser executado como um daemon.

Log Salvage

Quando o servidor de banco de dados esta off-line, voce pode ainda executar um backup de logical-log. Isto é conhecido como um log salvage. Ele copia alguns logical logs que ainda não foram copiados e não estão corrompidos ou destruidos. Voce pode então colocar esses logs para frente, durante o restore, resultando em um minimo de perda de dados.
Para ter certeza de que nenhum dados é perdido antes de voce iniciar um cold restore, voce deveria salvar manualmente os logical logs.
Voce perdera as transações nos arquivos de logical log que não estão copiadas ou salvas.

Os Backups de Logical Log são Necessarios?

Voce deve executar frequentes backups de logical-logs pelas seguintes razões:
  • Para fornecer total recuperação (recovery) das transações.
    O Recovery tem dois componentes: o physical restore e logical restore. O physical restore aplica-se aos dados contidos em um archive. O logical restore recria transações que ocorreram depois que o archive foi feito. Essas transações são guardadas nos logical logs. Se voce não tem backup dos logs e os logs não são tão longos no disco, você não podera refazer as transações.
  • Para prevenir que os logical logs se encham e travem o servidor.
    Para prevenir que se perca as informações das transações armazenadas nos logical logs, o servidor de banco de dados, requer que os logs sejam marcados como copiados (backed up) antes de reutiliza-los. Se todos os logs foram usados e não foram marcados como copiados, o servidor é bloqueado ate um backup dos logical logs for completado.
O Informix Dynamic Server não o habilita a escrever em cima de um log ate ele ser copiado. Voce pode, entretanto, descobrir que o LTAPEDEV esta definido para /dev/null. Neste cenario, o servidor marca o log como copiado, que ele estiver cheio, entretanto os dados não foram copiados. Isto é usado frequentemente como um atalho administrativo, evitando a necessidade de copiar realmente os logs. Se um restore é requerido, entretanto, os logs não estão disponiveis.
  • O disco contendo o logical log pode falhar.
    Se voce perdeu o disco que contem os logical logs, voce não sera capaz de restaurar as transações que foram escritas para os logs, mas ainda não foram copiadas para a fita. Implementando uma estrategia  de backup continuo de logical log, voce minimiza a quantidade de transações que estão no logical logs, mas não estão ainda copiadas. Como uma precaução adicional, você pode espelhar (mirror) o dbspace que contem os logical logs. Se um dos chunks falhar,  o par espelhado contem a relevante informação.
  • Alguns tipos de restores requerem aplicar o Backup de logical logs.
    Dependendo do utilitario que você usa, e dependendo de como o utilitario é usado, os logical logs devem ser requeridos para uma completa restauração. Por exemplo, restaurando um unico dbspace que voce traz o dbspace in sync com outros dbspaces.
    Este requer que os logical logs sejam aplicados do ponto de aplicação do archive ate o presente momento.
    Cada utilitario tem um cenario especifico, onde o uso dos logical logs em uma restauração não é requerido. Esteja certo que voce compreendeu as implicações de não copiar os logical logs se voce escolheu não copia-los.

O que é um Backup de Logical Log ? - Informix

Um backup de logical log é o processo de copiar o conteudo de um arquivo de logical log para uma midia secundaria de armazenamento. Os logical logs guardam registros de checkpoint, atividades administrativas, como comandos DDL, e atividades de transações para o banco de dados no servidor. Cada instancia no servidor, tem um numero finito de logical logs. O Servidor usa os logical logs em um metodo circular.
Gravações são escritas para o arquivo logical log em serie. Quando o primeiro log estiver cheio, o servidor começa a escrever no segundo log, e assim por diante. Quando todos os logs tiverem sido usados, o servidor começa a escrever no primeiro log novamente. Antes que o servidor possa reutilizar um log, é necessario que seja feito o backup do log.
Mesmo se nenhum dos bancos de dados no servidor estiver usando logging transações, deve ser feito o backup dos logical logs.

Quando os Logs são copiados?
Ha dois metodos que voce pode usar para copiar  seus logical logs. Voce pode explicitamente iniciar um backup do logical log, ou voce pode usar backup continuo de logical log:
  • Um backup automatico ou on-demand é explicitamente iniciado, e copia todos logical logs cheios e para o processo log corrente. Se voce escolheu usar este metodo, ele é altamente recomendado para executar frequentes backups de logical log.
  • Um backup continuo é mais adequado quando voce tem dispositivos de fita separados para archive e backup de logical log. Neste cenario, um dispositivo de fita pode ser dedicado para executar backup continuo de logical log. Com este metodo, o logical log é copiado tão logo quanto estiver cheio.
Restaurando muitos registros de logical log é lento comparado a restaurar paginas de um archive. Voce pode minimizar o numero de registros de log necessarios durante um restore, executando frequentes archives de seu dbspaces.
Escolhendo um Dispositivo para Backup dos Logs.

Quando você estiver escolhendo um dispositivo de backup para logical log, você deve considerar o seguinte:
  • Se o dispositivo de logical log difere do dispositivo de backup do dbspace, voce pode planejar seus backups desconsiderando a concorrencia do backup de dbspace planejado.
  • Se seu dispositivo de gravacao é lento, o logical log poderia encher-se mais rapido do que ser copiado para a fita. Neste caso, voce pode executar o backup para o disco e entao copiar o backup do disco para a fita.
  • Se somente um dispositivo de backup esta disponivel, certifique-se de que todos os logicals logs foram copiados antes de voce iniciar o backup dos espacos de armazenamento. Esta preocupação livra espaços em seus arquivos de logical-log.
Não defina o parametro de configuração LTAPEDEV para /dev/null. Este causara a marcação dos logical logs para backed up (U-B----) assim que o servidor for para o proximo log e antes que o ON-BAR tenha chance de enviar os dados para um storage manager. Se LTAPEDEV for /dev/null, somente restores de todo sistema pode ser executado.

Passos para criar um Archive - Informix

O Servidor executa varios passos internos quando um archive ou backup é iniciado. A preparação interna é a seguinte:

  • O Servidor temporariamente congela o status do uso de logical logs e checa a quantidade de espaço livre. Se o espaço livre for menor do que a metade dos logical log, o servidor aborta o archive. Se isto ocorrer, faça um backup de seus logical logs e tente o archive novamente.
    O ON-BAR parara o archive e automaticamente executara o backup dos logical log deste modo, voce pode tentar o archive novamente.
    Se voce quiser manter um logical log para On-archive ou ON-BAR, defina o parametro de configuração LBU_PRESERVE para 1.
  • O servidor inicia um checkpoint. O checkpoint marca o ponto de sincronização do archive. Algumas paginas criadas depois do checkpoint, não irão para o archive. Algumas paginas modificadas apos o checkpoint, terao suas before-image colocadas no physical log.
  • O servidor constroi uma lista de paginas dentro de cada chunk para serem arquivadas (achived). Paginas não usadas ate o momento do checkpoint não serão arquivadas.
  • O servidor constroi uma tabela temporaria para cada dbspace sendo arquivado, para guardar as before-image do physical log. A localização dessas tabelas temporarias são indicadas pelo parametro de configuração DBSPACETEMP. Se não ha espaço temporario suficiente, o servidor aborta o archive.
  • Uma thread para o archive, é iniciada internamente para gerar o archive dos dados.

O que é um Archive ou Backup - Informix

Um archive ou backup é o processo de copiar todos ou apenas um subconjunto de dbspaces, blobspaces, e arquivos de logical logs para um local secundario de armazenamento, ou tro disco, fita, ou dispositivo optico. O processo de backup garante que uma imagem consistente dos dados é criada, enquanto o sistema esta on-line, em modo multi-usuario, recebendo transações continuas.
Dependendo do utilitário de archiving selecionado, você pode fazer o backup de um unico objeto, multiplos objetos, ou da instância inteira. A habilidade para backup individual de dbspaces ou grupos de dbspaces possibilita maxima flexibilidade para a demanda do negocio. Pelo fato de um dbspace poder conter multiplos databases, um database, uma unica tabela, ou apenas parte de uma tabela, backups por dbspaces fornecem um nivel de granularidade de tabela melhor para backups e restores.
Com a introdução do ON-BAR no IDS 7.21, uma nova terminologia foi introduzida. O termo storage space refere-se a algum espaço de disco que é usado para armazenar dados do IDS, se ele é um dbspace ou blobspace. Alem disso, as palavras archive e backup, quando se referindo a espaços de armazenamento, são sinonimos. 

Archives Incrementais
O Servidor fornece tres diferentes niveis de archiving ou backing up dos dados: eles são referidos como archive de nivel 0, nivel 1 e nivel 2.

Nivel 0
Um archive de nivel 0, contem uma copia de todos os dados no servidor ou dbspace especifico, no estado em que se encontravam no momento em que o archive foi iniciado. Um level 0 é a linha base do archive.
Se discos e outras midias estao completamente destruidos e precisam ser recuperadas, voce precisa de um archive 0 de todos espaços de armazenagem e os logical log relevantes, para a restauração completa.
Nivel 1
Um archive nivel 1 contem uma copia de todos os dados no servidor ou dbspace especifico, que foram alterados desde o ultimo archive nivel 0, no estado em que se encontravam no momento em que o archive foi iniciado.
Nivel 2
Um archive nivel 2 contem uma copia de todos os dados no servidor que foram alterados desde o ultimo archive nivel 1 ou nivel 0, qualquer um mais recente, no estado em que se encontravam no momento em que o archive foi iniciado.

Abraços.

quinta-feira, 17 de setembro de 2009

Semaforos, Kernel, Memoria Compartilhada e Cia

Há ocosiões onde é extramamente necessario que dois ou mais processos/threads acessem um único recurso comum. Caso esse tipo de paralelismo não ocorra de forma controlada, podemos fazer com que um processo "sequestre ou atropele" a operação do outro.
É ai que entram nossos sinalizadores, vulgo semaforos. Com eles, é possivel acesso controlado a processos, de forma que só havera disponibilidade quando a operacao em andamento for finalizada.
Processos, memoria compartilhada e filas de mensagens é a principal triade de recursos compartilhados necessarios em ambientes *NIX para a perfeita comunicação entre processos (System V IPC ou tambem conhecida em outros ambientes com IPC ou Inter-Process Communication).
Esses semaforos funcionam como indicadores (flags) que sinalizam para o ambiente se o mesmo esta ou não em utilização ( os metodos de sinalização não são pertinentes ao artigo, mas podemos didaticamente imaginar que pode ser 0 e 1, respectivamente 0 para indisponivel e 1 para disponivel). Assim, o processo de sinalização requer colaboração e troca de informações entre processos.
Dependendo da quantidade de aplicações que existem no ambiente, a quantidade inicial de semaforos pode não ser suficientes para um perfeito controle de todo o sistema. Na verdade, a maioria dos sistemas operacionais modernos oferecem essas funcionalidades, porem os padrões das diversas distribuições são tão baixos que não é necessario um super-servidor para saturar esses recursos (principalmente o legado BSD). Por exemplo:
Uma instalação consideravel do PostGreSQL pode "extirpar" rapidamente vários limites de recursos do sistema operacional, comumente usando 1 semaforo para cada instancia concorrente. Uma instalação comum de Oracle consome aproximadamente 70 semaforos.
Quando esses recursos são saturados, sua falta manifesta um erro conhecido como "Chamada de Sistema Ilegal". Nesse caso,  não ha nada a ser feito, a não ser remover recursos "gulosos" que na maioria das vezes não é possivel recompilar o nucleo do kernel. Para os escovadores de bits e curiosos os arquivos são:
/usr/src/linux/include/asm/shmparam.h
/usr/src/linux/include/asm/semaphore.h
/usr/src/linux/include/asm/semaphore-helper.h
/usr/src/linux/include/linux/shm.h
/usr/src/linux/include/linux/sem.h 
Nessa dica, alem de darmos uma explanação sobre somaforos, iremos demonstrar como corrigir esses problemas sem desinstalar aplicações e ou recompilar o kernel.
O sistema de arquivos proc   
Muitos parametros de kernel podem ser alterados atraves do sistema de arquivos /proc ou usando o sysctl. Voce pode consultar esses valores consultado:

cat /proc/sys/kernel/sem   #Semaforos
cat /proc/mdstat                 # RAID status
cat /proc/cpuinfo                # Processador
cat /proc/version                # Versão do Kernel

ou ainda, uma variedade de informações de todo o sistema via:

procinfo
sysctl -a

Como estamos falando de semaforos e recursos do sistema, vamos dar uma olhada nesses valores:

ipcs -la

Lembram da ganancia por recursos do Oracle? Observem agora esses limites (100). Levando em consideração que o proprio S.O ja esta utilizando parte deles, nossa cota esta proxima de estouro. Vamos conhecer um pouco mais sobre esses indicadores.

Parametros IPC (System V)

SEMMNI
Numero maximo de identificadores de semaforos (conjunto)

SEMMNS
Numero maximo de semaforos para todo o sistema.

SEMMSL
Numero maximo de semaforos por conjunto.

SEMMAP
Numero de entradas no mapa de semaforos. Deve ser definido como o produto de SEMMNI e SEMMSL (SEMMAP=SEMMNI * SEMMSL).

SEMVMX
Valor maximo de um semaforo. Pelo menos 1000, onde o padrão é geralmente 32767. Não mude a não ser quando solicitado!

Esses valores podem ser modificados via arquivo de sistema proc sem necessidade de reinicialização. A operação abaixo ilustra essa mudança:

sysctl -w kernel.sem="250     32000     100    128"

Como esses valores são perdidos numa inicialização do sistema, os mesmos podem ser colocados em um script executado durante a inicialização, como erroneamente utilizado em gateways/firewall para habilitar roteamento de pacotes.

echo "1" > /proc/sys/net/ipv4/ip_forward

Como alternativa correta para ambos os exemplos mostrados, pode ser utilizado sysctl, para controlar esses parametros. Como esse arquivo é processado durante a inicialização, as mudanças devem ser inseridas em /etc/sysctl.conf conforme o exemplo:

kernel.shmall = 134217728
kernel.shmmax = 134217728
net.ipv4.ip_forward = 1

A sintaxe para o /etc/sysctl.conf é bem simples. Remova /proc/sys dos caminhos mencionados anteriormente e substitua o / pelo . utilizando a mesma estrutua. Assim:

/proc/sys/net/ipv4/ip_forward = net.ipv4.ip_forward


abraços.

Creditos : Jairo Willian Pereira

quarta-feira, 16 de setembro de 2009

Como Trabalha o Kernel do Linux

Definição da palavra Kernel em um dicionario de Ingles/Ingles:

1.
the inner and usually edible part of a seed or grain or nut or fruit stone
2.
a single whole grain of a cereal
3.
the choicest or most essential or most vital part of some idea or experience
Com isso temos a idéia de que é algo muito importante, pequeno, o centro, o nucleo. O kernel  é o nucleo do Sistema Operacional. Esse nucleo fica constantemente em memoria e é responsavel pela execução das funções mais baixas do sistema como:
  • Gerenciamento dos recursos de Hardware;
  • Gerenciamento de memoria;
  • Controle das operações I/O;
  • Gerenciamento de processos ;
  • Gerenciamento das operações multiusuario/multitarefa;
  • Gerenciamento do Sistema de Arquivos;
O nucleo não faz nada diretamente com o usuario. Todos os serviços são solicitados por programas utilitarios que são interpretados pelo interpretador de comandos e passados ao nucleo.

Entendendo o Kernel
O Kernel disponibiliza serviço para os aplicativos rodando através de inúmeros pontos de entradas conhecidas como chamadas de sistema (system calls).
O kernel utiliza chamadas de sistemas como leitura e escrita para prover acesso ao hardware.

Do ponto de vista de um programador isso parece uma função comum, embora na realidade uma chamada de sistema envolva diferentes interruptores no modo de operação "kernel space"  para o "user space" . Juntos esse conjunto de chamadas de sistema formam uma especie de "maquina virtual" que trabalha antes do hardware real. Um exemplo claro disso é o sistema de arquivos.

Agora que entendemos melhor o que o kernel faz, vamos olhar  mais atentamente a sua organização física. As primeiras versões do kernel eram monoliticas, ou seja, todos os modulos estava compilados dentro de um unico arquivo executavel. O kernel das distribuições mais novas são modulares, ou seja, os modulos podem ser carregados no kernel em tempo de execução, isso faz com que o nucleo do kernel fique menor e não seja necessario reiniciar a maquina para carregar ou substituir novos modulos.
O nucleo do kernel é carregado na memoria na hora do boot e é lido de um arquivo no diretorio "/boot" na maioria das vezes este arquivo é chamado de "vmlinuz-versão_do_kernel". Para ver a versão do kernel corrente utilize o comando:

uname -r

Os modulos ficam no diretorio "/lib/modules/VERSAO_DO_KERNEL"

Gerenciando Modulos

Veremos agora alguns comandos para gerenciar os modulos do seu kernel, como por exemplo o comando para listar os modulos carregados que é o "lsmod", o lsmod vai mostrar uma saída semelhante a esta:


Module                         Size     Used by
vfat                                14464   0
isofs                              36388   0
fat                                  54556   1 vfat
nfs                                 26540   0
lockd                             67720   1 nfs

Esta saida possui quatro campos dividios por nome do modulo que esta carregado, o tamanho do modulos , quantas vezes ele esta sendo utilizado e quais modulos que dependem dele. Podemos carregar um modulo utilizando o comando "modprobe" (podemos tambem utilizar o comando "insmod" porem o modprobe é mais aconselhavel pois ele resolve as dependencias do modulo). Outro ponto muito importante na saída do comando lsmod é o terceiro campo que indica a quantidade de vezes que o modulo esta sendo utilizado pois o linux não vai permitir a removacao de um modulo cujo o campo used seja diferente de zero, no exemplo acima vemos o modulo "isofs" (utilizado para dar suporte ao sistema de arquivos "ISO" que é utilizado em CD's) como o campo used "0" , neste caso podemos remover o modulo com o comando modprobe -r isofs", apos executar este comando o modulo isofs nao vai mais aparecer  quando executarmos o lsmod.
Não é muito comum carregar modulos manualmente no dia a dia, porem se voce precisar carregar um modulo manualmente voce pode incluir parametros especificos de cada modulo para carrega-lo como no exemplo a seguir:

modprobe usb_storage delay_use:3

No exemplo acima habilitamos o parametro "delay_use:3" para o modulo "usb_storage" que define um time-out de 3 segundos para o modulo procurar um novo device. Para saber quais as opções de cada modulo utilizamos  o comando modinfo como no exemplo a seguir:

modinfo usb_storage
filename: /lib/modules/2.6.27.29-0-default/kernel/drivers/usb/storage/usb-storage.ko
license: GPL
description: USB Mass Storage driver for Linux
autor: Matthew Dharm
srcversion: 99E0B653929DE200DF6AF9
depends: libusual,usbcore,scsi_mod
vermagic: 2.6.24-generic SMP mod_unload 586
param: delay_use:seconds to delay before using a new device (uint)

A linha que nos interessa neste caso é a que começa com "param" que mostra os parametros aceitos pelo modulo. Caso voce possua a source do kernel voce tambem pode encontrar uma documentação muito util em /usr/srv/versao_kernel/Documentation/kernel-parameters.txt

Sistema de arquivos /proc

kernel tambem nos fornece inumeras informações que podem ser encontradas no sistema de arquivos "/proc", os arquivos no /proc são criados pelo kernel (alguns voce pode alterar, outros não) um exemplo claro do tipo de informação que podemos encontrar no /proc esta no arquivo /proc/modules que mostra todos os moduls carregados no sistema , no arquivo /proc/meminfo que mostra o status detalhado da memoria do sistema e também o arquivo /proc/net/arp que mostra a tabela ARP.
Dos arquivos citados acima, nenhum pode ser alterado, porem existem arquivos dentro do /proc que podem ser manipulados, como por exemplo o /proc/sys/net/ipv4/ip_forward

echo 1 > /proc/sys/net/ipv4/ip_forward

Agora o encaminhamento de pacotes IP esta habilitado. Outro comando que também pode ser utilizado para executar a mesma tarefa é o "sysctl" como no exemplo a seguir:

sysctl net.ipv4.ip_forward
net.ipv4_ip_forward = 0

Acima sometne visualizamos o valor do ip_forward, para alterar esse valor utilizamos o comando sysctl como abaixo:

sysctl -w net.ipv4.ip_forward = 1

Porem tem um pequeno problema aqui, se reiniciarmos a maquina este arquivo voltara a ter conteudo igual a "0". E como solucionamos isso? A solução é muito simples, utilizamos o arquivo /etc/sysctl.conf para definir os valores que serão carregados em tempo de boot, basta acrescentar a linha abaixo no arquivo /etc/sysctl.conf

net.ipv4.ip_forward = 1

Melhorando a performance.

Muitos dos parametros do /proc/sys que permitem escrita podem ser utilizados para melhorar a performance do Linux, apesar de que a configuração padrão já habilite opções que trabalham muito bem. Um exemplo de como podemos modificar o kernel para melhorar a performance de acordo com o tipo de aplicação que voce vai utilizar esta no guia de instalação do Informix que pede para configurar alguns parametros como o "kernel.shmmax=4398046511104" que define o tamanho maximo de segmento de memoria partilhada para 4GB. (Memoria partilhada é um mecanisco de comunicação entre processos que permite que um segmento de memoria de ser visivel dentro do espaço de endereçamento de multiplos processos.)
Outra modificação que podemos fazer e definir que nossa maquina não vai responder por broadcast de icmp ( o bom e velho ping -b 255.255.255.255) configurando o sysctl da seguinte forma:

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

Agora fica a duvida, para ver os valores eu vou ter que dar cat de arquivo em arquivo ou saber todos os caminhos do comando sysctl? Claro que não, basta utilizar o comando 
sysctl -a

ele vai exibir todos os parametros e seus valores porem ele na fala para que serve cada um deles, porem isso podemos encontrar os detalhes no bom e velho "man proc".

Abraços. 

terça-feira, 15 de setembro de 2009

SGBD - Configurando o Sistema Operacional

Antes de começar a instalar e configurar o SGBD, primeiramente precisamos  configurar o Sistema Operacional adequadamente. 
A versão 32-bit do IDS pode ser instalado num S.O de 64-bit e ou 32-bit.
A versão 64-bit do IDS  pode ser instalado num S.O de somente 64-bit.

Modificando os parametros de Kernel do Unix/Linux

O IDS traz na sua documentação uma nota chamada de "Machine Notes" e essa Nota traz informações importantes sobre os recursos a serem configurados no Unix /Linux. É de extrema importancia ler esse documento antes da instalação e configuração do IDS.
Se os valores recomendados para o SGBD diferem significativamente do ambiente atual, considere modificar a configuração do Sistema Operacional.
Em alguns Sistemas Operacionais, pode-se especificar a quantidade de Shared Memory alocada para o SGBD. A quantidade de memoria disponivel influencia nos valores dos parametros de Shared Memory. Em geral, aumentando o espaço de Shared Memory aumenta-se a performance. Tambem tem que se especificar os numeros de Locks e Semaphares. 
Postarei um exemplo aqui, porem baseado no Linux SuSE 11.1 e IDS 11.50
Kernel 2.6.16 ou >
Glibc 2.4 ou >
libaio-0.3.104 ou >
libgcc-4.1.0 ou >
libstdc++-4.1.0 ou >
ncurses-5.5 ou >
pam-0.99.3.0 ou >

Se uma libaio.so.1 é encontrada, o IDS habilitara o Kernel Asynchronous I/O (KAIO) automaticamente. Senão o KAIO é desabilitado.

Parametros do Kernel
Esses valores dos Parametros do Kernel abaixo, foram usados para testar o produto pela propria IBM no ambiente citado acima. Esses valores poderão ser ajustados dependendo da aplicação e dos recursos disponiveis. Esses valores podem ser ajustados dinamicamente  no diretorio /proc  ou podera ser definidos no codigo fonte do Kernel e recompilado.

SHMMAX: 4.398.046.511.104
SHMMIN: 1
SHMMNI: 4096
SHMSEG: 128
SHMALL: 4.194.304
SEMMNI: 4096
SEMMSL: 250
SEMMNS: 32000
SEMOPM: 32

Planejamento para um Servidor de Banco de Dados.

Configurar um Sistema de Gerenciamento de Banco de Dados requer algumas decisões. Como o local de armazenamento dos dados, como acessar os dados e como proteger os dados. A instalação e configuração dos SGBD afetam significadamente o desempenho do banco de dados. 
Podemos personalizar o SGBD para que ele funcione muito bem com uma performance ótima em um ambiente de produção. Por exemplo, usando um SGBD para servir 1000 usuarios que acessam frequentemente, servindo operações curtas, como escrita e servindo também operações mais complexas, como consultas relacionais. 
Podemos planejar a configuração do SGBD considerando as Prioridades e Ambientes.

Considerando as Prioridades
Preparar a configuração inicial e a estrategia de backup, temos que ter em mente as caracteristicas do Servidor de Banco de Dados:
  • Existem outras aplicações, fora da aplicação padrão, que acessam o banco de dados?
  • Qual a expectativa de acessos simultaneos nesse banco de dados?
  • Até que ponto o DBA deseja controlar o ambiente do usuario?
  • Quais os recursos que temos em mãos para a instalação e configuração do SGBD?, tais como... espaço em disco, CPU, Memoria ou disponibilidade de operadores.
  • O servidor de BD vai trabalhar com muitas transações curtas? Longas?
  • A instalação será somente do SGBD ou terá produtos adicionais?
Considerando o Ambiente
Antes de iniciar a instalação do SGBD recolher o maximo de informação possivel. Muitas vezes sera necessario consultar o Administrador de Sistemas ou Redes para coletar as informações abaixo:
  • Host Name e Endereço de IP do servidor e de outros servidores e maquinas da rede.
  • A rede UNIX possui suporte ao NIS?
  • Configuração da Controladora de Discos
    Quantos discos estão disponiveis? Um disco é mais rapido que os outros? Quantas Controladores de Discos estão disponiveis? 
  • Quais os requisitos, caracteristicas e limitação do sistema de Backup?
  • O sistema Operacional é 64-Bit ou 32-Bit?
  • Sistema de gerenciamento de Shared Memory e outros recursos
    Quanto de Shared Memory esta disponivel? Quanto você pode usar para o SGBD?
Ate a proxima, abraços






Migração de Servidores de Banco de Dados ( Informix)

Para uns parece um trabalho arduo, para outros um trabalho a mais, e para outros a chance de reorganizar a estrutura fisica do banco de dados, mas não é bem assim. Vou tentar expor o meu ponto de vista:

Quando se chega a conclusão que devemos trocar um servidor, é porque algo não esta bem, principalmente a performance do Banco, os usuarios finais reclamando que o relatório esta muito demorado para rodar, e por ai vai.

Entendo que essa seja uma grande chance de fazer uma organização geral no banco de dados, principalmente na parte estrutural da coisa, trocando por miudos é a chance de fazer uma reorganização começando pelo Sistema Operacional, Particionamento de Discos, Instalação de Software de Gerenciamento de Banco de Dados (SGDB).

Isso esta acontecendo comigo hoje, de fato, estou fazendo uma migração dessa e vou tentar compartilhar aqui um pouco dessa experiência, que não é nova, mas por ser informatica é sempre uma nova experiencia, rss.

Aqui no caso de nossa empresa, chegamos a essa conclusão ja faz uns 2 meses, o primeiro passo foi levar a diretoria uma apresentação mostrando as nossas dificuldades a nivel de processamento de dados com os equipamentos que tinhamos em mão, uma vez apresentado, aprovado pela Diretoria, então fechamos um Servidor.

O Servidor que fechamos foi o seguinte:

Blade Systems c3000 com 4 Laminas com 2 processores Quad-Core, 16 GB de RAM e 2 Discos FastWide de 10K da HP é claro. ;-)

O Servidor chega de fabrica com Raid 0, espelhando os dois discos, é uma coisa que não me agrada muito, mas temos que tomar cuidado para certas decisões, no meu caso decidi desmontar o RAID e optei trabalhar com Volume Groups. A unica observação aqui é que estou usando o OpenSuSE 11.1 64 bits.

Optei por uma instalação Limpa no servidor com o minimo de pacotes possiveis, inclusive sem pacotes do sistema X.

Na configuração dos discos optei por criar duas VG's, pois a minha idéia é fazer Balanceamento de I/O.

A instalação foi um sucesso, e logo depois começei a instalação do banco de dados, mas isso vou continuar num outro post.

Abraços.


Abaixo o Servidor.