Projeto de Migração do PostgreSQL 8.1 pra 8.2.5 – FASE 4 : O Pavoroso Dia D !!

Pois é minha gente vamos ao pavoroso dia D …
O dia que ninguém almoça, ninguém respira e ninguém dorme !!!

Bem .. posso dizer que essa migração foi bem tranqüila.

Para não esquecer algum passo eu fizemos uma especie de check list de migração. Segue abaixo os procedimentos

1 – Compila
Esse é um processo que já vimos anteriormente … sendo assim não tem mistério.

PS: Só lembrando que para compilação ocorrer se erros é necessário 2 pacotes … Caso ele não esteja instalado …. instale !!!

# aptitude install libreadline-dev
# aptitude install zlib-dev

$ tar -xvzf postgresql-8.2.5.tar.gz
$ cd postgresql-8.2.5
$ cd /src/include
$ vi pg_config_manual.h

$ cd ../../
$ ./configure –prefix=/home/postgres/postgresql-8.2.5 –with-python –with-perl
$ make
$ make install

2 – Cria o cluster
Esse passo também é tranqüilo

/home/postgres/postgresql-8.2.5/bin/initdb -D /pgteste/pg825/dados/ –encoding=latin1

3 – Cria o diretório pg_log
Bem .. isso é um passo que tem que se levado em consideração, senão todas as mensagens de log são exibidas na tela. Uma outra opção é mudar o diretório de log no postgresql.conf

$mkdir pg_log

4 – Copiar e imprimir o postgresql.conf da produção e compara com o novo (8.2.5). Basicamente nada muda, mas temos que nos atentar ao parâmetro DATESTYLE, pois nas versões anteriores a o formato da data é MDY e nessa nova versão é exibido como DMY. Isso pode causar sérios problemas la na frente.

scp -rv postgres@sd1cco:/postgres/pg812/dados/postgresql.conf .
lsten_addresses = ‘*’
port = 5432
max_connections = 25
shared_buffers = 300MB
work_mem = 100MB
search_path = ‘public’
datestyle = ‘iso, mdy

$cat /proc/sys/kernel/shmmax
841572800

5 – Muda as portas. Para não ter nenhum tipo de intervenção vamos mudar a porta padrão do atual banco de produção e no novo banco.

Antiga produção de 5432 para 5434 e novo de 5432 para 5436

6 – Altera o pg_hba.conf.

Colocar as configurações que estão em produção

7 – Copia o _database e o _deny. Arquivos esse que define quais usuários são permitidos acesso no banco.

8 – Mudar o /proc/sys/kernel/shmmax. Entende-se que esse parâmetro já foi modificado, pois nesse caso a nova versão vai rodar no mesmo servidor.

vi /etc/sysctl.conf
kernel.shmmax = <VALOR>
cat > /proc/sys/kernel/shmmax
<VALOR>
ctrl + d

9 – Sobe os bancos. Lembrando que estão subindo em portas diferentes do padrão.

/home/postgres/postgresql-8.2.5/bin/pg_ctl -D . start
/home/postgres/postgresql-8.1/bin/pg_ctl -D . start

10 – Altera a senha do postgres da nova versão

/home/postgres/postgresql-8.2.5/bin/psql -p 5436
postgres# ALTER Role postgres PASSWORD ‘SENHA’;
postgres# CREATE DATABASE BANCO
WITH OWNER = postgres
ENCODING = ‘LATIN1’;

11 – Altera o timezone do banco (isso somente no horário de verão)

ALTER DATABASE BANCO SET TimeZone=”Brazil/DeNoronha”;

12 – Para poder fazer a conexão é necessário configurar o pg_hba.conf

# “local” is for Unix domain socket connections only
local all all trust
# # IPv4 local connections:
host all all 127.0.0.1/32 trust
host all all 0.0.0.0/0 md5
# # IPv6 local connections:
host all all ::1/128 trust

13 – DUMPALL direto do banco de produção para o banco novo

