Administrac ºa Âo PostgreSQL Com Alta Performance e Alta Disponibilidade

Amorim Weverton Rufino De / weverton.geek@gmail.
com
4Linux
também é
consultoria, suporte
e desenvolvimento.
Você já deve nos conhecer pelos melhores cursos de linux do Brasil mas a
4Linux também é consultoria, suporte e desenvolvimento e executou alguns
dos mais famosos projetos do Brasil utilizando tecnologias “open software”.
Você sabia que quando um cidadão faz uma aposta nas loterias, saca dinheiro em
um ATM (caixa eletrônico), recebe um SMS com o saldo de seu FGTS ou simula o valor
de um financiamento imobiliário no “feirão” da casa própria, ele está usando uma
infraestrutura baseada em softwares livres com consultoria e suporte da 4Linux?
Serviços
Consultoria: Suporte Linux e Open Source: Desenvolvimento de Software:
Definição de Arquitetura, tunning em Contratos com regimes de atendi- Customização visual e funcional de
banco de dados , práticas DEVOPS, mento – preventivo e/ou corretivo - softwares Open Source, consultoria para
metodologias de ensino on-line, em horário comercial (8x5) ou de a construção de ambiente ágeis de
soluções open source ( e-mail, monito- permanente sobre-aviso (24x7) para Integração Contínua (Java e PHP) e
ramento, servidor JEE), alocação de ambientes de missão crítica. Suporte mentoria para uso de bibliotecas, plata-
especialistas em momentos de crise e emergencial para ambientes construí- formas e ambientes Open Source.
auditoria de segurança. dos por terceiros. Parceiro Oficial Zend.
Parceiros Estratégicos
Saiba mais
www.4linux.com.br/suporte
contato@4linux.com.br
Amorim Weverton Rufino De / weverton.geek@gmail.com
Características e Instalação
do PostgreSQL
Curso 801
Administração
PostgreSQL com
Alta Performance e
Alta Disponibilidade
Versão 4.1
Características
Características e Instalaçãodo
e Instalação doPostgreSQL
MySQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características e Instalação do PostgreSQL
Objetivos da Aula
 Conhecer a Origem do PostgreSQL

 Instalar o PostgreSQL;
 Ver as Características;
 Trabalhar com psql
 Criar um Banco de Dados;
 Comando SELECT
 Setup do repositório no Debian
 Filtros (WHERE, AND)
 Setup do repositório no Centos
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Origem do PostgreSQL
Microsoft
Sybase Corp Informix IBM
Tandem -NonStop SQL PostgreSQL
Berkeley POSTGRES Postgres95
Berkeley INGRES
CA Ingres Corp.
1970 1984 1987 1995 2016
Tudo começou como INGRES

Em 1973 estava começando o projeto System R da IBM, quando dois cientistas
da Universidade da Califórnia Berkeley, Michael Stonebraker e Eugene Wong, se
interessaram pelo projeto e decidiram por eles mesmos desenhar um sistema de
bancos de dados relacionais, a primeira versão do INGRES foi disponibilizada em
1974, já com uma pequena comunidade de usuários e manutenção do código fonte.
Apesar de seguir os conceitos e premissas do System R de grande porte da IBM,
o INGRES era primordialmente usado no Unix para máquinas DEC.
Os derivados
O INGRES era vendido em código fonte, disponível em fitas por uma pequena
taxa. Em torno de 1.000 cópias circulavam principalmente em universidades.
Vários bancos de dados comerciais utilizaram em seu princípio partes do
código do INGRES, principalmente por causa dos estudantes que participaram do
projeto original em Berkeley e que se juntaram ou fundaram as companhias que os
desenvolveram:
●
Início dos anos 80, Tandem Computers - Non-Stop SQL
●Meados dos anos 80, Sybase Corporation - Sybase
●Em 1992 a Microsoft licenciou alguns produtos Sybase – SQL Server
●Em 1997 a Informix adquiriu os demais direitos – Sybase
●Em 2000 a IBM tornou-se proprietária da Informix – Sybase
INGRES hoje
Stonebraker e Wong criaram a RTI-Ingres. Em 1994 o então Ingres se tornou
propriedade da Computer Associates. Em 2004 alguns componentes do Ingres foram
liberados sob três licenças diferentes de código livre.
Em 2005 foi criada a Ingres Corporation. Ela mantém suporte ativo ao código
fonte e usuários até hoje.
Pronúncia e Suporte do PostgreSQL
Pronúncia e escrita
 PostgreSQL ou Postgres - CORRETO

 Postgri, Postigré, Postgrês, Postigris – ERRADO
Suporte da Comunidade
 www.postgresql.org/community
 www.postgresql.org.br/comunidade
Finalmente, PostgreSQL
●1996 O Postgres95 foi rebatizado como PostgreSQL, muitos usuários

carinhosamente ainda o chamam por Postgres, talvez pela herança do nome original
e facilidade da pronúncia. A comunidade aceita ambas as denominações PostgreSQL
e Postgres, é assim que pode ser escrito.
●
1997 PostgreSQL 6.0 com a inclusão do MVCC(Multiversion Concurrencu Control) e
novos datatypes de data, hora e tipos e geométricos.
● 2000 PostgreSQL 7.0 WAL(Write Ahead Log), schemas, indexação por texto.
●
2005 PostgreSQL 8.0 Suporte para Microsoft Windows, tablespaces, PITR.
●2010 PostgreSQL 9.0 Amadurecimento do PL/pgSQL, suporte completo a Windows

64 bits, implementação do VACUUM FULL, ferramenta de upgrade pg_upgrade para
versões 8.3 e 8.4 para a versão 9.0, explain funciona para JSON, XML e YAML e
evoluções nas metodologias de replicação.
Características do PostgreSQL
 Banco de dados ACID;

 Licença BSD;
 Suporte ao padrão ANSI-SQL:2008;
 Possui replicação nativa;
 Bando de Dados Multi-Plataforma;
 Diversas ferramentas da comunidade.
6
Características atuais
O PostgreSQL é considerado o banco de dados livre mais avançado do mundo
por várias razões. Suporta largamente o padrão ANSI-SQL 2008 e respeita a norma
ACID. É altamente extensível, tem vários tipos de índices para diversas aplicações.
Pode ser instalado na maioria dos sistemas operacionais tipo Unix como Linux,
Solaris, AIX, HP-UX, família BSD, Mac OS X, True 64, etc. Atualmente conta também
com porte nativo para Windows.
A licença utilizada é a BSD, que permite a redistribuição comercial em formato

binário, original ou alterada, do programa ou da documentação, desde que seja
mantida a citação original dos desenvolvedores, do código original da Universidade
da Califórnia e a ausência de garantias.
A maioria das linguagens de programação modernas preveem interface nativa

para o PostgreSQL. Para as linguagens que não possuem interface nativa pode ser
feito o acesso através da interface ODBC. Aplicações Java contam com driver JDBC 3
e 4.
Existem centenas de projetos livres e comerciais relacionados à administração,

monitoramento, interfaceamento e extensão do PostgreSQL. Existe tradução para 24
idiomas.
Características do PostgreSQL - ACID
Atomicidade Consistência
Isolamento Durabilidade
ACID é uma característica fundamental para os bancos de dados, pois fecha

todos os pontos a fim de garantir uma transação correta. As características são:
Atomicidade: Garantir o início, meio e fim da transação a fim de que a transação só

seja efetuada por completa ou não seja executada, garantir que a transação não seja
executada parcialmente.
Consistência: Com a execução de várias transações em paralelo nenhuma transação

pode permitir que o banco de dados fique inconsistente. Significa garantir que, em
todo o momento, os dados estarão consistentes tanto antes, quanto durante e após
cada transação.
Isolamento: As transações executadas em paralelo não podem interferir nas

transações concorrentes durante a execução. Essa garantia é dada por “locks” no
banco.
Durabilidade: Após a conclusão da transação o banco precisa garantir que o dado

fique íntegro mesmo que haja qualquer tipo de falha no banco de dados. O
PostgreSQL usa um mecanismo de escrita em disco para essa garantia.
Versionamento do PostgreSQL
Atualizações minoritárias
 9.5.X (terceiro número da versão);

 Correção de BUGs;
 Correções de Segurança;
Atualizações majoritárias
 X.X (primeiro ou segundo numero da versão)

 Novas funcionalidades
Versionamento
Sendo um projeto comunitário, o PostgreSQL provê atualizações através do
site oficial www.postgresql.org. Se o pacote instalado for fornecido diretamente pelo
seu S.O., verifique as opções de atualização disponíveis.
As versões do PostgreSQL são divididas em majoritárias e minoritárias. As
versões majoritárias são identificadas pelos primeiros dois números da versão,
também chamadas de série. As versões minoritárias são identificadas pelo último
número da versão.
Uma versão majoritária é lançada a cada, aproximadamente, um ano, após
extensivos testes Novas versões majoritárias costumam incluir novas
funcionalidades ao PostgreSQL, que são normalmente discutidas nas listas
internacionais de discussão, na página wiki do Roadmap e debatidas e aprovadas
na reunião de desenvolvedores, que ocorre em paralelo ao evento PgCon, no
Canadá, no mês de maio de cada ano.
Um exemplo de versão minoritária disponível atualmente (em maio de 2015)
é a 9.4.1, significando que têm todas as funcionalidades da série 9.4.x, sendo que
existe somente 1 versão de correção foi lançada.
As versões majoritárias atualmente disponíveis para download estão
disponíveis no link: https://www.postgresql.org/ftp/source/
Nota
Atualmente (2016) as versão suportadas são da 9.1 até a 9.6, versão anteriores a
9.1 não são mais suportadas pela comunidade, nestes casos é extremamente
recomendável a atualização para uma das versões mais novas e suportadas.
Formas de instalação do PostgreSQL
 Instalação do fornecedor do SO;

 Utilização do repositório do site postgresql.org;
 Pacotes em postgresql.org (“rpm” e “deb”);
 Compilar código fonte;
Instalação do fornecedor do S.O.

● Está pronto para instalar, costuma ser a forma mais fácil e rápida;
● As flags utilizadas na compilação geralmente são as default;
● Todo sistema operacional possui uma estrutura de diretórios definida por seus
desenvolvedores;
● A versão do PostgreSQL será fixada pelo fornecedor ou comunidade.
Pacotes em www.postgresql.org
● Não estão disponíveis para todos os S.O. ou todas as variantes e versões do S.O.;
● Em alguns casos, é a única opção disponível (ex. Windows);
● Têm suporte da comunidade;
● São compiladas com as flags definidas pela comunidade.
Compilar o código fonte

● Maior grau de dificuldade;
●
Exige a presença do compilador C e código fonte das bibliotecas necessárias;
● Permite a maior customização;
● Permite a instalação de qualquer uma das versões disponíveis do PostgreSQL.

Instalação do PostgreSQL no Debian
# aptget
# dpkg
10
A comunidade PostgreSQL oferece pacotes no site www.postgresql.org. As

seguintes características estão presentes:
● Não estão disponíveis para todos os S.O. ou todas as variantes e versões do S.O.
●
Para distribuições GNU/Linux estão disponíveis repositórios para apt e yum,
distribuições recentes baseadas em Debian e Red Hat, respectivamente. Os
repositórios são completos e disponibilizam todas as versões suportadas do
PostgreSQL, bem como módulos contrib e outras ferramentas acessórias em
versões atuais como o PgAdmin 3, Slony, etc.
● Existe o one-click installer para Linux disponibilizado pela empresa EnterpriseDB.
O one-click installer, instala o PostgreSQL no diretório /opt e é compatível com a

maioria das distribuições recentes.
●
Para alguns sistemas operacionais, os pacotes disponíveis na comunidade são a
única opção disponível, como Windows e Mac OS X.
● Os pacotes da comunidade tem suporte pelos meios oficiais da comunidade
PostgreSQL como a documentação, FAQ, listas de discussão e wiki.

● São compiladas com as flags padrão, definidas pela comunidade.
Instalação do Repositório PostgreSQL no Debian
Execute os comandos abaixo nos servidores: dbmaster e standby1
1 Servidores dbmaster e standby1 inserir o repositório:

1# vim /etc/apt/sources.list
+ deb http://apt.postgresql.org/pub/repos/apt/ jessiepgdg main
2 Realize o download da chave do PostgreSQL e adicionar ao apt:
2# wget https://www.postgresql.org/media/keys/ACCC4CF8.asc
3# aptkey add ACCC4CF8.asc
3 Atualize a lista de pacotes do repositório:

4 # aptget update
11
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Instalação do PostgreSQL no Debian
Execute os comandos abaixo nos servidores: dbmaster e standby1
1 Instale o pacote com o comando apt-get install conforme segue:

# aptget install postgresql9.6
1
2 Liste o conteúdo do diretório dos binários do PostgreSQL:
2 # ls l /usr/lib/postgresql/9.6/bin
3 Localize os binários dos programas abaixo:

3# whereis pg_dump
4# whereis psql
4 Liste as conexões da porta default do PostgreSQL:

