Estimar o tamanho do banco de dados

[wbarrence]

Amigos,

Não sei se estou fazendo a pergunta no fórum correto, por isso já peço desculpas aos moderadores.

Alguém conhece alguma ferramenta, técnica, método ou boa prática, para fazer a estimativa do tamanho de um banco de dados?

Será que no fórum tem algum consultor Oracle que lida com esse tipo de problema? Até mesmo determinar a solução mais indicada de acordo com o porte do sistema e da empresa?

Se possível indicar algum material para leitura, ou descrever alguma prática utilizada no dia-a-dia (que é o mais importante).

Desde já agradeço pela ajuda.

Att,

[adrianoturbo]

Brother,está ai uma um assunto interessante para responder numa sexta-feira boa para fugir do mundo e conhecer uma galáxia distante :estimativa de crescimento.
Já assistir esse filme que o DBA tem que virar mãe Dinah ,então vamos lá:
Era um vez um banco de dados em produção que tinha e estourou uma Tablespace com um aviso muito legal bem na cara : ORA-01652.
O que aconteceu ?
O sistema de arquivo do SO estava na tampa e o limite do Tablespace em 99,99%,ou seja , o próximo insert não seria commitado e consequentemente o ORA-01652 apareceria.
Mas ai onde está a estimativa de crescimento ? Você deve está se perguntando .
A resposta em todo lugar ,foi feito um estimativa de crescimento para o banco em 2009 e a previsão era que no final 2013 o banco iria parar e não deu outra,o banco parou.
O que fazer para resolver? Alocar espaço em disco em redimensionar o tamanho dos datafiles.
Vou dizer uma coisa estimativa não se faz por osmose ,requer um pouco de estudo de estatística, estudo de file system e tablespace ,resumindo espaço em disco, o maior vilão continua sendo a storage,é preciso levar o espaço em disco em consideração pra fazer premonições da Mãe Dinah.
Agora vou deixar de conversa fiada e vamos para o que interessa:
No Oracle tem duas views ótimas para fazer estimativas de crescimento: DBA_FREE_SPACE e DBA_DATA_FILES.
Faça o seguinte abrar aquela ferramenta legal da Microsoft que trabalha com planilhas que era nome de um banco:sim o Excel Econômico e crie as seguintes colunas :

Selecionar tudo

TABLESPACE | 1º DIA | 7° DIA | 14º DIA | 21ºDIA | 28ºDIA |35º DIA | 42ºDIA | 49ºDIA | 56º DIA | 63ºDIA | 70ºDIA |77ºDIA| 84ºDIA|91ºDIA

Temos aqui 15 colunas no total .

Basta fazer um relacionamento bacana dessas duas views e sai dando select a cada 7 dias e ir jogando os dados nessa planilha ,cara em apenas 91 dias descobrirá a média de crescimento do seu banco e poderá fazer uma projeção de crescimento.
É BOM SEMPRE LEMBRAR QUE DEVE -SE MONITORAR O TAMANHO DE ESPAÇO EM DISCO.
Bom amigão é isso,espero ter ajudado,logo abaixo tem um readme ,na verdade são dois falando muito bem dessas duas views,fique a vontade para ler é de graça a Oracle já pagou rs.

DBA_FREE_SPACE : http://docs.oracle.com/cd/B19306_01/ser ... s_3122.htm


DBA_DATA_FILES : http://docs.oracle.com/cd/B19306_01/ser ... s_3083.htm

[adrianoturbo]

Antes que me esqueça ,crie também uma planilha para o seu ou seus sistemas de arquivos com o mesmo esquemas dos múltiplos de 7 dias até 91 para monitorar o armazenamento em disco.

[stcoutinho]

Olá wbarrence,

Não sei se você dispõe da ferramenta CA-ERWIN em seu trabalho. Esta ferramenta permite que você faça uma estimativa grosseira do crescimento do seu banco de dados, bastando para isso modelar o banco de dados na ferramenta e responder (para cada tabela) qual seria a estimativa de "crescimento mensal", a "quantidade inicial de linhas" e o "tamanho máximo de linhas na tabela".

Mas digamos que você não tem nada disso, e que você vai criar sua base do zero. Como fazer uma previsão do espaço a ser ocupado no futuro?

Você poderia seguir uma regra empirica simples, e aplicar ela para cada tabela do seu futuro banco de dados:

00) Crie todas as tabelas vazias em um schema de trabalho;
01) Para evitar muito trabalho, desative eventuais constraints nas tabelas (ex: FK-foreign keys, AKs-unique keys, CK-checl constraints);
02) Insira para cada tabela um registro ficticio, preenchendo as colunas em toda a sua extensão. Ex: CD_CONTRATO VACHAR2(12) => popule esta coluna com "123456789012"/ ID_NUMERO NUMBER(2)=> popule esta coluna com "10", etc;
03) Gere as estatisticas completas deste schema:

Selecionar tudo

BEGIN DBMS_STATS.GATHER_SCHEMA_STATS (OWNNAME=> USER,ESTIMATE_PERCENT=> 100); END;

04) Pronto! Agora você pode fazer uma consulta no dicionário de dados para saber o tamanho médio em bytes deste registro. Faça um:

Selecionar tudo

SELECT TABLE_NAME,AVG_ROW_LEN FROM USER_TABLES ORDER BY TABLE_NAME;

05) A querie acima lhe mostra o tamanho médio em bytes do registro de cada uma das tabelas do schema;
06) Com estas informações, você pode criar um excel para "brincar com previsões de crescimento".
07) Crie um excel com estas colunas:
- Nome Tabela;
- Tamanho medio do registro em bytes;
- Quantidade inicial de registros (pode ser 0 ou ter uma quantidade inicial de registros) ;
- Crescimento Mensal;
- Projeção para 12 MESES e 24 MESES;

Exemplo:
- Nome Tabela : TBL_XPTO
- Tamanho medio registro : 2000 BYTES
- Quantidade inicial : 10
- Crescimento Mensal : 20
- Projeção para 12 MESES :

Selecionar tudo

FORMULA=((QUANTIDADE INICIAL)*(TAMANHO MEDIO REGISTRO))+((CRESCIMENTO_MENSAL)*12*(TAMANHO MEDIO REGISTRO)

- Projeção para 24 MESES :

Selecionar tudo

FORMULA=((QUANTIDADE INICIAL)*(TAMANHO MEDIO REGISTRO))+((CRESCIMENTO_MENSAL)*24*(TAMANHO MEDIO REGISTRO)

08) Este levantamento pode ser bem trabalhoso, mas você pode tentar "racionalizar" as estimativas:
- Exemplo: Tenho duas tabelas (tabela_nota_fiscal e tabela nota_fiscal_itens). Eu sei que cada NF tem 5 itens em medias, então se em 10 meses tenho 200 notas fiscais, então eu terei 200*5 itens de nota fiscal;
09) Lembre-se que - ao fazer previsoes de crescimento muito longas - você precisa entender que suas tabelas não vão crescer infinitamente até o banco explodir. Você provavelmente terá tabelas cadastrais com uma dezena de registros que jamais receberão novas cargas, ou tabelas gigantes que estarão sempre passando por uma rotina de limpeza;
10) Tomando estes cuidados, basta somar o valor encontrado para todas as tabelas do sistema que você estará proximo de uma estimativa GROSSEIRA do tamanho do banco de dados a ser alocado para seu sistema. Lembre-se que é uma estimativa .. você não é paranormal e nem tem o dom de prever o futuro. Então, eu poderia sugerir a você a aplicar uma "margem de erro" de 15% (pra cima)neste valor obtido. Eu sempre prefiro uma "abordagem pessimista", pois creio ser mais fácil dispor de um disco parcialmente vazio do que um disco cheio que não pode ser aumentado no momento;
11) Você vai me perguntar agora: e os índices? O que faço com eles? Pelo que pude ler sobre o assunto, não haveria uma formula muito confiável para você prever o crescimento de um indice, especialmente se serão feitos muitos updates/deletes nas colunas indexadas. Eu poderia sugerir - um super CHUTE - para você estimar em 60% do total ocupado pelos dados de seu schema;

Esta é uma forma bem GROSSEIRA E EMPIRICA de se prever um crescimento para uma base que AINDA não EXISTE. Se você tem o ERWIN, eu sugiro que modele seu banco por ele e projete o crescimento por meio da ferramenta. Pelo menos depois você pode explicar para seu cliente que você baseou seu calculo em uma ferramenta do mercado.

Se não dispor do ERWIN, então tente seguir o roteiro acima e DOCUMENTE a metodologia adotada e os resultados obtidos. Se mais para a frente seu banco crescer mais do que o previsto e seu cliente reclamar, você pode demonstrar para ele que não chutou os valores e tentou fazer uma análise do crescimento.

Creio que os foristas aqui do GLUFKE devem dispor de outras sugestões para o seu desafio.

Abraços e boa sorte,

Sergio Coutinho