sexta-feira, 21 de setembro de 2012

Tecnologia da Informação: openSUSE 12.2 - Análise de Sistemas e Performance

Tecnologia da Informação: openSUSE 12.2 - Análise de Sistemas e Performance: Saudações a todos, já faz algum tempo que não tenho escrevo no blog, tenho uma razão para isso, ultimamente tenho estado com minha agenda ch...

openSUSE 12.2 - Análise de Sistemas e Performance

Saudações a todos, já faz algum tempo que não tenho escrevo no blog, tenho uma razão para isso, ultimamente tenho estado com minha agenda cheia com muitos clientes de ótima qualidade.

E acabou de sair do forno a nova versão do openSUSE a versão 12.2, que na minha opinião esta ótima, já tenho inclusive instalado em um cliente, e esta rodando perfeitamente com o banco de dados Informix.

Vou estar postando por esses dias alguns artigos referente a análise do openSUSE para buscar uma melhor performance, espero que gostem.

Part I. Básico

Algumas observações sobre à Analise de Performance

O que vou tentar expor aqui são as razões para os problemas de desempenho e tentar proporcionar meios para resolver esses problemas. Antes de iniciar o tuning em seu sistema você deve ter certeza de que descartou problemas comuns, básicos, e de que encontrou a causa (gargalo) para o problema. Você também deve de ter um plano detalhado sobre como ajustar o sistema, porque a aplicação de dicas de ajustes aleatórias não vai ajudar, e poderia piorar as coisas. Não é tão fácil fazer ajustes de performance, requer estudo sobre o ambiente, paciência para a coleta de dados, e o mais importante saber o que esta alterando.

Também gostaria de chamar a atenção que tomem muito cuidado com ambientes de produção, não façam nada nesses ambientes sem ter certeza do que estão fazendo, por conta e risco de cada um.

Abordagem geral de um ajuste de sistema

Certifique-se do problema a ser resolvido

Antes de iniciar um tuning em seu sistema, tente descrever o problema mais exato possível.  Obviamente, um simples e geral comentário “O sistema esta muito lento!” não é uma descrição útil do problema. Se você pretende ajustar um servidor Web para uma entrega mais rápida de páginas estáticas, por exemplo, faz diferença se você especificar se precisa melhor a velocidade em geral, ou se é necessário melhor em horários de picos. Assim como melhorar a performance de um servidor WEB não é a mesma coisa que melhorar a performance de um banco de dados Informix ou Oracle. 

Além disso , certifique-se que você pode aplicar uma métrica para o seu problema, caso contrário você não será capaz de controlar se o ajuste foi bem sucedido ou não. Você sempre deve ser capaz de comparar  o "antes" e o "depois".

 

Descartar problemas comuns

Um problema de performance muitas vezes são causadas por problemas de redes ou hardwares, bugs, ou problemas de configuração. Certifique-se de descartar alguns problemas , tais como os listados abaixo antes de tentar ajustar seu sistema:

  • Verifique as entradas dos logs  /var/log/warn e /var/log/messages.

  • Verifique se um determinado processo ( usando top ou ps ) se comporta mal consumindo quantidades incomuns de tempo de CPU ou memória.

  • Verifique se há problemas de rede , analisando /proc/net/dev.

  • No caso de problemas de I/O com discos físicos,  certifique-se que não é causada por problemas de hardware(verifique os discos com o smartmontools) ou se o disco não esta cheio.

  • Garantir que os jobs em background estão programados para serem executadas na hora que o servidor tem cargas baixas de processamento.  Esses jobs também deverá rodar com baixa prioridade (definido através do comando nice).

  • Se o servidor executa diversos serviços, utilizando os mesmos recursos, considerar mover alguns serviços para outro servidor.

  • E por ultimo, verifique se o sua aplicação esta atualizada.

 

Procurando por gargalos

Encontrar o gargalo muitas vezes é a parte mais difícil ao ajustar um sistema. O openSUSE oferece uma série de ferramentas para ajudar nessa tarefa. Acompanhe as matérias futuras para obter informações detalhadas sobre as aplicações gerais do sistema de monitoramento e análise de arquivo de logs. Se o problema requer um longo tempo de análise mais profundo, o kernel do Linux oferece os meios para obter tal análise.

Depois de ter recolhido os dados necessários para analise. Primeiro, analise se o hardware do servidor (memória , CPU, bus ) e seus dispositivos de I/O  (disco , rede) são suficientes.  Se essas condições básicas são atendidas, o sistema pode ganhar performance.

 

Passo à passo dos ajustes

Certifique-se de planejar cuidadosamente o ajuste. É de importância vital fazer apenas um passo de cada vez. Só assim você será capaz de medir se a mudança proporcionou uma melhora ou até mesmo teve um impacto negativo. Cada atividade de ajuste deve ser medido ao longo de um período suficiente de tempo, a fim de assegurar-se que pode fazer uma analise baseada em dados significativos. Se você não pode medir um efeito positivo, não fazer a mudança permanente, volte como estava antes.

Bom por hora vai a dica ai, espero que gostem, vou postar mais materias a respeito do assunto.

Abraços

quarta-feira, 20 de junho de 2012

Configurando o Informix com Segurança

Label-based Access Control (LBAC) como recurso de segurança

Label-based access control (LBAC) é um meio pelo qual o sistema de banco de dados controla o acesso a objetos de tabela . O sistema de banco de dados controla o acesso anexando rótulos de segurança para os objetos de tabelas e compara com os rótulos de segurança concedios aos usuários que tentarem acessar o objeto.

O sistema controla o acesso de banco de dados , anexando rótulos de segurança para os objetos de mesa e comparar com as etiquetas de segurança concedidos aos usuários que tentarem acessar esse objeto. Ele concede acesso se os dois combinarem, caso contrario nega o acesso.

Existem três tipos de rotulos de segurança :

  1. Rotulo de segurança por linha (row): Um rótulo de segurança associada a uma linha de dados ou um registro em uma tabela do banco de dados
  2. Rotulo de segurança por coluna (column): Um rotulo de segurança associada com uma coluna em uma tabela do banco de dados
  3. Rotulo de segurança por usuário: Um rotulo de segurança concedido a um usuario do banco de dados. Um usuario pode ter acesso para leitura ou acesso para escrita.

Um rotulo de segurança pode conter um ou mais componentes. Há três tipos de componentes de rotulos de segurança:

  1. Set: Um set é uma coleção de elementos onde a ordem que esses elementos aparecem não é importante
  2. Array: Um array é um conjunto ordenado. Em um array, a ordem em que aparecem os elementos é importante porque indica o grau de sensibilidade dos dados
  3. Tree: Uma Tree representa uma hierarquia que podem ter multiplos nós e ramos. Por exemplo, trees podem ser usados para representar organogramas e para identificar os diferentes serviços dentro da organização.

Uma politica de segurança define o conjunto de componentes dos rotulos de segurança. DBSECADM é requirido para minupular objetos LBAC.

PAM - Pluggable Authentication Modules para sistemas rodando em UNIX ou Linux

O Pluggable Authentication Module (PAM) foi escrito originalmente pela Sun Microsystems para suportar diferentes modulos de autenticação. PAM permite ao administrador de sistemas implementar diferentes metodos de autenticação para diferentes aplicações.

Serviços de autenticação estão ligados aos niveis de aplicações. Por exemplo, um esquema de autenticação para  para um banco de dados pode ser diferente para o programa de login do UNIX.

Outras caracteristicas do PAM é o modulo de empilhamento. Onde muitos modulos podem ser empilhados um sobre o outro, fornecendo autenticação para uma aplicação de varias maneiras. Pam fornece um conjunto de API’s para suportar varios tipos de autenticação – gerenciamento de contas, gerenciamento de sessão e gerenciamento de senhas.

O Administrador do sistema pode habilitar ou desabilitar o uso do PAM.

Pluggable Authentication Modules são suportados em em ambos modos de 32-bit e 64-bit no Solaris, Linux, HP-UX, and AIX®.

 

Suporte à Autenticação LDAP no Windows.

Você pode usar o suporte para os modulos de autenticação LDAP quando você quiser usar o servidor LDAP para autenticar seus usuarios. LDAP no Windows é configurado similarmente ao Pluggable Authentication Module no UNIX e Linux, mas não suporta as caracteristicas do modulo de empilhamento. Ele apenas fornece um único módulo de autenticação.

A autenticação DLL esta localizada no diretorio %INFORMIXDIR%\dbssodir\lib\security. Os parametros de configuração são listados no arquivo %INFORMIXDIR% \dbssodir\pam.conf. O codigo-fonte para o Modulo de Autenticação LDAP e  exemplos de arquivos de configuração requeridos estão no diretorio %INFORMIXDIR% \demo\authentication.

O administrador de sistemas pode habilitar ou desabilitar a autenticação.

terça-feira, 19 de junho de 2012

CURRENT nao é a data e hora real quando dentro de procedure

Estou postando aqui um email que recebi de um amigo/irmão, o Carlos.

Carlão um abraço e obrigado por compartilhar conosco.

abaixo segue o email dele.

Pessoal,

Tivemos um problema ao fazer uma procedure que usa o comando CURRENT para recuperar a data e hora do sistema.