/home/postgres/postgresql-8.2.5/bin/pg_dumpall -p 5434 -i | /home/postgres/postgresql-8.2.5/bin/psql -p 5436 -d pg03

Conferência pós migração

14 – Verifica se todos os objetos foram migrados. Esse passo é de extrema importância, pois todos os objetos devem estar no novo banco. Para isso basta apenas rodar a query abaixo nas 2 bases. (O Leo Cezar salvou o dia me ajudando a montar esse script … Obrigado Leo !!!!):

SELECT o.esquema,o.objecto,COUNT(o.nm_objecto) FROM
(
SELECT n.nspname AS “esquema”,
CASE c.relkind
WHEN ‘r’ THEN ‘TABELAS’
WHEN ‘v’ THEN ‘VISÃO’
WHEN ‘S’ THEN ‘SEQUENCE’
WHEN ‘i’ THEN ‘INDICE’
END as “objecto”,
c.relname as “nm_objecto”
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN (‘S’,’r’,’v’,’i’)
AND n.nspname NOT IN (‘dbateste’,’information_schema’,’pg_catalog’,’pg_temp_1′,
‘pg_toast’,’xmg’,’postgres’,’publico’,’public’)

UNION
SELECT trigger_schema AS “esquema”,

‘TRIGGER’ AS “objecto”,
trigger_name as “nm_objecto”

FROM information_schema.triggers

UNION
SELECT specific_schema AS “esquema”,

‘FUNÇÃO’ AS “objecto”,
specific_name as “nm_objecto”

FROM information_schema.routines
WHERE data_type <> ‘”trigger”‘

UNION

SELECT specific_schema AS “esquema”,
‘FUNÇÃO DE TRIGGER’ AS “objecto”,
specific_name as “nm_objecto”

FROM information_schema.routines
WHERE data_type = ‘”trigger”‘

) AS o
GROUP BY esquema,objecto
ORDER BY 1,2
;

15 – Muda o caminho do .bashrc. Precisamos mudar o path do postgres nessa etapa.

$ vi /home/postgres/.bashrc
PG=$HOME/postgresql-8.2.5/bin
PATH=$PATH:/$PG
PAGER=/usr/bin/less
export PATH PG PAGER

16 – É importante não esquece que o serviço não sobe automático, sendo assim é de extrema importância ter um script no init pra fazer esse trabalho. No caso desse projeto esses arquivos já existem, só alteramos o caminho para 8.2.5.

17 – É importante também não esquece dos backups, os comandos de dump devem apontar para o home da nova versão. No caso desse projeto alteramos os caminhos de onde os dumps são alocado para um diretório com o nome da nova versão.

18 – E por final, baixe o banco da versao 8.1, altere a porta da versão 8.2 e suba novamente.

19 – Por final, podemos acompanhar o andamento do banco através de algumas views que podemos criar para monitorar memória, disco, consulta corrente e muito mais. (O Marquinho criou algumas que facilitam a vida do pẽao !!!). Vou postar somente uma para dar água na boca.

View para verificar % de utilização de memória

CREATE OR REPLACE VIEW disco_mem AS

SELECT (sum(pg_stat_database.blks_hit) / sum(pg_stat_database.blks_read + pg_stat_database.blks_hit) * 100::numeric)::integer AS “% de Utilização de Mem”
FROM pg_stat_database;

COMMENT ON VIEW disco_mem IS ‘
Calcula através das estatisticas o percentual de utilização disco / memória.
Valores acima de 70% significa que o banco esta realizado mais tarefas em memória do que i/o em disco’;

E no final entre mortos e feridos sobrevivemos todos!!
Kenia Milene

PGCON 2007 Bombou !!!!!

É isso ai minha gente no ultimo sábado rolou o 1o PGCON aqui no Brasil.

Contamos com cases super interessantes como o do METRO de São Paulo e da FAB. Colaboradores do mundo livre também estavam la, como Telles, Diogo, Leo, Isis, David Fetter, Fike, Euler, Dutra e muito mais …

O evento bombou mesmo tinha muita gente !!!! as palestras foram muito bem recebidas e o auditório ficou cheio até a ultima (que foi de tunning do Fike).