5 # netstat an | grep 5432
12
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Stop e Start do PostgreSQL no Debian
1 No servidor dbmaster realizar listar os processos do PostgreSQL:

1# ps ef | grep postgresql
2# systemctl status postgresql
2 Comandos para parar o PostgreSQL:

3# /etc/init.d/postgresql stop # Como “root”
4$ /usr/lib/postgresql/9.6/bin/pg_ctl stop # Como “postgres”
3 Comandos para iniciar o PostgreSQL:

5# /etc/init.d/postgresql start # Como “root”
6$ /usr/lib/postgresql/9.6/bin/pg_ctl start # Como “postgres”
4 Comando para reload do PostgreSQL:

7# service postgresql reload
13
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Instalação do PostgreSQL no Centos
# rpm # yum
14
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Instalação do PostgreSQL no Centos
Execute os comandos abaixo no servidor standby2
1 Realize a instalação do repositório com o comando abaixo:

1# rpm ivh
https://yum.postgresql.org/9.6/redhat/rhel7
x86_64/pgdgcentos969.63.noarch.rpm
2 Liste os repositórios do PostgreSQL e realize a instalação:
2# yum list postgres*
3# yum install postgresql96server
2 Localize os binários da instalação:
4# whereis pg_dump
5# whereis psql
15
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Criando um Cluster no PostgreSQL - Centos
No CentOS o cluster do PostgreSQL não foi criado, então vamos criar:
Execute os comandos abaixo no servidor standby2:
1 Crie um cluster no diretório default do Centos:
1 # /usr/pgsql9.6/bin/postgresql96setup initdb
2 Faça com que o serviço do PostgreSQL inicie no boot do SO:
2# systemctl enable postgresql9.6
3# systemctl start postgresql9.6
3 Valide as conexões de rede com o comando ss:

4# ss a | grep 5432
5# ss putan | grep 5432
16
O diretório de base onde residirá o cluster pode ser definido na variável de

ambiente \$PGDATA. Caso a variável exista e esteja correta, não será necessário passar
o parâmetro -D no utilitário initdb nem nos demais utilitários que precisam do diretório do
cluster.
O diretório deve ser de propriedade do usuário que gerenciará o cluster

(normalmente postgres) e deve estar vazio, caso contrário o initdb emitirá um erro e não
criará o cluster.
O cluster do PostgreSQL poderá conter quantos bancos de dados forem

desejados. Um cluster poderá ter vários usuários, cada um com permissões de acesso
diferentes. Cada cluster tem apenas um arquivo de configuração e um arquivo de
autenticação baseada em servidor. Uma única máquina pode ter vários clusters
PostgreSQL.
Vários clusters poderão estar rodando ao mesmo tempo, como várias instâncias,
se estiverem configurados para “escutarem” em portas TCP diferentes, definidos no
arquivo de configuração ou linha de inicialização da instância.
Compilando o PostgreSQL
 O procedimento é manual;
 Procedimento mais complexo;
 É necessário instalar pacotes de compilação;
 É necessário ter um entendimento sobre a
arquitetura do PostgreSQL;
17
Em situações específicas se faz necessário a compilação do PostgreSQL,

quando o servidor a ser instalado não tem acesso a internet por exemplo, é
necessário instalar todos os pacotes manualmente além da compilação do
PostgreSQL.
Num ambiente corporativo o ideal é padronizar os parâmetros de compilação,
assim como os procedimentos adotados pois, os procedimentos e diretórios podem
ser customizados, principalmente quando o sistema operacional se diverge.
Outro ponto importante é em relação a documentação, para facilitar o
troubleshooting o ideal é todos os diretórios default e opções de compilação fiquem
devidamente documentados afim de facilitar a administração do ambiente por outro
DBA.
Compilando a versão 9.2.1

Execute os comandos abaixo no servidor witness:
1 Faça o download de uma versão antiga do PostgreSQL:
1# wget
https://ftp.postgresql.org/pub/source/v9.2.1/postgresql
9.2.1.tar.gz
2 Instale os pacotes necessários:
3# aptget update
3# aptget install buildessential libreadline6dev
zlib1gdev
3 Descompacte o pacote do postgres 9.2.1 e faça a compilação:
4# tar vzxf postgresql9.2.1.tar.gz
5# cd postgresql9.2.1
6# ./configure prefix=/var/lib/postgresql/9.2
7# make
8# make install
18
Procedimentos básicos da compilação
1) Realizar o download do código fonte no site postgresql.org
2) Instalar os pacotes para compilação de acordo com o SO, ex: gmake, build-
essential, libreadline6-dev, zlib1g-dev, etc.
3) Configurar os parâmetros de compilação e instalar os pacotes.
As flags de compilação podem ser encontradas ao executar o comando a seguir:

# ./configure –help
Com esse comando é possível ver a lista das flags, dentre as flags de compilação
mais utilizadas estão:
--bindir=DIR
--sysconfdir=DIR
--with-blocksize=BLOCKSIZE
--with-pam
--with-ldap

4 Faça os ajustes para inicialização no linux:
1# cp contrib/startscripts/linux /etc/init.d/postgresql
2# chmod +x /etc/init.d/postgresql
3# vim /etc/init.d/postgresql
+ prefix=/var/lib/postgresql/9.2
+ PGDATA="/var/lib/postgresql/9.2/main"
4# updaterc.d postgresql defaults
5 Ajuste o path e as Libs do PostgreSQL:

5# sh c "echo 'PATH=/var/lib/postgresql/9.2/bin/:\
$PATH'> /etc/profile.d/pg.sh"
6# sh c "echo 'export PATH'>> /etc/profile.d/pg.sh"
7# ldconfig /var/lib/postgresql/9.2/lib/
19
4) Criar e editar arquivos de inicialização utilizando o script de inicialização já

disponibilizado com os binários do PostgreSQL.
É necessário também editar o prefixo e o PGDATA para adequar a nossa compilação.
O comando “update-rc.d” é um comando linux utilizado para acrescentar um serviço
no serviço de inicialização do Linux, o comando descrito informa ao Linux que o
PostgreSQL agora é um processo que deve ser inicializado automaticamente sempre
que houver um start do SO assim como quando houver um shutdown no ambiente, o
PostgreSQL será parado de uma forma segura com o shutdown padrão (fast).
5) Adicionar os binários do PostgreSQL no PATH.


6 Crie o usuário e os diretórios:
1# useradd shell /bin/bash d /var/lib/postgresql postgres
2# mkdir /var/lib/postgresql/9.2/main/
3# chown R postgres. /var/lib/postgresql/
7 Com o usuáro postgres, crie e inicialize o cluster:
1# su postgres
2$ initdb D /var/lib/postgresql/9.2/main/
3$ pg_ctl D /var/lib/postgresql/9.2/main l logfile start
8 Com o psql, verifique a versão atual instalada:
4 =# select version();
20
6) Criar usuário postgres e o diretório do cluster e ajustar permissões.
7) Criar e inicializar o PostgreSQL

Usuário postgres SO e Cluster

 Não são o mesmo usuário!!
Usuário do SO: postgres
 Usuário do SO criado na instalação do PostgreSQL;

 É o dono dos diretórios do PostgreSQL;
 Responsável por executar os processos do PostgreSQL;
Usuário do Cluster: postgres
 Usuário com permissões de DBA;

 Não deve ser usado pelos DBAS;
21
O usuário postgres
Não é uma boa prática rodar servidores como root ou administrador,

portanto, é interessante ter um usuário de sistema operacional não privilegiado
para tal. Geralmente é utilizado o usuário postgres para ser o dono dos diretórios e
processos do PostgreSQL. Outro usuário pode ser utilizado mas, neste curso,
utilizaremos o usuário postgres.
Quando o cluster é criado, um usuário postgres também existirá. Ele é,

inicialmente, superusuário do cluster.
O usuário postgres não tem senha no cluster, e recomenda-se que

permaneça assim. Também se recomenda que o usuário postgres do sistema
operacional não tenha senha (senha nula, sem acesso).
O usuário postgres do banco de dados não pode ser removido. Com ele, é
possível fazer uma recuperação de outros usuários em caso de emergência. Não
se recomenda que se utilize regularmente o usuário postgres para as tarefas
administrativas do banco de dados, muito menos utilizá-lo para tarefas de usuário
ou aplicações.
Para as tarefas administrativas que necessitem de superusuário,

recomenda-se criar novos superusuários com outros nomes, senhas seguras e
permissões de autenticação restritas (todos estes tópicos serão cobertos durante o
curso).
Utilizando o psql para gerenciamento do PostgreSQL
1 No Servidor dbmaster mudar para usuário postgres e entrar no psql:

1# su – postgres
2$ psql
2 Execute os comandos básicos:

3 =# \db Listar Tablespaces
4 =# \l Listar Bancos de dados
5 =# \dn Listar Schemas
6 =# \dt Listar tabelas
7 =# \h Ajuda para syntax dos comandos
8 =# \? Lista de atalhos de comandos
9 =# \q –Sair do psql
22
Segue exemplos de comandos disponíveis no PSQL:

Geral:
\q sair do psql
\watch [SEC] execute query every SEC seconds
Ajuda:
\? [commands] show help on backslash commands
\h [NAME] help on syntax of SQL commands, * for all commands
Query Buffer:
\e [FILE] [LINE] edit the query buffer (or file) with external editor
\s [FILE] display history or save it to file
Input/Output:
\i FILE execute commands from file
\o [FILE] send all query results to file or |pipe
Informações:
\d[S+] NAME describe table, view, sequence, or index
\dp [PATTERN] list table, view, and sequence access privileges
Formatação:
\x [on|off|auto] toggle expanded output (currently off)
Conexão:
\c {[DBNAME|- USER|- HOST|- PORT|-] | conninfo} conectar a um Banco
Sistema Operacional:
\timing [on|off] monitorar tempo de execução
\! [COMMAND executar comandos interativos no shell
Large Objects:
\lo_import FILE [COMMENT] importação de grandes objetos
COMPILAÇÃO
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Introdução ao Comando SELECT
 Função: Selecionar informações no banco;

 Recursos de filtro com WHERE;
 Recursos de múltiplas tabelas com JOIN;
 Pose ser usado vários SELECT's na mesma consulta;
 Auxilia na carga e exportação de dados;
 Pode ser usado com operadores.
24
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Syntax SELECT | WHERE
 Selecionar coluna 2 e 3 da tabela:

SELECT coluna1, coluna2 FROM tabela;
 Selecionar todos os campos da tabela:

SELECT * FROM tabela;
 Selecionar todas as colunas onde a coluna1 for igual a 10:

SELECT * FROM tabela WHERE coluna1 = 10;
25
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Comandos Básicos com SELECT
1 Selecione todos os registros da tabela pg_database:

1 postgres=# select * from pg_database;
2 Selecione apenas as colunas datname e datctype da tabela:

2 postgres=# select datname, datctype from pg_database;
3 Utilize a função COUNT para contar todos os registros da tabela:
3 postgres=# select count(*) from pg_database;
26
Syntax básica do comando SELECT:

Selecionando todos os campos da tabela:
SELECT * FROM nome_base.nome_tabela;
Selecionando somente as colunas1 e coluna2 da tabela:

SELECT coluna1, coluna2 FROM nome_base.nome_tabela;
Contando todos os registros da tabela:

SELECT count(*) FROM nome_base.nome_tabela;
Usando Filtros com WHERE/ AND/ LIKE/ =
1 Selecione na tabela pg_type os types quem começam com “n”:

1postgres=# select typname from pg_type
where typname like 'n%';
2 Selecione os campos name e setting da tabela pg_settings onde

o campo setting seja igual a “psql”:
2postgres=# select name, setting from pg_settings
where setting = 'psql';
3 Selecione os campos table_owner e table_name da tabela pg_tables
onde o schemaname seja igual a ‘pg_catalog’ e o table_name
termine com a letra c:
3postgres=# select tableowner, tablename from pg_tables
where schemaname = 'pg_catalog'
and tablename like '%c';
27
SELECT com utilização de Filtros:

Selecionando os registros da colunna que começam com a letra “A”:
SELECT * FROM nome_base.nome_tabela
WHERE nome_coluna LIKE 'A%';
Selecionando os registros da coluna que terminam com a letra “A”:

WHERE nome_coluna LIKE '%A';
Selecionando os registros que contém exatamente a palavra 'exata';

WHERE nome_coluna = 'exata';
Selecione os registros que contém a pavra 'texto' na coluna1 e o campo2 contém

'sim':
WHERE nome_coluna1 LIKE '%texto%'
AND nome_coluna2 = 'sim';
Recapitulando
 Conhecer a Origem do PostgreSQL

 Instalar o PostgreSQL;
 Ver as Características;
 Trabalhar com psql
 Criar um Banco de Dados;
 Comando SELECT
 Setup do repositório no Debian
 Filtros (WHERE, AND)
 Setup do repositório no Centos
28
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características
Estrutura Física eeLógica
Instalação
do do MySQL
PostgreSQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Estrutura Física e Lógica do PostgreSQL
Objetivos da Aula
Conhecer o diretório de dados  Conhecer a estrutura lógica do

PostgreSQL
do PostgreSQL
 Conceito de Cluster  Criar Schemas

 Conceito de Tablespaces  Criar Tabelas
 Detectar OID;  Conceitos de índices
30
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Estrutura do PostgreSQL
Entidades Físicas e Lógicas
Cluster
Tablespace Tablespace
TBL IDX TBL IDX TBL IDX TBL IDX
Schema Schema Schema Schema
Database Database
31
Cluster: É equivalente a uma instância de banco de dados que é composta pela infra
(processos, diretórios e arquivos) que dá sustentação os dados do PostgreSQL.
Tablespace: É o local de armazenamento dos dados do PostgreSQL.
Database: É o conjunto de objetos que dá sustentação aos dados que estarão

presentes no PostgreSQL..
Schema: É uma segmentação lógica de tabelas e índices.
Tabelas: São objetos onde as tuplas serão armazenadas.
Índices: São objetos que faz o mapa das tuplas presentes nas tabelas.
Conceito de Cluster
 Cluster no PostgreSQL é equivalente a uma instância;

 Composição lógica: tablespace(s), databases e schema(s);
 Composição física: diretórios, arquivos e links (alguns casos);
 Initdb é o utilitário de criação do Cluster do PostgreSQL;
 O Cluster é criado por default na instalação por pacotes Debian;
32
initdb e o cluster do PostgreSQL
O initdb é o primeiro utilitário de administrador que apresentaremos. Ele

permite criar um novo cluster limpo do PostgreSQL.
Chamamos de Cluster PostgreSQL o diretório onde os bancos de dados
residem, e tem esse nome por ser um “agregado de bancos de dados”. Cada
instância PostgreSQL roda sobre um cluster exclusivo para ela.
O nome cluster pode causar confusão em muitas pessoas, pois é comumente
utilizado no Brasil para identificar “aglomerados de servidores”. A palavra cluster em
inglês significa simplesmente “aglomerado” e, no caso do PostgreSQL, um cluster é
um aglomerado de bancos de dados.
No Debian GNU/Linux, o utilitário initdb é chamado automaticamente pela
instalação pelo aptitude, criando um cluster. Mesmo assim, o utilitário está disponível
em /usr/lib/postgresql/[versão]/bin/initdb caso o administrador decida criar novos
clusters utilizando a instalação padrão do PostgreSQL do Debian.
Para iniciar um cluster:

initdb D /diretorio
● O diretório deve ser de propriedade do usuário postgres;
●
O diretório precisa estar vazio;
● Pode ser criado mais de um Cluster por servidor em portas e diretórios diferentes;
Criando um novo cluster
# /usr/pgsql-9.6/bin/postgresql96-setup initdb -D <path>
# /usr/pgsql-9.6/bin/postgresql96-setup pg_ctl -D <path>
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Localização dos diretórios do Cluster
 Dados = “/var/lib/postgresql/[versão]/main”;
 Configuração = “/etc/postgresql/[versão]/main”;
 Dados e Conf = “/var/lib/pgsql/[versão]/data”;
34
No Debian, o instalador automaticamente criará um cluster de bancos de dados em:

/var/lib/postgresql/[versão]/main
●Os arquivos de configuração estarão em:
/etc/postgresql/[versão]/main
●Um arquivo de inicialização estará em:
/etc/rc2.d/
No Centos o cluster foi criado manualmente sendo dados e configuração em:

/var/lib/pgsql/[versão]/data
●Um arquivo de inicialização estará em:
/usr/pgsql9.5/bin/postgres
Alguns Diretórios do Cluster
1 Veja o conteúdo do diretório abaixo do servidor standby2:

# ls la /var/lib/pgsql/9.6/data
1
 base = local de criação dos databases;

 global = local do catalogo das tabelas do cluster;
 pg_clog = posição das transações (commit);
 pg_log = diretório de logs do PostgreSQL;
 pg_multixact = dados MVCC e locks;
 pg_stat_tmp = arquivos temporários de statísticas;
 pg_xlog = local dos logs de transação WAL;
35
● base - Subdiretório Contém um subdiretório para cada banco de dados em uso;

● global - Subdiretório. Contém o catalogo do PostgreSQL, conjunto de tabelas de
uso de todo o cluster, como a pg_class;
●pg_clog - Subdiretório. Contém dados sobre o estado da finalização das transações,
commit;
●pg_multixact - Subdiretório. Contém dados sobre o estado multitransacional.
Usado para shared row locks;
●
pg_stat_tmp - Subdiretório. Arquivos temporários do sub-sistema de
estatísticas;
●pg_subtrans - Subdiretório. Dados de estado de sub-transações;
●pg_twophase - Subdiretório Contém arquivos de estado para prepared transactions;
●pg_xlog - Sub-diretório. Contém os logs de transação, chamados de arquivos WAL
(Write Ahead Log);

Alguns arquivos do Cluster
1 Veja o conteúdo do diretório abaixo do servidor standby2:

1# ls la /var/lib/pgsql/9.6/data
 PG_VERSION = versão majoritária do PostgreSQL;
 pg_hba.conf = arquivo de configurações de autenticação;
 pg_ident.conf = mapa de relacionamento entre usuarios;
 postgresql.auto.conf = utilizado pelo “ALTER SYSTEM”;
 postgresql.conf = arquivo de configurações do Postgres;
 postmaster.opts = comando de inicialização do Postgres;
 postmaster.pid = numero do processo do Postgres;
36
● PG_VERSION - Arquivo. Contém a versão majoritária do PostgreSQL utilizada no

cluster, por exemplo, 9.5;
●postmaster.opts - Arquivo. Contém as opções de linha de comando da última
inicialização do PostgreSQL neste cluster;

●
postmaster.pid - Arquivo de trava. Contém o PID e ID do segmento de memória
compartilhada (pode não estar presente se o servidor não estiver rodando);
Os arquivos postgresql.conf, pg_hba.conf, e pg_ident.conf normalmente ficam no
diretório do cluster, mas isso é opcional desde a versão 8.0:
●postgresql.conf – Arquivo de configuração geral do PostgreSQL;
●pg_hba.conf – Arquivo de autenticação baseada em servidor, com as permissões
por usuário, banco de dados, máscara de rede, tipo de autenticação ou suas

combinações;
●
pg_ident.conf – Mapa de relacionamento entre usuários de sistema e de banco de
dados. Vazio por padrão.
Conceito de Tablespace
 Área definida para armazenar dados;

 Utilizada para distribuir carga de IO;
 Tablespace default é “pg_default”;
 Pode ser criada em um diretório;
 O usuário “postgres” deve possuir permissões;
 A tablespace só pode ser criada por superusuário;
Versões anteriores a 9.1 é necessário criar um link no
SO para redirecionar a tablespace.
37
Tablespace
É um recurso do PostgreSQL que permite a alocação de objetos do banco de

dados em localizações físicas separadas, é considerada uma estrutura física. Cada
tablespace reside em um diretório próprio, sendo que esse diretório pode ser
exatamente o ponto de montagem de um disco ou LUN independente.
O diretório onde uma tablespace será criada deve ser propriedade do usuário
postgres.
O recurso de tablespaces é muito útil para a distribuição física dos bancos de
dados e seus objetos, pois aqueles objetos mais acessados e que,
consequentemente, têm uma carga de acesso a disco mais alto, podem ser alocados
em recursos específicos de I/O como discos e até mesmo controladoras separadas.
Objetos que ocupam muito espaço físico e dependem de manutenção
específica também podem se beneficiar deste recurso, uma vez que pode ser alocado
exclusivamente em um sistema de discos e de arquivos que permita essa
flexibilidade.
Por padrão, o PostgreSQL coloca todos os dados na tablespace pg_default.
Um banco de dados pode ter sua tablespace padrão alterada, de forma que todos os
novos objetos, se não indicada na criação, irão para a tablespace padrão.
O diretório pg_tblspc do cluster do PostgreSQL conterá links simbólicos para
todas as tablespaces criadas no cluster. As tablespaces são comuns a todo o cluster.
Criando uma tablespace no PostgreSQL

Execute os comandos abaixo no servidor dbmaster:
1 Crie o diretório que será utilizado para os dados da tablespace:

1# mkdir /tbsdexter
2# chown postgres. /tbsdexter
3# chmod 700 /tbsdexter
2 Com o usuário “postgres” entre no postgres e crie uma tablespace:

4# su postgres
5$ psql
6=# CREATE TABLESPACE tbsdexter LOCATION '/tbsdexter';
3 Liste as tablespaces:
7 =# \db
38
Tablespace e o DBA
É trabalho do DBA identificar os objetos que precisam dessas necessidades

especiais, dimensionar e configurar as tablespaces necessárias. Os objetos que
podem ser movidos para tablespaces são bancos de dados inteiros, tabelas
selecionadas ou índices selecionados.
A criação de tablespaces é segura, podendo ser realizada a qualquer
momento, sem concorrência ou overhead significativo, sem causar impactos em
ambientes de produção.
● Para criar uma nova tablespace no psql:

CREATE TABLESPACE [nome] LOCATION '/diretorio/tablespace';
Conceito de Database / Banco de Dados
 Um Cluster pode possuir vários Databases;

 Os Bancos de Dados são independentes;
 O Database é criado em uma Tablespace existente;
 A Base de Dados só pode ser criada por superusuário;
 Um Banco de Dados posui um dono/owner;
39
Bancos de dados (Databases)
Databases são as maiores entidades lógicas do cluster do PostgreSQL. Todas

as outras entidades lógicas, estarão contidas em databases. Utilizaremos a
nomenclatura em português "banco de dados" para se referir a elas.
É importante notar que tablespaces são entidades físicas, portanto não faz
sentido dizer que uma tablespace está dentro de um banco de dados, embora um
banco de dados possa estar "contido" em uma tablespace, outros objetos como
tabelas e índices isolados também podem. Não misturar as entidades físicas com as
lógicas.
Todo cluster pode, e normalmente irá, possuir vários bancos de dados. Um

cluster recém criado conta com pelo menos três bancos de dados (postgres,
template0 e template1), sendo que, para ser utilizado em produção, pelo menos mais
um banco de dados será, via de regra, criado pelo DBA.
Todos os objetos lógicos como tabelas, índices, chaves, funções, visões,

gatilhos e etc são totalmente independentes entre os bancos de dados, assim como
as permissões de acesso.
Quando várias aplicações compartilham o mesmo cluster, idealmente,

deveriam ocupar bancos de dados independentes.
Databases Template[0|1] e postgres
postgres
 Catálogos do sistema;
 Dicionário de dados;
template1
 Utilizado como template na criação de um database;
 Pode ser customizado para criação dos Dbs;
template0
 Backup do template1;
 Jamais deve ser alterado;
40
Todo cluster do PostgreSQL terá, inicialmente, os seguintes bancos de dados já

criados:
postgres
O banco de dados "postgres" está disponível para ser utilizado como primeira
conexão ao cluster, logo após ser criado. Ele pode ser removido, desde que existam
outros bancos de dados disponíveis para conexão. Não se recomenda utilizar o banco
"postgres" no cotidiano para conter seus objetos de banco de dados, porém, ele pode
permanecer no cluster como um banco de conexão de emergência caso não se
lembre o nome de outros bancos disponíveis.
template1
O banco de dados template1 é o modelo que é utilizado por padrão na criação
de novos bancos de dados. Neste banco de dados, o administrador pode criar novos
objetos e fazer outras modificações, que serão automaticamente copiados para os
novos bancos de dados criados a partir de então.
template0
O banco de dados template0 é um modelo, similar ao template1, porém
recomenda-se jamais mexer nele ou removê-lo. Em caso de necessidade de se criar
um novo banco template1, por exemplo, pode-se utilizar este "modelo mínimo"
template0, e a única forma de criar um banco template0 é recriando o cluster.
Criando um database no PostgreSQL

1 Crie o banco de dados dbdexter na tablespace tbsdexter:

1 =# CREATE DATABASE dbdexter TABLESPACE tbsdexter;
2 Crie um superusuário chamado aluno e torne ele dono do dbdexter:

2=# CREATE USER aluno SUPERUSER PASSWORD '4linux';
3=# ALTER DATABASE dbdexter OWNER TO aluno;
3 Consulte o id da tablespace onde fica o banco de dados dbdexter:

4=# SELECT datname, dattablespace
FROM pg_database WHERE datname = 'dbdexter';
4 Liste os diretórios:
5=# \! ls la /var/lib/postgresql/9.6/main/pg_tblspc
41
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Conceito de Schemas
 Utilizado para segmentar um Database;

 Separar objetos dentro de uma mesma Base;
 Facilidade no permissionamento;
 Schema padrão dos Databases é o public;
 É necessário especificar schema.tabela;
42
Schemas
Schemas são subdivisões de bancos de dados que podem ser comparadas a

diretórios de um sistema operacional, embora não possam ser aninhados (schema
dentro de outro schema), só há um nível de profundidade.
São úteis para criar uma separação de objetos de aplicações diferentes que
compartilham o mesmo banco de dados, gerenciar grupos e usuários similares de
objetos diferentes e organizar bancos de dados com muitas tabelas.
Afim de permitir que tabelas fora do schema default sejam acessadas sem a
nomenclatura citada acima pode-se alterar o search_path padrão para o schema que
se deseja trabalhar automaticamente.
SET search_path = '[nome do schema]';
Objetos de mesmo nome no mesmo banco de dados podem coexistir em schemas

diferentes, para criar schemas no psql:
CREATE SCHEMA [nome];
Após a criação do schema, será obrigatório referir-se às tabelas com uma

nomenclatura completa schema.tabela em todos os comandos, para tabelas fora do
schema default;
Tabelas e índices
Tabelas
 Objeto de armazenagem de dados;

 Baseado em colunas de diversos tipos;
 Podem ser referenciadas;
Índices
 Mapa dos dados da tabela;

 Baseado em uma ou mais colunas da tabela;
 O padrão utiliza uma “árvore balanceada” (btree);
43
Tabelas
● Tabelas é uma estrutura com uma ou mais colunas utilizada para armazenamento
de dados;
● Para cada coluna de uma tabela um tipo de dado a ser inserido deve ser
associado;
● Uma ou mais colunas podem ser referenciadas entre as tabelas;
● As permissões de acesso podem ser individualisadas por tabela;
●
O PostgreSQL é responsável pelo gerenciamento das versões das tuplas
armazenadas nas tabelas.
Índices
● Índices são estruturas associadas a uma ou mais colunas de uma tabela com
intenção de tornar buscas mais eficientes;

● Criados implicitamente durante a criação de tabelas para a sua chave primária;
● Cabe ao DBA identificar quais colunas precisam ou não de índices e qual tipo de
índice deve ser utilizado;

● O tipo de índice padrão no PostgreSQL é o btree ou “balanced tree”; este tipo de
índice é balanceado e requer pouca manutenção.

● Para criar um índice basta seguir esta sintaxe:
CREATE INDEX [ nome do indice ] ON [ tabela ] ( [ colunas ] )
● Para recriar índices:
REINDEX [ indice | tabela | database ]
Criando schemas e tabelas no PostgreSQL

1 Crie os schemas secretaria e financeiro banco de dados dbdexter:

1=# \c dbdexter
2=# CREATE SCHEMA secretaria;
3=# CREATE SCHEMA financeiro;
2 Crie uma tabela em cada schema:
4=# CREATE TABLE secretaria.turma (id int);
5=# CREATE TABLE financeiro.mensalidade (pagamento boolean);
3 Verifique a estrutura criada:

6=# \dn
7=# \dt+ financeiro.*
8=# \dt+ secretaria.*
44
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Criando índices no PostgreSQL
Syntax:
CREATE INDEX nome_indice
ON tabela (coluna);
1 Crie um índice no campo id da tabela turma do schema secretaria:

1 =# CREATE INDEX idx_turma_id ON secretaria.turma (id);
2 Crie uma tabela chamada turma no schema financeiro:
2 =# CREATE TABLE financeiro.turma (descricao text);
45
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
OIDs e o Armazenamento Físico
Conceito: Identificador único de

um objeto no PostgreSQL
 Todo objeto possui um identificador único(OID);

 Linhas de tabelas podem possuir OID;
 OID é útil para mapear locais físicos dos objetos;
 OIDs não devem ser usados por usuários e aplicações;
 Arquivos de dados são segmentados em 1GB(default);
46
OIDs são os identificadores de objetos do PostgreSQL. OIDs são números seriais

únicos, por tipo de objeto, dentro de um cluster. Bancos de dados, tabelas, índices e
tablespaces sempre terão um OID. Linhas de tabelas terão um OID único em cada
tabela, desde que a tabela seja criada com a opção WITH OIDS. Embora os OIDs
sejam visíveis para usuários e aplicações, não é uma boa prática referir-se aos
objetos pelo OID, deixando a cargo do PostgreSQL administrar esses valores.
A utilidade do OID para o administrador é identificar os objetos dentro do layout
físico do cluster em disco, permitindo algumas ações de manutenção, por exemplo,
mover tablespaces de um diretório para outro ou medir o espaço físico ocupado por
um banco de dados ou tabela (embora o PostgreSQL ofereça funções que retornem
esses valores). Não há utilidade prática para os OIDs de linhas, por isso a criação de
tabelas com OIDs de linha foi tornada opcional nas versões mais recentes do
PostgreSQL, devendo ser usada apenas para retrocompatibilidade de sistemas
legados.
Para visualizar OIDs, vamos utilizar os catálogos de sistema do PostgreSQL,
executando comandos diretamente no psql.
O PostgreSQL armazena os dados em arquivos binários, chamados de
datafiles. São arquivos como outros quaisquer, com permissão de acesso exclusivo
para o usuário postgres (podendo ser outro usuário, se o PostgreSQL for iniciado de
forma diferente) .
Cada tabela ou índice terá pelo menos um arquivo de dados, que pode ser
encontrado no diretório base do cluster ou numa tablespace, se o objeto estiver lá.
Se necessário, mais de um arquivo será gerado para o mesmo objeto. O
PostgreSQL trabalha por padrão com pedaços de 1GB por causa de limitações em
alguns sistemas de arquivos legados.
Os objetos podem ser encontrados nos datafiles utilizando o seu OID.
Detectando OID no PostgreSQL

1 Selecione o OID do banco de dados dbdexter:

1=# SELECT datid FROM pg_stat_database
WHERE datname='dbdexter';
2 Localize o local físico do banco de dados:

=# \! ls la /tbsdexter/PG*/
2
3 Conecte no database dbdexter e verifique o OID da tabela alunos:

3=# SELECT relid, relname FROM pg_stat_all_tables
WHERE relname = 'mensalidade';
4=# \! ls la /tbsdexter/PG*/<dbOID>/<tabOID>
4 Selecione o OID usando conversão no PostgreSQL:

5 =# SELECT 'financeiro.turma'::regclass::integer;
47
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Recapitulando
Conhecer o diretório de dados  Conhecer a estrutura lógica do

PostgreSQL
do PostgreSQL
 Conceito de Cluster  Criar Schemas

 Conceito de Tablespaces  Criar Tabelas
 Detectar OID  Conceitos de índice
48
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características
Gerenciamento e Instalação do MySQL
do PostgreSQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Gerenciamento do PostgreSQL
Objetivos da Aula
 Formas de STOP do PostgreSQL;

 Conhecer o pg_hba.conf
 Usuarios e Roles
 Auditando usuários
 DCL - Data Control Language
50
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
STOP no Cluster do PostgreSQL

Pelo PostgreSQL
 Pode ser feito utilizando o pg_ctl;

 Stop Smart – Mais seguro;
 Stop Fast(default) – Seguro porém agressivo;
 Stop Immediate – Inseguro e Agressivo;
Pelo PostgreSQL
 Pode ser feito utilizando o KILL;
51
Lembre-se que você tem:

● Arquivos abertos
● Conexões de rede
● Transações em andamento
●
Semáforos
● Memória compartilhada
Não desejamos parar nossos bancos de dados nunca, mas é claro que várias
situações podem requerer esta tarefa. Um SGBD como o PostgreSQL terá:
Arquivos abertos – centenas ou até milhares de arquivos estão abertos em
disco quando bancos de dados estão transacionando.
Conexões de rede – sockets estão em uso, com clientes locais e/ou remotos
conectados.
Transações estão em andamento – a norma ACID prevê que as coisas
comecem, acontecem e terminem, tudo isso tem um intervalo de tempo.
Semáforos estão alocados – SGBDs multiprocesso utilizam o recurso de
semáforos do sistema operacional para controlar os processos que estão ocupando o
tempo de CPU e a comunicação entre eles.
Memória compartilhada está alocada – o desenho multiprocesso faz com que
uma área de memória esteja alocada para compartilhamento de todos os processos.
Considerando os itens acima, ao parar o cluster todos os recursos devem ser
liberados corretamente, caso contrário, o sistema operacional poderá não funcionar a
contento após uma parada do SGBD por esgotamento de recursos. O cluster pode
até não conseguir mais ser inicializado.
Tipos de STOP no Cluster

Smart | SIGTERM | kill -15
 Aguardará o encerramento das sessões;
 Incluindo processos de backup;
Fast | SIGINT | kill -2
 Finaliza e faz rollback de todas as transações;
 Realiza o Checkpoint;
Immediate | SIGQUIT | kill -3
 Dá um KILL em todas as transações;
 É equivalente a uma falha no servidor;
 A próxima inicialização irá ler os WAL files;
52
Parada smart
É a forma de parada mais segura, porém nem sempre viável, ao receber uma
solicitação de parada smart, o PostgreSQL aguardará que todas as transações
correntes sejam finalizadas, todas as sessões (conexões) abertas sejam encerradas
e, caso exista, um backup em andamento também será aguardado.
O uso da parada smart em ambientes complexos pode ser difícil ou até
impossível. Servidores de aplicação, pools de conexão, middlewares entre os
usuários e o banco de dados, scripts de automação rodando e até mesmo se algum
usuário deixou o psql ou pgAdmin abertos podem fazer com que o cluster não pare.
Será então necessário que todas as aplicações e clientes sejam parados
primeiro para que, em seguida, possa ser utilizada a parada smart.
Parada fast
A parada fast é a forma padrão de stop, ao receber uma solicitação de parada

fast, o PostgreSQL encerrará as transações correntes com um rollback, encerrará
sessões abertas e qualquer backup em andamento. Os recursos de sistema
operacional como semáforos e memória compartilhada serão liberados se a parada
for concluída com sucesso.
Note que uma parada fast, ao enviar o rollback das transações correntes, pode
fazer com que uma aplicação tenha comportamento inesperado se não estiver
preparada para tal. Esteja ciente de que a aplicação foi preparada para tratar esse
caso.
Parada immediate
Só deve ser utilizada em último caso. A parada immediate faz tudo o que a parada
fast faz, só que encerra todos os processos abruptamente, sem liberar corretamente os
recursos do sistema operacional. É equivalente a uma falha catastrófica.
Ao ser iniciado novamente, o PostgreSQL fará a releitura dos arquivos WAL
presentes no diretório pg_xlog, para garantir a gravação correta de todas as transações
finalizadas até o momento da parada.
A parada immediate tem utilidade caso o servidor esteja passando por problemas,
por exemplo, processos presos, e a parada fast não estiver funcionando.
Pode ser necessário utilizar comandos do sistema operacional para liberar
recursos não liberados pela parada, especialmente semáforos do Solaris.
Os seguintes sinais podem ser enviados ao processo postgres:

SIGTERM – equivale à parada smart
SIGINT – equivale à parada fast
SIGQUIT – equivale à parada immediate
SIGHUP | kill -1 – equivale ao reload
Utilizar o pg_ctl é mais prático e seguro.
Uso do kill
Os sinais de kill devem ser enviados ao processo pai postgres, nunca aos demais.
Caso um sinal de kill inadequado seja enviado a um processo de conexão (backend)
todo o seu cluster poderá falhar catastroficamente por corrupção da memória
compartilhada.
O processo postgres é o orquestrador e pai dos demais processos (que são forks
dele), portanto, ele possui rotinas capazes de interpretar os sinais kill. O pg_ctl faz todo
esse trabalho, por isso, prefira utilizá-lo sempre.
Ao instalar o PostgreSQL a partir dos pacotes disponibilizados de forma integrada

às distribuições Debian e Red Hat, bem como suas derivadas, scripts especializados são
disponibilizados para controlar o cluster. Prefira utilizar os scripts específicos das
distribuições sempre que disponíveis e isso for possível.
Nas distribuições Debian e suas derivadas, utilize como root o comando:

/etc/init.d/postgresql [start | stop | restart | reload | status]
Nas distribuições Red Hat 6 ou superior e suas derivadas, utilize como root o comando:
service postgresql-X.Y [start | stop | restart | reload | status | enable | disable]
Onde X.Y é a versão do PostgreSQL.

Utilização do pg_ctl
1 O pg_ctl não está no path, crie um link para que ele fique acessível:
1 # ln s /usr/lib/postgresql/9.6/bin/pg_ctl /bin/
2 Com o usuário postgres faça o stop smart e acompanhe os logs:
2 $ pg_ctl stop D /etc/postgresql/9.6/main m smart
3 Inicie o banco com o pg_ctl, faça o stop fast e veja os logs:
3$ pg_ctl start D /etc/postgresql/9.6/main
4$ pg_ctl stop D /etc/postgresql/9.6/main m fast
4 Inicie, faça o stop immediate, inicie e acompanhe os logs:
6$ pg_ctl stop D /etc/postgresql/9.6/main m immediate
54
Por isso o PostrgreSQL implementa várias formas de parada: smart, fast e

immediate, também é possível utilizar os sinais de kill que estão disponíveis no Linux
e toda a família Unix e derivados.
Utilizando o pg_ctl
O pg_ctl é a forma preferida para controlar o início e parada dos clusters
PostgreSQL, pois ele implementa uma série de facilidades ao administrador como
escolha dos sinais corretos nos processos corretos. O pg_ctl pode ser facilmente
implementado também em scripts.
Já foi mostrado nos capítulos anteriores o uso do pg_ctl para iniciar os clusters.
Para pará-los, a sintaxe será:
pg_ctl -m [modo] -D /dir/cluster stop
Se o modo for omitido, será utilizado o modo fast por padrão.
O reload não parará o cluster, apenas recarregará os arquivos de configuração.
Mais adiante veremos quais configurações podem ser alteradas e recarregadas sem
parada do cluster.
Não se deve passar a opção -m (modo) quando a intenção for fazer recarga de
arquivos de configuração (reload). Na recarga, não há qualquer indisponibilidade do
cluster, tudo continua funcionando normalmente.
Para parar e iniciar (restart) o cluster, ao invés de executar o pg_ctl duas vezes,
pode-se utilizar:
pg_ctl -m [modo] -D /dir/cluster restart
Existe também uma forma de apenas recarregar os arquivos postgresql.conf e
pg_hba.conf, chamada reload:
pg_ctl -D /dir/cluster reload
Processo de Autenticação PostgreSQL
55
Processo de Autenticação:
Os clientes do PostgreSQL fazem uma requisição do processo postmaster que
por sua vez realiza algum dos 3 tipos de autenticação que são:
Socket: No próprio Servidor via socket.

127.0.0.1: No próprio Servidor via rede de loopback (127.0.0.1)
listen_addresses: A partir de outro servidor ou interface de rede.
pg_hba.conf:
O Postmaster ao receber a requisição só encaminhará a requisição ao
PostgreSQL criando um processo em background caso a conexão de origem estejam
de acordo com as configurações que são carregadas do pg_hba.conf, essas
informações são carregadas de 2 formas diferentes:
1) Durante a inicialização do PostgreSQL;

