Tar Remoto

Bom, a maneira mas simples de se fazer um backup é gerando um tar, acontece que o ideal é que esse tar não fiquei localmente no servidor, o ideal é que ele fique armazenado de preferencia em um servidor de backup.

Por um acaso ao gerar o tar, você já recebeu a triste noticia que não tinha espaço locar para gerar o tar?????

Pois é minha gente …. ninguém merece, mas eu conheço uma forma para resolver esse pequeno contratempo, podemos fazer isso com um tar remoto.

O tar remoto nada mais é do que gerar o tar direto no diretório do servidor onde ele vai ficar armazenado.

Para isso bastar seguir o exemplo abaixo:

tar cvfzp – /home/backup/ | ssh user@host ‘cat – >/backup/kenia/backup_ 20050921.tar.gz’

Com isso geramos o tar do /home/backup direto no diretorio kenia do servidor remoto

Espero que possa ser útil

Kenia Milene

A Vida Dura de Um DBA

Há quem diga que a vida de um DBA é moleza …. digamos que não é tão simples assim, como a vida de um sysadmin também não é, e vou dizer mais .. se ele for sysadmin ou DBA de Datacenter, eu tiro o chapéu porque não tem vida, não tem sono, não tem nada, só um celular que deve estar disponível 24/7, mas isso é papo pra um outro post.

Um DBA tem algumas atribuições e responsabilidades, vou citar algumas delas:

1 – Criação e administração dos ambientes de banco de dados

2 – Participar dos projetos dos sistemas

O DBA deve participar dos projetos dos sistemas, pois o banco é parte essencial do projeto, conhecer as informações a serem utilizados a fim de integrá-los ao banco de dados, e ainda saber qual o hardware vai ser usado para entender se os discos, memória e processador são suficiente para a demanda do banco.

Se houver um DA a modelagem fica por conta dele, o DBA não precisa se envolver nesse momento.

Em alguns infeliz lugares isso não ocorre não é verdade ??? os GPs simplesmente projetam tudo sem ao menos falar com os DBAs, e quando os problemas começam a aparecer, “SE VIRA DBA, O PROBLEMA É DO BANCO!!!”. Sem falar em alguns sysadmins que simplesmente mensuram o servidor sem avisar ninguém, sem perguntar ao DBA quantas conexões para calcular processamento e memória, o tamanho do banco e quantos são para saber quantos discos tem que comprar … e por ai vai … E ainda por cima fica responsável pela modelagem de dados.

Existem ainda lugares onde não existe um sysadmin, ou um DBA, o cara que cuida do servidor de correio, firewall, file server, etc, é o mesmo que cuida do servidor banco. Sendo assim é contratado uma única pessoa para exercer a função de sysadmin, DBA, DA e GP e com com salário de estagiário. É o fim do mundo minha gente….

3 – Estabelecer junto o sysadmin regras para o ciclo de vida dos dados armazenados, a fim de evitar o alto índice de crescimento do banco de dados, que pode comprometer seu desempenho e ocupar desnecessariamente espaço em disco.

4 – É função do DBA, junto ao sysadmin também o estabelecimento de critérios e parâmetros para a instalação de programas clientes.

O DBA deve fornecer, ao sysadmin, que repassará para a equipe de suporte responsável pela instalação dos programas clientes de banco, os procedimentos para sua configuração, verificação e testes de conexões.

5 – É Dever do DBA em conjunto com o sysadmin o dimensionamento do equipamento destinado ao servidor de banco de dados

Cabe ao DBA acompanhar o crescimento da demanda (levando em consideração os tunnings para otimização), ter documentado comprovando que o banco esta sendo prejudicado pelo equipamento ultrapassado, ou quando for previsível o próximo esgotamento dos recursos do sistema. Planejar com o sysadmin a evolução do equipamento servidor do banco de dados.

6 – Suporte às equipes de DA na modelagem de dados (Se os DAs existirem!!!! )

O DBA deve auxiliar as equipes de AD na fase final do modelo conceitual de dados dos sistemas em desenvolvimento. Esse modelo deverá ser implantado em tabelas que, inclusive, poderão já existir.

7 – Apoio aos desenvolvedores na implantação ou manutenção de sistemas.

O DBA poderá auxiliar na otimização de códigos, conhecido como Tunning de Queries e criar índices e “views” para melhorar o desempenho das aplicações.

8 – Estabelecimento das políticas para assegurar a disponibilidade do banco e evitar a perda de informações.

O DBA deve estabelecer normas para os procedimentos de “backup”, “restore” e de paradas do banco para manutenção preventiva.

Geralmente é indicado pelos DBAs um segundo servidor para StandBy do banco de produção. Essa técnica é muito usada para quando houver um problema mais sério no servidor de produção e ele ficar indisponível, o servidor StandBy assume, mantendo a disponibilidade dos dados. Porém algumas empresas não têm budget para poder disponibilizar um segundo servidor, então nesse momento minha gente…. o DBA tem que se virar em 2 junto com o sysadmin para montar uma super operação de Backup.

9 – Garantia de segurança, estabelecendo algumas regras:

· Validação de acesso ao banco de dados, (Bem, eu sou contra a usuários externos, mas dependendo da aplicação é necessário);

· Privilégios de usuários;

· Controle de processos simultâneos em sistemas cliente-servidor.

10 – Garantia da integração dos objetos.

O DBA deve analisar o uso de “triggers”, “stored procedures”, “views”, bem como o uso de redundância controlada de dados. Assim, auxiliará as equipes de desenvolvimento, e evitará rotinas que possam por em risco à consistência do banco ou provocar o seu crescimento excessivo e desnecessário.

11 – Monitoramento do banco.

O DBA deve monitorar constantemente o banco, reorganizar as tabelas e ajustar os parâmetros às novas necessidades. Este tipo de ação permite que um bom desempenho do banco seja mantido, reduzindo a necessidade de troca ou evolução de equipamento.

Muitas vezes um banco mal administrado, pode levar a um errôneo julgamento da necessidade de troca de equipamento. É claro que todo equipamento tem um tempo de vida, mas em alguns momentos é possível mantê-lo ainda por um bom tempo, se o banco estiver rodando adequadamente. Isso acontece muito em órgãos públicos que dificuldades burocráticas para troca de equipamento.

12 – Avaliação da aquisição de upgrade de versão do banco.

O DBA deve estar “bem esperto” para evitar a defasagem tecnológica dos bancos. Mudanças eventualmente sugeridas devem considerar o impacto nos ambientes de desenvolvimento e de produção e a razão custo-benefício.

É de extrema importância um projeto de migração anual, evitando assim problemas com paths de segurança. Planeje também com o sysadmin o upgrade do Sistema Operacional, pois o upgrade do banco pode não acontecer, ou não resolver os problemas de segurança devido a versão do S.O ser muito antiga.

12 – Apresentação ao responsável de TI Relatórios de planejamento semestral das atividades a serem executadas e ainda relatórios das atividades já finalizadas para análise e aprovação.

13 – O Estabelecimento de políticas de replicação de dados também é muito importante.

O DBA deve estabelecer os parâmetros do sistema gerenciador do banco de dados, definindo a forma como a replicação de tabelas será feita.

Essa técnica é muito usada pelos desenvolvedores para cargas em ambientes de testes para homologação das aplicações em desenvolvimento. A freqüência dessas replicações será estabelecida em conjunto pelo DBA e pelos responsáveis pelas Equipes de Desenvolvimento.

Indico Também a leitura de um post sobre como o DBA deve agir para conseguir lidar com os desenvolvedores:
http://www.midstorm.org/~telles/2007/06/27/12-dicas-para-o-dba-lidar-com-o-desenvolvedor/

Kenia Milene

Gerenciamento de Memória em Bancos PostgreSQL