No final rolou a chopada fornecida pela Lev Chopp e todos os organizadores terminaram a noite jantando no Rocks.

Se o primeiro foi surpreendente imagina só os próximos como serão!!!!!

Alguem já brincou de onde esta o Wally ????? Vamos brincar de onde esta  a Kenia?????. Acredite se quiser .. mas eu estou ai no meio !!!!!!

_c081110.jpg

Kenia Milene

Projeto de Migração do PostgreSQL 8.1 pra 8.2.5 – FASE 3 : Os Testes do Desenvolvimento

Bem …. já logo de cara sabíamos que enfrentaríamos um problema.

A maioria dos desenvolvedores aqui não indicam o schema dos objetos em suas rotinas, o schema era definido através do search_path de cada usuário (ALTER ROLE usuario SET search_path=schema).

Porém a versão 8.2.5 não reconhece o código se não indicar <schema.objeto>. Até existe um parâmetro de compatibilidade no postgres.conf da nova versão (add_missing_from = off), ou poderíamos manter o search_path do usuário, mas isso faz com que o banco faça mais uma verificação, fazendo o mesmo trabalhar mais um pouquinho !!!!

Pois bem … notificamos o desenvolvedor sobre essa mudança, e o mesmo alterou uma rotina da aplicação para teste. Resultado????

O desenvolvedor achou que ficou mais rápido e concordou em modificar as outras rotinas e as futuras já vir com essa alteração.

Estamos no aguardo do desenvolvedor terminar seus testes e nos dar o OK para o dia D

É isso ai ….
Contagem regressiva para o Dia D !!!

Kenia Milene

O SEGREDO !!!

Pois é minha gente o que a força do pensamento é capaz de fazer não é verdade????

O subconsciente humano é extremamente poderoso, como uma arma, que se usada de maneira inadequada … pode causar sérios danos !!!!

Se usar seu subconsciente junto com determinação, tenha a certeza de que terá uma arma mais poderosa ainda !!!!

O Segredo fala sobre a lei a atração … “ATRAIA O QUE VOCÊ REALMENTE QUER PARA A SUA VIDA E NÃO O QUE NÃO QUER !!!!”

E não é que funciona mesmo !!!! Pois é minha gente todos nós temos nosso calcanhar de Aquiles … aquilo que se afetado tira o nosso chão mesmo !!!!, e infelizmente atiraram no meu. É difícil ???? Dói ??? Eu diria que a dor é insuportável !!!!

Perder aquilo que no seu julgamento é mais importante de tudo … é de deixar qualquer um sem rumo mesmo. E o que fazer nesse momento ???

Bem …. o meu conselho é … “SIGA O SEGREDO” !!!!

Eu aprendi que tudo aquilo que depende única e exclusivamente de você é possível, pode ser muito muito difícil mas acredite …. é possível !!!!!

Sendo assim … RECONSTRUIR É POSSIVEL !!!!

Olhe para o espelho e veja alem de alguem que sofre .. veja aguem que é capaz de batalhar para atingir seu objetivo … seja ele o quanto difícil for.

Acredite em você, porque a força que você tem dentro de si mesmo é imensa ao ponto de mover montanhas !!

Para de se lamentar, culpar a vida das injustiças que lhe foram feitas …. Pare de atrair para a sua vida aquilo que não é bom para você. Atraia tudo de bom, atraia bons fluidos, amigos, prosperidades, fartura, tranqüilidade, paz de espirito….. e é claro muito chocolate !!!!

Trace um objetivo e siga !!!! mas siga mesmo !!!!

Se quer parar de fumar, então jogue o maço no lixo olhe no espelho e diga: “Eu Sou Fudaster ….. Eu Consigo !!!!” (Meu amigo Rui não fuma já fazem anos !!!!)

Se esta com síndrome do pânico olhe no espelho e diga: “Eu Sou Mais Forte Que você .. Sai Pra La Coisa Ruim !!!!!” (Minha amiga Daniela, crescemos juntas !!!! … Não nos falamos a muito tempo mas ela conseguiu .. foi mais forte !!! e hoje enfrenta mercado lotado e shopping em liquidação)