2) Durante o RELOAD das configuraões.
Ajustando o PostgreSQL para Autenticação
Parâmetros (postgresql.conf):
port = 5432
Porta do PostgreSQL
hba_file = '/etc/postgresql/9.6/main/pg_hba.conf'
Define o local do arquivo “pg_hba.conf”, esse arquivo contém as
regras para que o client possa realizar uma tentativa de conexão.
listen_addresses = 'localhost'
Parâmetro que contém os IPs que poderão “escutar” a porta do
PostgreSQL.
56
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Arquivo pg_hba.conf
 Designar permissões antes da conexão com o Banco

 Gerenciar métodos de autenticação
 Determinar regras de conexão ao banco
 Gerar lista com regras mais restritivas primeiro
57
Para quê serve o pg_hba.conf
Como visto anteriormente nas permissões, é possível designar restrições e

liberações específicas por usuário para praticamente tudo dentro do cluster do
PostgreSQL. Essas configurações são aplicadas dentro do cluster, ou seja, um
usuário que tentar acessar um recurso não permitido já terá se conectado de alguma
forma ao banco de dados e as verificações serão feitas em catálogo.
O arquivo pg_hba.conf, acrônimo de Host-Based Authentication – autenticação
baseada em host, tem como função limitar os acessos antes mesmo que algum tipo
de conexão seja feita ao cluster.
Arquivo pg_hba.conf separação por colunas

