Dados do tipo data e hora apresentam muitas variações de formatação. Para o usuário as datas se apresentam como campos textuais, mas para o SGBD, são tipos de dados específicos, com características próprias, representando valores temporais. Para trabalhar com valores deste tipo, os sistemas fazem frequentemente conversões entre esses dois tipos.
Este post apresenta o uso das funções TO_DATE e TO_CHAR para formatar e tratar datas e horas.
* TO_CHAR - Formatando campos do tipo data para texto.
- Exemplo 1: Formatação padrão
postgres=# SELECT TO_CHAR(current_date, 'DD-MM-YYYY');
to_char
------------
17-06-2013
(1 registro)
- Exemplo 2: Formatação padrão utilizando o separador "/"
postgres=# SELECT TO_CHAR(current_date, 'DD/MM/YYYY');
to_char
------------
17/06/2013
(1 registro)
- Exemplo 3: Alterando a ordem de visualização do mês, dia e ano apresentados.
postgres=# SELECT TO_CHAR(current_date, 'DD-MM-YYYY'), TO_CHAR(current_date, 'MM-DD-YYYY'), TO_CHAR(current_date, 'YYYY-MM-YY');
to_char | to_char | to_char
------------+------------+------------
17-06-2013 | 06-17-2013 | 2013-06-13
(1 registro)
- Exemplo 4: Separando mês, dia e ano em campos distintos.
postgres=# SELECT TO_CHAR(current_date, 'DD') AS DIA, TO_CHAR(current_date, 'MM') AS MES, TO_CHAR(current_date, 'YYYY') AS ANO;
dia | mes | ano
-----+-----+------
17 | 06 | 2013
(1 registro)
- Exemplo 5: Apresentando o mês e o dia por extenso.
postgres=# SELECT TO_CHAR(current_date, 'DAY') AS DIA, TO_CHAR(current_date, 'MON') AS MES;
dia | mes
-----------+-----
MONDAY | JUN
(1 registro)
- Exemplo 6: Apresentando a hora do sistema formatada.
postgres=# SELECT TO_CHAR(current_timestamp, 'HH24:MI:SS');
to_char
----------
07:29:13
(1 registro)- Exemplo 7: Separando hora, minuto e segundos em camops distintos.
postgres=# SELECT TO_CHAR(current_timestamp, 'HH24'), TO_CHAR(current_timestamp, 'MI'), TO_CHAR(current_timestamp, 'SS');
to_char | to_char | to_char
---------+---------+---------
07 | 29 | 13
(1 registro)
- Exemplo 8: Usando TO_CHAR para inserção e atualização de dados.
postgres=#
postgres=# CREATE TABLE char_date_tst (momento varchar(10));
CREATE TABLE
postgres=# INSERT INTO char_date_tst (momento) VALUES (TO_CHAR(current_date, 'MM-DD-YYYY'));
INSERT 0 1
postgres=# UPDATE char_date_tst SET momento = '01-05-2010' WHERE momento = TO_CHAR(current_date, 'MM-DD-YYYY');
UPDATE 1
postgres=# SELECT * FROM char_date_tst;
momento
------------
01-05-2010
(1 registro)* TO_DATE - Formatando campos do tipo texto para data.
- Exemplo 1: Usando TO_DATE para data em formato DD-MM-YYYY.
postgres=# SELECT TO_DATE('30-04-2010', 'DD-MM-YYYY');
to_date
------------
2010-04-30
(1 registro)
- Exemplo 2: Usando TO_DATE para data em formato MM-DD-YYYY.
postgres=# SELECT TO_DATE('04-30-2010', 'MM-DD-YYYY');
to_date
------------
2010-04-30
(1 registro)
- Exemplo 3: Usando TO_DATE para data com separador "/"
postgres=# SELECT TO_DATE('04/30/2010', 'MM/DD/YYYY');
to_date
------------
2010-04-30
(1 registro)
- Exemplo 4: Teste de igualdade entre datas de formatos distintos usando TO_DATE.
postgres=# SELECT TO_DATE('04-30-2010', 'MM-DD-YYYY') = TO_DATE('30-04-2010', 'DD-MM-YYYY') AS IGUALDADE;
igualdade
-----------
t
(1 registro)
- Exemplo 5: Usando TO_DATE para inserção e atualização de dados.
postgres=# CREATE TABLE date_tst (momento date);
CREATE TABLE
postgres=# INSERT INTO date_tst VALUES (TO_DATE('04-30-2010', 'MM-DD-YYYY'));
INSERT 0 1
postgres=# UPDATE date_tst SET momento = momento + 1 WHERE momento = TO_DATE('04-30-2010', 'MM-DD-YYYY');
UPDATE 1
postgres=# SELECT * FROM date_tst;
momento
------------
2010-05-01
(1 registro)* Considerações Finais
Os exemplos acima não cobrem todas as possibilidades, mas podem ajudar nas principais operações que lidem com a formatação de datas e horas no postgresql. A cláusula CAST é uma alternativa para conversão entre estes tipos de dados, mas não realiza formatações sobre os mesmos.
Fonte:
http://postgresqlbr.blogspot.com.br/2013/06/formatacao-de-data-e-hora-com-as.html
Conteúdo do cotidiano e gratuito de tecnologia em Banco de dados, Servidores Windows, Linux, BSD e Desenvolvimento em PL/SQL.
quinta-feira, 26 de dezembro de 2013
[PostgreSQL] - Os Comandos BEGIN, COMMIT e ROLLBACK
O comando BEGIN inicia um bloco de comandos SQL que fazem parte de uma transação. Os comandos realizados após o este comando só são persistidos em disco e seus resultados só são apresentados aos demais usuários do banco após a efetivação com o comando COMMIT.
A transação é finalizada pelo comando COMMIT, o qual dispara a efetivação da transação no banco de dados e torna visível para os demais usuários os resultados da execução dos seus comandos.
O comando ROLLBACK aborta a transação que está em andamento, impedindo que os as alterações nos dados nela realizadas sejam persistidos no banco de dados.
Sintaxe:
BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ]
onde o transaction_mode é um dos listados abaixo:
ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }
READ WRITE | READ ONLY
Obs.: os transaction modes serão discutidos em maior profundidade ao se detalhar o comando SET TRANSACTION.
COMMIT [ WORK | TRANSACTION ]
ROLLBACK [ WORK | TRANSACTION ]
Exemplos:
1 - Sintaxe mais simples com BEGIN e COMMIT
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
insert into tstdel values (2,'teste2', current_timestamp);
SELECT * FROM tstdel;
COMMIT;
2 - Sintaxe mais simples com BEGIN e COMMIT. A cláusula WORK não tem efeito é é mantida por compatibilidade.
BEGIN WORK;
insert into tstdel values (1,'teste', current_timestamp);
insert into tstdel values (2,'teste2', current_timestamp);
SELECT * FROM tstdel;
COMMIT WORK;
3 - Sintaxe mais simples com BEGIN e COMMIT. A cláusula TRANSACTION não tem efeito é é mantida por compatibilidade.
BEGIN TRANSACTION;
insert into tstdel values (1,'teste', current_timestamp);
insert into tstdel values (2,'teste2', current_timestamp);
SELECT * FROM tstdel;
COMMIT TRANSACTION;
4 - A transação abaixo é abortada com o ROLLBACK. A inserção realizada não é gravada no banco de dados.
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
ROLLBACK;
5 - A transação abaixo é abortada com o ROLLBACK. A inserção realizada não é gravada no banco de dados. A cláusula WORK não tem efeito e é mantida por compatibilidade.
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
ROLLBACK WORK;
6 - A transação abaixo é abortada com o ROLLBACK. A inserção realizada não é gravada no banco de dados. A cláusula TRANSACTION não tem efeito e é mantida por compatibilidade.
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
ROLLBACK TRANSACTION;
A transação é finalizada pelo comando COMMIT, o qual dispara a efetivação da transação no banco de dados e torna visível para os demais usuários os resultados da execução dos seus comandos.
O comando ROLLBACK aborta a transação que está em andamento, impedindo que os as alterações nos dados nela realizadas sejam persistidos no banco de dados.
Sintaxe:
BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ]
onde o transaction_mode é um dos listados abaixo:
ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }
READ WRITE | READ ONLY
Obs.: os transaction modes serão discutidos em maior profundidade ao se detalhar o comando SET TRANSACTION.
COMMIT [ WORK | TRANSACTION ]
ROLLBACK [ WORK | TRANSACTION ]
Exemplos:
1 - Sintaxe mais simples com BEGIN e COMMIT
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
insert into tstdel values (2,'teste2', current_timestamp);
SELECT * FROM tstdel;
COMMIT;
2 - Sintaxe mais simples com BEGIN e COMMIT. A cláusula WORK não tem efeito é é mantida por compatibilidade.
BEGIN WORK;
insert into tstdel values (1,'teste', current_timestamp);
insert into tstdel values (2,'teste2', current_timestamp);
SELECT * FROM tstdel;
COMMIT WORK;
3 - Sintaxe mais simples com BEGIN e COMMIT. A cláusula TRANSACTION não tem efeito é é mantida por compatibilidade.
BEGIN TRANSACTION;
insert into tstdel values (1,'teste', current_timestamp);
insert into tstdel values (2,'teste2', current_timestamp);
SELECT * FROM tstdel;
COMMIT TRANSACTION;
4 - A transação abaixo é abortada com o ROLLBACK. A inserção realizada não é gravada no banco de dados.
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
ROLLBACK;
5 - A transação abaixo é abortada com o ROLLBACK. A inserção realizada não é gravada no banco de dados. A cláusula WORK não tem efeito e é mantida por compatibilidade.
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
ROLLBACK WORK;
6 - A transação abaixo é abortada com o ROLLBACK. A inserção realizada não é gravada no banco de dados. A cláusula TRANSACTION não tem efeito e é mantida por compatibilidade.
BEGIN;
insert into tstdel values (1,'teste', current_timestamp);
ROLLBACK TRANSACTION;
[PostgreSQL] - Trate com BLOBs e CLOBs Diretamente no PSQL!
Armazenar grandes objetos binários (Binary Large Objects - BLOBs), tais como vídeos, imagens e arquivos PDF, e grandes objetos textuais (Character Large Objects - CLOBs) em um banco de dados é uma atividade que pode apresentar dificuldade maior que a vivenciada em se lidar com tipos de dados tradicionais.
Cada SGBD apresenta sua padronização e o PostgreSQL apresenta seus métodos de armazenamento, exclusão e recuperação de BLOBs e CLOBS. A portabilidade entre SGBDs não costuma ser fácil neste caso.
Um recurso bastante simples para lidar com estes grandes objetos dentro do postgres é disponibilizado de dentro do psql, objeto deste post.
Quatro funções permitem operações sobre large objects, viabilizando a sua criação, recuperação, consulta e exclusão:
- \lo_import ARQUIVO [COMENTÁRIO] - Importa um arquivo do filesystem (levando em conta a search_path) para o postgresql, atribuindo ao mesmo um identificador de objeto (OID) e um comentário, quando fornecido este parâmetro
- \lo_list - Apresenta uma listagem dos objetos binários importados
- \lo_export OIDLOB ARQUIVO - Exporta um BLOB ou CLOB do postgres para o filesystem sem removê-lo do postgresql, referenciando-o pelo seu OID
- \lo_unlink OIDLOB - Elimina um large object do postgresql com base no seu OID.
Abaixo, sem a preocupação de esgotar este tema, a demonstração do tratamento de BLOBs e CLOBs no postgres via psql.
* Listagem de grandes objetos (large objets) armazenados
postgres-# \lo_list
Objetos grandes
ID | Descrição
----+-----------
(0 registro)
* Recuperação dos caminhos da Serch_path, utilizados para recuperar arquivos para o psql
postgres=# SHOW search_path;
search_path
----------------
"$user",public
(1 registro)
* Importação de Arquivos
* Exclusão de arquivo previamente importado
postgres=# \lo_unlink 16401
lo_unlink 16401
postgres=# \lo_list
Objetos grandes
ID | Descrição
-------+-------------
16400 |
16402 | Arquivo PNG
(2 registros)
* Exportação de arquivo do postgresql para o filesystem
postgres=# \lo_import novofile.pdf
lo_import 16403
postgres=# \lo_export 16403 testeexport.pdf (gera o arquivotesteexport.pdf no filesystem)
* Importação de CLOB
postgres=# \lo_import miniclob.txt 'Arquivo CLOB'
lo_import 16405
postgres=# \lo_list
Objetos grandes
ID | Descrição
-------+--------------
16400 |
16402 | Arquivo PNG
16403 |
16404 |
16405 | Arquivo CLOB
(5 registros)
* Considerações Finais
Prefiro trabalhar com large objects no filesystem, ao invés de registrá-los no próprio banco de dados.O acréscimo de mais uma camada reduz a portabilidade e a velocidade de acesso, mas tende a aumentar de certa forma a segurança e a facilitar operações de backup e recovery.
Caso se deseje utilizar este recurso na aplicação, utilizando as funções dentro do SQL, o postgresql apresenta o recurso das Server-Side Functions, bastante similar e que oferece maior controle.
E você, como lida com os seus BLOBs e CLOBs?
Fonte:
http://postgresqlbr.blogspot.com.br/2013/04/trate-com-blobs-e-clobs-diretamente-no.html
Cada SGBD apresenta sua padronização e o PostgreSQL apresenta seus métodos de armazenamento, exclusão e recuperação de BLOBs e CLOBS. A portabilidade entre SGBDs não costuma ser fácil neste caso.
Lidar com Large Objects pode não ser tão trivial!
Um recurso bastante simples para lidar com estes grandes objetos dentro do postgres é disponibilizado de dentro do psql, objeto deste post.
Quatro funções permitem operações sobre large objects, viabilizando a sua criação, recuperação, consulta e exclusão:
- \lo_import ARQUIVO [COMENTÁRIO] - Importa um arquivo do filesystem (levando em conta a search_path) para o postgresql, atribuindo ao mesmo um identificador de objeto (OID) e um comentário, quando fornecido este parâmetro
- \lo_list - Apresenta uma listagem dos objetos binários importados
- \lo_export OIDLOB ARQUIVO - Exporta um BLOB ou CLOB do postgres para o filesystem sem removê-lo do postgresql, referenciando-o pelo seu OID
- \lo_unlink OIDLOB - Elimina um large object do postgresql com base no seu OID.
Abaixo, sem a preocupação de esgotar este tema, a demonstração do tratamento de BLOBs e CLOBs no postgres via psql.
* Listagem de grandes objetos (large objets) armazenados
postgres-# \lo_list
Objetos grandes
ID | Descrição
----+-----------
(0 registro)
postgres=# SHOW search_path;
search_path
----------------
"$user",public
(1 registro)
* Importação de Arquivos
postgres=# \lo_import arqdoc.doc
lo_import 16400 (OID DO NOVO ARQUIVO IMPORTADO)
postgres=# \lo_import arqpdf.doc 'Arquivo Binario PDF'
não pôde abrir arquivo "arqpdf.doc": Arquivo ou diretório não encontrado
postgres=# \lo_import arqpdf.pdf 'Arquivo Binario PDF'
lo_import 16401
postgres=# \lo_import arqpng.png 'Arquivo PNG'
lo_import 16402
postgres=# \lo_list (LISTAGEM DE ARQUIVOS IMPORTADOS)
Objetos grandes
ID | Descrição
-------+---------------------
16400 |
16401 | Arquivo Binario PDF
16402 | Arquivo PNG
(3 registros)
lo_import 16400 (OID DO NOVO ARQUIVO IMPORTADO)
postgres=# \lo_import arqpdf.doc 'Arquivo Binario PDF'
não pôde abrir arquivo "arqpdf.doc": Arquivo ou diretório não encontrado
postgres=# \lo_import arqpdf.pdf 'Arquivo Binario PDF'
lo_import 16401
postgres=# \lo_import arqpng.png 'Arquivo PNG'
lo_import 16402
postgres=# \lo_list (LISTAGEM DE ARQUIVOS IMPORTADOS)
Objetos grandes
ID | Descrição
-------+---------------------
16400 |
16401 | Arquivo Binario PDF
16402 | Arquivo PNG
(3 registros)
* Exclusão de arquivo previamente importado
postgres=# \lo_unlink 16401
lo_unlink 16401
postgres=# \lo_list
Objetos grandes
ID | Descrição
-------+-------------
16400 |
16402 | Arquivo PNG
(2 registros)
* Exportação de arquivo do postgresql para o filesystem
postgres=# \lo_import novofile.pdf
lo_import 16403
postgres=# \lo_export 16403 testeexport.pdf (gera o arquivotesteexport.pdf no filesystem)
* Importação de CLOB
postgres=# \lo_import miniclob.txt 'Arquivo CLOB'
lo_import 16405
postgres=# \lo_list
Objetos grandes
ID | Descrição
-------+--------------
16400 |
16402 | Arquivo PNG
16403 |
16404 |
16405 | Arquivo CLOB
(5 registros)
* Considerações Finais
Prefiro trabalhar com large objects no filesystem, ao invés de registrá-los no próprio banco de dados.O acréscimo de mais uma camada reduz a portabilidade e a velocidade de acesso, mas tende a aumentar de certa forma a segurança e a facilitar operações de backup e recovery.
Caso se deseje utilizar este recurso na aplicação, utilizando as funções dentro do SQL, o postgresql apresenta o recurso das Server-Side Functions, bastante similar e que oferece maior controle.
E você, como lida com os seus BLOBs e CLOBs?
Fonte:
http://postgresqlbr.blogspot.com.br/2013/04/trate-com-blobs-e-clobs-diretamente-no.html
Recuperando Informações de Sessão no PostgreSQL
Qual é o banco de dados corrente? E qual o usuário corrente? Qual é exatamente a versão do postgres que estamos utilizando? Estas informações são úteis para se poder trabalhar com bancos de dados, e são fornecidas por funções informacionais de sessão. Vamos apresentar neste post uma listagem com as funções disponibilizadas no postgres e alguns exemplos de utilização:
* Banco de dados e Esquema
Para recuperar informações de banco de dados e esquema, utilizam-se as funçõescurrent_database(), current_schema() e current_schemas(boolean).
* Informações de Conexão
Permitem a recuperação dedados sobre os servidores e clientes utilizados na conexão, e as portas de comunicação utilizadas. Funções: inet_client_addr(), inet_client_port(), inet_server_addr() einet_server_port().
* Dados do usuário da sessão.
São consultados com as funções sem parênteses current_user, session_user e user.
* Versão do PostgreSQL
---------------------------------------------------------------------------------------------------------
PostgreSQL 9.2.1 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3, 32-bit
(1 registro)
* Recuperando todos os dados da sessão
--------------------------------------------------------------------------------------------------------------------
ESQUEMAS : {pg_catalog,public}
ESQUEMA : public
USER : postgres
SES. USR.: postgres
USUARIO : postgres
VERSAO : PostgreSQL 9.2.1 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3, 32-bit
BANCO : postgres
(8 registros)
Fonte:http://postgresqlbr.blogspot.com.br/2012/11/recuperando-informacoes-de-sessao-no.html
current_database() | name | Nome do banco de dados corrente. |
current_schema() | name | Nome do esquema corrente. |
current_schemas(boolean) | name[] | Nomes dos esquemas no caminho de procura incluindo, opcionalmente, os esquemas implícitos. |
current_user | name | Nome do usuário do contexto de execução corrente. |
inet_client_addr() | inet | Endereço da conexão remota. |
inet_client_port() | int4 | Porta da conexão remota. |
inet_server_addr() | inet | Endereço da conexão local. |
inet_server_port() | int4 | Porta da conexão local. |
session_user | name | Nome do usuário da sessão. |
user | name | Equivalente à função "current_user" |
version() | text | Informações relativas à versão corrente do PostgreSQL |
* Banco de dados e Esquema
Para recuperar informações de banco de dados e esquema, utilizam-se as funçõescurrent_database(), current_schema() e current_schemas(boolean).
Exemplo 1: Dados dos esquemas.
postgres=# SELECT current_database(), current_schema();
current_database | current_schema
------------------+----------------
postgres | public
(1 registro)
current_database | current_schema
------------------+----------------
postgres | public
(1 registro)
Exemplo 2: Caminho de procura com e sem os esquemas implícitos.
postgres=# SELECT current_schemas(true) as SCHEMAS_TODOS, current_schemas(false) AS SCHEMAS_EXPLICITOS;
schemas_todos | schemas_explicitos
---------------------+--------------------
{pg_catalog,public} | {public}
(1 registro)
schemas_todos | schemas_explicitos
---------------------+--------------------
{pg_catalog,public} | {public}
(1 registro)
* Informações de Conexão
Permitem a recuperação dedados sobre os servidores e clientes utilizados na conexão, e as portas de comunicação utilizadas. Funções: inet_client_addr(), inet_client_port(), inet_server_addr() einet_server_port().
Exemplo 3: Informações da conexão corrente.
postgres=# SELECT inet_client_addr(), inet_client_port(), inet_server_addr(), inet_server_port();
inet_client_addr | inet_client_port | inet_server_addr | inet_server_port
------------------+------------------+------------------+------------------
| | |
(1 registro)
inet_client_addr | inet_client_port | inet_server_addr | inet_server_port
------------------+------------------+------------------+------------------
| | |
(1 registro)
* Dados do usuário da sessão.
São consultados com as funções sem parênteses current_user, session_user e user.
Exemplo 4: Dados do usuário e mudança de usuário.
postgres=# SELECT current_user, session_user, user;
current_user | session_user | current_user
--------------+--------------+--------------
postgres | postgres | postgres
(1 registro)
postgres=# SET SESSION AUTHORIZATION 'user1';
SET
postgres=> SELECT current_user, session_user, user;
current_user | session_user | current_user
--------------+--------------+--------------
user1 | user1 | user1
(1 registro)
current_user | session_user | current_user
--------------+--------------+--------------
postgres | postgres | postgres
(1 registro)
postgres=# SET SESSION AUTHORIZATION 'user1';
SET
postgres=> SELECT current_user, session_user, user;
current_user | session_user | current_user
--------------+--------------+--------------
user1 | user1 | user1
(1 registro)
* Versão do PostgreSQL
Exemplo 5: Consulta à versão do postgresql.
postgres=# SELECT version();
version ---------------------------------------------------------------------------------------------------------
PostgreSQL 9.2.1 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3, 32-bit
(1 registro)
* Recuperando todos os dados da sessão
Exemplo 6: Consulta a todas as informações de sessão:
postgres=# SELECT 'BANCO : ' || current_database() AS INFO UNION SELECT 'ESQUEMA : ' || current_schema() AS INFO UNION
SELECT 'ESQUEMAS : ' || CAST(current_schemas(true) AS VARCHAR) AS INFO UNION
SELECT 'USUARIO : ' || current_user AS INFO UNION
SELECT 'SES. USR.: ' || session_user AS INFO UNION
SELECT 'USER : ' || user AS INFO UNION
SELECT 'CLI. ADR.: ' || inet_client_addr() AS INFO UNION
SELECT 'CLI. POR.: ' || inet_client_port() AS INFO UNION
SELECT 'SER. ADR.: ' || inet_server_addr() AS INFO UNION
SELECT 'SER. POR.: ' || inet_server_port() AS INFO UNION
SELECT 'VERSAO : ' || version() AS INFO;
info --------------------------------------------------------------------------------------------------------------------
ESQUEMAS : {pg_catalog,public}
ESQUEMA : public
USER : postgres
SES. USR.: postgres
USUARIO : postgres
VERSAO : PostgreSQL 9.2.1 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3, 32-bit
BANCO : postgres
(8 registros)
Fonte:http://postgresqlbr.blogspot.com.br/2012/11/recuperando-informacoes-de-sessao-no.html
sexta-feira, 20 de dezembro de 2013
[ORACLE] - Desabilitar expiração de senha no Oracle
-- Desabilita expiração de senha no Oracle --
ALTER PROFILE DEFAULT LIMITFAILED_LOGIN_ATTEMPTS UNLIMITED
PASSWORD_LIFE_TIME UNLIMITED;
-- Seleciona usuário/ data_expiração / status_conta --
select username,expiry_date,account_ status from dba_users;
-- Altera senha e desbloqueia a conta --
alter user teste identified by "teste123" account unlock;
terça-feira, 26 de novembro de 2013
[PostgreSQL] - Tablespaces
Enquanto os esquemas dividem um banco de dados em particionamentos lógicos, o tablespace divide um banco de dados fisicamente. Tablespace no PostgreSQL é uma pasta no sistema de arquivos utilizada para armazenamento físico dos dados e objetos de um banco de dados.
Ao se criar um banco de dados no PostgreSQL são criados dois tablespaces:
- PG_DEFAULT - por padrão, quando não é definido explicitamente um tablespace, os dados e objetos são armazenados no tablespace PG_DEFAULT.
- PG_GLOBAL - armazena objetos globais, visíveis a todos os bancos
Um tablespace pode armazenar dados de diversos bancos de dados, desde que se tenha permissão para acesso aos mesmos. Um banco de dados também pode dividir seus objetos e dados entre vários tablespaces.
Os tablespaces são utilizados para:
- Gerenciamento de espaço de armazenamento de dados - pode-se armazenar bancos grandes em mídia com tamanho apropriado que esteja disponível na rede.
- Melhor desempenho - objetos que sofrem mais acessos podem ser alocados em discos mais rápidos, por exemplo, com ganho substancial de desempenho.
Os principais comandos relacionados são:
- CREATE TABLESPACE - Criação de tablespaces
- DROP TABLESPACE - Exclusão de tablespaces sem conteúdo
Para visualizar a lista de tablespaces do seu servidor PostgreSQL, basta se fazer uma consulta na tabela pg_tablespace.
Exemplo:
1 - Recuperação do identificador de objeto e dos dados dos tablespaces do servidor.
SELECT oid, * FROM pg_tablespace;
2 - Recuperando o Tablespace e o usuário que tem permissão de owner do tablespace
SELECT T.oid, T.spcname, T.spcowner, U.usename
FROM pg_tablespace T, pg_user U
WHERE T.spcowner = U.usesysid;
Fonte:
http://postgresqlbr.blogspot.com.br/2007/06/tablespaces-no-postgresql.html
Ao se criar um banco de dados no PostgreSQL são criados dois tablespaces:
- PG_DEFAULT - por padrão, quando não é definido explicitamente um tablespace, os dados e objetos são armazenados no tablespace PG_DEFAULT.
- PG_GLOBAL - armazena objetos globais, visíveis a todos os bancos
Um tablespace pode armazenar dados de diversos bancos de dados, desde que se tenha permissão para acesso aos mesmos. Um banco de dados também pode dividir seus objetos e dados entre vários tablespaces.
Os tablespaces são utilizados para:
- Gerenciamento de espaço de armazenamento de dados - pode-se armazenar bancos grandes em mídia com tamanho apropriado que esteja disponível na rede.
- Melhor desempenho - objetos que sofrem mais acessos podem ser alocados em discos mais rápidos, por exemplo, com ganho substancial de desempenho.
Os principais comandos relacionados são:
- CREATE TABLESPACE - Criação de tablespaces
- DROP TABLESPACE - Exclusão de tablespaces sem conteúdo
Para visualizar a lista de tablespaces do seu servidor PostgreSQL, basta se fazer uma consulta na tabela pg_tablespace.
Exemplo:
1 - Recuperação do identificador de objeto e dos dados dos tablespaces do servidor.
SELECT oid, * FROM pg_tablespace;
2 - Recuperando o Tablespace e o usuário que tem permissão de owner do tablespace
SELECT T.oid, T.spcname, T.spcowner, U.usename
FROM pg_tablespace T, pg_user U
WHERE T.spcowner = U.usesysid;
Fonte:
http://postgresqlbr.blogspot.com.br/2007/06/tablespaces-no-postgresql.html
[PostgreSQL] - Comando SHOW
O PostgreSQL tem dúzias de variáveis de configuração que tem influência no comportamento do banco, em sua segurança e no desempenho. Acompanhar estes parâmetros de forma simples permite melhor controle do funcionamento do servidor.
O Comando SHOW é uma extensão do PostgreSQL que facilita este acompanhamento. Este comando permite que se visualize todos os valores das variáveis de configuração do seu banco de dados. O autovacuum está ativado? Qual é o estilo de data que está sendo utilizado no momento? Perguntas como essa são facilmente respondidas pela utilização deste comando.
Problemas conhecidos:
- Este comando não permite a cláusula WHERE. Desta forma recuperamos todas as dezenas de parâmetros ou apenas parâmetros específicos, um de cada vez.
- O comando não aceita recuperar uma lista de parâmetros definida pelo usuário (SHOW par1, par2,..., parN).
- Testes com os comandos SELECT, UNION e SELECT INTO não funcionaram, isto é, não é possível utilizar o SHOW com estes comandos.
Sintaxe:
SHOW name
SHOW ALL
Exemplos:
1 - Mostrando todos os parâmetros de configuração
SHOW ALL;
2 - Mostrando parâmetros específicos
SHOW array_nulls;
SHOW autovacuum;
O Comando SHOW é uma extensão do PostgreSQL que facilita este acompanhamento. Este comando permite que se visualize todos os valores das variáveis de configuração do seu banco de dados. O autovacuum está ativado? Qual é o estilo de data que está sendo utilizado no momento? Perguntas como essa são facilmente respondidas pela utilização deste comando.
Problemas conhecidos:
- Este comando não permite a cláusula WHERE. Desta forma recuperamos todas as dezenas de parâmetros ou apenas parâmetros específicos, um de cada vez.
- O comando não aceita recuperar uma lista de parâmetros definida pelo usuário (SHOW par1, par2,..., parN).
- Testes com os comandos SELECT, UNION e SELECT INTO não funcionaram, isto é, não é possível utilizar o SHOW com estes comandos.
Sintaxe:
SHOW name
SHOW ALL
Exemplos:
1 - Mostrando todos os parâmetros de configuração
SHOW ALL;
2 - Mostrando parâmetros específicos
SHOW array_nulls;
SHOW autovacuum;
segunda-feira, 25 de novembro de 2013
[PostgreSQL] - Movendo Tabelas, Índices para Tablespaces e Domínios para schema
Bom pessoal, segue abaixo uma forma automatizada para movimentação de tabelas, índices e domínios no PostgreSQL:
-- Mover tabelas para Tablespace específica no PostgreSQL:
SELECT 'ALTER TABLE ' || table_schema || '.' || table_name || ' SET TABLESPACE tbs_zeustab;'
FROM information_schema.tables
WHERE table_schema = 'public'
ORDER BY table_name;
-- Mover Índices para Tablespace específica no PostgreSQL:
SELECT 'ALTER INDEX ' || schemaname || '.' || indexname || ' SET TABLESPACE tbs_zeusindx;'
FROM pg_catalog.pg_indexes
WHERE schemaname = 'pagila' and tablespace is null
ORDER BY tablename;
-- Mover Dominios para Schema específico no PostgreSQL:
SELECT 'ALTER DOMAIN ' || domain_schema || '.' || domain_name || ' SET SCHEMA pagila;'
FROM information_schema.domains
WHERE domain_schema = 'pagila'
ORDER BY domain_name;
-- Mover tabelas para Tablespace específica no PostgreSQL:
SELECT 'ALTER TABLE ' || table_schema || '.' || table_name || ' SET TABLESPACE tbs_zeustab;'
FROM information_schema.tables
WHERE table_schema = 'public'
ORDER BY table_name;
-- Mover Índices para Tablespace específica no PostgreSQL:
SELECT 'ALTER INDEX ' || schemaname || '.' || indexname || ' SET TABLESPACE tbs_zeusindx;'
FROM pg_catalog.pg_indexes
WHERE schemaname = 'pagila' and tablespace is null
ORDER BY tablename;
-- Mover Dominios para Schema específico no PostgreSQL:
SELECT 'ALTER DOMAIN ' || domain_schema || '.' || domain_name || ' SET SCHEMA pagila;'
FROM information_schema.domains
WHERE domain_schema = 'pagila'
ORDER BY domain_name;
Assinar:
Postagens (Atom)