Quer um carro novo ???? então coloque as contas (imagino que não são poucas) no papel … planeje o pagamento aos poucos .. mas pague !!! e no final .. acredite … terá seu carro … !!!

Se Perdeu alguem que era muito especial olhe no espelho e diga: “Se ele se foi era porque não era pra mim mesmo .. Seja Feliz !!!” (Essa é pra mim mesmo !!)

Acorde olha na janela e se estiver sol diga “Que dia maravilhoso .. vou tomar aquela cerveja estupidamente gelada” (Marquinho, Fabio Telles, Chico e Rui .. Essa é pra vocês. Esses meninos valem ouro !!!).

Se estiver chovendo diga “Hoje a noite vou mukiar debaixo dos cobertores com o meu novo amor e ver aquele filminho gostoso!!!” (Vanessinha … essa é em homenagem a seu novo relacionamento. Essa pequena vai longe !!)

Sendo assim minha gente … trace uma meta na sua vida .. e acima de tudo ATRAIA APENAS AQUILO QUE VOCÊ QUER PARA A SUA VIDA !!!

E seja Feliz !!!!!
Eu consegui. a Dani, a Vanessinha e o Rui também …
Você também consegue

Para quem quiser saber mais sobre o segredo: O Segredo

Abraço a todos
Kenia Milene

Projeto de Migração do PostgreSQL 8.1 pra 8.2.5 – FASE 2 : Preparando o Ambiente PostgreSQL

Permissões

Bem como dito la no começo o ponto de montagem para o banco é o /postgres, esse ponto deve ter o dono e o grupo postgres para que tudo funcione perfeitamente, sendo assim, antes de tudo crie o usuário postgres !!!!
Assim que o server foi instalado fizemos as alterações acima.

A Compilação

A versão para que vamos migrar é a 8.2.5, baixamos a versão, descompactamos e compilamos no diretório /home/postgres/postgresql-8.2.5 como mostrado a seguir:

$ tar -xvzf postgresql-8.2.5.tar.gz
$ cd postgresql-8.2.5
$ cd src/include
$ vi pg_config_manual.h

#define BLCKSZ 8192

Nesse parâmetro definimos o tamanho de cada bloco, que nesse caso será compilado com blocos de 8KB.

Porque a compilação no home do postgres?????

A compilação no home do postgres nos da a possibilidade de ter mais de uma versão do postgreSQL na mesma máquina, ou seja, posso ter no servidor de produção por exemplo a versão 8.1 (Operacional no momento) e a versão 8.2.5. Com isso posso caso alguma catástrofe aconteça (Esperamos que não!!!) , é possível voltar tudo para a versão anterior. Veja a seguir os passos para a compilação:

$ cd ../../
$ ./configure –prefix=/home/postgres/postgresql-8.2.5 –with-python –with-perl
$ make
$ make install

Path do usuário

É importante alterar o path do usuário postgres, pois como compilamos no home, precisamos indicar onde buscar os binários.

$ vi /home/postgres/.bashrc
PG=$HOME/postgresql-8.2.5/bin

PATH=$PATH:/$PG

PAGER=/usr/bin/less

export $PATH $PG $PAGER

LESS=”-S-N”

$ vi /home/postgres/.bash_profile
PATH=$PATH:$HOME/postgresql-8.2.5/bin:$HOME/bin
PAGER=less

export $PATH $LESS

unset USERNAME

Criando o Cluster

Para isso criamos a seguinte estrutura de arquivos: /postgres/pg825/dados
onde criaremos o cluster através do comando initdb e com o parâmetro latin1 para indicar o idioma a ser usado:

$ cd /home/postgres/postgresql-8.2.5/bin/
$ initdb -D /postgres/pg825/dados/ –encoding=latin1

Ajustando Parâmetros do PostgreSQL

Para configurar os parâmetros antes de subir o banco vamos alterar o arquivo postgresql.conf que esta no /postgres/pg825/dados/ :