TIPO DATABASE USUÁRIO CIDR-ADDRESS MÉTODO OPÇÕES
local all usuário desnecessário trust

reject
host sameuser joao,maria 172.20.143.89/32 password
IP único md5
hostssl samerole +grupo 172.20.143.0/24 ident
Rede pequena peer
hostnossl @arq_lista @arq_lista 10.6.0.0 ldap
255.255.0.0 pam
cert
58
Campo TYPE ou TIPO

Conexão por Unix Domain Sockets, ou seja, conexão por socket do sistema
operacional, sem o uso de rede ou da interface loopback (localhost).
O psql tentará se conecta por socket local se não for especificada a opção -h.
Os aplicativos baseados em libpq têm o mesmo comportamento. Na opção -h pode
ser também passado o diretório do socket.
local
●Conexão por Unix Domain Sockets;
●
Nem todos os clientes aceitarão conectar-se por este método;
●O psql tentará se conecta por socket local se não for especificada a opção -h;
●Se nenhuma linha do pg_hba.conf contiver este valor, a conexão por socket será
totalmente desativada.
host
●TCP/IP remoto ou local;
●Não criptografadas ou por SSL;
●Verificar listen_address do arquivo postgresql.conf.
hostssl
●Similar à opção host, somente SSL.
●O PostgreSQL deve estar compilado com suporte a SSL (biblioteca OpenSSL
disponível);
●Deve estar ativa em postgresql.conf;
●Todas as cifras da biblioteca OpenSSL.
hostnossl
●Exatamente o oposto de hostssl;
●
Somente conexões não criptografadas serão aceitas.
Campo DATABASE
●Especificar diretamente banco de dados;
●
Separar múltiplos valores por vírgulas;
●"all" representará todos os bancos;
●"sameuser" usuários do banco de mesmo nome;
●
"samerole" usuários pertencentes a grupo de mesmo nome do banco.
●"@" seguido do nome do arquivo, arquivo de lista.
Campo USER
●Especificar usuário;
●
Separar múltiplos valores por vírgulas;
●Papel de grupo, precedido por "+", todos os usuários pertencentes ao grupo poderão
se valer de tentativas de conexão;

●
Especificar um arquivo com lista de valores, utilizando "@".
Campo CIDR-ADDRESS
Funciona com IPV4 e IPV6;
Depende do sistema operacional para IPV6;
Utilizar um registro IPV4 e outro IPV6 mesmo que haja equivalência.Esta é a única
coluna que pode conter de zero a dois valores separados por espaço, sendo aceitas.
Para linhas do tipo local, este campo não deve ser especificado (nenhum valor na
coluna, coluna ignorada)
Para registros host, hostssl e hostnossl, este campo pode conter:
Endereços tipo CIDR-address (um valor na coluna), por exemplo:
172.20.143.89/32 um único host
172.20.143.0/24 rede pequena
10.6.0.0/16 rede grande
201.0.0.0/8 internet, todos os IPs começando por 201
0.0.0.0/0 toda a internet
Campo METHOD
Quando a tentativa de conexão coincidir com toda a combinação dos campos
anteriores, o PostgreSQL utilizará o método de conexão especificado neste campo.
Se este método aprovar a tentativa (como usuário e senha válidos), o usuário
se conectará ao banco de dados. Caso contrário, a conexão será recusada e, como já
citado acima, não haverá outras tentativas de conexão existentes no arquivo
pg_hba.conf abaixo desta linha.
trust
●Menos seguro;
●Permitirá a conexão incondicionalmente, por qualquer pessoa, preenchendo os
requisitos dos outros campos;

●Nenhuma senha será solicitada.
reject
●
Rejeitar a conexão incondicionalmente;
●Útil para excluir hosts;
●Método utilizado para realizar blacklist.
md5
●Senha criptografada;
●
Viajará criptografada pela rede;
●Preferido para conexões não SSL;
●É o método mais usado na prática.
password
●Requererá uma senha não criptografada;
●A senha viaja sem criptografia pela rede;
●Não utilize em redes não privadas.
Ident → peer
●
Usuário do S.O é o mesmo do Postgres;
●TCP/IP, servidor ident, não recomendado;
●Socket, verificará pelo S.O.;
●
Não pede senha;
●Em Solaris a partir do PostgreSQL 8.4;
●Interessante para muitos usuários locais.
gss: Autenticação tipo Single Sign On com Kerberos.

sspi: Disponível para PostgreSQL no Windows, permite autenticação Single Sign On.
krb5: Autenticação tipo Single Sign On com Kerberos versão 5.
ldap: Autenticar usando LDAP. Configurações adicionais são necessárias.
radius: Autenticar usando um servidor RADIUS.
cert: Autenticar usando os certificados SSL existentes. Nenhuma senha será
solicitada. A cn do certificado deve ser o nome do usuário. O cliente deve possuir o
certificado válido e correspondente. O servidor deve possuir o certificado raiz da
autoridade que emitiu o certificado do cliente.
pam: Autenticar usando PAM, disponível em alguns sistemas operacionais como
Linux e Solaris .Para os métodos baseados em Kerberos, NTLM, LDAP, RADIUS,
certificados e PAM, o usuário deverá previamente existir no catálogo do PostgreSQL,
e ser o mesmo do serviço externo. Apenas o par usuário/senha será verificado junto
ao serviço externo para permissão de conexão.
Ajustando Primeiro nível de acesso do PostgreSQL

1 Edite o arquivo postgresql.conf permitindo acessos remotos:

1# vim /etc/postgresql/9.6/main/postgresql.conf
+ listen_addresses = '*'
2 Agora vamos dar permissões na base dbdexter no pg_hba:

2# vim /etc/postgresql/9.6/main/pg_hba.conf
+ host dbdexter dexter 192.168.200.30/32 md5
+ host dbdexter dexter 192.168.56.1/32 md5
+ host dbdexter suporte 192.168.200.30/32 ldap
3 Reinicie o serviço do postgresql:

3 # service postgresql restart
61
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Usuários e Roles
Usuário
 Usuário pode ser membro de uma role | grupo;
 Deve possuir senha criptografada;
 Pode definir tempo de expiração e lock;
Roles
 Roles: Superuser, Create role, Create DB, Replication;
 Role tem o mesmo conceito que grupo;
 Uma role pode ser atribuida a qualquer usuário;
 Roles são usadas para agilizar a concessão de privilégios;
62
Criação de usuários
O PostgreSQL trabalha com permissões em um esquema de roles - papéis.

Todo usuário é um papel.
Principais roles
SUPERUSER: Privilégios de DBA assim como o usuário “postgres”.
CREATEDB: Privilégio para criação de Databases.
CREATEROLE: Privilégios para criação e remoção de Roles / Usuários.
LOGIN: Privilégios com permissões de LOGIN no Postgres.
REPLICATION: Privilégios de replicação de dados.
Criando Usuários e Roles

Execute os comandos abaixo no dbdexter:
1 Crie os usuários conforme exemplos:
1=# CREATE ROLE dexter WITH PASSWORD '4linux';
2=# CREATE GROUP consulta;
2 Verifique os usuários, faça alterações e depois valide novamente:

3=# \du
4=# ALTER USER dexter WITH LOGIN;
5=# ALTER USER consulta RENAME TO desenvolvedores;
6=# ALTER USER dexter SET lock_timeout TO 100;
7=# \du
3 Valide o login com o usuário dexter:
8=# SHOW lock_timeout; \q
9$ psql Udexter h127.0.0.1 dbdexter c "SHOW lock_timeout;"
63
Syntax de criação de usuários:
Criar um usuário:
CREATE USER nome_usuario [WITH rule_option] WITH PASSWORD;
Criar um usuário já com a opção de login:

CREATE USER nome_usuario WITH LOGIN;
Criar um usuário pertencente a uma role e com limite de conexões:

CREATE USER usuarioA WITH ROLE usuarioB CONNECTION LIMIT 10;
Syntax de alteração de usuários:
Alterar a senha do usuário:

ALTER USER nome_usuario WITH PASSWORD 'nova_senha';
Alterar um parâmetro default:

ALTER USER nome_usuario CONNECTION LIMIT 100;
Auditando usuários
 Customizar parametros de logs do postgresql.conf;

 log_connections – Auditar conexões realizadas;
 log_disconnections – Auditar conexões finalizadas;
 log_hostname – Auditar hostname conectado;
 log_statement – Auditar comandos executados ex:ddl;
 log_line_prefix – Formato da geração do LOG;
64
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Ajustando os logs para Auditoria

1 Edite o arquivo postgresql.conf para auditar os usuários:

+ log_connections = on
+ log_disconnections = on
+ log_hostname = on
+ log_line_prefix = '%t [%p]: [%l1] db=%d,user=%u@%r %x:%v '
+ log_statement = 'ddl'
2 Reinicie o serviço do postgresql:
2 # systemctl restart postgresql
65
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
DCL - Data Control Language
Conceito:
Comandos de
➢ GRANT – Conceder privilégios.
controle e
privilégios a dados. ➢ REVOKE – Revogar privilégios.
Syntax:
GRANT [SELECT|INSERT...] ON schema.tabela TO usuário;
REVOKE [DELETE|UPDATE...] ON schema.tabela FROM usuário;
66
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Algumas permissões
 GRANT [dmls] ON TABLE [tab] TO role;

 GRANT ALL PRIVILEGES ON DATABASE TO role;
 GRANT CREATE ON TABLESPACE tbs_name TO role;
 GRANT EXECUTE ON FUNCTION func_name TO role;
 GRANT role1 TO role2 WITH ADMIN OPTION;