Verificamos que se utilizado mais de uma vez dentro da procudure o mesmo retorna sempre a mesma informacao, mesmo depois de levar varios segundos/minutos entre um comando e outro;

No site da IBM explica que ele congela essa data e hora quando chamado uma procedure para retornar sempre a mesma informacao ate o termino da execução dela.

Por conta disso fomos atrás de outra forma de obte-la e encontramos a seguinte:

  SELECT DBINFO('utc_to_datetime', sh_curtime)

  FROM sysmaster:sysshmvals;

Como esse comando é bem mais complicado, criei uma função para retornar mais facilmente a data/hora, podendo ser chamada em suas procedures:

DROP FUNCTION current_time;

CREATE FUNCTION current_time()

RETURNING DATETIME YEAR TO FRACTION;

  DEFINE current_time DATETIME YEAR TO FRACTION;

  SELECT DBINFO('utc_to_datetime', sh_curtime)

  INTO current_time

  FROM sysmaster:sysshmvals;

  RETURN current_time;

END FUNCTION;

Exemplo de utilizacao:

select current_time() from empresa;

Para comparar a diferença basta fazer uma query com processamento demorado e comparar, o campo CURRENT vai mostrar a mesma data/hora para todos os registros, enquanto que a funcao CURRENT_TIME() apresentará a data/hora que 'printou' cada linha;

select current, current_time() from estoque_trans

by callprog

quarta-feira, 9 de maio de 2012

System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix

Arquivo de configuração

O arquivo de configuração: Unix/Linux

Os parâmetros de configuração do servidor são armazenadas em um arquivo localizado no diretório $INFORMIXDIR/etc.

Especifique o nome do arquivo, definindo a variável de ambiente ONCONFIG. Não especifique o caminho completo, somente o nome do arquivo.

Se a variável de ambiente ONCONFIG não está definido, o nome de arquivo padrão ONCONFIG é usado.

Exemplo:

export ONCONFIG=onconfig.prd

O arquivo de configuração contém muitos parâmetros diferentes que permitem que você configure seu servidor para as suas necessidades específicas. Alguns parâmetros são definidos no momento em que você configura o servidor pela primeira vez e, uma vez que o servidor foi inicializado pela primeira vez, alguns parâmetros não podem ser alterados. A maioria dos parâmetros , no entanto, podem ser modificados após a inicialização do servidor.

Abaixo  os seguintes parâmetros no arquivo de configuração deve ser configurado antes de um servidor ser inicializado porque o root dbspace contém as páginas reservadas, informações sobre todos os bancos de dados no servidor e bancos de dados que armazena suas atividades.

    • Root dbspace
    • Mensagens
    • Informações do Servidor

Root dbspace

Cada servidor deve ter um rootdbspace. Inicialmente, o root dbspace também contem o phyical e logical logs. No entanto, eles devem ser movidos mais tarde para outros dbspaces.

Configurando o root dbspace

ROOTNAME       rootdbs          #Root dbspace name
ROOTPATH /dev/online_root # Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device (kilobytes)
ROOTSIZE 300000 # Size of root dbspace (kilobytes)
Esses parametros somente podem ser modificados antes de inicializar o servidor pela primeira vez. Não podem ser modificados os espaços alocados para o root dbspace durante a inicialização do servidor.

Mensagem

Configurando o caminho das mensagens:

MSGPATH   /var/log/idslog/online.log  # System message log file path
CONSOLE /dev/console # System console message path

O servidor IDS prove dois destinos diferentes para as mensagens:



  • MSGPATH: este parametro indica o caminho e o nome do arquivo onde todas as mensagens serão gravadas. Este arquivo é criado quando o servidor é inicializado pela primeira vez, se ele não existir.
  • CONSOLE: este é o caminho onde é especificado onde o servidor ira monstrar as mensagens de console. Uma mensagem de console é muito importante para o administrador do servidor onde o banco de dados reside. Por exemplo, backup e restore requer uma troca de fita, essas mensagens são enviadas para a CONSOLE. Por padrão, este parametro é configurado com o dispositivo de conssole do servidor, porem pode ser configurado para enviar as mesagens para um arquivo.

Informação do SERVER


Configurando informação de um servidor especifico:

SERVERNUM 	      #Unique id corresponding to an IDS server
DBSERVERNAME #Name of default database server name
DBSERVERALIASES #Names of additional database server names

Esses parâmetros devem ser definidos para que o servidor possa ser identificado exclusivamente no computador.


Informação dos Logs


LOGBUFF      #Size in kilobytes for the three logical-log buffers in shared memory
LOGFILES     #Number of logical-log files
LOGSIZE      #Size of logical-log files



PHYSBUFF     #Amount of shared memory reserved for the buffers
PHYSFILE     #Size of the initial physical log
PHYSDBS      #Name of the dbspace in which the physical log resides


Logical Logs


Os arquivos de Logical Logs são coleções de paginas contíguas no disco que são usados para armazenar os registros de transações para o servidor. Esses registros de transações são usados para explorar todas as alterações feitas na base de dados que foram criados em modo logging. Todos os bancos de dados compartilham do mesmo conjunto de arquivos de Logical Logs. Cada servidor deve ter no minimo três arquivos de Logical Logs.


Adicionando arquivos de Logical Logs manualmente:


Você pode adicionar arquivos de Logical Logs manualmente pelos seguintes motivos:



  • Para aumentar o espaço alocado em disco para os Logical Logs
  • Para alterar o tamanho dos arquivos de Logical Logs
  • Para completar uma transação aberta
  • Para mover arquivos de Logical Logs para uma dbspace diferente

As duas maneiras que você pode adicionar um arquivo de log lógico são:



  1. Para adicionar arquivos no final da lista usando o comando onparams –a
  2. Após o arquivo de Logical Log atual usando o comando onparams –a –i

O seguinte comando adiciona um arquivo de Logical Log até o fim da lista de arquivos de logs no dbspace dbslog, usando o tamanho de arquivo de log especificado pelo parametros de configuração LOGSIZE:

onparams -a –d dbslog

O seguinte comando adiciona arquivos de Logical Log de 1000KB após o arquivo de log atual no dbspace dbslog:

onparams -a -d logspace -s 1000 -i

Para adicionar um arquivo de Logical Log com um novo tamanho (nesse caso, 250KB), execute o comando abaixo:

onparams -a -d logspace -s 250

Você pode dropar um arquivo de Logical Log usando o seguinte comando:

onparams -d -l lognum -y

Você pode mover os arquivos de Logical Logs para:



  • Eliminar arquivos de Logical Logs do dbspace corrente
  • Adicionar arquivos de Logical Logs para uma nova dbspace

Estratégia para estimar o tamanho e os números de Logical Logs


É mais fácil de gerenciar arquivos de Logical Logs grandes do que muitos arquivos de Logical Logs pequenos.  Se os arquivos de Logical Logs não são suficientes, frequentemente checkpoints serão disparados, isso impacta diretamente na performance. Para aplicações que geram uma pequena quantidade de dados de log, começe com 10 arquivos de logs com o tamanho de 100MB. Se um grande número de objetos em uma blobspace são alterados frequentemente, você necessitara de backups frequentes para liberar espaçoss na blobspace.


A expressão a seguir fornece um exemplo de como calcular a configuração de espaço total para os logs, em kilobytes:

LOGSIZE = (((connections * maxrows) * rowsize) / 1024) / LOGFILES

A politica de Objetivo de Tempo de Recuperação (RTO – Recovery Time Objective) determina a tolerância de perda de dados em caso de uma falha do servidor. Se esta politica é necessária,



  1. Utilize backups automaticos de logs sempre que um arquivo de log encher
  2. Utilize o agendador para criar tarefas que faça backup automatico de logs em determinados intervalos de tempo
  3. Se o espaço de log ficar cheio antes dos logs serem bacapeados, adicione novos arquivos de logs para permitir a continuidade do processamento das transações
  4. Utilize o agendador para adicionar tarefas para detectar a situação acima e adicionar logs automaticamente

Physical Log


O servidor tem um log especial que é utilizado para fins de recuperação automática. Esses registros são chamados de Physical Log. O physical log é uma coleção de paginas contiguas no disco.


Quando uma página é lida em um buffer de memória compartilhada e modificada por um usuário, uma copia dessa pagina em sua condição original é gravada dentro do physical log. Essa copia de paginas é conhecida como “before image” (copia da pagina antes de sua alteração). Apenas a primeira mudança da pagina  em um buffer causa a gravação do before image no pysical log. Quaisquer alterações posteriores na mesma página não gravará novo before image para serem salvas no physical log. Estas imagens são utilizados por um mecanismo automático de recuperação.


Você pode mover a localização e o tamanho do physical log usando o comando onparams.


A seguir o comando move o physical log para o dbspace dbsphyslog e redimenciona para 3000KB:

onparams -p -d dbspace1 -s 3000

Estimando o tamanho do Physical Log


O parametro de configuração PHYSFILE especifica o tamanho do physical log. O tamanho do physical log depende de:



  1. Da taxa de atividades gerada pelas transações do physical log
  2. Da utilização do parametro de configuração RTO_SERVER_RESTART para especificar um valor de tempo de recuperação