$ cd /postgres/pg825/dados/
$ vi postgresql.conf

Parâmetro que define quais endereços clientes poderão fazer conexão no banco. Nesse caso todo e qualquer host é permitido, essa restrição faremos em outro arquivo.

listen_addresses = ‘*’

Parâmetro que define qual porta o serviço irá responder

port = 5432

Número máximo de conexões simultâneas permitidas. Essa é uma informação importante, que deve ser levada em consideração.

max_connections = 25

Memória compartilhada, é indicado no caso de servidores dedicado que seja disponibilizado para o postgresql 1/3 da memória disponível. Como temos 1GB de memória vamos então colocar 300MB.
shared_buffers = 300MB

Parâmetro que define a área de ordenação, área essa usada pelo ORDER BY por exemplo. É a área da memoria disponível no disco usada para ordenação das transações.
É importante saber que se essa área não for o suficiente, vai pra disco fazendo que com tudo fique mais lento. A área de ordenação é definida por usuário, e a quantidade total de conexões permitidas * a área de ordenação não pode ser maior do que a memória disponível ( No nosso caso os 600MB restantes). Lembrando que a ordenação não usa a memória compartilhada e sim a memória disponível.
Nesse caso o valor esta maior do que o normal, pois 25 conexões * 100MB cada uma seria equivalente a 2,5GB (Contamos com que os 25 usuários não façam ordenações simultâneas). Como é apenas ambiente de testes para as aplicações o número de conexões é bem reduzido, logo, não teremos problemas nesse ambiente quanto a área de ordenação.

work_mem = 100MB

Parâmetro que define a ordem da procura no schemas quando um objeto é referenciado apenas pelo nome, sem o schema.
Com esse parametro setado sem a variável $user, todo e qualquer objeto, seja ele tabela, view … etc , que não for apontado o schema será retornado um erro de objeto inexistente.

search_path = ‘public’

Alterando Parâmetros do Kernel

Os parâmetros variam de acordo com o Hardware. O ideal é que a memória compartilhada (Shared_buffers) do servidor seja equivalente a 1/3 da memória total e o shmmax seja equivalente a shared+S.O, ou seja, o parâmetro SHMMAX deve ser o valor da shared_buffers + uma folga para o Sistema Operacional. No nosso caso:

$cat /proc/sys/kernel/shmmax
841572800

Levantando o banco

Depois dos parâmetros configurados vamos levantar o banco:

$ /home/postgres/postgresql-8.2.5/bin/pg_ctl -D . start

Para sabermos se tudo correu bem primeiro vamos ver se o serviço esta de pé:

$ ps -aux | grep postgres
postgres 14666 0.3 0.2 29524 2364 pts/0 S 16:29 0:00 /home/postgres/postgresql-8.2.5/bin/postgres -D .

E então fazer uma conexão no banco

$ psql
Welcome to psql 8.2.5, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

postgres=#

Importação do Banco de Produção

Bom .. agora só falta os dados … para isso vamos fazer um dumpall da produção e redirecionar para nosso servidor de testes.
Usamos dumpall porque dessa forma ele leva tudo mesmo … inclusive usuários e grupos.
No servidor de produção:

$ pg_dumpall -p 5432 -i | psql -h host -p 5432 -d banco

Ambiente Disponível e Era isso !!!
Até a fase 3

Kenia Milene

Projeto de Migração do PostgreSQL 8.1 pra 8.2.5 – FASE 1 : O HARDWARE

Pois é minha gente la vou eu para mais uma aventura no mundo dos dados…
O desafio dessa vez é migrar a versão de vários bancos postgreSQL, inclusive os bancos de BI. olha só que aventura …
Bom, vou postando aqui as fases desse projeto, e a primeira fase é preparação de um ambiente de testes e homologação, para isso contamos com um servidor de testes dedicado ao projeto:

A migração

Na verdade essa migração esta sendo feita porque estamos com uma versão muito antiga, o que pode causar sérios problemas com possiveis bugs e assim podemos usufruir das melhorias.

