Requisitos DBView em máquina local
Estas são as nossas orientações documentadas de pré-requisitos para a utilização/configuração do DBView:
1) Hardware
- 8GB de RAM (mínimo de 4GB - se forem máquinas físicas, as memórias devem ter ECC)
- CPU 4 cores de 2.00GHz (mínimo 2 cores)
- 100GB espaço em disco
- Placa de rede de alta velocidade (Gigabit Ethernet)
- Se forem máquinas físicas, optar por equipamentos com arquitetura server (processador, chipset, memória, interfaces de dispositivos de armazenamento - preferencialmente SAN, ou ao menos DAS - etc.). Se forem VMs, optar por serviços que garantam IOPS - garantia de I/Os por segundo)
2) Software
- Linux 64bits (kernel 3.4 ou superior) (usamos CentOS 6.5
- PostgreSQL 9.3.4
Ps: Se for utilizar Windows (versões server), então adicionar 2GB de RAM extra
Reforçamos que a recomendação é para um servidor dedicado de banco de dados, ou seja, executando somente o sistema operacional e o PostgreSQL.
É importante salientar a necessidade de que o DBA mantenha a instância do Postgres usada pelo DBView no escopo de suas rotinas de administração. Mesmo com um hardware adequado será necessário realizar tuning inicial do PostgreSQL e do Sistema Operacional, antes de colocar o DBView em produção, para que os recursos do hardware sejam melhor aproveitados tanto pelo SO quanto pelo próprio SGBD. Na implantação das rotinas de ETL para o Qlik, também é recomendável realizar o tuning antes da entrada em produção. O DBA deverá, ainda, monitorar regularmente os indicadores de desempenho e realizar os ajustes, redimensionamentos, rotinas recorrentes (Vacuum, por exemplo), etc.
Atualmente os ambientes mantidos no DBView remoto ocupam aproximadamente 20GB, sendo realizados aproximadamente 2.3 operações de DML. Este parâmetro baseou o cálculo do espaço em disco, já prevendo datafiles, áreas de backup e archives locais e áreas de movimentação de dados. Quanto ao dimensionamento dos datafiles, o DBA pode optar pela melhor política de acordo com as práticas que costuma adotar. O mesmo vale para dimensionamento de data buffers, áreas de rollback etc.. Não existem recomendações fixas de nossa parte para esses parâmetros.
Segue sugestão de passos para implementação do DBView local:
1. Instalar o servidor: sistema operacional e Postgres, e tuning inicial
2. Baixar dump do banco de dados do DBView (forneceremos esses dumps assim que vocês sinalizarem que o servidor está ok)
- O DBView é segmentado por ambiente uMov.me.
- Em cada um dos ambientes, a uMov.me atualisará os dados na tabela "transactionlog", todos os comandos necessários para atualizar o DBView local.
3. Você deverá criar a rotina que lê esta tabela em frequência a ser definida de acordo com as suas necessidades de negócio e executar os comandos de atualização nas tabelas de dados do DBView Local. Não fornecemos uma rotina padrão pois, além da mesma ser bastante simples, normalmente cada cliente a implementa de acordo com suas necessidades.
Para restaurar utilizar o pg_restore conforme exemplo:
$ pg_restore -U postgres -Fc -v -d nome_da_base nome_do_arquivo.pgbkp
Também é possível utilizar via PGAdmin, menu "Tools > Restore" estando conectado no database que se deseja restaurar.
IMPORTANTE!!!
No database que for restaurado será criado um schema chamado "u9999" (onde 9999 = código do ambiente) e todos objetos (tabelas) são criados dentro deste esquema, então ao fazer um SELECT na base será necessário utilizar o schema antes do nome da tabela, ex:
SELECT * FROM u9999.activity;
Caso não deseje utilizar essa nomenclatura com o nome do esquema antes do nome da tabela você pode usar uma das alternativas:
1) Setar o 'search_path' para o usuário que conecta no banco, por exemplo:
ALTER ROLE postgres SET search_path TO "$user", public, u9999;
2) Alterar o esquema de todas as tabelas para o 'public', então é necessário executar para cada tabela:
ALTER TABLE u9999.activity SET SCHEMA public;
...
3) Se a base de dados utilizada para restaurar for NOVA, ou seja, não contenha objetos no schema 'public' então você pode também:
DROP SCHEMA public;
ALTER SCHEMA u9999 RENAME TO public;
Particularmente recomendamos a primeira opção por ficar definitiva, mesmo que depois seja atualizado (restaurado) um novo dump na mesma base. A terceira opção também é boa, mas deve ser utilizada com cuidado para não remover o schema 'public' e objetos que eventualmente existem nele (em caso de uma base que já está sendo utilizada).
Mais informações
A tabela "transactionlog" serve como base para buscar os registros que devem ser atualizados.
Utilize os campos trl_id e trl_datehour ou apenas um destes para saber os registros que você deve executar.
O conteúdo a ser executado você encontra no campo trl_statements
Mas precisa ser executado um a um.