Um dos pontos mais importante a ser analisado quando administramos um banco de dados é a MEMÓRIA COMPARTILHADA.
Saber, ao montar um servidor o quanto deixar de memória para o sistema operacional e o quanto alocar para o banco.
Será que a memória compartilhada é o suficiente para a quantidade de usuários (conexões) que tenho ???? e se meu banco tiver uma quantidade muito grande de transições ??? e se for um DW onde a maior fatia são das consultas???
Pois bem, esses eram alguns fantasmas que rondava a minha singela vida de DBA. Mas eu aprendi e espero que possa ajudar a quem estiver com essas mesmas dúvidas.

Primeiramente qual o papel da memória compartilhada?

Memória compartilhada é o valor disponibilizado no buffer para as transações do banco. Esse valor é variável, em bancos Postgres é indicado que este valor deve estar entre 1000 (8MB) a 500000 (400MB), e manipular esses valores dependendo do número de conexões e consultas (complexas ou simples).
Alguns bancos indicam ainda que o valor a ser destinado ao banco não pode ultrapassar de 1/3 (33%)da RAM disponível.

Como ela é calculada?

Um usuário consome em média 14,2 KB por conexão, com essa informação calculamos através da seguinte fórmula:((bloco do S.O X pag. a ser utilizada)+(14,2 KB * conexões))+250 KB= memória compartilhada

EX: ((4096 X 500000)+(14,2 *50))+250 KB= 2048000960 (2.048GB)

Esse valor deve ser setado nos parâmetros do kernel da seguinte forma:

echo “kernel.shmmax=2048000960 ” >> /etc/sysctl.conf ; sysctl -p

Tamanho dos Blocos

Esse parâmetro é usado para configurar o tamanho do bloco, o tamanho é definido tendo em vista as transições no banco, pois em uma transição pequena é melhor a busca em blocos pequenos e no caso de grandes buscas como em um DW por exemplo, é melhor um bloco maior.
Para grandes buscas como um DW, use 8192, porém esse valor só será considerável em servidores que suporte esse tipo de blocagem, e não se esqueça que será necessário diminuir a shared buffer, caso contrario, use a blocagem 4096.
Cada usuário utiliza em media 14,2 KB por conexão. Quanto mais conexões existirem no banco, menor deve ser a quantidade de páginas disponíveis. Tudo esta relacionado ao tipo e tamanho das transações e a área de ordenação.

Área de Ordenação

A área de ordenação (work_mem), é uma quantidade de memória física para realização de consultas por usuários. No caso de um DW é interessante ter essa área grande, pois, quanto maior a quantidade de memória destinada melhor será o desempenho da consulta principalmente se a mesma for complexa. Se a quantidade de memória estipulado nesse parâmetro foi ultrapassado o banco será obrigado a fazer SWAP causando lentidão nas consultas (e muito estress recheadas de ligações de usuários histéricos), resultando na concorrência entre o banco de dados e o sistema operacional.
No caso de banco com muitas consultas como um DW é indicado um servidor com uma quantidade considerável de memória e colocar o sistema operacional e o banco em discos separados para manter um melhor desempenho.

Então como diminuir a quantidade de páginas?

Bem, a paginação deve ser diminuída quando o número de conexões aumentar, isso tem que acontecer para que posteriormente não seja necessário mexer na memória compartilhada. Quando necessário, a quantidade de páginas a ser diminuída seguindo a seguinte fórmula:
(usuário acrescidos * 14,2KB) / blocos

Ex: 20 usuários acrescidos com a blocagem de 4 KB

(20 * 14,2) / 4
284 /4
71 KB(arredondando 100KB)

Sendo assim é necessário diminuir 100KB do shared buffer

Consultando as informações para os cálculos e alterando os arquivos de configuração

banco1=#
SELECT name, setting
FROM pg_settings
WHERE name IN(‘shared_buffers’,’max_connections’,’block_size’,’work_mem’);

name | setting

——————+———
block_size | 4096
max_connections | 50
shared_buffers | 500000
work_mem | 500000

com exceção do block_size que é definido na compilação os outros parâmetros podem ser alterados no postgresql.conf de cada banco.

Kenia Milene