Mas a nossa maior preocupação é: As aplicações vão funcionar?????? A principio sim, mas isso vamos ver ao longo dos testes.

Hardware

Bom .. a primeira luta é para ter um servidor de testes dedicado. Conseguimos!!!!
Não é uma super máquina mas para os testes com o desenvolvimento vai suprir as necessidades.
Infelizmente o projeto não contempla upgrade de hardware, ficamos com os servers antigos.

model name : Intel(R) Pentium(R) 4 CPU 1.80GHz
cpu MHz : 1800.354

cache size : 512 KB
D
isk1 : 10 GB
D
isk2 : 40 GB

Particionamento

O disco menor deixamos para o Sistema Operacional e o segundo disco para o banco, assim evitamos concorrência na gravação.

/dev/hda2 /
/dev/hda1 /boot
/dev/hdb1 /postgres

Sistema Operacional

Mesmo Sistema Operacional e kernel do servidor de teste será o mesmo que esta em produção.

S.O : Fedora Core 4
Kernel : 2.6.11-1

É isso ai ….
Até a fase 2 !!!!
Kenia Milene

Fazendo Cálculo com Números Decimais em Shell Script Usando o bc

Olha vou dizer que essa deu dor de cabeça….

Estava eu pensando em criar um script … um check list com algumas informações relevantes para fazer um tuning em alguns bancos PostgreSQL.

Até ai tudo bem né .. o Shell Script da conta do recado. O que eu não contava é que o Shell Script trata tudo, seja la o que for, como texto.

Ai é que a porca começa a torcer o rabo, porque como eu vou fazer meu cálculo se no meio da expressão numérica tem números decimais????

Depois de muito queimar a mufa fui obrigada a pedir ajudar não aos universitários, mas sim para um cara fudaster chamado Julio Cezar Neves. É isso ai minha gente .. falou em Shell Script, ele é o cara. Obrigado Pela Ajuda Julio !!!!!

Bem, ele me ajudou com o tal cálculo falando da utilização do bc e também uma informação que é de extrema importância. O caractér usado para decimal conta na hora do cálculo, ou seja, um número decimal é interpretado através do . e não da , (isso depende do locale do S.O mas preferi nem mexer pra não feder mais)

Enfim, depois de muita luta e um olho roxo o cálculo saiu. O Script ainda não esta pronto, mas assim que tiver eu posto ele aqui.

Segue abaixo um exemplo de cálculo de expressões numéricas com decimais usando Shell Script !!!

shared=`cat $PRODUCAO/postgresql.conf | grep shared_buffers |awk ‘{print $3}’`

connection=`cat $PRODUCAO/postgresql.conf | grep max_connections |awk ‘{print $3}’`

calculo=`echo “scale=2; ((250 + 8.2 * $shared + 14.2 * $connection) * 1024) ” | bc`

echo $shared 185000
echo $connection 100
echo $calculo 1555118080.0

É isso ai minha gente …

Kenia Milene

Oração do DBA

AVE BANCO CHEIO DE DADOS
MILHÕES DE REGISTROS CONVOSCO
BENDITO SOIS VÓZ ENTRE AS ESTATÍSTICAS
BENDITO A ALTA DISPONIBILIDADE … STANDBY
SANTA PACIÊNCIA MÃE DO DBA
ASSIM COMO NÓS ADMINISTRAMOS NOSSOS DADOS
E NÃO NOS DEIXEI CAIR EM DESESPERO
AGORA E NA HORA DO RESTORE
AMÉM

Kenia Milene

Regras Básicas de Tuning de Banco de Dados

Antes de começar a trabalhar é importante ressaltar algumas regras de performance. São elas:
1 - Verifique os problemas de software e hardware antes de mexer com o banco, muitas vezes o hardware não é adequado ou a aplicação não tem um bom fluxograma;