67
GRANT {{SELECT|INSERT|UPDATE|DELETE|TRUNCATE|REFERENCES|TRIGGER}
[,...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column [, ...] )
[,...] | ALL [ PRIVILEGES ] ( column [, ...] ) }
ON [ TABLE ] table_name [, ...]
GRANT {{CREATE|CONNECT|TEMPORARY|TEMP} [,...] | ALL [ PRIVILEGES ] }
ON DATABASE database_name [, ...]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
ON { FUNCTION function_name ( [ [ argmode ] [ arg_name ] arg_type
[, ...] ] ) [, ...]
| ALL FUNCTIONS IN SCHEMA schema_name [, ...] }
GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }
ON SCHEMA schema_name [, ...]
GRANT { CREATE | ALL [ PRIVILEGES ] }
ON TABLESPACE tablespace_name [, ...]
GRANT role_name [, ...] TO role_name [, ...] [ WITH ADMIN OPTION ]
Concedendo privilérios
1 Faça os procedimentos com o usuário dexter conforme segue:
1# psql Udexter h127.0.0.1 dbdexter
2=> select * from secretaria.alunos;
2 Abra outra sessão com o usuário aluno e dê permissões ao

usuário dexter a partir da base dbdexter:
3=# GRANT USAGE ON SCHEMA secretaria TO dexter;
4=# GRANT SELECT ON TABLE secretaria.alunos TO dexter;
3 Volte ao passo 1, execute select nas tabelas alunos e cursos:
4 Agora na sessão 2 dê permissão em todo o schema:

5=# GRANT SELECT ON ALL TABLES IN SCHEMA secretaria TO dexter;
68
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Recomendações Gerais
 Mínimo privilégio possível sempre;

 Sempre auditar ambientes produtivos;
 Não utilizar usuário compartilhado;
 Manter permissões atualizadas;
69
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Gerenciamento do PostgreSQL
Recapitulando
 Formas de STOP do PostgreSQL;

 Conhecer o pg_hba.conf
 Usuarios e Roles
 Auditando usuários
 DCL - Data Control Language
70
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Fundamentos de SQL e Carga de Dados
Objetivos da Aula
 Surgimento do SQL
 Operações DDL e DML
 Funções do PostgreSQL
 Carga de Dados
 Importação e exportação de CSV
71
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
SQL - Structured Query Language
 Linguagem utilizada no PostgreSQL

 Usada amplamente pelos bancos de dados Relacionais;
 Foi criado pela IBM na década de 70 ;
 Normatizado pela ANSI e ISO;
 Versão 2015 sendo revisada;
72
Conceitos:
SQL é uma linguagem de consulta estruturada padrão dos bancos de dados
relacionais, sendo muitas de suas características inspiradas em álgebra relacional.
A IBM criou o SQL e rapidamente foi se expandindo. Em um dado momento,
houve a necessidade de uma padronização, que foi realizada pela ANSI (American
National Standards Institute) e pela ISO.
Timeline Padrão ANSI/ISO:

1992 = Foi realizada uma revisão e dado o nome de SQL-92.
1999 = Inserção de expressões regulares de espelhamento, queries recursivas e
gatilhos(triggers).
2003 = Características XML, sequências padronizadas e colunas com valores
generalização.
2008 = Realiza-se uma nova revisão e é definido o padrão default da versão 9.5 do
PostgreSQL.
2015 = Revisão mais recente que está sendo homologada.
DDL - Data Definition Language
Conceito:
Comandos de definição estrutural de objetos, ou

seja, comandos de criação, alteração ou remoção
de objetos no banco de dados.
➢ CREATE [TABLE, VIEW, TRIGGER, etc]

➢ ALTER [TABLE, INDEX ,etc]
➢ DROP [TABLE, INDEX, VIEW,etc]
➢ RENAME
➢ TRUNCATE
73
DDL - Data Definition Language - Linguagem de Definição de Dados: Uma DDL

permite ao utilizador definir tabelas novas e elementos associados. A
maioria dos bancos de dados SQL comerciais tem extensões proprietárias no DDL.
Os comandos básicos da DDL são poucos:
CREATE - cria um objeto (uma tabela, por exemplo) dentro da base de dados.
DROP - apaga um objeto do banco de dados.
Alguns sistemas de banco de dados usam o comando ALTER, que permite ao usuário
alterar um objeto, por exemplo, adicionando uma coluna a uma tabela existente.
Outros comandos DDL são:
CREATE TABLE – Cria uma tabela;

CREATE INDEX – Cria um índice;
CREATE VIEW – Cria uma view;
ALTER TABLE – Altera uma tabela;
ALTER INDEX – Altera um índice;
DROP TABLE – Apaga uma tabela;
DROP VIEW – Apaga uma view;
DROP INDEX – Apaga um índice;
RENAME TABLE – Renomeia uma tabela.
Datatypes – Tipos de Dados - PostgreSQL
Datatype: Características de cada coluna da tabela,

abaixo os mais utilizados pelo PostgreSQL:
Tipo Descrição
INTEGER INT, BIGINT, SMALLINT, números inteiros
NUMERIC Campo numérico inteiros e não inteiros
TIMESTAMP Data e tempo
BOOLEAN VERDADEIRO ou FALSO
CHAR Caracteres ex CHAR(8) reserva o espaço de 8 caracteres
VARCHAR Caracteres até um determinado limite
TEXT Para campos de texto com muitos caracteres
UUID Campo para inserir UUID único
JSON Dados de JSON em forma de texto
POINT Campo para dados geométricos num plano
74
Datatypes ou Tipos de Dados

São os tipos de dados aceitos em uma coluna dentro do banco de dados. Os
bancos de dados relacionais possuem vários tipos de dados em que uma coluna pode
ser formatada. Esses tipos de dados são bastante variáveis, porém alguns são
comuns entre a grande maioria dos bancos de dados relacionais. Seguem os
datatypes do PostgreSQL::
Name Aliases Description

bigint int8 signed eight-byte integer
bigserial serial8 autoincrementing eight-byte integer
bit [ (n) ] fixed-length bit string
bit varying [ (n) ] varbit variable-length bit string
boolean bool logical Boolean (true/false)
box rectangular box on a plane
bytea binary data ("byte array")
character [ (n) ] char [ (n) ] fixed-length character string
character varying [ (n) ] varchar [ (n) ] variable-length character string
cidr IPv4 or IPv6 network address
circle circle on a plane
Name Aliases Description

date calendar date (year, month, day)
double precision float8 double precision floating-point number (8
bytes)
inet IPv4 or IPv6 host address
integer int, int4 signed four-byte integer
interval [ fields ] [ (p) ] time span
json textual JSON data
jsonb binary JSON data, decomposed
line infinite line on a plane
lseg line segment on a plane
macaddr MAC (Media Access Control) address
money currency amount
numeric [ (p, s) ] decimal [ (p, s) ] exact numeric of selectable precision
path geometric path on a plane
pg_lsn PostgreSQL Log Sequence Number
point geometric point on a plane
polygon closed geometric path on a plane
real float4 single precision floating-point number (4
bytes)
smallint int2 signed two-byte integer
smallserial serial2 autoincrementing two-byte integer
serial serial4 autoincrementing four-byte integer
text variable-length character string
time [ (p) ] [ without time time of day (no time zone)
zone ]
time [ (p) ] with time zone timetz time of day, including time zone
timestamp [ (p) ] [ without date and time (no time zone)
time zone ]
timestamp [ (p) ] with time timestamptz date and time, including time zone
zone
tsquery text search query
tsvector text search document
txid_snapshot user-level transaction ID snapshot
uuid universally unique identifier
xml XML data
Prática DDL
1 Crie a tabela teste no schema secretaria do banco dbdexter:

1=# \c dbdexter
2=# CREATE TABLE secretaria.teste (id int, nome

varchar(50), idade decimal, email varchar(45));
2 Renomeie a tabela teste para alunos:
3=# ALTER TABLE secretaria.teste RENAME TO alunos;
3 Acrescente o campo senha na tabela alunos:

4=# ALTER TABLE secretaria.alunos ADD senha varchar(45);
4 Remova a tabela turma do schema secretaria:

5=# DROP TABLE secretaria.turma;
76
Syntax dos comandos:
Criar tabela:
CREATE TABLE nome_tabela (coluna1 [TYPE], coluna2 [TYPE]);
Criar tabela temporária:

Tabela temporária dura o tempo da sessão corrente, somente a sessão corrente
conseguirá trabalhar com a tabela temporária e o término da sessão implica no DROP
da tabela temporária.
CREATE TEMPORARY TABLE nome_tabela_temp (coluna1 [TYPE]);
Renomear tabela:
Mesmo renomeando a tabela o OID é mantido.
ALTER TABLE nome_atual RENAME TO nome_novo;
Adicionar nova coluna:

ALTER TABLE tabela ADD nova_coluna [TYPE];
Remover tabela:
DROP TABLE nome_tabela;
Criar índice:
CREATE INDEX nome_indice ON tabela (coluna);
DML - Data Manipulation Language
Conceito:
Comandos de consultas e manipulação de dados
do banco de dados, inserções, atualizações,
remoção de registros mantendo a estrutura de
dados inalterada.
➢ SELECT – Comando de consultas de dados*
➢ INSERT – Comando de inserção de dados
➢ UPDATE – Comando de atualização de dados
➢ DELETE – Comando de remoção de dados

77
DML - Data Manipulation Language – Linguagem de Manipulação de Dados
O DML é utilizado para realizar inclusões, consultas, alterações e exclusões de

dados presentes em linhas. Estas tarefas podem ser executadas em várias linhas de
diversas tabelas ao mesmo tempo. Os comandos são:
SELECT * FROM [tabela] – Seleciona dado(s) na tabela;
Pode ser usado para auxilisar alterações dos dados.
INSERT INTO [tabela] VALUES [valores] – Inserção de valor(es);
UPDATE [tabela] SET [coluna] = [valor] – Atualiza registro(s);
DELETE FROM [tabela] – Remove um ou mais registros.

Prática DML
1 Insira um registro na tabela secretaria.alunos informando as colunas:

1=# INSERT INTO secretaria.alunos (id, nome, idade, email)
VALUES (1, 'Jose Silva', 28, 'jose.silva@dexter.com.br');
2 Insira um registro na tabela secretaria.alunos:
2=# INSERT INTO secretaria.alunos VALUES (2, 'Maria Santos',
20, 'maria.santos@dexter.com.br', 'SdeWd43dfSS4');
3 Atualize o campo senha do aluno de id 1:
3=# UPDATE secretaria.alunos SET senha = 'D34Dsw'
WHERE id = 1;
4 Remova o registro de id 2 da tabela alunos:
4=# DELETE FROM secretaria.alunos WHERE id = 2;
78
Syntax dos comandos:
Inserir um registro declarando as colunas:

INSERT INTO tabela (coluna1,coluna2) VALUES (valor1,valor2);
Inserir um registro declarando valor para todas as colunas:

INSERT INTO tabela VALUES (valor1, valor2, valor3);
Atualizar registro(s):
UPDATE tabela SET coluna = [valor]
[WHERE campo = condição];
Remover registro(s):
DELETE FROM tabela
[WHERE campo = condição];
Utilizando SELECT para inserir dados:

INSERT INTO tabela VALUES (SELECT * FROM outra_tabela);
Utilizando SELECT para remover dados:

DELETE FROM tabela WHERE coluna IN (SELECT * FROM outra_tabela);
Utilizando SELECT para atualizar dados:

UPDATE tabela SET coluna = valor WHERE ID = (SELECT id FROM
outra_tabela WHERE coluna = valor);
Algumas funções no PostgreSQL
1 Função CAST para converter un campo numeric em integer:

1=# SELECT CAST(283.84 AS INTEGER);
2 Função COALESCE para ver o primeiro argumento não nulo:

2=# SELECT COALESCE(NULL, 8, 2, 3);
3 Funções GREATEST | LEAST para valores máximos e mínimos:

3=# SELECT GREATEST(28,53,1,23,36);
4=# SELECT LEAST(28,53,1,23,36);
4 Função LENGTH para contar caracteres:

5=# SELECT LENGTH('4LINUX');
5 Função INITCAP para deixar aas primeiras letras maiúsculas:

6=# SELECT INITCAP('joel sanTANA');
79
Funções no PostgreSQL:
Há diversas funções disponíveis no PostgreSQL, essas funções são utilizadas

afim de auxiliar nas consultas e facilitar buscas e alterações de dados, há diversos
tipos como, conversão, filtros, numéricos, comparação, substituição etc.
A utilização dessas funções são bastante práticas e simples melhorando a
produtividade tanto do Desenvolvedor quanto do DBA.
Trabalhando com Carga de Dados
 Pode ser feita a partir de arquivos CSV ou texto

 Utilizar COPY ao invés de INSERT;
 Realizar transações por Blocos;
 Aumentar Shared Buffers;
 Desabilitar fsync somente para a carga inicial;
80
A carga de dados no PostgreSQL podem ser feitas de diversas formas

diferentes, INSERTS, COPY, dump, CSV, etc, porém vale a pena reforçar que uma
grande carga de dados ao ser realizada deve ser bem avaliada pois a forma de
inserção interfere diretamente na performance da carga de dados, até mais do que os
parâmetros utilizados no PostgreSQL.
Trabalhando com Carga de Dados

1 Crie o banco de dados bi e crie as tabelas para carga de dados:

1=# CREATE DATABASE bi;
2=# \c bi
3=# CREATE TABLE carga_insert (id int, valor text);
4=# CREATE TABLE carga_bloco (id int, valor text);
5=# CREATE TABLE carga_copy (id int, valor text);
6=# CREATE TABLE carga_csv (id int, valor text);
2 Meça os tempos de carga para cada situação:
6$ time psql bi < /opt/insert_comum_10k.sql
7$ time psql bi < /opt/insert_blocos_10k.sql
8$ time psql bi < /opt/insert_copy_10k.sql
81
Exportação e Importação de CSV

3 Exporte os dados da tabela carga_insert para um arquivo CSV:

1$ time psql d bi A F ";" c "select * from carga_insert;" >
insert_csv_10k.csv
4 Também é possível exportar para HTML:
2$ time psql d bi A H c "select * from carga_insert;" >
exemplo.html
5 Apague a primeira e a última linha do arquivo insert_csv_10k.csv
6 Faça a importação dos dados na tabela carga_csv:

6$time psql d bi c "COPY carga_csv (id, valor)
FROM '/var/lib/postgresql/insert_csv_10k.csv' WITH
DELIMITER AS ';';"
82
Fundamentos de SQL e Carga de Dados
Recapitulando
 Surgimento do SQL
 Operações DDL e DML
 Funções do PostgreSQL
 Carga de Dados
 Importação e exportação de CSV
83
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
CaracterísticasInterno
Funcionamento e Instalação do MySQL
e Parametrização
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Funcionamento Interno e Parametrização
Objetivos da Aula
 Conhecer a arquitetura por trás de um DML;
 Conceitos de Memória Compartilhada;
 Aprender sobre a integridade do PostgreSQL;
 Parametrização dos WAL files;
 Função do Checkpoint;
 Alterar parâmetros com ALTER SYSTEM;
85
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Processos do PostgreSQL
86
Processos do PostgreSQL:
O processo supervisor gerencia uma coleção de bancos de dados de uma

máquina. Esta coleção é chamada de agrupamento - cluster de banco de dados.
O processo supervisor gerencia vários processos servidor, sendo um processo
para cada conexão. Para ajudar o processo supervisor nessa tarefa de gerência,
alguns subprocessos, ilustrados na figura do próximo slide, desempenham as
seguintes tarefas:
Processos responsáveis pelo funcionamento do PostgreSQL, os processos em
vermelho, são os processos fundamentais para o funcionamento do PostgreSQL, os
em amarelo são processos importantes, porém não vitais, e os processos em verde
são os processos chamados pelos clients.
Background Writer: Escreve continuamente no disco o que está nos buffers

compartilhados de memória (shared buffers); apenas um processo com este nome
deve existir por cluster.
Checkpointer: Processo responsável pela gerência dos checkpoints, despejo
completo de buffers da memória para o disco e gerenciamento da rotação dos logs
adiantados de transação; este processo foi criado a partir da versão 9.2,
anteriormente o controle de checkpoints era feito pelo ``background writer'' e o
processo ''checkpointer'' não existia; apenas um processo com este nome deve existir
por cluster.
WAL Writer: faz a escrita dos logs adiantados de transação, toda vez que uma escrita
(modificação de dados) ocorre; é responsável pela garantia de que os dados escritos
estejam efetivamente em disco; apenas um processo com este nome deve existir por
cluster.
Statistics collector: Coleta estatísticas sobre o uso dos objetos dos bancos de
dados; apenas um processo com este nome deve existir por cluster.
Logger: Coleta todas mensagens da saída de erro e escreve em arquivos de log;
também gerencia a rotação desses arquivos de acordo com tempo e/ou tamanho;
apenas um processo com este nome deve existir por cluster, podendo não existir
dependendo da configuração.
Archiver: Arquiva os log de transação (WAL) em um local especificado, normalmente
para fins de backup contínuo; apenas um processo com este nome deve existir por
cluster, podendo não existir dependendo da configuração.
Autovacuum launcher: Dispara execuções de processos ``autovacuum worker''
quando apropriado; apenas um processo com este nome deve existir por cluster,
podendo não existir dependendo da configuração.
Autovacuum worker: Processos que fazem as rotinas de manutenção ANALYZE e
VACUUM automaticamente. Eles se conectam ao banco de dados e tabela
determinados pelo processo ``autovacuum launcher'', e fazem esses trabalhos;
nenhum ou vários processos com este nome podem existir por cluster dependendo do
momento.
Mapa de execução do DML
88
●
A estrutura do servidor PostgreSQL é modular. Na figura são apresentados os
principais módulos e o caminho que os comandos SQL percorrem ao serem
executados. Os comandos DML - Data Manipulation Language, tais como SELECT e
UPDATE, utilizam pelo menos os módulos analisador (parser), reescritor (rewriter),
otimizador (optimizer) e executor.
●Outros comandos são tratados de maneira diferente porque não precisam dos
módulos de reescrita, otimização e execução, e são tratados pelo módulo Utility

Commands.
As funções desempenhadas por esses módulos são descritas a seguir:
Parser: Faz a análise léxica e sintática de consultas SQL. A análise léxica produz uma
sequência de tokens (palavras chave) que serão utilizados durante a análise sintática
para produzir uma árvore (query tree) a partir de um conjunto de regras predefinidas.
Os tokens e sintaxe de um comando devem obedecer à especificação da linguagem
SQL;
Rewriter: Reescreve a árvore verificando a existência das tabelas, visões e colunas

necessárias à consulta solicitada.
Optimizer: Com a árvore validada pelo rewriter, tenta produzir um plano ótimo. O
optimizer traça os possíveis caminhos para execução de uma consulta e escolhe
aquele que tem o menor custo dos planos avaliados. Em consultas com muitas
junções, o planejador poderia gastar muitos recursos para determinar um plano ótimo
e utiliza um algoritmo mais rápido que não analisa todas as possibilidades, mas
oferece um plano bom
Executor: Executa o plano escolhido pelo optimizer e retorna o resultado ao cliente;
Utility Commands: Executa comandos DDL – Data Definition Language, como

CREATE e DROP, comandos DCL – Data Control Language, como GRANT e
REVOKE, e comandos diversos como COPY, CLUSTER e SAVEPOINT;
Access Method: Contém a API para manipular os diversos tipos de métodos de

acesso a dados suportados (B+-Tree, Hash, GiST e GIN). É utilizado por outros
módulos como Catalog, Optimizer e Executor;
Buffer Manager: Gerencia os buffers de memória compartilhada;
Catalog: É o local onde o PostgreSQL armazena metadados, como as informações

sobre tabelas e colunas, bem como informações para auxiliar na manutenção do
SGBD. O catálogo do sistema são tabelas e visões. Por exemplo, a adição de uma
coluna em uma tabela modifica o catálogo para que ele reflita a definição atual da
tabela;
Utilities: Contém rotinas de suporte tais como tipos de dados embutidos, funções
embutidas, rotinas de erro, rotinas de cache, rotinas de ordenação, gerenciador de
memória, gerenciador de funções e rotinas de suporte a codificação multibyte;
Lock Manager: Gerencia as travas (locks) entre as diversas sessões;
Transaction Manager: Gerencia as transações executados no SGBD. Os comandos

BEGIN, COMMIT, ROLLBACK, SAVEPOINT, ROLLBACK TO e RELEASE (chamados
às vezes de DTL – Data Transaction Language) são utilizados neste módulo para
alterar o estado do sistema.
Fluxo de dados - Leitura
Leitura(1) tenta realizar a leitura em cache;

Leitura(2) faz a leitura em disco;
90
Quando uma operação de consulta ou escrita é realizada ela interage com

diversos processos até chegar a base de dados. Em ambos os casos tudo começa
com a aplicação abrindo uma nova conexão que chega ao processo supervisor do
PostgreSQL.
Este cria um fork de si mesmo para atender esta conexão, esse fork age como
um processo de backend que trata a conexão, as transações e realiza o parsing das
operações.
Se for uma operação de leitura, seu primeiro passo após a interpretação do

comando é consultar a memória compartilhada, se ele encontrar a informação
necessária lá então ele a usará para retornar a requisição. No caso de não encontrar
a informação no cache o próprio backend vai até o cluster e obtêm a informação de lá
dos arquivos de dados. A Figura ilustra este tipo de comportamento.
Funcionamento Interno do PostgreSQL
91
Escrita definitiva no cluster:

● Checkpoint – Meio mais natural de ocorrer
● Background writer – Faz escrita de páginas em menor escala (páginas menos
utilizadas).
Escrita(1): Background escreve no arquivo de WAL;

Escrita(2): Background escreve no Shared Buffers;
Escrita(3): Background escreve direto na Tablespace;
Escrita(4): BGWriter escreve os dados do Shared Buffer em Disco em menor escala;
Escrita(5): Se necessário o Checkpoint escreve os dados do Shared Buffer em disco;
No caso de uma operação de escrita, o fluxo é mais complicado devido aos

vários passos que o backend realiza. Ao receber qualquer operação de modificação
de dados, o primeiro passo é enviar ao WAL writer, o processo responsável pela
gravação dos logs adiantados de transação no diretório pg_xlog.
Somente após sua confirmação, o backend tenta usar o cache para gravar
essa modificação. Se o backend não conseguir gravar no cache caso ele esteja cheio,
o próprio backend gravará as informação no diretório do cluster.
WAL (Write-Ahead Logging)
Conceito: Arquivos de log das transações

executadas, por segurança, cada ação no
banco de dados é registrada nesse log.
 Logs de transações binários de 16MB(default);

 São arquivos de “REDO”;
 Gravação e leitura feita por páginas de 8k(default);
 Garante a durabilidade da Transação
92
WAL (Write-Ahead Logging)
Todos os arquivos de dados no PostgreSQL, logs adiantados de transação

(WAL) e blocos de memória, são dividido em páginas, cada página contendo exatos 8
kB na compilação padrão.
O tamanho das páginas pode ser alterado, mas é necessário recompilar o
PostgreSQL. Para a maioria das aplicações, não existem ganhos significativos em
alterar o tamanho das páginas.
Nas aplicações em que isso apresentar algum ganho, é importante notar que
para a restauração de backup e criação de réplicas os binários devem ser compilados
exatamente da mesma forma.
Os logs de transação, arquivos WAL, são arquivos comuns, binários, com 16
MB cada na compilação padrão. Embora seja possível alterar o tamanho dos arquivos
WAL, isso não traz benefícios, pois o tamanho da área total ocupada pelos arquivos
WAL pode ser controlada por outros parâmetros de configuração, e os arquivos WAL
atuam em conjuntos de segmentos.
Quando o PostgreSQL escreve ou lê dados do disco, isto é feito por páginas.
Na escrita, se o parâmetro full_page_writes estiver desligado, pode existir escrita
parcial de páginas, o que não é recomendado na maioria dos casos.
Alguns Parâmetros do WAL

wal_buffers = 1 (default 4MB)
Buffers para escrita em WAL;
wal_writer_delay = 200ms
Delay da escrita em millisegundos;
wal_level = minimal
Nível de detalhe dos arquivos de WAL
1 Altere o parâmetro wal_buffers para 8M:

+ wal_buffers = 8MB
2 Reinicie o postgresql e valide conforme segue:

4 =# SHOW wal_buffers;
93
wal_buffers;
● Área de memória compartilhada;

● Buffer onde os dados a serem gravados no WAL são armazenados inicialmente;
●
Atualmente usar -1, uma espécie de auto tuning, que normalmente representa 3%
dos “shared buffers”.
Antes de serem gravados fisicamente em disco, os dados dos logs de
transação são armazenados em uma área de memória compartilhada denominada
wal_buffers, a qual tem seu conteúdo gravado em disco a cada commit.
O tamanho desta área é definido na opção wal_buffers o que por padrão nas
últimas versões do PostgreSQL utiliza o valor -1, o qual representa um espécie de
auto tuning pois dessa forma seu tamanho é de aproximadamente 3% o valor dos
shared buffers.
Aumentar este valor pode ajudar em servidores onde existem muitas
transações concorrentes, porem o aumento excessivo pode causar picos de IO
devido a grande quantidade de dados sendo gravados de uma única vez. Na maioria
dos casos o valor automático é suficiente.
Shared Buffers
Conceito: Área da memória compartilhada

utilizada para cache de leitura e escrita
 Memória compartilhada alocada na inicialização;

 Área de buffer/chache de Leitura e Escrita;
 Divididos em blocos limpos(=disco) e sujos(<> disco);
 Recomenda-se não utilizar mais de 40% RAM do server;
 Valores acima de 8GB não traz ganhos significativos;
94
WAL e o Shared Buffers
O PostgreSQL, por ser um banco de múltiplos processos, utiliza uma área de

