|
| Accueil → WINDEV 25 → Sobre como e onde armazenar um database Ms SQL server e PostgreSQL |
| Sobre como e onde armazenar um database Ms SQL server e PostgreSQL |
| Débuté par Boller, 24 mai 2025 18:01 - Aucune réponse |
| |
| | | |
|
| |
Membre enregistré
4 520 messages |
|
| Posté le 24 mai 2025 - 18:01 |
Bom dia
Esse é um artigo técnico aprofundado no comparativo sobre estratégias de alocação dos arquivos MDF, LDF e BKP no SQL Server, com base em 3 propostas A, B e C. O foco é em performance, segurança, tolerância a falhas e custo-benefício. Ao final, vou emitir um parecer técnico como recomendação.
As Estratégias de Armazenamento para Banco de Dados SQL Server: Comparativo entre Soluções A, B e C, estão usando as melhores práticas:
Introdução
Ao criar um novo banco de dados no SQL Server, é crucial definir corretamente onde serão armazenados os arquivos:
• MDF (dados),
• LDF (log de transações),
• BKP (backups regulares).
A escolha de onde alocar esses arquivos influencia diretamente na performance, segurança, integridade e escalabilidade do banco de dados. Vamos analisar três cenários distintos com prós, contras e exemplos de scripts.
⸻
Cenário A — Tudo em um único servidor
• MDF: HD principal do servidor.
• LDF: Mesmo HD do MDF.
• BKP: Backup no mesmo servidor, posteriormente copiado para um terceiro PC.
Script de Criação
CREATE DATABASE [ERP_CENARIO_A]
ON PRIMARY (
NAME = N'ERP_CENARIO_A_DATA',
FILENAME = N'C:\SQLDATA\ERP_CENARIO_A.MDF',
SIZE = 512MB, FILEGROWTH = 128MB
)
LOG ON (
NAME = N'ERP_CENARIO_A_LOG',
FILENAME = N'C:\SQLDATA\ERP_CENARIO_A.LDF',
SIZE = 256MB, FILEGROWTH = 64MB
);
Backup e cópia manual
BACKUP DATABASE [ERP_CENARIO_A]
TO DISK = N'C:\SQLBACKUP\ERP_CENARIO_A.BAK'
WITH FORMAT, INIT, NAME = 'Full Backup - Cenário A';
-- Cópia para outro PC (ex: via robocopy ou script de rede)
-- robocopy C:\SQLBACKUP \\OUTROPC\BACKUPS\ERP_CENARIO_A\
Vantagens
• Fácil implementação e manutenção.
• Menor custo (um único servidor).
Desvantagens
• Risco alto: falha no HD compromete tudo (dados + log).
• Performance limitada em alto volume de I/O.
• Backup precisa ser copiado externamente manualmente.
⸻
Cenário B — MDF e LDF em HDs distintos do mesmo servidor
• MDF: HD1 do servidor.
• LDF: HD2 do mesmo servidor.
• BKP: Backup salvo diretamente em outro PC via rede.
Script de Criação
CREATE DATABASE [ERP_CENARIO_B]
ON PRIMARY (
NAME = N'ERP_CENARIO_B_DATA',
FILENAME = N'D:\SQLDATA\ERP_CENARIO_B.MDF',
SIZE = 512MB, FILEGROWTH = 128MB
)
LOG ON (
NAME = N'ERP_CENARIO_B_LOG',
FILENAME = N'E:\SQLLOG\ERP_CENARIO_B.LDF',
SIZE = 256MB, FILEGROWTH = 64MB
);
Backup direto em rede
BACKUP DATABASE [ERP_CENARIO_B]
TO DISK = N'\\OUTROPC\BACKUPS\ERP_CENARIO_B.BAK'
WITH FORMAT, INIT, NAME = 'Full Backup - Cenário B';
Vantagens
• Melhora de performance com separação de I/O.
• Mais segurança contra corrupção do log.
• Backup já em local externo.
Desvantagens
• Custo intermediário (dois HDs).
• Risco de falha no servidor ainda existe (não é tolerância total a falhas).
⸻
Cenário C — Distribuído por Storages externos
• MDF: Storage A (iSCSI ou SAN).
• LDF: Storage B.
• BKP: Storage C (remoto, seguro).
Script de Criação
CREATE DATABASE [ERP_CENARIO_C]
ON PRIMARY (
NAME = N'ERP_CENARIO_C_DATA',
FILENAME = N'Z:\SQLDATA\ERP_CENARIO_C.MDF', -- Storage A
SIZE = 512MB, FILEGROWTH = 128MB
)
LOG ON (
NAME = N'ERP_CENARIO_C_LOG',
FILENAME = N'Y:\SQLLOG\ERP_CENARIO_C.LDF' -- Storage B
);
Backup seguro e isolado
BACKUP DATABASE [ERP_CENARIO_C]
TO DISK = N'\\StorageC\Backups\ERP_CENARIO_C.BAK'
WITH FORMAT, INIT, NAME = 'Full Backup - Cenário C';
Vantagens
• Alta performance e escalabilidade.
• Máxima segurança e tolerância a falhas.
• Ideal para empresas com políticas de segurança rígidas.
Desvantagens
• Alto custo (3 storages dedicados).
• Requer configuração e administração avançada.
⸻
Conclusão Técnica
• Para pequenas empresas ou ambientes de testes, o Cenário A pode ser suficiente.
• Para empresas médias com necessidade de segurança e performance moderada, o Cenário B oferece o melhor custo-benefício.
• Para grandes corporações com missão crítica, Cenário C é o mais recomendado, por garantir alta disponibilidade, segurança, escalabilidade e performance, ainda que exija investimento mais alto.
O que é Storage?
Storage, em TI, é uma solução de armazenamento de dados externa ou dedicada, usada para guardar arquivos, bancos de dados, backups e informações críticas de forma segura, centralizada e com alta performance.
É como um “HD gigante e inteligente”, normalmente conectado a servidores por rede, que oferece:
• Alta capacidade
• Alta velocidade
• Alta confiabilidade
• Redundância (RAID, snapshots, espelhamento)
• Gerenciamento centralizado
⸻
Principais tipos de Storage
1. DAS (Direct Attached Storage)
• Conectado diretamente ao servidor.
• Ex: HDs ou SSDs internos.
• Uso: local e barato, mas limitado em escalabilidade.
2. NAS (Network Attached Storage)
• Conectado à rede via IP (como se fosse uma pasta compartilhada).
• Uso: ideal para compartilhamento de arquivos, backups e arquivos de mídia.
3. SAN (Storage Area Network)
• Rede dedicada de armazenamento, geralmente via iSCSI ou Fibre Channel.
• Uso: ambientes corporativos, bancos de dados, virtualização.
• Altíssimo desempenho, tolerância a falhas e escalabilidade.
Espero que essas dicas sejam levadas em conta quando forem criar um banco de dados Ms SQL Server
Não tem lógica numa empresa capaz de ter um Storange ter um banco no exemplo A é correr riscos à toa sendo que o exemplo C garante a performance do banco, das restaurações snapshots e dos bkps!
Poucos sabem que o MDF pode ficar num HD e o LDF em outro e isso muda a performance drasticamente pois a controladora de discos dividirá as tarefas e isso dará um resultado incrível em suas aplicações.
E isso também é possível fazer com o PostgreSQL !!!
Os tablespaces podem ser direcionados para outras unidades de disco.
E inclusive isso é altamente recomendado em ambientes profissionais ou críticos!
Assim como no SQL Server, você pode:
⸻
1. Separar arquivos de dados, logs e backups em diferentes storages
PostgreSQL armazena tudo no diretório data/, mas com configuração avançada, você pode:
• Montar datafiles (dados) em um Storage A.
• Redirecionar WAL logs (Write-Ahead Log) para um Storage B.
• Armazenar backups com pg_dump ou base backups em um Storage C (inclusive na nuvem).
⸻
2. Exemplos práticos de como fazer isso
Separar dados e WAL logs
Você pode usar um symlink ou montagem separada:
# Suponha que o log vá para /mnt/storageB/pg_wal
mv /var/lib/postgresql/15/main/pg_wal /mnt/storageB/pg_wal
ln -s /mnt/storageB/pg_wal /var/lib/postgresql/15/main/pg_wal
Fazer backups com pg_basebackup para Storage C
pg_basebackup -D /mnt/storageC/backups/pg15 -Ft -z -P -U replicador
⸻
3. Benefícios ao usar Storage com PostgreSQL
Recurso Benefício com Storage
Performance Aumento por separar I/O de dados e logs
Segurança Backup em storage externo garante integridade
Redundância RAID + snapshots automáticos
Escalabilidade Pode crescer sem downtime adicionando mais volumes
Alta disponibilidade Facilitada via replicação + storage rápido
⸻
4. Tecnologias que combinam com PostgreSQL
• ZFS ou BTRFS para snapshots nativos.
• pgBackRest para backups em storages externos com compressão.
• PostgreSQL + SAN com discos dedicados para IOPS intensivos.
• Ceph + PostgreSQL em clusters escaláveis.
⸻
Conclusão
Sim, PostgreSQL também pode e DEVE usar arquitetura com múltiplos storages, especialmente quando:
• O volume de dados é grande,
• O ambiente exige alta disponibilidade,
• A empresa quer minimizar riscos e otimizar performance.
--
Adriano José Boller
______________________________________________
Consultor e Representante Oficial da
PcSoft no Brasil
+55 (41) 99949 1800
adrianoboller@gmail.com
skype: adrianoboller
http://wxinformatica.com.br/ |
| |
| |
| | | |
|
| | | | |
| | |
|