Checkpoints são acionados quando 75% do physical log esta cheio e o processamento precisa completar antes que o log fique cheio, para que o servidor de banco de dados não bloqueie todas as transações. A fim de evitar que as transações sejam bloqueadas, verifique se o servidor de banco de dados tem espaço suficiente de physical log para conter todas as atividades de transações durante o processamento do checkpoint.


Se você especificar um valor para o parâmetro de configuração RTO_SERVER_RESTART, o servidor monitora a carga de trabalho e acionamentos de checkpoints para atender a politica RTO. Isso gera algumas atividades de Physical Log. Os registros extras é usado para auxiliar o bufferpool durante o fast recovery de modo que a repetição seja executada de forma otimizada. Se o physical log é considerado grande em relação ao tamanho combinado de todos os buffer pools, paginas descarregadas e paginas com falhas que ocorrem durante um fast recovery. Paginas descarregadas e paginas com falhas reduz substancialmente a performance do fast recovery, e o servidor de banco de dados não pode manter a politica RTO.


Para sistemas com espaço de buffer pool menor que 4GB, o physical log pode ser redimensionado para 110% combinado com todos os buffer pools. Para sistemas com um buffer pool maiores que 4GB monitorar as atividade de checkpoint. Se ocorrer checkpoints com muita frequencia e parecem afetar o desempenho, acrescente mais physical log.


Você pode usar o comando onstat –g ckp para visualizar as configurações recomendadas.


You can use the onstat -g ckp command to display configuration recommendations.


Novos parametros do ONCONFIG na versão 11













































Parametros de ConfiguraçãoDescrição
RTO_SERVER_RESTARTPermite a utilização RTO (Recovery Time Objective) padrões para definir a quantidade de tempo, em segundos, para que o Dynamic Server terá que se recuperar de um problema depois que você reiniciar o DS e colocar o servidor em modo online ou quiescente.
RAS_PLOG_SPEEDA taxa à qual o physical log pode ser recuperado durante um fast recovery.
RAS_LLOG_SPEEDA taxa à qual o logical log pode ser recuperado durante um fast recovery. Não configuravel. IDS atualiza esses valores para refletir a velocidade de recuperação real. ( As unidades são paginas por segundos).
AUTO_CKPTSAtiva ou desativa checkpoints automaticos.
AUTO_LRU_TUNINGAtiva ou desativa o ajuste automático de LRU
AUTO_AIOVPSAtiva ou desativa a capacidade do servidor de banco de dados para aumentar o número de AIO VPs automaticamente e descarrega threads quando o servidor detectar que AIO VPs não estão acompanhando a carga de trabalho.
SQLTRACEControla o comportamento padrão, como o numero de instruções SQL para rastrear e o modo de rastreamento do recurso de consulta drill-down.
EXPLAIN_STATAtiva ou desativa a inclusão de uma seção de estatísticas de querys no arquivo explain.out que a declaração SET EXPLAIN gerou ou o comando onmode –Y session_id pode mostrar.
USELASTCOMMITTEDEspecifica se o servidor de banco de dados usa a ultima dos dados comitados quando ocorre um bloqueio.
SHMVIRT_ALLOCSEGEspecifica um limite no qual o IDS deve alocar a memória do servidor e do nivel de alarme ativado se o servidor não poder alocar o novo segmento de memória.
ENCRYPT_HDRAtiva ou desativa a criptografia entre os servidores HDR pareados.
LOG_INDEX_BUILDSDefine para 1 (um) para habilitar o log das paginas de indice durante a instrução CREATE INDEX. Obrigatorio no nó primario ao utilizar nós Secundario (RSS).
ENCRYPT_SMX0. Não utiliza criptografia em conexão SMX
1. Negocia a criptografia em conexão SMX
2. Deve-se utilizar criptografia em conexão SMX

quarta-feira, 25 de abril de 2012

System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix

Configurando a Conectividade

Existem três metodos disponiveis para a configuração da conectividade entre client-server e o sistema on-line:

  1. Através de uma conexão de memória compartilhada. Quando a aplicação cliente o e servidor de banco de dados estão no mesmo computador, este é o método preferido de comunicação. Aplicação e o servidor de banco de dados trabalha no mesmo segmento de memória compartilhada.
  2. Através de uma conexão TCP/IP, usando SOCKETS ou uma interface de programação TLI. TCP/IP pode ser usado em ambas comunicações,locais e remoto.
  3. Através  de uma conexão “stram pipe”. Isso é uma conexão local, metodo de comunicacao que o UNIX utiliza.
arquivo sqlhosts

Quando um aplicativo tenta uma conexão com um servidor de banco de dados, há algumas informações basicas que necessitam ser configuradas para fazer a conexão. Essas informações  estão armazenadas em $INFORMIXDIR/etc/sqlhosts, um arquivo que deve ficar no diretorio $INFORMIXDIR/etc. Para alterar o local do arquivo slqhosts, utilize a variavel de ambiente INFORMIXSQLHOSTS. Cada servidor que hospeda um banco de dados ou um cliente deve ter um arquivo sqlhosts.