2 - Tenha um enfoque global, entenda todos as partes do sistema (hardware, S.O, rede, Banco de Dados, SQL e a própria aplicação. A baixa performance pode não estar ligada ao Banco e sim aos outro componentes que acabam afetando o banco;

3 - Modifique uma parte de cada vez, divida a tarefa em partes, analise, altere e veja os resultados um de cada vez. Muitas vezes ao modificar vários procedimentos ao mesmo tempo acaba-se dificultando a resolução caso algum imprevisto;

4 - NÃO PRATIQUE TUNING POR ESPORTE. Tuning é coisa séria e um parâmetro mal configurado por onerar ou até mesmo fazer com que o Banco pare de funcionar;

5 – Não tente resolver todos os problemas. Segundo Pareto 80% da resolução dos problemas são resultantes de 20% de ajustes, sendo assim, não perca tempo;

6 - Acima de tudo entenda o seu tipo de aplicação. Aplicações Web, OLTP ou DW requerem atenções diferentes.

CAUSA DOS PROBLEMAS

65% das causas de baixa performance em Bancos de Dados são causadas pelas aplicações. Dificilmente temos no mesmo ambiente um DBA Desenvolvedor ou um Desenvolvedor DBA, sendo assim, muito , mas muito cuidado na criação das consultas.

25% são causados pelos modelos de dados. Banco mal modelado tende a ser terrível. A melhor forma é normalizar o modelo, com isso ganhamos economia de espaço e a não repetição dos dados. Porém é necessário uma análise, pois em relatórios muito grandes não é aconselhável normalização quando falamos de ganho de performance.

5% são problemas do SGDB, acontece do gerenciador do banco não ter um algoritmo eficiente, ou não consegue manter as informações necessárias na memória por tempo eficiente. Atenção na aplicação de patchs e upgrades de versões.

5% são causadas por configurações ou deficiências do Sistema Operacional. Atenção no fluxo da rede, muitas vezes o servidor esta com uma placa de rede não adequada para a quantidade de fluxo de informações que trafega. Verificações de parâmetros de Kernel também são consideráveis, pois o S.O pode não estar deixando o banco escalonar que influencia no impacto do sistema.

TIPOS DE APLICAÇÕES

WEB - O Banco de dados costuma ser menor do que a memória disponível. Por ser pequeno, todo o seu conteúdo cabe na memória As consultas são bem simples e a quantidade de escrita é bem pequena.

OLTP - Nesse caso o Banco é grande e não cabe na memória, podendo chegar a 1TB. 20 a 40% das consultas são de pequeno porte e cresce consideravelmente a quantidade de escrita dos dados em disco.

DW - São bancos de grande porte variando de 100GB a 100TB. Esse tipo de banco tem cargas muito pesadas de dados e a escrita de dados costuma ser por meio de cargas com horários determinados, mas o volume de consultas é grande, sendo que, essas consultas na sua grande maioria sao complexas usadas para alimentação de relatórios.

PRIORIDADES NO SISTEMA OPERACIONAL

Cada tipo de aplicação demanda uma prioridade diferente no sistema operacional, levando-se em contas as considerações acima.

WEB - CPU, RAM, I/O. Na sua maioria o Banco esta em memória, sendo assim, o maior consumo é de CPU para o processamento das informações;

OLTP - I/O, RAM, CPU. A característica desse tipo de banco é justamente o grande volume de gravação em disco. Como grande parte do consumo é de I/O (Disco), deve-se dar uma atenção especial para eles em bancos desse porte. Um equilíbrio entre discos e memória é muito interessante nesse tipo de Banco de Dados;

DW - RAM, CPU, I/O. DataWareHouse tem a característica de ser um banco para consultas, muito usado em soluções de BI. A metodologia de uso de um DW varia de empresa para empresa, mas o ideal seriam cargas com horários pré-determinados (Madrugada, por exemplo) e as consultas durante o dia. Sendo assim o recurso mais consumido é a memória para retornar o valor das consultas, portanto é de extrema importância que o servidor de DW tenha uma quantidade grande de memória para evitar o uso de SWAP.

Obtive parte dessas informações no curso de Tuning de PostgreSQL, mas elas cabem para qualquer que seja o Banco de Dados.

Kenia Milene