Oferecemos consultoria altamente qualificada do Banco de Dados Informix de maneira flexível e econômica. Se você está procurando uma solução para um problema específico ou deseja melhorar o desempenho geral do seu sistema, pode confiar na AJMSolutions para fornecer resultados tangíveis e mensuráveis.
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/warne/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 :
- 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
- Rotulo de segurança por coluna (column): Um rotulo de segurança associada com uma coluna em uma tabela do banco de dados
- 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:
- Set: Um set é uma coleção de elementos onde a ordem que esses elementos aparecem não é importante
- 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
- 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.
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:
- Para adicionar arquivos no final da lista usando o comando onparams –a
- 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,
- Utilize backups automaticos de logs sempre que um arquivo de log encher
- Utilize o agendador para criar tarefas que faça backup automatico de logs em determinados intervalos de tempo
- 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
- 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:
- Da taxa de atividades gerada pelas transações do physical log
- 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ção | Descrição |
| RTO_SERVER_RESTART | Permite 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_SPEED | A taxa à qual o physical log pode ser recuperado durante um fast recovery. |
| RAS_LLOG_SPEED | A 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_CKPTS | Ativa ou desativa checkpoints automaticos. |
| AUTO_LRU_TUNING | Ativa ou desativa o ajuste automático de LRU |
| AUTO_AIOVPS | Ativa 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. |
| SQLTRACE | Controla 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_STAT | Ativa 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. |
| USELASTCOMMITTED | Especifica se o servidor de banco de dados usa a ultima dos dados comitados quando ocorre um bloqueio. |
| SHMVIRT_ALLOCSEG | Especifica 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_HDR | Ativa ou desativa a criptografia entre os servidores HDR pareados. |
| LOG_INDEX_BUILDS | Define 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_SMX | 0. 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:
- 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.
- 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.
- 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:
- Pathname: o caminho do arquivo ou o nome do raw device a ser utilizado para o chunk.
- 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.
- 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
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.
- 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:
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
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;
- 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;
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 RSS
- 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 SDS
- 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 cluster
- 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
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
Assinar:
Postagens (Atom)