Cada entrada (cada linha) do arquivo sqlhosts contem as informações para um banco de dados. Utilize espaços em brancos (espaços, tabulação ou ambos) para separar os campos. Não inclua espaços em branco ou tabulação dentro de um campo. Para colocar comentarios no arquivo sqlhosts, inicie a linha com um caracter (#). Você também pode deixar linhas totalmente me branco para facilitar a leitura.  Regras de sintaxe adicionais para cada um dos campos serão fornecidos nas postagens seguintes, que descrevem as entradas no arquivo sqlhosts. Use um editor de texto padrão para inserir as informações no arquivo sqlhots.

Exemplo de um arquivo sqlhosts
dbservername nettype hostname servicename
tst onipcshm isis tst
tstsoc onsoctcp isis tstsrv
prdsoc onsoctcp vishnu prdsrv

dbserver corresponde à variavel de ambiente INFORMIXSERVER e DBSERVERNAME ou DBSERVERALIASES no arquivo ONCONFIG.

A coluna nettype contém informações cruciais sobre tipo de servidor de banco de dados e como as conexões vão ser feitas. O nettype consiste em oito letras dividas em três categorias.

As duas primeiras letras representam o produto do banco de dados. As proximas três letras referem-se a interface de programação usado para a conexão. As três ultimas letras referem-se ao protocolo especifico ou mecanismo IPC.

onde:

d = produto,
i = interface,
p = protocolo

ddiiippp

on – Dynamic Server
se – Standard Engine

ipc – Conexão IPC
tli – Conexão TLI
soc – Conexão socket

shm – Shared memory
str – Stream pipes
tcp – Protocolo TCP/IP
spx – Protocolo IPX/SPX

Hostname  é o nome do servidor que esta armazenado o banco de dados.

Todos os nomes de serviços é necessario estar no /etc/services.

Exemplo de um arquivo /etc/services

tstsrv 1550/tcp
prdsrv 1540/tcp

terça-feira, 24 de abril de 2012

Planejamento para um cluster de alta disponibilidade em Informix

Antes de você iniciar  a configuração dos servidores e banco de dados para usar com um cluster de alta disponibilidade, você pode querer fazer um planejamento inicial. A lista a seguir contem as tarefas a realizar:

  • Escolher e adquirir hardware apropriados;
  • Se você estiver usando mais de um servidor de banco de dados para armazenar dados que você deseja replicar, migrar dados e redistribuir, veja se existe a possibilidade de ser gerenciado por um unico servidor de dados.
  • Assegurar que todos os banco de dados que você deseja replicar esteja em modo “transaction loggin”.
  • Desenvolver aplicativos para fazer uso de ambos os servidores de banco de dados de replicação.
  • Criar uma programação para iniciar o HDR pela primeira vez.
  • Projetar um espaço de armazenamento e programação dos backups de logical logs para o servidor de banco de dados primario.
  • Produzir um plano de como lidar com falhas de um servidor de banco de dados e como reiniciar o HDR após uma falha.

Configurando Clusters

Para configurar seu sistema como um cluster de alta disponibilidade, você deve tomar as seguintes ações:

  • Conheça os requisitos de hardware e sistema operacional;
  • Atender aos requisitos dos dados de banco de dados;
  • Atender aos requisitos de configuração do banco de dados;
  • Configurar a conectividade.

Vamos explanar cada item acima.

Você pode configurar seu sistema para usar o Secure Sockets Layer (SSL), um protocolo de comunicação que garante a privacidade e integridade dos dados transmitidos através da rede, para a comunicação do HDR. Você pode usar o protocolo SSL para conexões entre os servidor primario e secundario e para conexões com servidores secundarios Remote Standalone(RS) e Shared Disk(SD) em uma configuração de alta disponibilidade.

Requisitos de Hardware e Sistema Operacional

Para um cluster de alta disponibilidade funcionar, o hardware deve atender a certos requisitos.

O hardware deve atender aos seguintes requisitos:

  • Os servidores primario e secundario deve ser capaz de executar  a mesma imagem do IBM Informix, mesmo que eles  não tenham Hardware e Sistemas Operacionais identicos. Por exemplo, você pode usar servidores com diferentes Sistemas Operacionais Linux 32-bit porque nesses Sistemas Operacionais a imagem do Informix poderá ser executada. Nesta situação, você não pode  adicionar um Servidor com Sistema Operacional Linux 64-bit porque nesse Sistema Operacional é exigida uma outra imagem do Informix, (Informix 64-bit). Verifique o arquivo “machine notes”: você poderá utilizar alguma combinação de hardware e Sistemas Operacionais suportados no mesmo arquivo “machine notes”.
  • Os Hardwares que executa os servidores primario e secundario devem suportar conectividade com redes.
  • A quantidade de espaço em disco alocado para os dbspaces secundario devem ser identicos ao servidor primario. O tipo de espaço em disco  é irrelevante; você pode usar uma mistura de raw devices com cooked files nos dois servidores.
  • Os chunks nos dois servidores devem estar no mesmo caminho. Os links simbólicos são permitidos em plataformas UNIXs, mas não na plataforma Windows.

Requisitos dos dados e banco de dados

Os dados e banco de dados deve atender aos seguintes requisitos:

  • Todos os dados devem ser “logged”.

    Todos os banco de dados que você quer replicar deve estar em modo “transaction logging”.

    Este requisito é importante porque o servidor de banco de dados secundario utiliza os registros de logical logs do servidor primario para se auto atualizar. Se o banco de dados primario não utiliza o logical logs, não será capaz de gerar os logical logs para atualizar os outros servidores. Os registros podem ser “buffered” ou “unbuffered”.
  • Os dados deve estar localizado no mesmo dbspace ou sbspaces

    Se o servidor primario tem “simple large objects” armazenados em blobspaces, modificações nos dados dentro dessa blobspace não são replicados como parte do processamento normal do HDR. No entanto,  dados “simple large objects” são replicados.

    ”Smart large objects”, que são armazenados em sbspaces, são replicados. O sbspace deve estar em “logged”. “User-defined types” (UDTs) são replicados, a menos que eles estejam armazenados no Sistma Operacional.
  • Os servidores secundarios não deve usar compressão de disco.

    Se você utilizar o recurso de compressão de disco do Informix, dados que é comprimido na tabela de origem é comprimido na tabela de destino. Você não pode executar operações de compactação em um servidor HDR secundario., RS secundario ou SD secundario, porque o servidor HDR de destino deve ter os mesmos dados e layout físico com o servidor de origem.

Requisitos de configuração do servidor de banco de dados

Para os servidores de alta disponibilidade do cluster funcionar, você deve configurar completamente cada um dos servidores de banco de dados.

Estes tópicos descrevem as considerações de configuração para os pares de cluster de servidor de banco de dados:

  • Versão do servidor de banco de dados
  • Configuração do dbspace e chunk
  • Tamanhos de paginas em ambientes HDR
  • Espelhamento
  • Configuração do Physical-log
  • Dbspace e dispositivos de backup para  logical-log
  • Configuração dos Logical-logs
  • Configuração dos parametros do HDR
Versão do servidor de banco de dados

A versão do servidor de banco de dados no servidor primario e secundario deve ser identicas.

Configuração do dbspace e chunk

O numero de dbspaces, o numero de chunks, os seus tamanhos, os nomes de caminhos, e seus offsets devem ser identicos nos servidores,  primario e secundarios. Além disso, a configuração deve conter pelo menos um dbspace temporário se o HDR secundario for usado para gerar atividades de relatorios.

somente UNIX:

Você deve usar links simbolicos para os chunks criados em raw devices.

Importante: Se você não usar links simbolicos para os nomes do caminho dos chunks, você não poderá mudar o nome do caminho de um chunk facilmente.

Os seguintes parâmetros do ONCONFIG devem ter o mesmo valor em cada um dos servidores HDR:

  • ROOTNAME
  • ROOTOFFSET
  • ROOTPATH
  • ROOTSIZE
Tamanhos de paginas em ambientes HDR

O tamanho de paginas de um dbspace, e e as especificações do buffer pool são propagadas automaticamente do servidor primario para o servidor secundario. Embora o servidor primario e os secundarios devem ter os mesmos buffer pools, os números de buffers em buffer bool não são obrigatórios.

Espelhamento

Você não é obrigado a definir o parametro MIRROR para o mesmo valor nos dois servidores de banco de dados; você pode habilitar o espelhamento em um servidor de banco de dados e desabilitar no outro servidor. Entretanto, se você especificar um chunk espelhado para o rootdbs do servidor primario, você tera que especificar um chunk espelhado também para o servidor secundario. Portanto, os seguintes parametros do ONCONFIG deve ser definido para o mesmo valor em ambos os servidores de banco de dados:

  • MIRROROFFSET
  • MIRRORPATH
Configuração do Physical-log

O physical log deve ser identico em ambos os servidores. A seguir os parametros do ONCONFIG que devem ser os mesmos valores em cada servidor:

  • PHYSBUFF
  • PHYSFILE
Dbspace e dispositivos de backup para logical-log

Você pode especificar diferentes  dispositivos de fitas para os servidores primario e secundario.

Se você usa o ON-Bar, configure os parametros de configuração do ON-Bar com os mesmos valores em ambos os servidores.

Se você utiliza o ontape, o tamanho do dispositivo e o bloco do dispositivo para o dispositivo de armazenamento e logical-log devem ser identicos.   A seguir os parametros do ONCONFIG que devem ter os mesmos valores em ambos os servidores:

  • LTAPEBLK
  • LTAPESIZE
  • TAPEBLK
  • TAPESIZE
Configuração dos Logical-logs

Todos os registros de logical-logs são replicados para o servidor secundario. Você deve configurar os numeros de arquivos de logical-log e o tamanho dos logical-log com valores iguais em ambos os servidores. Abaixo segue parametros do ONCONFIG que devem ter os mesmos valores:

  • LOGBUFF
  • LOGFILES
  • LOGSIZE
  • DYNAMIC_LOGS
Configuração dos parametros do HDR

A seguir os parametros de configuração do HDR que devem conter o mesmo valor em ambos os servidores:

  • DRAUTO
  • DRINTERVAL
  • DRTIMEOUT

segunda-feira, 23 de abril de 2012

System Administration Certification exam 918 for IBM Informix Dynamic Server 11 prep, Part 1– Instalação e Configuração do Informix

Gerenciando espaço em disco

O servidor de banco de dados utiliza as seguintes físicas para gerenciar disco:

  • Chunk
  • Page
  • Extent
  • Blobpage
  • Sbpage

Chunk

Chunk é uma unidade de disco ou um espaço físico atribuído para o servidor. Um chunk pode ser um raw device (device de character especial) ou arquivo UNIX (cooked file). Quando atribuir chunk para o server, você precisa especificar os três valores seguintes:

  1. Pathname: o caminho do arquivo ou o nome do raw device a ser utilizado para o chunk.
  2. Offset: a distância física, especificado em KB a partir do início do dispositivo onde a leitura e escrita do dispositivo começa. Se você criar chunks usando cooked files, use o offset como zero; o offset maior que zero é somente usado com raw devices.
  3. Size: é o tamanho do espaço criado em KB, atribuido para ser utilizado com raw device a partir do offset ou o tamanho do arquivo UNIX usado para o chunk.

O server tem um limite lógico de 32.767 chunks. No entando, o Kernel do UNIX pode ter limitações para o numero de arquivos de um processo.

Page

É a unidade basica que o server utiliza para I/O é paginas. Começando pela versão 10 do IDS, o tamanho da pagina não é mais corrigido com base na plataforma do produto. Qualquer chunk/dbspaces criado após o root dbspace pode ter tamanhos de paginas entre 2K à 16K. Usando multiplos de tamanho de paginas como padrão. Um conjunto de buffers  é criado se não existir paginas do tamanho especificado.

Extent

Coleção de paginas fisicas continuas em um disco. Tamanhos das extents da tabela são especificados no momento da criação da tabela.

Blobpage

Blobpage é a unidade básica de armazenamento para os dados tipos blobs armazenados em blobspaces. O tamanho da blobpage pode ser configurado para ser múltipo do tamanho de paginas do sistema.

Sbpage

Um sbpage é um tipo de pagina que o server usa para armazenar objetos grandes (smart large objects) dentro de um sbspace. Ao contrario dos blobpages, sbpages não são configuraveis. Sbpage é do mesmo tamanho das paginas do servidor de banco de dados.

Unidades Lógicas

O servidor de banco de dados armazena as dados nas seguintes unidades lógicas:

  • Dbspace
  • Blobspace
  • Sbspace
  • Tblspace

Dbspace

Dbspace é uma coleção lógica de um ou mais chunks usados para armazenar bando de dados e tabelas. Cada dbspace deve ter pelo menos um chunk atribuido a ele.

Blobspace

Um blobspace é uma unidade lógica de armazenamento composto de um ou mais chunks que armazena somente dados TEXT e BYTE. O servidor de banco de dados gravados em blobspaces diretamente em discos. Estes dados não passam pela shared memory residente.

Sbspace

Um sbspace é um unidade lógica de armazenamento composto de um ou mais chunks que armazena os “smart large objects”, isso incluem BLOB, CLOB e UDTs (user-defined data type).

Tblspace

Tblspace é uma coleção de todos os extents alocados para armazenar informações  para uma detrminada tabela ou índice em um único dbspace. Espaço representado por uma tblspace não são continuas necessáriamente, mas o espaço representado por qualquer uma das extents são continuos.

Criando dbspace com onspaces

onspaces
-c
-d <dbspace>
-k <pagesize>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
-t <tempspace>


onde

spacename é o nome da dbspace a ser criada.
pagesize é o tamanho das paginas a ser criada para o novo dbspace.
mpathname é o pathname do mirror
moffset é o offset do mirror
offset é offset dentro do dispositivo em KB.
pathname é o caminho para inicializar o chunk.
-t indica que o dbspace criado é temporario.

Exemplo: Para criar um dbspace espelhado de 1 milhão de KB chamado de dbspace1 com offset de 200.000 KB para inicializar um chunk primario e um offset de 450.000 para o chunk espelhado.

onspaces –c –d dbspace1 –p /dev/rdsk/device1 –o 200000 –s 1000000 –m /dev/rdsk/device2 450000

Criando blobspace

onspaces
-c
-b <spacename>
-g <blobpagesize>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>

Exemplo: Para criar um blobspace espelhado de 1 milhão de KB chamado de blobsp1 com offset de 200.000 KB para inicializar ambos chunks (primario) e um chunk espelhado e um blobpage de 100 KB (2K tamanho da pagina do sistema).

onspaces –c –b blobsp1 –g 50 –p /dev/rdsk/device8 –o 200000 –s 1000000 –m /dev/rsdk/device9 200000

Criando um sbspace

-c
-S <spacename>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>
-t
-Ms <metasize>
-Mo <metaoffset>
-Df <options>

onde

spacename é o nome do blobspace a ser criado.
blobpagesize é o tamanho do blobpage em número de páginas em disco.
mpathname é o pathname do espelhamento
moffset é o offset do mirror
pathname é o caminho do chunk.
size é o tamanho do chunk em KB.
-t indica se o dbspace criado é temporario
metasize é o tamanho da área do sbspace em KB
metaoffset é o tamanho da área do offset do sbspace em KB.

Exemplo: Para criar um sbspace espelhado de 1 milhão de KB chamado de sbspace1 com um offset de 200.000 KB para inizializar ambos chunks (primario) e um chunk espelhado , com um metadado no tamanho de 7500 KB com 10000 KB de offset e uma expectativa média  de smart blobsize de 32KB.

onspaces –c –S sbspace1 –p /dev/rdsk/device5 –o 200000 –s 1000000 –m /dev/rdsk/device6 200000 –Ms 7500 –Mo 10000 –Df “AVG_LO_SIZE=32”

Eliminando Espaços

O utilitario onspaces pode ser usado para eliminar um dbspace, blobspace ou sbspace via linha de comando do sistema. Antes de um dbspace ser eliminado, todos os bancos e tabelas criados nesse dbspace deve ser eliminado.

Antes de um blobspace ser eliminado, todas as tabelas que possuem coluna TEXT/BYTE do blobspace tem que ser eliminado.

Exemplo:

onspaces –d dbspace1

Adicionando um chunk para um dbspace ou blobspace

O utilitario onspaces pode ser usado para adicionar um chunk num dbspaces ou blobspaces.

onspaces
-a <spacename>
-m <mpathname moffset>
-o <offset>
-p <pathname>
-s <size>

Exemplo: Para adicionar um chunk espelhado de 500.000 KB para o dbspace dbspace2 com 100.000 KB de offset.

onspaces –a dbspace2 –p /dev/rdsk/device4 –o 100000 –s 500000

Adicionando um chunk para um sbspace

o utilitario onspace pode ser usado para adicionar chunk para um sbspace.

Exemplo: Para adicionar um chunk espelhado de 100.000KB a um sbspace (sbspace1) com um offset de 20.000 KB para inicializar ambos chunks e metadado de 750 KB e 1000 KB de offset.

onspaces –a sbspace1 –p /dev/rdsk/chunk6 –o 20000 –s 100000 –m /dev/rdsk/chunk7 –Ms 750 –Mo 1000

SQL admin API

Você pode usar  as nova função SQL de administração para funções API para realizar  tarefas administrativas remotamente através do EXECUTE FUNCTION de SQL. Eles são as funções ADMIN e TASK. Estes fornecem uma interface SQL para administração como uma linha de comandos.  Só podem ser chamado pelo usuário informix e são definidos no banco de dados sysadmin.

As funções ADMIN  e TASK executa uma tarefa especifica o que equivale a um utilitário administrativo, insere uma nova linha dos historicos de comandos na tabela command_history do banco de dados sysadmin.

Criando um dbspace usando a função TASK()

EXECUTE FUNCTION TASK (‘create dbspace’, ‘dbs1’, ‘/dev/rdsk/device1’,’200000’,’1000000’);
Output: (expression) Space ‘dbs1’ added.

Eliminando um dbspace usando a função TASK()

EXECUTE FUNCTION TASK (‘drop dbspace’,’dbs1’);
Output (expression) Space ‘dbs1’ dropped.
** WARNING ** A level 0 archive will need to be done before any chunks from
DBspace dbs1 can be reused (see Dynamic Server Administrator’s manual).

Adicionando espelhamento para o dbspace acima usando a função TASK()

EXECUTE FUNCTION TASK (‘add mirror’, ‘dbs1’,’/dev/rdsk/device1’,’200000’,’/dev/rdsk/device2’,’450000’);
Output: (expression) Mirror chunk ‘/dev/rdsk/device2’ added to space ‘dbs1’

Criando um blobspace usando a função TASK()

EXECUTE FUNCTION TASK (‘create blobspace’, ‘blobsp1’, ‘/dev/rdsk/device8’, ‘50’,’200000’,’1000000’);
Output: (expression) Space ‘blobsp1’ added.

quarta-feira, 18 de abril de 2012

Guia do Iniciante para HDR no IDS 11.50

Conceitos e Beneficios do HDR

  • HDR permite  que todos os dados em uma instancia IDS seja copiada em um outro servidor em uma rede;
  • É uma “instace level”, tecnologia de replicação para fornecer copias de seus dados para outros servidores Informix.
  • Não tem restrições, como exigir chaves primarias em suas tabelas, etc. Exige que seus bancos de dados sejam “logged”,  no entento, sua tecnologia é baseada nos registros de logs. Isso não replica dados BLOBspaces.
  • Sistemas Operacionais subjacentes e versão do IDS deve ser identica nos servidores envolvidos o HDR.
  • Beneficios em caso de desastres: Servidores e Dados são redundantes minimizando o downtime
  • Pode-se criar um Servidor de relatorios com o servidor secundario, tendo o beneficio da performance: descarregamentos de algumas atividades, queries no servidor secundario. Melhor performance.
  • Dados locais para usuarios remotos, melhor performance.

HDR antes da versão 11

  • Primario: Este é o servidor que os usuários normalmente se conectam. Permite atualizações de dados, como de costume.  Este é a fonte de dados copiado para o secundario.
  • Secundario: Um servidor de backup somente leitura que recebe atualizações do primario.

HDR (IDS 11.50)

  • Primario: Este é o servidor que os usuários normalmente se concectam. Permite atualizações de dados  como de costume. Este é a fonte de dados copiado para o secundario.
    Uma das melhorias mais importantes em HDR a partir da versão 11.10 é que agora você pode ter multiplos servidores secundarios, ates você estava limitado a somente um servidor secundario. Alem disso, existem diferentes tipos de servidores secundarios que lhe permite uma configuração adequada para suas necessidades empresarias.
  • Secundario: Servidor de backup que recebe os dados do servidor primario. Ele também permite UPDATEs usando o “redirect writes” (ex, as atualizações  são realmente enviadas para o servidor primario e, em seguida recebidos através de replicação.
  • Checkpoints entre o servidor Primario e o HDR secundario são sempre sincronizados.
  • Commits entre o servidor Primario e o servidor secundario pode ou não ser sincronizados (depende da sua configuração).
  • Servidor secundario Standalone remoto (RSS): Um novo tipo  de servidor secundario foi introduzido na versão 11.10 o que é atualizado em modo assincrono e tem mais conectividade mais flexivel com o servidor primário.
  • Adequado para usar como um servidor de relatorios e tambem locais distantes geograficamente e em redes de baixa velocidade, para fazer balanceamento de CPU, memoria, e tambem como um rápido  e facil failover se o servidor primario falhar.
  • Requer indexação em paginas de logging.
  • Shared Disk Secondary (SDS): Um novo tipo de servidor secundario introduzido na versão 11.10. Tal como o nome implica, ele não tem sua própria  copia separada do espaços de disco. Discos compartilhados com o servidor primario.
  • Normalmente usado com arrays de discos ou SAN shared

HDR no IDS 11.50

  • Os servidores que participam do HDR são servidores IDS regulares, colocado em um papel especifico ( primario, HDR, secundario, RSS, SDS) usando o comando onmode.
  • Pode haver um servidor primario, zero ou um HDR secundario, e zero, um multiplos servidores RSS e SDS em um clauster MACH 11 ( MACH = Multi node Active Cluster for High availability)
  • Servidores RSS/SDS pode ser seus unicos servidores secundarios, ou eles podem ser utilizados com um HDR secundario.
  • HDR é inicialmente configurado com um backup nivel zero e um physical restore (execto para servidores SDS).
  • Após a configuração inicial, os dados entre os servidores são mantidos em sincronia usando os logical logs.

hdr

  • DRINTERVAL – parametro onconfig que controla se a replicação ocorre de maneira assincrona ou sincrona.
  • DRINTERVAL –1 – (sincrono, ex. servidor primario aguarda por notificação vindo do servidor secundario antes de descarregar o logical-log buffer, como um commit)
  • DRINTERVAL outro valor exeto –1 ( assincrono – exemplo 30 segundos)
  • HDR Threads
    • drprsend: (primario) envia buffers
    • drsecrecv: (secundario) recebe buffers
    • drprping: (primario) checa a conectividade
    • drsecping: (secundario) checa a conectividade
    • drsecapply: (secundario) recepção da copia do buffer para o recuperação do buffer
    • logrecvr: (secundario) recuperação logica – atualização dos dbspaces
    • RSS_send: usa uma comunicação full duplex ( ex. sem aguardar o recebimento de uma notificação), esse thread envia paginas de logs para um servidor RSS. (roda no servidor primario)
    • RSS_recv: recebe paginas de logs vinda do servidor primario. (roda no servidor RSS)
    • RSS_apply: copia o conteudo do buffer de recepção para o buffer de recuperação. (roda no RSS server)
  • Atualizando o servidor secundario através do Redirected Writes
    • uma das melhorias mais significantes na versão HDR 11.50
    • Servidores secundarios (todos os tipos) agora permitem atualizações de dados.
    • As atualizações são transferidas para o servidor primario e então propagadas de volta para o servidor secundario
    • Inserts, updates e deletes para a maioria dos tipos de dados são suportados.
    • Usando as novas caracteristicas de controle de versões do IDS faz escritas redirecionadas  trabalhando com maior eficiencia.
  • Gerencimaneto de conectividade
    • Novo componente de software que gerencia os pedidos de conexões a partir das aplicações clientes.
    • Permite você definir niveis de serviços (SLAs) e configuração automatica failover.
    • Monitora todos os servidores dentro do clauster.
    • Pode decidir sobre o servidor mais adequado para a conexão da aplicação cliente.
  • Planejar um servidor HDR é obrigação
  • Requisitos de negocios ( ex. planejamento de recuperação de desastre, capacidade adicional de comunicação, dados locais) conduz a configuração técnica.
  • Com base nos requisitos de negocios, hardware/software disponiveis e redes disponiveis, você decidira sobre o tipo  e o numero de secundários.
  • Sistema Operacional e versão do Informix tem que ser identica.
  • Layouts dos chunks deve ser identico ( mas espelhamentos de chunks não há necessidade)
  • Banco de dados devem ser logged.

Planejamento e configuração do HDR

DRAUTO

0 (OFF) – significa não mudar automaticamente o tipo de servidor.
1 (RETAIN_TYPE) – significa mudar automaticamente do secundario para o padrao se a replicação falhar, volta para o secundario  quando o HDR reinicializar.
2 (REVERSE_TYPE) – significa mudar automaticamente do secundario para o padrao numa falha, para o primario quando o HDR reinicializar.

DRIDXAUTO

0 (off) significa que não há replicação automatica de indices para o secundario caso esteja corrompido.
1 (on) significa replicação automatica dos indices  para o servidor secundario se os indices estiverem corrompidos.  A configuração habilitada é requerida para servidores RSS.

DRINTERVAL

Interalo maximo, em segundos, entre a descarga do buffer de replição.
Valores aceitos –1, 0 e valores positivos inteiros
Valor padrão é de 30 segundos o que significa que se pode levar até 30 segundos para que as alterações do servidores primarios seja replicado para o servidor secundario.
-1 – significa configuração sincrona.

DRLOSTFOUND

Caminho para os arquivos lost&found da replicação.
Quando a replicação assincrona é utilizada e em caso de falha, isso possibilita que algumas transações sejam comitadas no servidor primario mas não no servidor secundario. Essas transações são armazenadas em um arquivo em lost&found.

DRTIMEOUT

Periodo de tempo, em segundos, que o servidor primario aguarda para receber uma notificação vinda do servidor secundario.
Após este periodo de tempo decorrido e sem notificação de recebimento, o Informix reconhece que houve uma falha.
Default é 30 segundos.

Passo a passo:

Requisitos e planejamento são completos e seguindo um cenário tipico é selecionado:

passo

Primeiro passo:

Assegurar que todos os servidores tem o TCP/IP necessário configurados como por exemplo /etc/hosts.

vishnu server

vishnu:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost


10.0.1.5        vishnu.ajmsolutions vishnu
10.0.1.9        isis.ajmsolutions isis
vishnu:~ #

isis server

isis:~ # cat /etc/hosts
#
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.
# Syntax:
#
# IP-Address  Full-Qualified-Hostname  Short-Hostname
#

127.0.0.1       localhost

10.0.1.9        isis.ajmsolutions isis
10.0.1.5        vishnu.ajmsolutions vishnu
127.0.0.2      isis.ajmsolutions isis
isis:~ #

Segundo passo:

Assegurar que todos os servidores estão em modo de confiança entre si (“trust mode”) -  /etc/hosts.equiv

vishnu server

vishnu:~ # cat /etc/hosts.equiv
#
# hosts.equiv   This file describes the names of the hosts which are
#               to be considered "equivalent", i.e. which are to be
#               trusted enough for allowing rsh(1) commands.
#
# hostname
isis
vishnu:~ #

isis server

isis:~ # cat /etc/hosts.equiv
#
# hosts.equiv   This file describes the names of the hosts which are
#               to be considered "equivalent", i.e. which are to be
#               trusted enough for allowing rsh(1) commands.
#
# hostname

vishnu
isis:~ #

Terceiro Passo:

Verifique se o serviço do informix (ports) de cada servidor não esta bloqueado e esta sendo reconhecido em cada servidor (/etc/services)

vishnu server

vishnu:~ # cat /etc/services |egrep "prdsrv|tstsrv"
prdsrv          1540/tcp
tstsrv           1550/tcp
vishnu:~ #

isis server

isis:~ # cat /etc/services |egrep "prdsrv|tstsrv"
prdsrv          1540/tcp
tstsrv          1550/tcp
isis:~ #

Quarto Passo:

Garantir que cada servidor tem entradas dos outros servidores em seus arquivos sqlhosts do Informix. Você deve usar uma conexão TCP/IP e não conexões de memorias compartilhadas  para configuração do HDR.

vishnu server

informix@vishnu:/> cat $INFORMIXDIR/etc/sqlhosts
#**************************************************************************
#
#  Licensed Material - Property Of IBM
#
#  "Restricted Materials of IBM"
#
#  IBM Informix Dynamic Server
#  (c) Copyright IBM Corporation 1996, 2004 All rights reserved.
#
#   Title:      sqlhosts.demo
#   Description:
#               Default sqlhosts file for running demos.
#
#**************************************************************************
# IANA (www.iana.org) assigned port number/service names for Informix:
# sqlexec 9088/tcp
# sqlexec-ssl 9089/tcp

prd        onipcshm     vishnu    prd
prdsoc  onsoctcp       vishnu   prdsrv
tstsoc   onsoctcp       isis         tstsrv

informix@vishnu:/>

isis server

informix@isis:~> cat $INFORMIXDIR/etc/sqlhosts
#**************************************************************************
#
#  Licensed Material - Property Of IBM
#
#  "Restricted Materials of IBM"
#
#  IBM Informix Dynamic Server
#  Copyright IBM Corporation 1996, 2009
#
#   Title:           sqlhosts.demo
#   Description:     Default sqlhosts file for running demos.
#
#**************************************************************************
# The connectivity information for each database server includes four fields
# of required information and one optional field. You can also configure
# database server groups.
#
# The format for the five fields of connectivity information for a database
# server is one line in the UNIX  sqlhosts file, as follows:
#
# <dbservename> <nettype> <hostname> <servicename> <options>
#
# dbservername is the name of a database server on the network.
#
# nettype is an 8-character string specifying the protocol in this format:
#
# ddiiippp
#
# where
#   dd  =  Database product [|ol|on|dr]
#   iii =  Interface type [ipc|soc|tli|sql]
#   ppp =  Protocol [imc|nmp|shm|spx|str|tcp|ssl|mux]
#
# hostname is the name of the computer where the database server resides.
#
# servicename is a service name entry from the services file.
#
# options in the fifth field:

#
#   b=<connection buffer size>
#   c=<connection redirection>
#   g=<group name>
#   i=<group identifier>
#   e=<end of group>
#   m=<multiplexed connection>
#   k=<keep alive setting>
#   r=<client security setting>
#   s=<server security setting>
#   csm=<communication support module>
#
# To create an entry for a group, put a group name in the dbservername field,
# the word group in the nettype field, a hyphen in both the hostname and the
# servicename fileds, and i=<group identifier> in the options field.
#
# For additional information on the parameters, see the IBM Informix
# Administrator's Guide.
#**************************************************************************
# IANA (www.iana.org) assigned port number/service names for Informix:
# sqlexec 9088/tcp
# sqlexec-ssl 9089/tcp


tst         onipcshm        isis               tst
tstsoc   onsoctcp          isis               tstsrv
prdsoc  onsoctcp          vishnu          prdsrv
informix@isis:~>

Quinto Passo:

Assegure-se que os seguintes valores do ONCONFIG estejam identicos entre os servidores.

ROOTNAME, ROOTPATH, ROOTOFFSET, ROOTSIZE
PHYSDBS, PHYSFILE
TAPEBLK, TAPESIZE, LTAPEBLK, LTAPESIZE
LOGFILES, LOGSIZE
DRAUTO, DRINTERVAL, DRTIMEOUT

Sexto Passo:

Pegue um archive nivel 0 do servidor primario (vamos utilizar mais adiante)

Setima Passo:

Configurar o servidor primario para iniciar como um primario ligando ao servidor secundario

informix@vishnu:~/etc> onmode -d primary tstsoc

Oitavo Passo

Restaurar o archive nivel 0 como uma restauração fisica no HDR secundario.

informix@isis:~> ontape -p
Restore will use level 0 archive file /ontapeDir/archiveDir/isis_0_L0. Press Return to continue ...


Archive Tape Information

Tape type:      Archive Backup Tape
Online version: IBM Informix Dynamic Server Version 11.50.FC8GE
Archive date:   Wed Apr 18 11:58:18 2012
User id:        informix
Terminal id:    /dev/pts/0
Archive level:  0
Tape device:    /ontapeDir/archiveDir/
Tape blocksize (in k): 32
Tape size (in k): system defined for directory
Tape number in series: 1

Spaces to restore:1 [rootdbs                                                                                                                         ]
2 [dbsphyslog                                                                                                                      ]
3 [dbslog                                                                                                                          ]
4 [dbsnfe                                                                                                                          ]
5 [prd                                                                                                                             ]
6 [dbscrm                                                                                                                          ]

Archive Information

IBM Informix Dynamic Server Copyright 2001, 2010  IBM Corporation.
Initialization Time       07/17/2011 00:47:09
System Page Size          2048
Version                   18
Index Page Logging        OFF
Archive CheckPoint Time   04/18/2012 11:58:17

Dbspaces
number   flags    fchunk   nchunks  flags    owner                            name
1        40001    1        1        N  B     informix                         rootdbs                                                        
2        40001    2        1        N  B     informix                         dbsphyslog                                                     
3        40001    3        1        N  B     informix                         dbslog                                                         
4        42001    4        1        N TB     informix                         dbstmp1                                                        
5        42001    5        1        N TB     informix                         dbstmp2                                                        
6        42001    6        1        N TB     informix                         dbstmp3                                                        
7        40001    7        1        N  B     informix                         dbsnfe                                                         
8        40001    8        8        N  B     informix                         prd                                                            
9        40001    16       1        N  B     informix                         dbscrm         

Chunks
chk/dbs offset   size     free     bpages   flags pathname
1   1   0        150000   114833            PO-B  /dbroot/rootdbs
2   2   0        500053   0                 PO-B  /dblogs/physlog/dbsphyslog
3   3   0        1750053  0                 PO-B  /dblogs/logs/dbslog
4   4   0        200053   199527            PO-B  /dbtmp/dbstmp.1
5   5   0        200053   199750            PO-B  /dbtmp/dbstmp.2
6   6   0        200053   199644            PO-B  /dbtmp/dbstmp.3
7   7   0        1500053  1145313           PO-B  /dbnfe/dbsnfe
8   8   0        1500053  63                PO-B  /dblogix/prd.1
9   8   0        1500003  16                PO-B  /dblogix/prd.2
10  8   0        1500003  18                PO-B  /dblogix/prd.3
11  8   0        1500003  175               PO-B  /dblogix/prd.4
12  8   0        1500003  284               PO-B  /dblogix/prd.5
13  8   0        1500003  86187             PO-B  /dblogix/prd.6
14  8   0        1500003  1500000           PO-B  /dblogix/prd.7
15  8   0        1500003  1500000           PO-B  /dblogix/prd.8
16  9   0        1000053  697460            PO-B  /dblogix/crm.1

Continue restore? (y/n)y
Do you want to back up the logs? (y/n)y
File created: /ontapeDir/logicalLogs/isis_0_Log0000000007
File created: /ontapeDir/logicalLogs/isis_0_Log0000000008
Log salvage is complete, continuing restore of archive.
Restore a level 1 archive (y/n) n

Nono Passo:

Configure o servidor HDR secundario para inicializar como secundario ligando ao servidor primario

informix@isis:~/etc> onmode –d secondary prdsoc

Décimo Passo:

Verifique se agora você tem um HDR pariado

vishnu server

informix@vishnu:~> onstat -g dri

IBM Informix Dynamic Server Version 11.50.FC8GE -- On-Line (Prim) -- Up 03:04:24 -- 2857436 Kbytes

Data Replication at 0xd4caf028:
  Type           State        Paired server        Last DR CKPT (id/pg)    Supports Proxy Writes
  primary        on          tstsoc                       -1 / -1         NA

  DRINTERVAL   30
  DRTIMEOUT    30
  DRAUTO       0
  DRLOSTFOUND  /usr/informix/etc/dr.lostfound
  DRIDXAUTO    0
  ENCRYPT_HDR  0
  Backlog      0

informix@vishnu:~>

isis server

informix@isis:~> onstat -g dri

IBM Informix Dynamic Server Version 11.50.FC8GE -- Fast Recovery (Sec) -- Up 01:03:41 -- 2889780 Kbytes

Data Replication at 0xf320f028:
  Type           State        Paired server        Last DR CKPT (id/pg)    Supports Proxy Writes
  HDR Secondary  on          prdsoc                       -1 / -1         N

  DRINTERVAL   30
  DRTIMEOUT    30
  DRAUTO       0
  DRLOSTFOUND  /usr/informix/etc/dr.lostfound
  DRIDXAUTO    0
  ENCRYPT_HDR  0
  Backlog      0

informix@isis:~>

terça-feira, 17 de abril de 2012

A Fábrica do Futuro

A fábrica do futuro caracteriza-se por outros aspectos, além de uma instalação repleta de robôs e um elevado grau de automação, e está devidamente organizada em torno da tecnologia, do computador, que integra, por softwares especialmente desenvolvidos, praticamente todas as atividades. Nela, há o uso generalizado de ferramentas como CAD, MRP II, ERP, EDI, e acima de tudo, destaca-se a presença do trabalhador do conhecimento ( o knowledge worker,  o colaborador que usa a cabeça, o saber, mais do que as mãos). Podemos dizer que a fábrica do futuro apresenta as seguintes características:

  • Organização da produção: focada na alta produtividade. As atividades que não agregam valor são eliminadas. A filosofia de fazer certo desde a primeira vez é levada a extremos. Os refugos e retrabalhos não são admitidos. Os métodos de trabalho têm mecanismos para a prevenção de problemas. Os níveis de estoques são baixíssimos, poís o just-in-time esta em toda parte, e os componentes são entregues diretamente nas linhas de fabricação e/ou montagem. As fabricas são extremamente limpas e organizadas, em decorrência da aplicação sistemática do housekeeping. Os colaboradores são treinados em várias funções, desde a operação, preparação e manutenção até projetos de novos produtos e/ou processos produtivos, são todos controlados por computadores por meio de software integrados.
    Hoje já existem muitas fábricas do futuro em plena operação, a exemplo dos sistemas denominados produção enxuta, que surgiram no Japão e estão se espalhando por todo o mundo.
    A autoridade do colaborador, no que se refere à qualidade do produto, é praticamente ilimitada. Ele pode, a qualquer instante, parar a linha de produção, uma vez constatada uma não-conformidade já ocorrida ou latente. O espirito de grupo e de compromisso mútuo está presente. Todos os outros colaboradores procuram ajudar na solução do problema para que a linha volte à normalidade o mais rápido possível. Metodologias de identificação e solução de problemas são amplamente difundidas e incorporadas à cultura de todos os colaboradores. A gestão dos processos é feita pela utilização de indicadores de desempenho amplamente discutidos e aceitos por todos os colaboradores que estiverem intimamente ligados aos objetivos estratégicos e táticos da empresa;
  • Projeto dos produtos e dos processos: os projetos dos produtos  são desenvolvidos juntamente com os processos onde serão fabricados. A engenharia simultânea é aplicada em larga escala, passando a ser lugar-comum em todas as empresas. A atenção aos objetivos dos clientes guia o projeto, e a utilização de técnicas como o desdobramento da função qualidade (QFD) e  a análise de falhas (FMEA) assegura maior qualidade e confiabilidade aos produtos. Os produtos têm um menor número de componentes, o que diminui os riscos de falhas e os custos, sem que se perca a flexibilidade, pois os produtos são modulados.
  • Layout: é o elemento determinante da fábrica do futuro. As fábricas grandes até então tidas como padrão são divididas em várias pequenas unidades dentro da fábrica original, devidamente focalizadas, organizadas em células de produção, com elevado grau de automação. Os novos projetos contemplam áreas reduzidas para estoques de matérias-primas e produtos acabados, e não há previsão de áreas para retrabalho. Até mesmo as áreas  reservadas para os produtos em processos são reduzidas, pois as linhas são balanceadas de forma a permitir um fluxo contínuo e sem acúmulo em determinados pontos de processo. Esse processo de mudança permite que possa se dobrar a produção utilizando-se a metade da área até então usada.
  • Comunicação visual: as informações sobre produção, produtividade, objetivos atingidos e a atingir, porcentagem de refugos, etc., estão dispostas em quadros espalhados por todas as instalações, para serem lidos, analisados e criticados por todos os colaboradores. A era dos gerentes que guardam informações para deter o poder esta chegando ao fim.  Na fábrica do futuro as informações são disponibilizadas em tempo real, como a utilização de painéis eletrônicos conectados a vários terminais de entrada de dados. A utilização de cores é explorada ao máximo, com cartões kanban, contêineres, bancadas, etc., coloridos de forma a transmitir uma ou mais informações sobre o andamento dos processos.
  • posto de trabalho:  o posto de trabalho é projetado tendo em vista  os conceitos de ergonomia, procurando o conforto, bem-estar e segurança dos colaboradores. Além disso, a fábrica do futuro é ecologicamente correta. isto é, não é poluidora. São certificadas nos termos da ISO 14000 ou normas correspondentes. A preocupação em trabalhar com materiais recicláveis está presente em todas elas.

Fonte: Martins, P. G.; Laugeni, F. P. (2006). Administração da Produção. São Paulo. Saraiva.

Soluções de disponibilidade em IDS

HDR

  • Implementado pela primeira vez com a versão 6 do Informix; ps
  • Fornece Hot Backup secundário;
  • Pode ser usado para compensar o processamento de leitura;
  • Fácil configuração;
    • Faça um backup dos dados primários e restaure;
  • Trabalha com atualização automatica dos logs no servidor secundario
    • Servidor Secundario esta em modo de recuperação;
  • Suporta commits sincronizada;

 

Soluções avançadas de Alta Disponibilidade em Informix

  • Implementado com a versão 7.22 do Informix;
  • Uso
    • Particionamento de carga de trabalho;
    • Capacidade de substituição;
  • Suporta atualizações em qualquer lugar
    • Latencia muito baixa;
    • Sincronização locais com dados globais;
  • Integrado
    • Compatível com todas as soluções de disponibilidade de outros Informix;
    • Segurança das comunicações de dados;

er

Algumas características ER

  • Templates
    • Permite um grande conjunto de tabelas para ser implementado ao longo de um grande número de nós com apenas um par de comandos;
  • Check/Sync
    • Permite  verificação/reparo/sincronização online de um ambiente;
  • Suporta mudanças de esquema;
  • Configurações de replicações
    • Permite a administração de um grande número de replicações com um único comando;

Outras características ER

  • Resolução de conflitos
    • Usado para determinar se a versão atual ou apenas recebeu versão da linha ‘ganhador’;
    • Ignorar – Linha deve ser aplicada como é;
    • Timestamp – Atualizações mais recentes vence;
    • Store Procedure;
  • Direcionamento
    • Root, non-root e leaf nodes;
  • Integração com HDR
  • Permite um nó ER para ser um nó HDR

Remote Standalone Secondary (RSS)

  • Próximo passo para a evolução do HDR – nós RSSrss
    • Novo tipo de secundario – nós RSS
    • Pode ter 0 para N nós RSS
    • Pode coexistir com HDR Secundario
  • Uso:
    • Relatório
    • Aplicações WEB
    • Backup adicional no caso do primeiro falhar
  • Semelhança com nó HDR secundario:
    • Recebe logs do primario
    • Tem seu proprio conjunto de disco para gerir
    • RSS tem um impacto minimo no desempenho do primario
  • Diferenças  com nó HDR secundario
    • Só pode ser promovido a HDR secundario, nunca como primario
    • Modo SYNC não suportado

Compartilhamento de disco secundario (SDS – Shared Disk Secondary)

  • Proximo passo evolutivo
    • Nós SDS compartilha discos com o primario
    • Pode ter 0 para N nós SDShdr
  • Uso
    • Ajuste online da capacidade  como mudanças na demana
    • Não duplicar o espaço em disco
  • Caracteristica
    • Não requer nenhum hardware especifico
    • Simples para configurar
    • Pode coexistir com ER
    • Pode coexistir com nós HDR e RSS
  • Semelhanças com nó HDR secundário:
    • O primario pode ser trocado por qualquer nó SDS

Uso do disco compartilhado

  • Maior disponibilidade
  • Misturando atividades de relatorios e atualizações
    • Processamento de relatorios frequentes afeta o sistema de produção OLTP
  • Tendo nós DSS e OLTP trabalhando no mesmo dados
    • O primario pode ser configurado como um sistema OLTP enquanto uma  ou mais nós SDS são configurados como DSS/PDQ
  • Capacidade dinamica
    • O nó SDS é rapidamente instanciado, é facil de adicionar ou aumentar a capacidade como a mudança na demanda de trabalhos

Atualizando o secundário

O que é isto

  • Suporte adicionado no IDS 11.50
  • Suporta uma operação DML (INSERT, UPDATE e DELETE) no nó secundario
  • Usam concorrência otimizada para evitar a atualização de uma copia obsoleta da linha
  • Suporta commit de leitura em nós secundarios
  • Trabalha com os tipos de dados básicos, UDTs (aqueles que armazenam os dados no servidor) registros SMART BLOBs, e partições BLOBs.
  • Suporta tabelas temporarias – explícitos e implícitos.
  • Trabalha com ER.

Otimizando concorrencias  e escritas no secundario

  • Adicionado IDS 11.50
  • Adicionado suporte para versões de linha
    • CREATE TABLE……. WITH VERCOLS
      ALTER TABLE…… [ADD] / [DROP] VERCOLS
      • Cria uma coluna sombra que consiste em uma soma de verificação de inserção (ifx_insert_checksum) e atualiza a versão da coluna (ifx_row_version).
  • Se for determinado que a imagem anterior (before image) no secundário é diferente da imagem atual do primário, em seguida a gravação da operação não é permitida e uma EVERCONFLICT erro (-7350) é retornado.
  • Se a tabela não utiliza VERCOLS, então a before image da linha é usado para verificar se a atualização não esta tentando gravar numa linha obsoleta.

Gerenciamento de conexões

  • Mantem o conhecimento de todos nós dentro do clusterpolice
  • Registro de adição e remoção dos nós
  • Monitora os tipos de nós
  • Monitora carga de trabalho dos nós
  • Rotas aplicações  para nós do destino
  • Trabalha sobre o conceito de “Service Level Agreement (SLA)
    • Conecta-se ao primario
    • Conecta-se o melhor possivel com o secundario
  • Pode existir multiplas conexões de modo que não há nenhum ponto de falha

 

Arbitro

  • O proposito é detectar rapidamente a falha do server primario
  • Parte do gerenciador de conexões
  • Obtém a confirmação através de caminhos alternativos antes de realizar um failover
  • Executa um failover usando uma API de interface administrativa
  • Há failover para o arbitro assim como há failover para o gerenciamento de conexão.

Soluções básicas de restauração de logs continuos

lapis

log

Opções  de restauração dos continuos logs com ontape/onbar

Com as opções de restauração dos continus logs, o servidor irá suspender a restauração de log:

ontape –l –C
roll forward deve começar com o numero de log 7
a restauração de log será suspenso no numero de log 7

a restauração de log pode ser reiniciada novamente com o comando ontape

ontape –l –C
roll forward deve começar com o numero de log 8
a restauração de log será suspenso no numero de log 10

Modo de recuperação é terminado pelo comando ontape –l

Alterações dos dados externos

  • Observação do log exposto
  • Fornece uma base para o IDS nao replicado
  • Trabalha totalmente em protocolo SQL
    (UDRs e pseudo smart blob)

Algumas API basicas

  • CDC_OPENSESS()
    Estabelece um ambiente de CDC e retorna um ‘sessionID’, que é realmente um fd para um pseudo smartblob
  • CDC_SET_FULLROWLOGGING()
    Faz com que a linha inteira seja registrada. Um requisito para CDC
  • CDC_STARTCAPTURE()
    Define quais as tabelas devem ser capturado
  • CDC_ACTIVATESESS()
    Dados de alteração para ser devolvido ao cliente através do pseudo smartblob

Recuperação de dados CDC

  • Os dados são recuperados através de uma interface smartblob
  • Isso permite que aplicativos do CDC para ser escrito em qualquer ferramenta de cliente que suporta grandes objetos.
  • Implementado dentro de um banco de dados ‘CDC’ composto por UDRs e pseudo objetos, assim como o sysmater.
  • Para ler os dados do CDC e pseudos LOB
    • mi_lo_read() – UDRs
    • ifx_lo_read() – ODBC/C(++)
    • ifxLoRead() - Java