memória compartilhada denominada shared buffer para cache de leitura e escrita.
Devido a escrita ser realizada nos “shared buffers” é necessário ter garantias
do que foi gravado, pois os dados estão em memoria e ainda não foram persistidos
em disco. Esta garantia é obtida através dos logs adiantados de transação
denominados WAL (Write Ahead Log).
Shared Buffers
Os shared buffers, conforme citado anteriormente, são uma região de memória
compartilhada utilizada como buffer/cache de escrita e leitura comum a todos os
backends. Esta região tem seu tamanho limitado ao definido na opção
shared_buffers.
Ao iniciar o PostgreSQL, este segmento de memória sera totalmente alocado.
O sistema operacional deve estar configurado para aceitar a quantidade de memória
compartilhada especificada aqui.
O valor padrão típico é 128MB, mas este valor pode ser menor devido a
algumas configuração do ser sistema operacional. Esse valor também pode ser
definido em unidades de memória (kB, MB ou GB). Para bom desempenho em
produção, este valor deve ser aumentado, pois o valor padrão vem definido somente
para permitir a inicialização do banco. Este assunto será abordado em capítulo futuro.
De maneira geral recomenda-se que o tamanho dos shared buffers não
ultrapassem 40% do tamanho da memoria RAM, e também não ultrapassem a faixa
dos 4GB a 8GB. Existem limitações em ambiente Windows que tornam o uso de
grandes quantidades de shared buffer inviável. Em testes realizados, valores maiores
que 256MB causaram degradação do desempenho.
Ajustando parâmetros com ALTER SYSTEM

1 Altere o parâmetro shared_buffers com o comando ALTER SYSTEM:

1 =# ALTER SYSTEM SET shared_buffers = '256MB';
2 Agora valide se a alteração surtiu efeito:
2=# SHOW shared_buffers;
3=# \! cat /etc/postgresql/9.6/main/postgresql.conf |
grep shared_buffers
3 Reinicie o postgresql e valide conforme segue:
4=# SHOW shared_buffers;
5=# \! cat /etc/postgresql/9.5/main/postgresql.conf | grep

shared_buffers
6=# \! cat /var/lib/postgresql/9.5/main/postgresql.auto.conf
95
Parâmetros de configuração:
ALTER SYSTEM
A versão 9.4 do PostgreSQL adicionou uma nova cláusula SQL chamada ALTER
SYSTEM. Com este comando, você pode editar diretamente as configurações do
arquivo posqtgresql.conf. Se faz necessário em alguns parâmetros a reinicialização
do Postgresql, ou reload dependendo do contexto.
Alterar um parâmetro com ALTER SYSTEM:

ALTER SYSTEM SET parametro = ‘valor’;
Exibir um parâmetro:
SHOW parametro;
Shared Buffers e o BGWriter
Processo responsável pela escrita dos

blocos sujos do Shared Buffers em Disco.
bgwriter_delay = 200ms
Intervalo de execuções do BGWriter em milisegundos.
bgwriter_lru_maxpages = 200
Quantidade máxima de páginas por rodada do BGWriter.
bgwriter_lru_multiplier = 2.0
Fator de multiplicação onde (qtd paginas anterior * lru_multiplier);
96
O background writer (também chamado de bgwriter) é um processo responsável pela

escrita dos bloco sujos (dirty) dos shared buffers no disco. O objetivo é que processos
backends não tenham que aguardar por escritas em disco, o background writer fará
isso.
Como visto anteriormente o bgwriter utiliza o algoritmo de LRU (Least Recently
Used) para decidir quais blocos devem ser gravados. Ele é ativado em intervalos de
tempo definidos pela opção bgwriter_delay.
Para evitar picos de IO, existe um número máximo de páginas que podem ser
escritas por rodada, este número é definido na opção bgwriter_lru_maxpages'.
A cada rodada o bgwriter define a quantidade de páginas a serem gravadas,
baseado na média das paginas removidas em rodadas anteriores junto com um
multiplicador que é definido na opção bgwriter_lru_multiplier. Este multiplicador
permite que o número previsto seja igual à média anterior (1.0), menor que a média
anterior (< 1.0) ou maior que a média anterior (> 1.0).
Utilizar o multiplicador prevê uma proteção contra picos de atividade do banco
de dados, pois mais buffers limpos serão deixados no cache. O número máximo de
buffers em bgwriter_lru_maxpages será, todavia, sempre respeitado.
Valores muito baixos nos parâmetros do background writer reduzem o I/O
causado por ele, mas tornará mais provável que os processos de sessão do
PostgreSQL façam escritas por eles mesmos, prejudicando o desempenho de escrita
do PostgreSQL.
Ajustando o BGWriter para bancos Transacionais

1 Edite o arquivo postgresql.conf ajustanto o bgwriter:
+ bgwriter_delay = 100ms
+ bgwriter_lru_maxpages = 300
+ bgwriter_lru_multiplier = 3.0
2 Faça o reload do serviço do postgresql:

2 # service postgresql reload
97
Utilizar shared buffers muito grandes podem denegrir o desempenho do banco, pois o
bgwriter terá de varrer uma quantidade de blocos muito grande, o que vai levar a um
tempo mais longo de execução e assim desperdiçar recursos sem necessidade.
O PostgreSQL foi desenhado pensando na utilização do cache do sistema de

arquivos do sistema operacional, por isso que nem sempre é necessário alocar
grandes quantidades de shared buffer para se obter bom desempenho.
O uso maior de shared_buffers normalmente é desejado em ambientes de

maior taxa de modificações de dados, enquanto nos ambientes de maior leitura (mais
SELECT), prefere-se deixar mais memória disponível pro cache do próprio sistema
operacional.
WAL e Checkpointer
Faz a escrita dos dados Shared Buffers em Disco

permitindo a remoção dos arquivos de WAL antigos.
checkpoint_timeout = 5min
Limite de tempo para execução do Checkpoint;
max_wal_size = 1GB
Limite de tamanho da área de WAL para execução do Checkpoint;
min_wal_size = 80MB
Tamanho mínimo da área de WAL para execução do Checkpoint;
checkpoint_completion_target = 0.5
Fator de escala de tempo de execução de checkpoint;
checkpoint_warning = 30s
Intervalo mínimo entre checkpoints caso ultrapasse um log é gerado.
98
Quando o número de segmentos disponíveis se esgota, ocorre um checkpoint,

que é o ponto onde os dados em shared buffer serão efetivamente gravados em disco
para que seja possível eliminar os segmentos atuais e criar novos.
Os checkpoints são necessários, pois sem eles haveria a necessidade de
manter todos os logs de transação indefinidamente:
●Ponto onde os dados em “shared buffer” serão efetivamente gravados em disco, para
que seja possível eliminar os segmentos atuais e criar novos;

●
Necessários, pois sem eles os WAL não poderiam ser eliminados.
●Quando esgota o tempo definido na variavel checkpoint_timeout;
Dica: será exibido log caso ocorram mais de uma vez no período definido na opção:
checkpoint_warning;
LOG: checkpoints are occurring too frequently (x seconds apart)
O ideal é que os checkpoints ocorram preferencialmente por esgotamento do
tempo, pois caso ocorram por falta de segmentos com muita frequência podem
prejudicar o desempenho, devido a carga de I/O gerada na gravação dos “shared
buffers” em disco.
Uma dica será exibida no log do PostgreSQL caso os checkpoints ocorram em
períodos inferiores à opção “checkpoint_warning”
Aumentar o número de segmentos pode ajudar no desempenho do banco,
porém, deve-se tomar o cuidado de não aumentar demais, pois quando ocorrer um
crash o tempo de recuperação sera muito grande devido a necessidade de aplicar
todos estes segmentos.
Verifique seu tempo de SLA e faça testes para saber a quantidade de
segmentos aceitável no seu ambiente.
Alterando o Checkpoint
1 Verifique o numero do processo do checkpointer:

1 # ps ef | grep checkpointer
2 Veja agora quem está lendo o pg_xlog:

2 # lsof | grep pg_xlog
3 Altere o parâmetro checkpoint_timeout:

3=# SHOW checkpoint_timeout;
4=# ALTER SYSTEM SET checkpoint_timeout = 200;
5=# SELECT pg_reload_conf();
6=# SHOW checkpoint_timeout;
99
Com o intuito de suavizar picos de I/O durantes os checkpoints o PostgreSQL

utiliza uma técnica espalhamento da gravação em determinado tempo. Este tempo é
uma fração do tempo (em caso de checkpoint por tempo) ou número de segmentos
(em caso de checkpoint por esgotamento de segmentos) que levaram o checkpoint a
ocorrer, esta fração é definida na opção “checkpoint_completion_target”.
Utilizando o valor default:
Se o Checkpoint ocorreu por tempo;

●checkpoint_timeout = 300;
●checkpoint_completion_target = 0.5;
O tempo de gravação será espalhada em:

300 * 0.5 → 150 segundos.
Após as alterações:
Se o Checkpoint ocorreu por tempo;

●checkpoint_timeout = 200;
●checkpoint_completion_target = 0.5;
O tempo de gravação será espalhada em:

200 * 0.5 → 100 segundos.
WAL - fsync
Fsync
Garante a escrita em disco (não fica no chache do SO);
Por default é habilitado para garantir a escrita em disco;
Desabilitar ou alterar o “wal_sync_method” não é recomendado.
fsync = on
Habilita ou desabilita o fsync;
wal_sync_method = fsync
Métodos de sincronia da escrita dos arquivos de WAL;
full_page_writes = on
Cada escrita ocupa uma página inteira, desabilitar esse parâmetro
pode comprometer a integridade dos dados na recuperação.
100
Afim de se assegurar

Idioma

Administrac ºa Âo PostgreSQL Com Alta Performance e Alta Disponibilidade

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Administrac ºa Âo PostgreSQL Com Alta Performance e Alta Disponibilidade

Enviado por

Direitos autorais:

Amorim Weverton Rufino De / weverton.geek@gmail.

Características e Instalação do PostgreSQL

 Conhecer a Origem do PostgreSQL

Sybase Corp Informix IBM

Tandem -NonStop SQL PostgreSQL

Berkeley POSTGRES Postgres95

Tudo começou como INGRES

●Em 1992 a Microsoft licenciou alguns produtos Sybase – SQL Server

●Em 1997 a Informix adquiriu os demais direitos – Sybase

●Em 2000 a IBM tornou-se proprietária da Informix – Sybase

Pronúncia e Suporte do PostgreSQL

 PostgreSQL ou Postgres - CORRETO

●1996 O Postgres95 foi rebatizado como PostgreSQL, muitos usuários

●2010 PostgreSQL 9.0 Amadurecimento do PL/pgSQL, suporte completo a Windows

 Banco de dados ACID;

A licença utilizada é a BSD, que permite a redistribuição comercial em formato

A maioria das linguagens de programação modernas preveem interface nativa

Existem centenas de projetos livres e comerciais relacionados à administração,

Características do PostgreSQL - ACID

ACID é uma característica fundamental para os bancos de dados, pois fecha

Atomicidade: Garantir o início, meio e fim da transação a fim de que a transação só

Consistência: Com a execução de várias transações em paralelo nenhuma transação

Isolamento: As transações executadas em paralelo não podem interferir nas

Durabilidade: Após a conclusão da transação o banco precisa garantir que o dado

 9.5.X (terceiro número da versão);

 X.X (primeiro ou segundo numero da versão)

Formas de instalação do PostgreSQL

 Instalação do fornecedor do SO;

 Compilar código fonte;

Instalação do fornecedor do S.O.

● As flags utilizadas na compilação geralmente são as default;

● Em alguns casos, é a única opção disponível (ex. Windows);

● Têm suporte da comunidade;

● São compiladas com as flags definidas pela comunidade.

Compilar o código fonte

● Permite a instalação de qualquer uma das versões disponíveis do PostgreSQL.

Instalação do PostgreSQL no Debian

A comunidade PostgreSQL oferece pacotes no site www.postgresql.org. As

O one-click installer, instala o PostgreSQL no diretório /opt e é compatível com a

PostgreSQL como a documentação, FAQ, listas de discussão e wiki.

Instalação do Repositório PostgreSQL no Debian

Execute os comandos abaixo nos servidores: dbmaster e standby1

1 Servidores dbmaster e standby1 inserir o repositório:

2 Realize o download da chave do PostgreSQL e adicionar ao apt:

3 Atualize a lista de pacotes do repositório:

Instalação do PostgreSQL no Debian

Execute os comandos abaixo nos servidores: dbmaster e standby1

1 Instale o pacote com o comando apt-get install conforme segue:

2 Liste o conteúdo do diretório dos binários do PostgreSQL:

3 Localize os binários dos programas abaixo:

4 Liste as conexões da porta default do PostgreSQL:

Stop e Start do PostgreSQL no Debian

1 No servidor dbmaster realizar listar os processos do PostgreSQL:

2 Comandos para parar o PostgreSQL:

3 Comandos para iniciar o PostgreSQL:

4 Comando para reload do PostgreSQL:

Instalação do PostgreSQL no Centos

Instalação do PostgreSQL no Centos

Execute os comandos abaixo no servidor standby2

1 Realize a instalação do repositório com o comando abaixo:

2 Localize os binários da instalação:

Criando um Cluster no PostgreSQL - Centos

No CentOS o cluster do PostgreSQL não foi criado, então vamos criar:

Execute os comandos abaixo no servidor standby2:

1 Crie um cluster no diretório default do Centos: