Vous êtes sur la page 1sur 30

PostgreSQL

Trabalho Final - Sistemas de Bases de Dados


Mestrado em Engenharia Informtica
GRUPO 15
Realizado por:
AnaGonalves,n40611
MoissLpez,n40368
PedroCamelo,n39522
PedroHernndez,n40356
1
ndice
1.Introduo
1.1Introduohistricaeaplicabilidadedosistemaestudado
1.2Notasdeinstalao
2.CoberturadoSQL
2.1.DataDefinitionLanguage
2.2.Constraints
2.3.ForeignKeys
2.4.AssertionseTriggers
2.5.Views
2.6.Rules
3.ArmazenamentoeFileStructure
3.1.FormatodeArmazenamentodeFicheiroseDirectoriasdeSistema
3.2.Armazenamentofisicodetuplosdegrandedimenso
3.3.FreeSpaceMap
3.4.VisibilityMap
3.5.InitializationFork
3.6.BackendInterface(BKI)
3.8.BufferManagement
3.10.OraclevsPostgreSQL
4.Indexaoehashing
4.1.Tiposdendices
4.1.1Btree
4.1.2Hash
4.1.3GeneralizedSearchTree(GiST)
4.1.4SPGist
4.1.5GeneralizedInvertedIndexes(GIN)
4.2.IndexesandORDERBY
4.3.MulticolumnIndexes
4.4.UniqueIndexes
4.5.ANALYZEEEXPLAIN
4.6.OraclevsPostgreSQL
5.ProcessamentoeOptimizaodePerguntas
5.1Planner
5.2Consultarplanosdeexecuo
5.2.1EXPLAIN
5.2.2EXPLAINANALYZE
5.4Optimizarosplanosdeexecuo
5.4.1OperaoSELECT
5.4.2OperaoORDERBY
5.4.3OperaoJOIN
NestedLoopJoin
2
MergeJoin
HashJoin
5.5GeneticQueryOptimizer
5.5.1AlgoritmoGentico
5.6Parametrizao
5.7ComparaocomOracle
6.Gestodetransacesecontrolodeconcorrncia
6.1Transaces.
6.2Queprotocolousadoparagarantirisolamento
6.3Deadlocks
6.4Nveisdegranularidadedoslocks
AccessShareLock
RowShareLock
RowExclusiveLock
ShareLock
ShareRowExclusiveLock
ExclusiveLock
AccessExclusiveLock
Bloqueiosaonveldafila
Bloqueiosaonveldapage
6.5Nveisdeisolamento.
READCOMMITTED
REPEATABLEREAD
SERIALIZABLE
6.6Comolidacomconsistncia.
6.7Comolidacomatomicidadeedurabilidade.
Atomicidade
Durabilidade
6.8OraclevsPostgreSQL
7.Suporteparabasesdedadosdistribudas
8.Outrascaractersticasdosistemaestudado
8.1.SuporteparaaWEB
8.2.SuporteparaXML
8.3.Storedprocedures
8.4.TriggerseFornecimentodeServios
8.5.Segurana
Interna
Externa
8.6.Tipodedadossuportados
8.7.Ferramentas
9.Referncias
3
1. Introduo
Hoje em dia os SIstemas de Bases de Dados do suporte a uma srie de aplicaes
que so usadas por milhes de pessoas, sendo portanto uma parte importante do mundo da
informtica de hoje em dia. As bases de dados apresentam solues fiveis para o
armazenamento e consulta de dados em larga escala, sendo por isso usadas tanto em
aplicaescomuns,comoparaplataformasbancrias,militares,espaciaisentreoutros.
Neste trabalho iremos analizar o Sistema de Gesto de Base de Dados (SGBD)
PostgreSQL. Fazendo ao mesmo tempo uma comparao com o SGBD Oracle nos pontos
queconsideramosmaisimportantes.
Nas prximas seces iremos abordar uma perspectiva histrica do SGBD, as
diferenas que apresenta em relao ao SQL, a forma como armazena e dispem a sua
estrutura de ficheiros, os tipos de indices que dispe, o processamento e optimizao de
queries, a gesto de transaces e controlo de concorrncia e outras caracteristicas que
considermosrelevantesdoSGBDemestudo.
1.1 Introduo histrica e aplicabilidade do sistema estudado
O SGBD PostgreSQL um avano do sistema POSTGRES desenvolvido pelo
Professor Michael Stonebraker com o apoio da Defense Advanced Research Projects
Agency (DARPA), da Army Research Office (ARO), da National Science Foundation (NSF)
e da ESL, Inc. O seu desenvolvimento comeou em 1986 e foi apresentado pela primeira
veznaACMSIGMODConferenceem1988,tendosidolanadoparaopblicoem1989.
Passou a ser apelidado de Postgres95 depois de Andrew Yu e Jolly Chen terem
introduzido um interpretador de SQL ao SGBD. O SQL veio substituir a linguagem
PostQUEL, que era a usada at altura por este SGBD. Foi tambm neste momento que foi
lanadoparaainternetcomoopensource.
No ano de 1996 o SGBD foi renomeado para PostgreSQL de forma a reflectir a
relaoentreoPOSTGRESeacompatibilidadeentrealinguagemSQL.
Actualmente o PostgreSQL adoptado pela industria como uma das referncias de
sistema de base de dados opensource, sendo tambm conhecido pelas suas
implementaes extensas de algoritmos e tcnicas desenvolvidas em ambientes
acadmicos.
4
1.2 Notas de instalao
Para a instalao do SBD recorreuse a uma mquina virtual de 20gb de espao
com uma instalao do Ubuntu Server 13.04 (64bits), o utilizador tem o username sbd, e a
password 12345678. Foi instalado o servio OpenSSH (sudo aptget install
opensshserver) para aceder mquina atravs de um terminal SSH e foi instalado um
servidorPostgreSQL(sudoaptgetinstallpostgresql).
A verso que se encontra nos repositrios do Ubuntu a 9.1, pelo que esta foi a
verso instalada. Ao contrrio do que est descrito na documentao, os ficheiros relativos
estrutura fisica do servidor foram instalados na directoria
/var/lib/postgresql/9.1/main/, os ficheiros de configurao foram instalados no
destinoesperado/etc/postgresql/9.1/main/.
Para ser possvel aceder consola do PostgreSQL sem ser a partir da prpria VM, o
servidor foi configurado para fazer listen para toda a gama de IPs, para este efeito foi
alteradooseguinteparamtronoficheiropostgresql.conf:
listen_addresses=*
Foi feito login atravs de uma sesso SSH e criouse um novo utilizador
linuxpoison com a password password (sem aspas) e foi criada a base de dados
linuxdb:
$sshsbd@<IP>
...
$sudoupostgrescreateuser
Enternameofroletoadd:linuxpoison
Shallthenewrolebeasuperuser?(y/n)n
Shallthenewrolebeallowedtocreatedatabases?(y/n)n
$sudoupostgrescreatedblinuxdb
deseguidaforamdadastodasaspermissesaoutilizadorlinuxpoisonsobreabasede
dadoslinuxdb:
$sudoupostgrespsql
postgres=#alteruserlinuxpoisonwithencryptedpassword'password'
ALTERROLE
postgres=#grantallprivilegesondatabaselinuxdbtolinuxpoison
Foi necessrio adicionar permisses para o acesso do utilizador por parte do
computador fisico VM nas configuraes do PostgreSQL. Adicionouse uma configurao
aoficheiropg_hba.conflocalizadoem/etc/postgresql/9.1/mainparaesteefeito.
#TYPEDATABASEUSERADDRESSNETMASKMETHOD
hostallall172.16.101.1255.255.255.0password
5
de seguida o servidor foi reiniciado de forma a que a configurao de acesso adicionada no
pontoanteriortomasseefeito:
$/etc/init.d/postgresqlrestart
Para podermos interagir com o servidor PostgreSQL a partir do programa
postgresqlclientusmososeguintecomando:
$psqlh172.16.101.133linuxdblinuxpoison
Passwordforuserlinuxpoison:password
psql(9.0.10,server9.1.9)
SSLconnection(cipher:(NONE),bits:1)
Type"help"forhelp.
linuxdb=>
A partir deste momento foi possvel efectuar consultas e executar operaes a partir
daconsoladoPostgreSQL.
6
2. Cobertura do SQL
O PostgreSQL no apresenta suporte a diversas funcionalidades definidas na
linguagem SQL:2011. No entanto para algumas funcionalidades apresenta mecanismos
equivalentes. Nas prximas subseces apresentamos de forma resumida os vrios
mecanismossuportadosnadeclaraodecomandosSQLsobreoSGBDemestudo.
2.1. Data Definition Language
A DDL uma linguagem de programao utilizada por aplicaes e utilizadores que
permite definir vrias estruturas de dados em bases de dados. No caso do SQL, as
principaisqueriesdestetiposo,CREATETABLE,DROPTABLEeALTERTABLE.
2.2. Constraints
As constraints so restries sobre as tabelas do SGBD, permitindo um controlo
sobreosdadospresentesnamesma.
2.3. Foreign Keys
O PostreSQL apresenta suporte para foreign keys, que numa tabela permitem
referenciarchavesreferentesaoutrastabelas.
2.4. Assertions e Triggers
Os triggers consistem em cdigo SQL que executado antes ou depois de uma
actualizao ou remoo na base de dados. As assertions consistem em cdigo SQL que
garantequedeterminadascondiessosatisfeitas.
O PostgreSQL no apresenta suporte para assertions, pelo que sugerese a
utilizaodetriggersquegarantamasmesmascondies.
2.5. Views
As views consistem numa tabela virtual no SGBD criada a partir de uma query. Este
mecanismo no guarda o resultado da query a que corresponde, pelo que de cada vez que
umaviewexecutada,aqueryaquecorrespondeexecutada.
7
2.6. Rules
As rules consistem num mecanismo que permite fazer alteraes na execuo das
queries. Quando uma query dispara uma rule, a query rescrita de acordo com as regras
daruleemquesto.
8
3. Armazenamento e File Structure
Neste capitulo ser descrita a forma como a estrutura de ficheiros e armazenamento
feita no PostgreSQL, de que forma so ordenados os dados no disco e que tipo de
estruturasdedadossousadasparaarmazenamentodedados.
3.1. Formato de Armazenamento de Ficheiros e Directorias de Sistema
Toda a informao fsica relativa ao PostgreSQL encontrase arquivada na directoria
PGDATA, que geralmente em sistemas UNIX based, se encontra localizada no caminho
absoluto /var/lib/pgsql/data. Vrios clusters de informao podem existir na mesma
mquina,sendocontroladospordiferentesinstnciasdabasededados.
As pages do PostgreSQL ocupam 8kB por defeito, sendo possvel que o seu
tamanho seja alterado durante a compilao do SBD. A tabela seguinte representa a
estruturadeumapagenestesistema:
24bytes
Cabealhoda
page,contm
informaoda
mesmae
apontadorespara
oespaolivre
Arraydepares
offset,lengthde
apontadorespara
osrecords
presentesna
page
EspaoLivre Records
Espaoreservado
paramtodosde
indicesdedados
especificos
EstruturadeumapagenoPostgreSQL
3.2. Armazenamento fisico de tuplos de grande dimenso
O PostgreSQL usa uma tcnica denominada de TOAST The OversizedAttribute
Storage Technique para armazenamento de tuplos de grande dimenso nas pages. Os
tuplos so guardados de forma a que no faam spawn em multiplas pages. Esta soluo
no entanto no permite um armazenamento numa nica page para tuplos que ultrapassem o
tamanho das pages, para estes casos o contedo dos tuplos comprimido ou dividido entre
vriaspagesdeformaaqueoseuarmazenamentosejapossvel.
3.3. Free Space Map
Esta estrutura de dados est presente em todas as heaps e indices de relaes
(excepto para indices de hash) de forma a mapear o espao disponivel em cada relao.
Consiste numa rvore binria em cada folha aponta para o espao livre dos indices e heaps,
osnveissuperioresagregamainformaodosnveisinferiores.
9
3.4. Visibility Map
Esta estrutura de dados mapeia as pages que se encontram visiveis para todas as
transaces a ocorrer em determinado momento. Apenas ocupa um bit do heap de cada
page, caso este bit esteja a um todos os tuplos dessa page se encontram visiveis para o
conjuntodetransaces.
3.5. Initialization Fork
O initialization fork corresponde a uma tabela vazia ou ndice que usado aps um
crash sobre uma unlogged table. O seu uso acontece atravs da sua cpia para o main fork
databela,sendoosrestantesforkseliminados.
As unlogged tables so tabelas que no usam a tcnica de write ahead logging
(WAL) durante o seu funcionamento. Esta tcnica que ajuda a garantir as propriedades
ACID (Atomicity, Consistency, Isolation, Durability), consiste na escrita das operaes num
log antes de serem aplicadas na tabela. Ao no recorrerem ao WAL, as unlogged tables so
consideravelmente mais rpidas em comparao com uma tabela normal mas tm a
desvantagemdeseremmaisrelaxadasemrelaospropriedadesACID.
3.6. Backend Interface (BKI)
Os ficheiros BKI so ficheiros escritos numa linguagem de scripting que o
PostgreSQL interpreta e permitem alterar o funcionamento da estrutura interna do sistema,
esta linguagem permite rescrever por completo o comportamento interno da estruturao
dosdadosemecanismosusadosparaacessoaosmesmosporpartedoPostgreSQL.
3.8. Buffer Management
O PostgreSQL usa a tcnica de Write Ahead Logging (WAL) para garantir a
integridade dos dados, que consiste na escrita das operaes sobre uma tabela num log
antes de serem aplicadas. A sincronizao dos dados em memria com o sistema de
ficheiros forado atravs de um procedimento chamado depois da escrita das operaes
no log. Durante a sincronizao so usados checkpoints e buffers partilhados de forma a
permitiraescritadosdadosemdisco.
O tamanho por default dos buffers partilhados usados pelo PostgreSQL so de
32MB, este valor pode ser modificado manualmente de acordo com a memria RAM
disponvel em sistema. A buffer cache composta por um array de buffer entries,
percorrido de forma sequncial e quando chega ao fim retorna ao inicio, a este tipo acesso
chamadodeclocksweep.
10
Os buffers existentes no PostgreSQL so composto por uma srie de estados que
permitem identificar o estado da informao que dispem. Quando um buffer est a ser
acedido por parte de um cliente marcado como pinned e no pode ser reciclado para a
criao de novos buffers. Quando escrita informao sobre um buffer este marcado
como dirty. Apresentase de seguida dois exemplos de progresso de estados sobre os
buffersexistentesnoPostgreSQL:
(unpinned,notdirty)>read>(pinned,notdirty)>update>(pinned,dirty)>
transactioncomplete>(unpinned,dirty)>checkpoint>(unpinned,notdirty)
(unpinned,notdirty)>insert>(pinned,dirty)>backgroundwriterwrite>(pinned,
notdirty)>transactioncomplete>(unpinned,notdirty)
Omecanismodevacuumlibertaespaonosbuffersquandoosdadosdeixamdeser
necessrios.
3.10. Oracle vs PostgreSQL
O Oracle ao contrrio do PostgreSQL apresenta pages de 4kB de tamanho por
defeito. Apesar de apresentar checkpoints da mesma forma que o PostgreSQL apresenta,
no dispe de um mecanismo de Write Ahead Logging, por sua vez tambm no dispem
deunloggedtables.
11
4. Indexao e hashing
Neste captulo iro ser descritos os diferentes tipos de ndices que so permitidos
em PostgreSQL e uma sries de caractersticas e propriedades que PostgreSQL tem em
relaoindexao.
4.1. Tipos de ndices
O ProgresSQL dispe de vrios tipos de ndices, de seguida iro ser descritos as
seguintesestruturasdeindexao:BTree,Hash,Gist,SPGisteGin.
4.1.1 B-tree
Esta estrutura de dados uma implementao das highconcorrency btrees de
LehmanYao. A btree a estrutura de indexao usada por defeito quando usado o
comando CREATE INDEX. O query planner usa um indice disposto numa btree quando a
consultaemquestousaumdosseguintesoperadores:
<<==,>=,>
As btrees podem ser usadas sobre indices de valor inteiro, texto ou NULL. Esta
estrutura de dados tambm permitem obter o indice de forma ordenada. O comando para a
criaodebindicesaseguinte:
CREATEINDEXnameONtable(column)
4.1.2 Hash
Esta estrutura de dados uma implementao do linear hashing de Litwins, esta
estrutura de dados plenamente dinmica e no necessita ser optimizada periodicamente.
O query planner usa um indice hash sempre que uma coluna indexada est implicada
numa comparao que utiliza o operador de igualdade =. O comando para criar indices hash
oseguinte:
CREATEINDEXnameONtableUSINGhash(column)
4.1.3 Generalized Search Tree (GiST)
As GiST so estruturas de dados baseadas em rvores equilibradas, podem ser
utilizadas para operaes de igualdade e so usadas para indexar tipos de dados
geomtricosedetexto.
12
Estas estruturas de dados so usadas quando necessrio implementar esquemas
de indexao arbitrria. As btrees e outros tipos de estruturas de dados podem ser
implementadas em GiST, da mesma forma as consultas que fazem uso de indices GiST
podem depender da estratgia de indexao definida nas tabelas. Esto disponiveis os
seguintes operadores sobre os indices quando uma estrutura de dados de indexao usa a
estratgiaGiST:
<<&<&>>><<|&<||&>|>>@><@~=&&
4.1.4 SP-Gist
Os indices SPGiST, tal como os indices GiST, oferecem uma infraestrutura que
suporta vrias classes de procura. As SPGiST so implementadas sobre um bloco de
disco no equilibrado, sendo portanto diferentes das estruturas baseadas em quadtrees, kd
trees e suffix trees. O PostgreSQL usa SPGiST indexes para pontos bidimensionais, que
apoiamconsultasindexadasequeusamosseguintesoperadoresdeigualdade:
<<>>~=<@<^>^
4.1.5 Generalized Inverted Indexes (GIN)
Este tipo de indexao desenhada para indices que contm mais do que uma
chave, por exemplo arrays. Os indices GIN suportam vrias estratgias de indexao,
definidaspeloutilizador,assimcomoosoperadoresausarporessasestratgias.
4.2. Indexes and ORDER BY
Alm de simplesmente procurar os tuplos obtidos por uma query, o PostgreSQL
pode tambm devolver o resultado de uma forma ordenada. Isto permite que uma query que
usa o comando ORDER BY j venha ordenada pelo valor pretendido, simplificando a
execuo das pesquisas. Os indices btree so, por defeito, ordenados por ordem
crescente, sendo que os valores null so dispostos no fim. Este tipo de indices tambm
podem ser acedidos de forma inversa, o que permite satisfazer procuras da forma ORDER
BY<atributo(s)>DESC.
CREATEINDEXtest2_info_nulls_lowONtest2(infoNULLSFIRST)
CREATEINDEXtest3_desc_indexONtest3(idDESCNULLSLAST)
4.3. Multi-column Indexes
Enquanto que o PostgreSQL tem a possibilidade de criar indices multicoluna,
importante referir quando que faz sentido usar este tipo de indices. O query planner tem a
possibilidade de combinar e usar vrios indices de uma nica coluna, numa query
13
multicoluna ao efetuar uma pesquisa por indices bitmap. Em geral, podese criar um indice
em cada coluna que cubra as condies da query e na maioria dos casos o PostgreSQL ir
fazer uso dos mesmos, logo necessrio fazer uma verificao do custo e justificar a razo
da criao do indice multicoluna antes de o usar. Este tipo de indices tem um custo e este
tipo de indexao s optimiza queries que referenciam as colunas pela mesma ordem do
indice.
4.4. Unique Indexes
Os unique indexes garantem que a tabela no tem mais de um indice com o mesmo
valor. Este tipo de ndice til por duas razes: integridade dos dados e rendimento do
tempo das consultas. Os lookups sobre um unique index so geralmente bastante rpidos.
Apenas as btrees garantem que os indices so unicos, este tipo de indice pode ser
instanciadosobreumatabeladaseguinteforma:
CREATEUNIQUEINDEXnameONtable(column[,...])
4.5. ANALYZE E EXPLAIN
Nem sempre os indices gero as melhores estatisticas de performance desejadas
para as consultas sobre o SGBD, pelo que aconselhavel efectuar o comando ANALYZE
apsacriaodoindice.
O comando ANALYZE gera estatsticas sobre os contedos das tabelas do SGBD e
armazena os resultados no sistema catalogao. Esta estatstica utilizada pelo query
plannerdeformaadeterminarosplanosdeexecuomaiseficazes.
ANALYZE[VERBOSE][tabela[(columna[,...])]]
De modo identico, conveniente usar o comando ANALYZE quando um indice
eliminado, evitando desta forma que o query planner tenha em conta este indice em
consultas futuras.Para cada consulta possivel saber as operaes que o SGBD efectua
internamenteparaobteroresultadofinal,atravsdocomandoEXPLAIN.
EXPLAINquery
O comando EXPLAIN devolve o plano de execuo para a query em questo. O
plano de execuo composto pelo nmero de tuplos em disco, a cardinalidade das
operaeseosalgoritmosdejunoepesquisausados.
4.6. Oracle vs PostgreSQL
A grande diferena entre Oracle e PostgreSQL na indexao a incorporao dos
indicesGINeGiST,quenoexistemnoOracle.
14
5. Processamento e Optimizao de Perguntas
5.1 Planner
O planner existe com o objectivo de encontrar o plano de execuo de uma query
com o menor custo possvel. Para tal, o planner precisa ter em conta o tempo de execuo
de cada operao que resulta do algoritmo escolhido, nmero de entradas da tabela e da
ordemdeexecuodasoperaoexistentesnumaquery.
Existe assim a necessidade do SGBD de guardar alguma informao extra sobre as
tabelas da base de dados. Para tal o SGBD guarda, numa tabela chamada pg_class, uma
estimativa do nmero de entradas de cada tabela, nmero de entradas dos respectivos
indexes e o nmero de disk blocks ocupados por cada tabela e index. Esta informao
guardanosatributosreltupleserelpages.
Como exemplo, imaginese uma base de dados que contm uma tabela chamada
tenk1 e que sobre esta tabela existem os indexes tenk1_hundred, tenk1_thous_tenthous,
tenk1_unique1, tenk1_unique2 que foram criados para diferentes consultas feitas a esta
tabela.Podeseentofazeraseguinteconsulta:
SELECTrelname,relkind,reltuples,relpages
FROMpg_class
WHERErelnameLIKEtenk1%
Esta consulta mostranos o contedo da tabela pg_class com os dados da tabela
tenk1erespectivosindexes:
relname relkind reltuples relpages
tenk1 r 10000 358
tenk1_hundred i 10000 30
tenk1_thous_tenthous i 10000 30
tenk1_unique1 i 10000 30
tenk1_unique2 i 10000 30
No entanto, tendo em conta que maioria das consultas tm uma clusula where,
estas retornam s uma fraco dos tuplos existentes na tabela. Assim sendo, o planner
precisa de uma estimativa do nmero de entradas que obtm com uma clusula where.
Esta informao guardada na tabela pg_statistic. No entanto, aquando da necessidade de
obter a informao desta tabela, o SGBD consulta antes a vista pg_stats visto que
pg_statistic s pode ser lida por um superuser e pg_stats pode ser lida por todos os
utilizadores.
15
Exemplo:
SELECTattname,inherited,n_distinct,
array_to_string(most_common_vals,E\n)asmost_common_vals
FROMpg_stats
WHEREtablename=road
attname inherited n_distinct most_common_vals
name f 0.363388 I580Ramp+
I880Ramp+
SpRailroad+
I580+
I680Ramp
name t 0.284859 I880Ramp+
I580Ramp+
I680Ramp+
I580+
StateHwy13Ramp
5.2 Consultar planos de execuo
O PostgreSQL fornece dois comandos que permitem ao utilizador consultar o plano
de execuo que so criados para uma dada consulta. Estes comandos so o EXPLAIN e
EXPLAINANALYZE.
5.2.1 EXPLAIN
Aestruturadeumplanodeexecuopodeservistacomoumarvoreemqueos
nssochamadosplannodeseosnsdoltimonvelsochamadosdescannodes.Por
normaestesscannodesretornamtuplosdatabela.Osscannodespodemserdediferentes
tiposdependendodosmtodosdeacesso,sendoeles:sequentialscans,indexscanse
bitmapindexscans.
OresultadodocomandoEXPLAINcorrespondervoredoplanodeexecuoem
quecadalinhacorrespondeaumnequeindicaotipodonerespectivocusto.Aprimeira
linhamostraovalortotaldocustodoplanodeexecuo.Exemplo:
EXPLAINSELECT*FROMtenk1
QUERYPLAN:

SeqScanontenk1(cost=0.00..458.00rows=10000width=244)
16
Osnmerosapresentadosemparntesisso,daesquerdaparaadireita:
1. Custodearranque,estimado
2. Custototal,estimado
3. Nmerodetuplos,estimado
4. Tamanhodetuplos,embytes,estimado
5.2.2 EXPLAIN ANALYZE
O comando EXPLAIN com a opo ANALYZE mostra a preciso das estimativas do
planner. Neste caso o comando executa a query e mostra o nmero real de tuplos e o
tempo real de execuo de cada plan node e no final mostra o tempo total de execuo.
Exemplo:
EXPLAINANALYZESELECT*
FROMtenk1t1,tenk2t2
WHEREt1.unique1<10ANDt1.unique2=t2.unique2
QUERYPLAN

NestedLoop(cost=4.33..118.25rows=10width=488)(actualtime=0.370..1.126rows=10
loops=1)
>BitmapHeapScanontenk1t1(cost=4.33..39.44rows=10width=244)(actual
time=0.254..0.380rows=10loops=1)
RecheckCond:(unique1<10)
>BitmapIndexScanontenk1_unique1(cost=0.00..4.33rows=10
width=0)(actualtime=0.164..0.164rows=10loops=1)
IndexCond:(unique1<10)
>IndexScanusingtenk2_unique2ontenk2t2(cost=0.00..7.87rows=1width=244)
(actualtime=0.041..0.048rows=1loops=10)
IndexCond:(unique2=t1.unique2)
Totalruntime:2.414ms
OcomandoEXPLAINtemaindaumaopoBUFFERSquepodeserusada
juntamentecomANALYZEequemostramaisestatsticas:
EXPLAIN(ANALYZE,BUFFERS)SELECT*FROMtenk1WHEREunique1<100AND
unique2>9000
QUERYPLAN

BitmapHeapScanontenk1(cost=25.07..60.23rows=10width=244)(actual
17
time=3.069..3.213rows=10loops=1)
RecheckCond:((unique1<100)AND(unique2>9000))
Buffers:sharedhit=16
>BitmapAnd(cost=25.07..25.07rows=10width=0)(actualtime=2.967..2.967
rows=0loops=1)
Buffers:sharedhit=7
>BitmapIndexScanontenk1_unique1(cost=0.00..5.02
rows=102width=0)(actualtime=0.732..0.732rows=200loops=1)
IndexCond:(unique1<100)
Buffers:sharedhit=2
>BitmapIndexScanontenk1_unique2(cost=0.00..19.80
rows=1007width=0)(actualtime=2.015..2.015rows=1009loops=1)
IndexCond:(unique2>9000)
Buffers:sharedhit=5
Totalruntime:3.917ms
5.3 Parsing da query
Uma das fases do processamento de uma query passa pelo parsing desta. Para tal
o parser recebe a query em ASCII e valida a sintaxe da mesma. Caso a sintaxe esteja
correcta, o parser retorna uma rvore, caso contrrio lana erro. O parser e o lexer so
implementadoscomferramentasdeUnix:bisoneex.
O lexer responsvel por reconhecer comandos SQL e por cada comando
reconhecido entregao ao parser. O parser por sua vez dispara uma aco por cada
comandoeestaacoexecutadaemC.
5.4 Optimizar os planos de execuo
5.4.1 Operao SELECT
Quando o planner recebe uma consulta SELECT comea por fazer scan a cada
tabela usada na query. Um scan sequencial sempre creado, independentemente da
consulta. Caso a consulta contenha uma clusula WHERE relation.attribute OPR constant
em que a tabela contenha um indce em que a chave seja relation.attribute ento um scan
criado para este ndice. Este processo repetese at no haver mais ndices que
correspondam ao atributo e operao da consulta. No fim do processo, o plano com
melhorestemposescolhidoparaexecuo.
5.4.2 Operao ORDER BY
UmindexscancriadotambmnocasodaconsultaterumaclusulaORDERBY
emqueoatributodeordenaocorrespondaaoatributoqueordenaoindce.
5.4.3 Operao JOIN
18
Quandoaconsultanecessitadeexecutarajunoentreduasoumaistabelas,so
criadosscansapsacriaodescansparatabelasindividuais.Ajunoentretabelaspode
serfeitacomumdostrsalgoritmos.
Nested Loop Join
criadoumscanparaarelaodadireitaparacadatuploencontradonarelaoda
esquerda.Estealgoritmoapesardefcildeimplementarpodesercaroemtermosde
complexidadetemporal.Noentanto,searelaodadireitapudercriarumindexscanesta
situaopodertornarsevantajosa.
Merge Join
Cada relao ordenada pelos atributos da juno antes da operao de juno ser
executada. Assim so criados dois scans paralelos para as duas relaes e os tuplos em
comum so seleccionados para criar o resultado da juno. Este algoritmo tornase mais
agradvelqueoanteriortendoemcontaquecriadosumscanporcadarelao.
Hash Join
criado um scan para a relao da direita de modo a carregar esta para uma hash
table usando os atributos da juno como chave. De seguida criado um scan para a
relao da esquerda e os tuplos encontrados so usados como chaves para encontrar os
tuploscorrespondentesdarelaodadireita.
5.5 Genetic Query Optimizer
OcomportamentonormalqueoPostgreSQLtemperanteajunodetabelaspode
serextremamentecaroemtermosdetempoeespaoseonmerodetabelasenvolvidas
formuitoelevado.Assimsendo,esteSGBDcriouumaalternativaparaaoptimizaode
junes,sendoestaalternativeumalgoritmogenticoquetratadeumaquerycomjuno
demuitastabelaseficientemente.
5.5.1 Algoritmo Gentico
Este algoritmo consiste numa heurstica de optimizao que executa uma pesquisa
aleatria. O conjunto de planos de execues possveis para a optimizao do problema so
vistos como indivduos de uma populao. A aptido do indivduo especifica a sua
capacidade de adaptao ao ambiente. Os cromossomas representam as coordenadas do
indivduo no espao de procura. Um gene a subsequncia de cromossomas que
codificam o valor do parametro a optimizar. Com estes parametros feita a simulao da
evoluodestesindivduosdemodoaencontraromelhorindivduodapopulao.
19
5.6 Parametrizao
Tendo em conta que o PostgreSQL no garante que encontre sempre um plano de
execuo ptimo para uma consulta, este SGBD permite parametrizar esta optimizao
comasseguintesopes:
enable_bitmapscan(boolean)permiteounoacriaoplanosdotipobitmapscan
enable_hashagg(boolean)permiteounoousodeagregaoporhashing
enable_hashjoin(boolean)permiteounoousodeplanosdotipohashjoin
enable_indexscan(boolean)permiteounoousodeplanosdotpoindexscan
enable_indexonlyscan(boolean)permiteounoousodeplanosdotipo
indexonlyscan
enable_material(boolean)permiteounoousodematerializao
enable_mergejoin(boolean)permiteounoousodeplanosdotipomergejoin
enable_nestloop(boolean)permiteounoousodeplanosdotiponestedloopjoin
enable_seqscan(boolean)permiteounoousodeplanosdotiposeqscan
enable_sort(boolean)permiteounoousodeordenao
enable_tidscan(boolean)permiteounoousodeplanosdotipoTIDscan
5.7 Comparao com Oracle
AoptimizaodequeriesemOracleempoucodiferentedoprocedimentoem
PostgreSQL.Noentanto,aocontrriodePostgreSQLquepodernemsempreencontraro
planoptimo,Oracleescolhesempreoplanoqueconsomemenosrecursosepermite
tambmparametrizarocomportamentodooptimizador.Resumidamente,emOracle
quandorecebidaumaqueryooptimizadorsegueosseguintespassos:
1. DiversosplanossocriadosbaseadosnasoperaesSQLeconfiguraesdo
optimizador
2. feitaaestimativadostemposdecadaplano,baseadanosdadosdaestruturado
SGBDqueguardaasestatsticasdoacessoaosdados
3. Ovalordocustoestimadoatravsdostemposdecadaplanoedosrecursosdo
computadorqueconsomem
4. Planossequenciais,apesardemaisdemorados,sotidosemcontapara
processamentoparalelodasconsultas
5. Ooptimizadorcomparaoscustosobtidoseescolheoquetivermenorcusto.
20
6. Gesto de transaces e controlo de concorrncia
6.1 Transaces.
NoPostgreSQLpossvelespecificartransaesatravsdosseguintescomandos:
BEGIN usado para indicar expressamente o incio de uma transaco. Todas as
instrues de BEGIN devem ser feitas correctamente para serem gravadas de forma
permanente. No caso de haver um erro, a transao inteira falha e as mudanas no sero
aplicadas. O PostgreSQL usa um BEGIN implcito em cada instruo se no for includo
explicitamente.
COMMIT usado para gravar as alteraes feitas numa transao de forma
permanente. Depois de executar este comando, as alteraes feitas na transao so
escritas de forma permanente e tornamse visveis para outras transaes concorrentes na
base de dados. O PostgreSQL usa um COMMIT implcito em cada instruo, se no for
declaradoexplicitamente.
ROLLBACK usado para descartar todas as operaes numa transao. Quando
uma transao falha uma das suas operaes, feito um ROLLBACK. Quando este
comandoexecutado,todasasalteraesefectuadaspelatransacosorevertidas.
SAVEPOINT utilizado para definir os pontos de controlo de uma transao.
Algumas das operaes, devido sua complexidade, podem ter um elevado nmero de
instrues. O mecanismo de SAVEPOINT ajuda a dividir as instrues da transaco, o que
facilita o ROLLBACK at ao SAVEPOINT caso a transao d erro nas instrues
seguintes.
ROLLBACK TO usado para reverter as alteraes feitas aps um SAVEPOINT.
Depois de definir um SAVEPOINT podese voltar para esse ponto usando o comando
<nome_savepoint> ROLLBACKTO. Todas as alteraes feitas aps <nome_savepoint>
serodescartadasenoserovisiveisdepoisdeexecutarocomandodeCOMMIT.
O PostgreSQL no tem suporte para nested transactions e para transaes de longa
durao. Acrescentando a coluna xact_start para pg_stat_activity torna a identificao de
transacesdelongaduraomaisfcil.
6.2 Que protocolo usado para garantir isolamento
Para garantir isolamento, o PostgreSQL utiliza o protocolo multiversion concorrency
control, MVCC. A principal diferena entre o multiversion e o lock que em locks MVCC
derivados de uma consulta de dados (leitura) no entram em conflitos com locks derivados
da gravao de dados e leitura, portanto, nunca bloqueiam a escrita, e a escrita nunca
21
bloqueiaaleitura.
O PostgreSQL fornece vrios tipos de locks para controlar o acesso simultneo aos
dados nas tabelas. Estes locks podem ser utilizados para o bloqueio controlado em
situaes que o MVCC no der o comportamento desejado. Para navegar por listas de locks
emcirculao,podeserusadaaviewdosistemapg_locks.
6.3 Deadlocks
Para lidar com DEADLOCKS, o PostgreSQL detecta automaticamente as situaes
de impasse, resolvendoas ao interromper uma das transaes envolvidas, permitindo que a
outrasejaconcluda.
6.4 Nveis de granularidade dos locks
A lista em baixo mostra os tipos de locks disponiveis e em que contextos so usados
automticamente pelo PostgreSQL. Os locks tambm podem ser obtidos explicitamente
atravsdocomandoLOCK.
AccessShareLock
EmconflitocomomododebloqueioACCESSEXCLUSIVE.
O comando SELECT obtm um bloqueio neste modo nas tabelas referenciadas. Em
geral,issoqualquerdvidaslumamesaenomodificlaobtmestemododebloqueio.
RowShareLock
ConflitoscomosmodosdebloqueioEXCLUSIVEeACCESSEXCLUSIVE.
O SELECT FOR UPDATE e SELECT para comandos AO adquirir um bloqueio
neste modo na tabela de destino (s) (alm de bloqueio ACCESS SHARE nas outras tabelas
referenciadasmasnoselecionadasFORUPDATE/FORSHARE).
RowExclusiveLock
ConflitoscomaSHARE,SHAREROWEXCLUSIVEmodos,exclusivoeacesso
bloqueioexclusivo.
Os comandos UPDATE, DELETE e INSERT obtm este modo de bloqueio na tabela
dedestino(almdobloqueioACCESSSHAREnasoutrastabelas referenciadas).
Em geral, este modo de bloqueio ser adquirido por qualquer comando que modifica os
dadosemumatabela.
ShareLock
Conflitos com a quota de atualizao exclusiva, SHARE, SHARE ROW EXCLUSIVE,
EXCLUSIVE e ACCESS modos de bloqueio EXCLUSIVE. Este modo protege a tabela contra
alteraesnoesquemasimultneoseexecuodocomandoVACUUM.
22
Adquirida por vcuo (sem o FULL), analisar, CREATE INDEX ao mesmo tempo, e
algumasformasdeALTERTABLE.
ShareRowExclusiveLock
Conflitos com o ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE
ROW EXCLUSIVE, EXCLUSIVE e ACCESS modos de bloqueio EXCLUSIVE. Este modo
protege a tabela contra alteraes de dados simultneos, e autoexclusivo, para que
apenasumasessopodeprendlodeumavez.
Este modo de bloqueio no obtido automaticamente por nenhum comando do
PostgreSQL.
ExclusiveLock
ConflitoscomaSHAREROW,ROWEXCLUSIVE,SHAREUPDATE
EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE e ACCESS modos de
bloqueio EXCLUSIVE. Este modo permite apenas bloqueios simultneos compartilhar o
acesso, ou seja, somente leituras da tabela podem prosseguir em paralelo com uma
transaoqueobteveestemododebloqueio.
Este modo de bloqueio no obtido automaticamente em tabelas por nenhum
comandodoPostgreSQL.
AccessExclusiveLock
Conflitos com fechaduras de todos os modos (ACCESS SHARE, SHARE ROW,
ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
EXCLUSIVE e ACCESS EXCLUSIVE). Este modo garante que o titular a nica operao
deacessotabeladequalquerforma.
Adquirido pela ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, e
os comandos VACUUM FULL. Este tambm o modo de bloqueio padro para o comando
LOCKTABLEnoespecificarummodoexplicitamente.
Bloqueios ao nvel da fila
Os bloqueios no nvel de linha pode ser bloqueios compartilhados ou exclusivos. Um
bloqueio exclusivo no nvel de linha em uma linha especfica obtido automaticamente
quando a linha atualizada ou excluda. O bloqueio mantido at que a transao
confirmada ou revertida como bloqueios no nvel de tabela. Bloqueios no nvel de linha no
afetamaconsultadedados,masapenasoblocodosescritoresnamesmalinha.
Bloqueios ao nvel da page
Alm dos bloqueios de tabela e de linha, em nvel de pgina share / exclusivo
bloqueios so usados para controlar a ler / escrever acesso a pginas da tabela no buffer
pool compartilhado. Esses bloqueios so libertados imediatamente aps a linha ser lida ou
23
actualizada.
6.5 Nveis de isolamento.
No PostgreSQL voc pode encomendar qualquer um dos quatro nveis de isolamento
padro SQL e apoiado sintaticamente, mas apenas trs dos que atuam internamente no
PostgreSQL:ReadCommitted,LeituraRepetida,Serializable.
READ COMMITTED
A declarao s pode ver as linhas efetivadas antes de comear. Esta a
configuraopadro.
REPEATABLE READ
Todos os comandos da transao corrente enxerga apenas as linhas efetivadas
antes da primeira consulta ou instruo de modificao de dados so executadas nesta
transao.
SERIALIZABLE
Todos os comandos da transao corrente enxerga apenas as linhas efetivadas
antes da primeira consulta ou instruo de modificao de dados so executadas nesta
transao. Se um padro de leitura e escrita entre transaes serializveis concorrentes
criaria uma situao que no poderia ter acontecido para alguns (um de cada vez) execuo
serial destas operaes, podese desfazer um erro serialization_failure. Transaes
serializveis so apenas REPEATABLE READ operaes que adicionar monitoramento
nonblockingparaospadresperigososdeleitura/gravaodeconflitos.
O nvel adicional, READ UNCOMMITTED, definido no padro SQL tratado como
READCOMMITTED.
Podemosdefinirdaseguinteforma:
SETTRANSACTIONtransaction_mode[,...]
SETTRANSACTIONSNAPSHOTsnapshot_id
SETSESSIONCHARACTERISTICSASTRANSACTIONtransaction_mode[,...]
ondeatransaction_modeumdoscomandosseguintes:
ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED
|READUNCOMMITTEDREADWRITE|READONLY
24
[NOT]DEFERRABLE
6.6 Como lida com consistncia.
O problema lidando com consistncia quando estamos no nvel de isolamento
padro ciclos aparcin, quando um ciclo aparece, verificaes de integridade no iro
funcionar corretamente sem alguma ajuda, entao quando um padro detectado o que
poderia causar um ciclo na ordem aparente de execuo, uma das transaes envolvidas
revertidaparaquebrarociclo.
6.7 Como lida com atomicidade e durabilidade.
Atomicidade
No PostgreSQL, podemos obter um conjunto de instrues SQL executadas dentro
de uma transao, abrangendo entre BEGIN e COMMIT. Isto assegura que corre tudo ou
nada. Se chegar em algum ponto dentro da transao precisa desfazer completamente, use
ROLLBACK em vez de COMMIT, e todas as alteraes so desfeitas. Por outro lado,
qualquer frase PostgreSQL isolado como se ele estivesse sendo executado dentro de uma
pequena operao, mas no use BEGIN, cada instruo implicitamente incorpora BEGIN e,
seforbemsucedida,aCOMMIT.
Durabilidade
PostgreSQL usa uma tcnica padro chamada WAL (writeahead logging ou
writeahead registos) para controlar tanto a consistncia e durabilidade das transaes.
Resumidamente explicando, que as mudanas em arquivos de dados (tabelas e ndices)
s se materializam quando l anteriormente na pista difcil em que tais mudanas so
observadas. Seguindo este procedimento, necessrio enviar pginas com o disco de cada
vez que uma transaco completada. Esta tcnica no s melhora o desempenho do
servidor, mas a uma falha da mquina, possvel recuperar o banco de dados de registo
que, qualquer alterao no aplicada s pginas de dados no disco ser novamente feita a
partir do registo (rolo forward de recuperao, ou refazer), enquanto que as possveis
alteraes nas pginas de disco transaes incompletas pode ser desfeita a manuteno
daintegridadeeconsistnciadedados(recuperaorollparatrs,oudesfazer).
6.8 Oracle vs PostgreSQL
Sobre o assunto de transaces, ambos os programas so muito semelhantes, pois
ambos so muito completos e no h nenhuma diferena notvel, s que PostgreSQL tem
maisLocksModesqueOraclemasnoumadiferenamuitosignificativa.
25
7. Suporte para bases de dados distribudas
OPostgreSQLnoapresentasuporteparabasededadosdistribudas.
26
8. Outras caractersticas do sistema estudado
8.1. Suporte para a WEB
Para suporte WEB est disponivel a ferramenta phpPgAdmid. PhpPgAdmin uma
aplicao site que prev uma maneira conveniente aos clientes de criar bases de dados,
tabelas, as alterar e consultar seus dados usando a linguagem regular SQL. O PhpPgAdmin
baseado na ferramenta phpMyAdmin, mas hoje em dia j no compartilha cdigo com esta
aplicao. Esta ferramenta usa as mesmas funcionalidades da sua congnere e dispem
demaisfuncionalidadesadaptadasparaosistemadebasededadosPostgreSQL.
8.2. Suporte para XML
O PostgreSQL dispe de suporte nativo a XML, que pode ser utilizado para manter
tabelas. Tambm permite importar e exportar documentos em XML. O PostgreSQL s
compatvelactualmentecomXPath,queumsubconjuntodoXQuery.
8.3. Stored procedures
Uma stored procedure armazenada no PostgreSQL pode ser escrita em diversas
linguagens de programao. A instalao por defeito do PostgreSQL dispe das seguintes
linguagens: PL/pgSQL, PL/Perl, PL/Tcl e PL/Python. A nica linguagem que est disponvel
automaticamente PL/pgSQL. Para utilizar o PL/Perl, PL/Tcl ou PL/Python necessrio
configurarocompiladordoPostgreSQLcomosseguintesparmetros:
withperlwithtclwithpython
8.4.Triggers e Fornecimento de Servios
PostgreSQL dispe da utilizao de triggers, para o seu uso existem os seguintes
comandos:
CREATE[CONSTRAINT]TRIGGERname{BEFORE|AFTER|INSTEADOF}{event[OR...]}
ONtable[FROMreferenced_table_name]
{NOTDEFERRABLE|[DEFERRABLE]{INITIALLYIMMEDIATE|INITIALLYDEFERRED}}
[FOR[EACH]{ROW|STATEMENT}]
[WHEN(condition)]
EXECUTEPROCEDUREfunction_name(arguments)
OPostgreSQLtambmproporcionaosserviosdeJDBCeODBC.
27
8.5. Segurana
Interna
A extenso da sepgsql (dotada de PostgreSQL desde a verso 9.1) proporciona uma
capa adicional de segurana integrando com SELinux. Isto utiliza a caracterstica de
seguranaetiquetadePostgreSQL.
Externa
O PostgreSQL suporta de forma nativa um amplo nmero de mecanismos de
autenticao:
Trust
Password(MD5outexto)
GSSAPI
SSPI
Kerberos
ident (mapas S/O de nome de utente proporcionado por um servidor ident a nome de
utentedobasededados)
peer(nomedeutentelocaldemapasanomedeutentedebancodedados)
LDAP
RADIUS
Certificate
PAM
O GSSAPI, SSPI, Kerberos, peer, ident e certificate tambm podem utilizar um
arquivo especificado por map que mostra que os utentes de certificado igualada por que o
sistema de autenticao tem permisso para ligar como um utente de base de dados
especfico.
8.6. Tipo de dados suportados
Integer:BIGINT,INTEGER,SMALLINT.
FloatingPoint:DOUBLEPRECISION,REAL.
Decimal:DECIMAL,NUMERIC.
String:CHAR,CHARACTER,CHARACTERVARYING,TEXT,VARCHAR.
Boolean:BOOLEAN.
Binary:BYTEA.
Date/Time:DATE,INTERVAL,TIME,TIMESTAMP.
28
Outros: ARRAYS, BIT, CIDR, CIRCLE, ENUM, GIS data types, INET, MACCADDR,
MONETARY, PATH, POLYGON, SEQUENCE, TIMESTAMP, USER DEFINED DATA
TYPES,USERDEFINEDTYPES,UUID,XML,XMLTYPE.
8.7. Ferramentas
Psql O principal frontend para PostgreSQL um programa que corre sobre a
consola, pode ser utilizado para efectuar consultas SQL de forma directa, ou executar
operaesapartirdeumficheiro.
pgAdmin ferramenta gratuita e open source de administrao de interfaces
grficasparaPostgreSQL,compatvelcominmerossistemasoperativos.
phpPgAdmin aplicao web de administrao de bases de dados PostgreSQL,
escrita em PHP e baseada na interface do phpMyAdmin, uma aplicao web para a
administraodebasesdedadosMySQL.
pgFouine log analyzer que gera anlises e relatrios detalhados de arquivos de
registodoPostgreSQL.
MADlib uma biblioteca de anlise de cdigo aberto para PostgreSQL prever
mtodos matemticos, estatsticos e de aprendizagem mquina estruturados e dados no
estruturados.
Assistente de migrao de MySQL includo com o instalador de PostgreSQL de
EnterpriseDB.(cdigofontedisponveltambm)
Performance Wizard includo com o instalador de PostgreSQL de EnterpriseDB.
(cdigofontedisponveltambm)
PostGIS um complemento muito popular que oferece compatibilidade com objectos
geogrficos.
pgRouting PostGIS extendido que proporciona funcionalidades de routing
geoespacial.
Postgres Enterprise Manager uma ferramenta closedsource que consiste num
servio de mltiplos agentes e uma GUI que proporciona monitoring, remote management,
reports,planningetunning.
STLinksSpatialKitextensoparaligarcombasesdedadosespaciais.
29
9. Referncias
The PostgreSQL Global Development Group, PostgreSQL 9.2.4 Documentation,
http://www.postgresql.org/files/documentation/pdf/9.2/postgresql9.2A4.pdf
NikeshJauhari,HowtoInstall/ConfigurePostgreSQLUnderUbuntuLinux
http://linuxpoison.blogspot.tw/2012/01/howtoinstallconfigurepostgresql.html
GregorySmith,PostgreSQLBufferManagement
http://www.westnet.com/~gsmith/gregsmith/content/postgresql/PostgreSQLBufferManagem
ent.htm
Oracle,OracleDatabase2DayDBA11gRelease1(11.1)
http://docs.oracle.com/cd/B28359_01/server.111/b28301.pdf
ComparisonOraclevsPostgreSQL
http://databasemanagementsystems.findthebest.com/compare/3643/OraclevsPostgreSQL
WikiofPostgreSQL
http://wiki.postgresql.org/wiki/Main_Page
30

Vous aimerez peut-être aussi