Compartilhando conhecimento com o mundo

Com tecnologia do Blogger.

Pesquisa

Download

Blogger Tricks

Blogger Themes

Visitas

Assuntos

12/17/2013

Procedimento para restringir o acesso ao banco de dados INFORMIX


No Informix os usuários são autenticados pelo sistema operacional (padrão), ou seja, para se conectar em um banco os usuários precisam estar criados no Linux/Windows. Abaixo o passo a passo para liberar permissão a um usuário acessar uma tabela.

No Linux o usuário Coophafe foi criado
[s343:informix]$/export/home/informix> finger Coophafe
Login: Coophafe                              Name: Coophafe - CPNJ 1234567891011 - 01/01/2013
Directory: /export/home/Coophafe             Shell: /bin/bash
Never logged in.
No mail.
No Plan.
No dbaccess de o comando grant ao banco e a tabela desejada
[s343:informix]$/export/home/informix> echo "grant connect to Coophafe ; grant select on ano to Coophafe;" | dbaccess desenv

Database selected.

Permission granted.

Database closed.
O usuário Coophafe quando for tentar acessar vai conseguir;
[s343:coophafe]$/export/home/informix> echo "select count(*) from ano" | dbaccess desenv

Database selected.

      (count(*)) 

              32

1 row(s) retrieved.

Database closed.
Na falta da permissão a tabela vai dar esses essos:
[s343:coophafe]$/export/home/informix> echo "select count(*) from ano" | dbaccess desenv

  387: No connect permission.

  111: ISAM error:  no record found.
Referencia

12/16/2013

Quando o Lock Exclusivo Realmente não é Lock Exclusivo - Informix


Este artigo que iremos abordar e demonstrar uma situação que lock exclusivo em uma tabela não é realmente exclusivo (ou que achávamos que era exclusivo), um analista questionou que uma tabela dele tinha um campo chamado ID e este campo tinha vários registros repetidos na tabela e pela lógica da programação dele isso não deveria ocorrer (o campo ID não é um campo serial e sim um decimal) a lógica da programação do analista era uma operação de select para ver o último valor do campo ID e depois um lock na tabela para inserir o registro. Foi questionado o porque o Informix não estaria "lockando" os dados como deveria fazer.

Primeira Cenário

1 - Primeiro vamos dar um select em uma tabela em modo lock table exclusivo
SQL:   New  Run  Modify  Use-editor  Output  Choose  Save  Info  Drop  Exit
Run the current SQL statements.

----------------------- desenv@desenv ---------- Press CTRL-W for Help --------

begin work;
lock table aidf in exclusive mode;
select count(*) from aidf;

 Table locked.
2 - Checando, a tabela realmente esta em lock;
[s343:informix]$/export/home/informix> echo "select owner, username, hostname, dbsname, tabname, type from 
syssessions s, sysmaster:syslocks l where sid = owner AND tabname not like 'sys%';" | dbaccess sysmaster

Database selected.

owner     35677
username  informix
hostname  s343.ms
dbsname   desenv
tabname   aidf
type      X

1 row(s) retrieved.

Database closed.
3 - Checando o processo que esta lockando a tabela
[s343:informix]$/export/home/informix> onstat -g sql 35677

IBM Informix Dynamic Server Version 11.70.FC2 -- On-Line -- Up 17 days 23:48:28 -- 1575104 Kbytes


Sess       SQL            Current            Iso Lock       SQL  ISAM F.E. 
Id         Stmt type      Database           Lvl Mode       ERR  ERR  Vers  Explain    
35677      -              desenv             LC  Not Wait   0    0    9.24  Off        

Last parsed SQL statement :
  select count(*) from aidf
4 - Com o lock ainda rodando vou tentar acessar esta tabela - vou tentar fazer um select
[s343:informix]$/export/home/informix> echo "select count(*) from aidf" | dbaccess desenv

Database selected.

  252: Cannot get system information for table.

  113: ISAM error:  the file is locked.
Error in line 1
Near character position 25

Database closed.
5 - Vamos fazer uma outra pesquisa rodando com o ISOLATION dirty read - Consegui ler a tabela mesmo ela estando em lock;
[s343:informix]$/export/home/informix> echo "set isolation dirty read; select count(*) from aidf" | dbaccess desenv

Database selected.

Isolation level set.

      (count(*))

            3000

1 row(s) retrieved.

Database closed.
Como não temos habilitado para os usuários o ISOLATION DIRTY READ o que deve estar ocorrendo são dois (ou mais) selects consecutivos e logo em seguida deve estar vindo dois insert (só com o campo ID igual para os dois);

Solução

Foi recomendado para o analista alterar a lógica do programa em vez de (select, lock e insert) que estava sendo feito para (lock, select e insert) para ter certeza que não ocorrer dois (ou mais) selects consecutivos;

Referencia

12/07/2013

Replicação no Informix


Os bancos de dados armazenam informações importantes para o seu negócio, e os empresários reconhecem que ter os dados disponiveis em pelo menos dois lugares é uma estratégia sensata. Não seria ótimo se o dba pudesse configurar o banco de dados para replicar os dados que você queria outro servidor automaticamente? Bem, no Informix desde a versão 7 tem esta funcionalidade. Isto ocorre através de um recurso chamado Enterprise Replication (ER), que é ao mesmo tempo flexível e poderosa.

O Enterprise Replication (ER) trabalha por você definir primeiro os servidores entre os quais gostaria que os dados sejam replicados. Isso cria uma topologia de rede - de root, leaf, e nodes não root, não leaf - que vai replicar os dados. Cada nó ER pode ser para um único servidor ou um cluster de servidores, que vamos discutir neste artigo. Todos os nós interligados em conjunto são chamados um Dominio ER. O domínio não define quais os dados serão transferidos, apenas os caminhos ou as rotas ao longo do qual os dados fluem.

Em seguida, você decide quais dados você gostaria de ser replicado. Isso é definido por uma consulta SQL que envolve um servidor, banco de dados, tabelas e colunas. A consulta atua como um filtro, cuja saída decide os dados para replicar e revela-se uma ferramenta muito flexível. Se você gostaria de uma tabela inteira para ser replicado, sua consulta seria
select * from nome_da_tabela 
Se você quer apenas as primeiras três colunas a serem replicados, sua consulta seria agora
select coluna1, coluna2, coluna3 from nome_da_tabela
Se você quer apenas determinadas linhas a serem replicadas, basta usar a cláusula where em sua consulta. Para ajudar com ER a replicação exige que a tabela tem uma chave primária definida.

Depois que a consulta está escrito, determine os nós que devem participar em replicar os dados. Vamos dizer que você quer nós A, B e C para todos tenham os mesmos dados em sua tabela de funcionários. Então, A, B, e C são os seus participantes. O ER pode ser configurado de modo que em caso de alterações de dados são feitos em qualquer servidor, os outros participantes se tornam muito atualizado. Isto é chamado de atualização em qualquer lugar cenário. O que acontece se você só deseja ter atualizações a partir de A, em B e C, mas não volta para o nó A? O ER oferece uma flexibilidade que dá para fazer isso. Em situações em que ocorrem alterações de dados em mais de um participante, pode acontecer que uma linha alterada em entre em conflito com o servidor B com uma mudança que ocorre no servidor C. O ER permite que você defina regras para lidar com tais conflitos automaticamente. Eles incluem comparações de timestamps, a execução de uma storage procedure, e ignora os conflitos.

Agora que você sabe a consulta, os participantes, e o cenário, ter todas essas informações e usá-lo para criar algo chamado de replicate. Pense como se fosse uma torneira que controla o fluxo de dados a partir da consulta. A torneira pode ser ligada ou desligado, você pode ter quantas torneiras você queira. Repetições podem ser agrupados em conjuntos, o que torna mais fácil para os usuários a controlar várias replicates. Além disso, você pode usar modelos para ajudá-lo a criar rapidamente as repetições de várias tabelas. Todo este trabalho é feito através do utilitário chamado cdr.

Depois de uma replicate foi criada e iniciada, como é que os dados realmente são movidos? Pois bem, em primeiro lugar, a replicação ocorre de forma assíncrona. Isto significa que pode haver um atraso entre os dados a ser comprometido por um nó e aparecendo em outro nó. E apenas os dados confirmados, é replicada. O ER trabalha lendo os logs lógicos, testando se um registro do log precisa ser replicado e, finalmente, enviar essas informações para os participantes apropriados.

Um exemplo simples

Vamos criar um exemplo simples de ER. Vamos replicar a tabela do banco de dados "db1" empregados de uma forma de atualização em qualquer lugar entre server1 e server2. (Os seguintes passos assumem a conta informix é usado.) Passo 1: Preparar os arquivos SQLHOSTS

O SQLHOST é o arquivo que deve ser configurado em cada servidor (server1 e server2) eles devem conter uma entrada de cada para ambos os servidores, bem como duas definições do grupo. Cada grupo representa uma ER nó :
grp1  group   -  -  i=1
server1  onsoctcp host port g=grp1

grp2  group  -  -  i=2
server2  onsoctcp host port g=grp2
Etapa 2: Preparando o espaço em disco ER

Para cada servidor, execute os seguintes passos:

2.1 - Edite o arquivo ONCONFIG para conter um espaço blob inteligente:
CDR_QDATA_SBSPACE sbs1
2.2 - Inicie o servidor.

2.3 - Crie um chunk smart blob space, e adicione o espaço para o servidor. Por exemplo, no UNIX:
touch /ids/chunks/sbs1_chunk1
chmod 660 /ids/chunks/sbs1_chunk1
onspaces -c -S sbs1 -p /ids/chunks/sbs1_chunk1 -s 100000 -o 0
Passo 3: Adicione os nós para um novo domínio ER

No servidor1, execute o seguinte comando:
cdr define server --init grp1
No server2, execute o seguinte comando:
cdr define server --sync=grp1 --init grp2
Esses comandos criam um ER domínio de dois nós de raiz.

Passo 4: Preparar a tabela para replicar

Em ambos server1 e server2, execute os seguintes comandos SQL:
CREATE DATABSE db1 WITH LOG;
CREATE TABLE employees(id int primary key, ...);
Etapa 5: Criando uma replicate

No servidor1, execute:
cdr define replicate --conflict=ignore r_employees \
"db1@grp1:informix.employees"  "select * from employees" \
"db1@grp2:informix.employees"  "select * from employees"
Passo 6: Inicie a replicar

Em cada servidor, execute:
cdr start replicate r_employees
Agora você está replicando os dados! Um insert, update ou deleteo de uma linha em ambos servidores server1 server2 em breve irá aparecer no outro servidor. Este é apenas o início do uso de ER.

Referencia

Usando Template na Replicação

A replicação (ER) no Infomix fornece um mecanismo para criar e implantar a replicação para um grupo de tabelas para um ou mais servidores. Uma template é especialmente útil se você tiver um grande número de tabelas a serem replicadas entre vários servidores. Internamente, uma template define um grupo de replicates e um set grupo de replicate específico de tabelas utilizando atributos como banco de dados, tabelas, colunas e chaves primárias a partir do nó mestre. Uma template é uma extensão do conceito de conjunto para ajudar a replicar uma grande quantidade de tabelas.

Comandos de Template no Enterprise Replication

Criando uma template usando o comando cdr define template, e instanciando ou efetuar, a template em servidores com o comando cdr realize template.

O replicação (ER) tem dois comandos principais e dois comandos de apoio:
cdr define template 
Define os participantes template (tabelas) em que a replicação precisa ser iniciado.
cdr realize template
Realiza um template em vários servidores, opcionalmente, cria tabelas, ou executa a sincronização inicial. Este comando usa o dicionário mestre criado durante a utilização do nó mestre especificado com o comando cdr define template..
cdr list template
Lista o conteúdo das templates ou lista todas as templates definidas no sistema.
cdr delete template
Exclui o template especificada.

As principais vantagens de usar as templates

Uma das principais vantagens da utilização de templates é a facilidade de utilização e a eliminação de erros.

O uso de Template torna fácil a administração e a configuração no Enterprise Replication:

- As templates fornecem os meios mais simples de configuração e implantação em para clientes com um grande número de tabelas;
- O domínio completo de replicação Enterprise pode ser configurado usando um simples conjunto de comandos, com opções, tais como a definição de replicates em todas as tabelas dentro de um banco de dados e listando tabelas especificadas na linha de comando ou usando um arquivo de entrada.
- Uma template pode executar a sincronização de dados inicial em novos servidores adicionados a template ou a topologia Enterprise Replication.
- Uma template pode ser criar tabelas durante a realize se essas tabelas não existirem em servidores de destino.

Usando modelos elimina a maioria dos erros relacionados ao esquema da tabela:

- Internamente, os modelos de definir repetições mestre que pegar todos os tipos de erros que os clientes da IBM são susceptíveis de enfrentar por causa de diferentes esquemas para as tabelas replicadas entre nós Enterprise Replication. Prevenção tipo de dados incompatibilidade entre nós Enterprise Replication ajuda a evitar a possível corrupção de dados durante a definição replicar.
- As templates podem usar o dicionário mestre replicado a partir do nó mestre para criar tabelas em outros nós para garantir esquemas consistentes entre um grande número de nós.

Criando e gerenciando templates

Esta seção descreve como usar modelos e detalhes de sua implementação.

Usando templates para definir a Enterprise Replication em muitos nós DBAs podem usar modelos para desenvolver scripts e podem configurar a replicação ao longo de um grande número de nós de servidor com apenas alguns comandos. Sem o uso de templates, muitos comandos mais individuais são necessárias. Usando templates, você também pode facilmente adicionar um novo servidor no seu ambiente de replicação na Empresa e, opcionalmente, criar novas tabelas e tornar real o carregamento de dados inicial para essas tabelas.

Se você precisa criar uma replicação no Informix para centenas de tabelas para replicar a centenas de servidores, definindo uma réplica para cada tabela, você precisa executar centenas de definir comandos replicados. Além disso, você precisará fornecer as cláusulas SELECT detalhados para cada tabela na linha de comando cdr para cada repetição. Por outro lado, se você usar um modelo, você pode executar a mesma tarefa com apenas dois comandos: um para definir o modelo para todas as centenas de tabelas, e depois outro para perceber o template em todas as centenas de servidores.

Por exemplo, suponha que você queira criar uma replicação que replica cinco tabelas, tab1, tab2, tab3, TAB4 e tab5, a partir de um banco de dados chamado teste entre três nós, SERV1, SERV2 e SERV3.

Usando o método tradicional para definir repetições, você deve usar o cdr definir repl comando cinco vezes:

Listagem 1. Definindo replicado utilizando o método tradicional (pre-template)
cdr define repl rep1 -C
"ignore"
"test@g_serv1:pravin.tab1" "select * from tab1"
"test2@g_serv2:pravin.tab1" "select * from tab1"
"test3@g_serv3:pravin.tab1" "select * from tab1"
....
cdr define repl rep5 -C
"ignore"
"test@g_serv1:pravin.tab5"" "select * from tab5"
"test@g_serv2:pravin.tab5" "select * from tab5"
"test@g_serv3:pravin.tab5"  "select * from tab5"
Agora, suponha que você queira adicionar mais dois servidores, serv4 e serv5, às replicates. Mais uma vez você deve usar o comando indivíduo cdr change repl cinco vezes para serv4 e serv5: Listagem 2. Adicionando nós adicionais à topologia ER usando o método tradicional (pre-template)
cdr change repl rep1 -a
"test@g_serv4:pravin.tab1"" "select * from tab1"
"test@g_serv5:pravin.tab1" "select * from tab1"
...
cdr change repl rep5 -a
"test@g_serv4:pravin.tab5"" "select * from tab5"
"test@g_serv5:pravin.tab5" "select * from tab5"
Realizando a mesma tarefa usando modelos requer apenas dois comandos:

Listing 3. Definindo replicate usando template
cdr define template temp1 -c serv1
--C
"ignore"
--master=g_serv1
--database=test tab1 tab2 tab3 tab4 tab5

cdr realize template temp1 g_serv1 test2@g_serv2 test3@g_serv3
Para adicionar dois servidores adicionais para a definição de replicação, você pode perceber o modelo novamente sobre os novos servidores:

Listagem 4. Adicionando nós adicionais à topologia ER usando o modelo
cdr realize template temp1 g_serv4 g_serv5
Note que os bancos de dados em Serv2 e serv3 foram teste2 e teste3, respectivamente, e chamado testes em todos os outros nós.

Usando as opções de comando define

Você tem várias opções para configurar o comando cdr define.

O exemplo a seguir ilustra o comando cdr define template que lista cada tabela na linha de comando:

Listagem 5. Definindo modelo de lista especificando de tabelas na linha de comando
cdr define template tem1 -c g_serv1
--C timestamp -S tran
--master=g_serv1
--database=test  table1 table2 table3
O seguinte exemplo referencia a linda de tabelas chamadas tabfile.txt:

Listagem 6. Definindo template de lista especificando de tabelas a partir de um arquivo
cdr define template tem1 -c g_serv2
-C timestamp -S tran
--master=g_serv1
--ignoredel y
--database=test
--file=tabfile.txt
O exemplo a seguir ilustra o comando template realize template por quatro bancos de dados em quatro servidores diferentes:

Listagem 7. Tornar real templetes em nós com nomes de banco de dados diferentes
cdr realize template tem1 -c Detroit
new_cars@detroit
new_cars0@chicago
new_cars1@newark
new_cars2@columbus
Replicando um banco de dados inteiro

Você pode usar templetes para replicar um banco de dados inteiro, definindo replicates para cada uma das tabelas no banco de dados de uma só vez.

Suponha que você tenha um banco de dados chamado teste que tem centenas de tabelas no banco de dados. Se você quiser configurar a replicação para todas essas tabelas, você pode emitir o seguinte comando:

Listagem 8. Configurar a replicação para um grande conjunto de tabelas
cdr define template temp1 -c g_serv1 -C ignore -a -d test
Nota: Você pode especificar a opção -M no comando na Listagem 8 para especificar o servidor que contém o banco de dados a ser utilizado como base do template. Se essa opção não for especificada, o servidor especificado na opção de conexão é usado.

Este comando define replicates em todas as tabelas internas da base de dados de teste. Este comando inclui automaticamente todas as tabelas definidas pelo usuário na definição de modelo e exclui os pontos de vista e tabelas internas definidas no banco de dados.

Convenção de nomenclatura para replicates geradas por templates

Os nomes de repetições master gerados por modelos são baseados no nome do modelo, o nome do servidor, um ID interno exclusivo, o ID de replicação, e o nome da tabela. Os nomes são sempre únicas no sistema e podem ser facilmente identificados pela combinação do nome do modelo, nome do servidor e nome da tabela. No exemplo a seguir, o nome do modelo é temp1, o nome do servidor é g_pkcdr1, e os nomes das tabelas são t1 e t2:

Listagem 9. A saída do comando define modelo
cdr define template temp1 -C "ignore" -M g_pkcdr1 -d test t1 t2
Obtaining dictionary for test@g_pkcdr1:''pravin''.t1
Creating mastered replicate temp1_pkcdr1_1_1_t1 for table 'pravin'.t1

Obtaining dictionary for test@g_pkcdr1:''pravin''.t2
Creating mastered replicate temp1_pkcdr1_1_1_t2 for table 'pravin'.t2
Você pode ver o nome da replicate gerada usando o comando cdr list repl

Listagem 10. A saída do comando lista repl
cdr list repl

CURRENTLY DEFINED REPLICATES
-------------------------------
REPLICATE:        temp1_pkcdr1_1_1_t1
STATE:            Inactive ON:pkcdr1
CONFLICT:          Ignore
FREQUENCY:        immediate
QUEUE SIZE:        0
PARTICIPANT:      :.
OPTIONS:          transaction,fullrow
REPLTYPE:          Master

REPLICATE:        temp1_pkcdr1_2_1_t2
STATE:            Inactive ON:pkcdr1
CONFLICT:          Ignore
FREQUENCY:        immediate
QUEUE SIZE:        0
PARTICIPANT:      :.
OPTIONS:          transaction,fullrow
REPLTYPE:          Master
Convenções na nomenclatura para conjuntos de réplicas geradas por templates

O nome de um conjunto de réplica é gerado por um modelo é o mesmo que o nome do modelo.

No exemplo anterior, o nome da repetição criado internamente definida é temp1, como mostrado pelo comando cdr list repliset:

Listagem 11. A saída do comando lista replset
cdr list replset

Ex T REPLSET                PARTICIPANTS
--------------------------------------------------------
N  Y temp1                  temp1_pkcdr1_1_1_t1
                            temp1_pkcdr1_2_1_t2
Visualizando os modelos existentes

Para listar os templates no sistema, você pode usar o comando cdr list template para ver os detalhes da template.

Para o exemplo anterior, a saída do comando exibe uma breve informações sobre o banco de dados e tabelas:

Listagem 12. O resultado do comando template de lista breve
cdr list template brief temp1

TEMPLATE            DATABASE            TABLES
==============================================
temp1              test                pravin.t1
                                       pravin.t2
A versão completa do comando exibe os detalhes sobre um modelo:

Listagem 13. A saída do comando modelo lista completa
cdr list template full temp1

CURRENTLY DEFINED TEMPLATES
===========================
TEMPLATE:        temp1
TEMPLATE ID:    6553615
SERVER:          g_pkcdr1
DATABASE:        test
REPLICATE:      template1_pkcdr1_1_1_t1
OWNER:          pravin
TABLE:          t1

TEMPLATE:        temp1
TEMPLATE ID:    6553615
SERVER:          g_pkcdr1
DATABASE:        test
REPLICATE:      template1_pkcdr1_2_1_t2
OWNER:          pravin
TABLE:          t2
Executar uma sincronização inicial para novos nós

O exemplo a seguir ilustra tornar real uma template, criando as tabelas e carregamento de dados em quatro servidores de banco de dados alvo:

Listagem 14. Realizar sincronização inicial usando o modelo
cdr realize template tem1 -c g_serv2 -autocreate
--syncdatasource=g_serv2
--extratargetrows= keep
--target g_serv2 g_serv1 g_serv3 g_serv4
Você pode dar o comando cdr delete template para excluir uma template. Este comando exclui a template especificada e também os conjuntos de réplicas associados. Este comando também exclui internamente essas master replicates que ainda não foram realizados em qualquer um dos nós Enterprise Replication.

Alterando a definição da templates

Você não pode atualizar uma template. Para fazer alterações em um modelo, você deve excluí-la com o comando cdr delete template e, em seguida, recriá-la com o comando cdr define template.

Considerações especiais para o uso das templates

Os pontos a seguir fornecem informações adicionais sobre o uso de modelos:

Primário contra configuração somente leitura servidor

Por padrão, todos os nós da template tornadas reais são realizados como nós principais que suportam atualização em qualquer lugar de replicação. Se você precisa configurar um servidor como um servidor somente leitura, então você pode especificar o comando --target (-t) opção durante a realização do modelo.

Escolher um servidor não-leaf para definir modelos

Uma template deve ser definida a partir de um servidor não-leaf, como conjuntos de réplicas e repetições devem ser, porque o nó modelo deve replicar a informação da template/replset toda o topologia Enterprise Replication.

Escolhendo um nó mestre

O nó mestre deve ter conectividade com todos os servidores da topologia Enterprise Replication. O Master replicates exigi que todos os nós de acesso ao nó mestre para obter as informações do dicionário sobre tabelas, colunas e chaves primárias. Portanto, se alguns nó da topologia está atrás de um firewall, você deve garantir que eles ainda são capazes de acessar o nó mestre.

Lidando com a integridade referencial entre tabelas durante a definição da template

Se houver tabelas no banco de dados em que um modelo está sendo definidos que têm restrições de integridade referencial entre si, em seguida, definir a template para essas tabelas usando --exclusive com a opção (-X). Isso determina automaticamente a relação pai e filho entre tabelas, como especificar um conjunto de replicação exclusivo. Essa relação é mantida durante a sincronização inicial e quando se inicia o replicate set.

A cláusula SELECT tem todas as colunas das tabelas (full row replication)

Por padrão, as templates configura a replicação para full rows of tables (todas as colunas na tabela), porque eles são projetados para facilitar a criação de ambientes de replicação em larga escala. Se você precisa definir as replicates por apenas um conjunto de colunas da tabela, então você tem que usar repetições individuais ou usar o modelo e, em seguida, alterar as replicates individuais.

Checando um esquema sem tornal real

Se você precisa checar a configuração de replicação existente, você pode definir um modelo falso nessas tabelas e perceber o modelo com a opção --verify (-v). O --verify verifica as tabelas, colunas, tipos de dados, e assim por diante entre o nó mestre e o nó em que a template está sendo tornada real. Esta opção também informa sobre as tabelas em falta nos nós de destino. O exemplo a seguir checa se as tabelas incluídas na template existente em três servidores, se existe a chave primária, se há uma incompatibilidade de tipo de dados, e assim por diante:
cdr realize template temp1 -c Detroit --verify chicago newark columbus
Este comando não faz nada só checa.

Criando automaticamente tabelas no novo nó

Em uma configuração totalmente nova, você pode usar templates para criar uma cópia exata de uma tabela em outros nó usando o comando --autocreate option (-u). (Isto não pode ser feito por tabelas que contêm tipos de dados definidos pelo usuário, a menos que a mesma definição UDT existe em todos os nós da Enterprise Replication.) O exemplo a seguir cria as tabelas da template em três servidores:
cdr realize template temp1 -c Detroit --autocreate chicago newark columbus
Dbspace requirida

Quando você usa uma template para criar novas tabelas nos nós sendo realizado, por padrão, as tabelas são criadas no mesmo dbspace em que o banco de dados reside. Para especificar um dbspace diferente, em que para criar as tabelas, use a opção --dbspace.

Para tabelas com crcols

Para usar a replicação baseada em tempo, você deve configurar as tabelas de ter shadow columns antes de definir as templates.

Reparação inicial ou sincronização

Opcionalmente, é possível optar por fazer a sincronização inicial em novos nós sendo tornados reais pela template. Você pode usar opção --extratargetrows com qualquer uma destas três opções: keep, delete, e merge para especificar como vai lidar com as rows duplicadas.

Todos os servidores da template precisam de conectividade direta entre nós Enterprise Replication ao fazer o reparo inicial usando templates.

Aplicar como proprietário ou como usuário informix

Por padrão, as rows aplicadas para a sincronização inicial, durante a realização do modelo são aplicadas pelo usuário informix. Você pode especificar que as linhas são aplicadas pelo proprietário da tabela de origem usando o opção --applyasowner (-o). Você deve garantir que este proprietário existe em todos os nós que estão sendo realizados. Referencia

12/01/2013

Tipos de Armazenamento - Informix


Tipos de Armazenamento

Figura do Raw Device e do Cooked File
          Raw Device                                Cooked File
+------------------------------+        +------------------------------+
|++++++++++++++++++++++++++++++|        |                              |
|++++++++++++++++++++++++++++++|        |            +-----+           |
|++++++++++++++++++++++++++++++|        |            |+++++|           |
|++++++++++++++++++++++++++++++|        |            |+++++|           |
|++++++++++++++++++++++++++++++|        |            |+++++|           |
|++++++++++++++++++++++++++++++|        |            +-----+           |
|++++++++++++++++++++++++++++++|        |                              |
+------------------------------+        +------------------------------+
      /dev/informix/sbd1                 /export/home/informix/espace2
O Informix permite duas opções para você armazenar os seus dados:
  • Raw Device é um tipo especial que é criado pelo UNIX/Linux, proporciona uma melhor performance uma vez que não é montado e o seu controle é independente do UNIX/Linux file system.
  • Cooked File é um arquivo comum que é gerenciado pelo sistema operacional. Enquanto o servidor de banco de dados (IDS) controla o conteúdo do arquivo, faz requisições de I/O para o sistema operacional.
Preparando um Raw Device : Para criar um raw device, você deverá consultar os manuais de administração do seu sistema UNIX/Linux (não utilize o comando mount).

Criando um mais espaço - Raw Device - 800 Gb (800*1024*1024=838860800)
chown informix:informix /dev/sda3
chmod 660 /dev/sda3
ln -s /dev/sda3 /dev/informix/aafai240_dbs
onspaces -c -d aafai240 -p /dev/informix/aafai240_dbs -s 838860800 -o 0  -k 16
Criando um Cooked File : Cooked files são mais fáceis de utilizar, porém, conforme foi comentado tem uma performance menor, principalmente se no seu sistema operacional está habilitado o Kernel AIO.

Adicionando mais 45 gigas no chunck usrdbs - (45*1024*1024=47185920)
chown informix:informix /INFORMIXTMP/aafai240P_02
chmod 660 /INFORMIXTMP/aafai240P_02
onspaces -a usrdbs -p /INFORMIXTMP/aafai240P_02 -o 0 -s 47185920
Verifying physical disk space, please wait ...
Chunk successfully added.
Referencia - Link 2