Categoria: Banco de dados

Categorias
Banco de dados PostGreSQL

Recover and replace win1252 content to utf-8 for a PostgreSQL database

I shouldn't be the first to need to export data from a PostgreSQL database installed on Windows with a win1252 code to a database with UTF-8 code (in my case, on a Linux server).

It is not enough to transform the transfer file to UTF-8, as the characters of win1252 (left double quote, right double quote, single quote and dash) will be there, with a weird value in your database.

In my experience, I had to import data as-is and afterwards perform an update using the function to rewrite data for UTF-8 characters correctly.

The following code examples are for: 1 - transform to HTML characters; 2 - transform to single characters.

HTML:

-- DROP FUNCTION substitui_win1252_html(texto);

CREATE OR REPLACE FUNCTION substitui_win1252_html(texto text)
    RETURNS text AS
$$
BEGIN

    texto := replace(replace(replace(replace(replace(texto, '’', '’'), '“', '“'), '”', '”'), '•','•'), '–', '–')::text; 
    RETURN texto;

END;
$$
LANGUAGE plpgsql;

Simple:

-- DROP FUNCTION substitui_win1252(texto);

CREATE OR REPLACE FUNCTION substitui_win1252(texto text)
    RETURNS text AS
$$
BEGIN

    texto := replace(replace(replace(replace(replace(texto, '’', ''''), '“', '"'), '”', '"'), '•','•'), '–', '-')::text;  
    RETURN texto;

END;
$$
LANGUAGE plpgsql;

Don't worry about the squares that you might see. If you copy it to a good text editor, you will their actual value.

Categorias
PostGreSQL

PostgreSQL – pg_upgrade from 10 to 12

I have some PostgreSQL databases running pretty well but we need to keep our software updated. This is a mandatory practice for a high-quality service. Those servers are running version 10 and they need to be upgraded to version 12. I have used pg_dump / pg_restore strategy for a long time, but this time I would rather use pg_upgrade.

Let's dive into how to do it.

Table of contents:

  1. Install
  2. InitDB
  3. Check upgrade consistency
  4. Set locale
  5. Upgrade
  6. Configurations

Install

The package postgresql12-server contains everything needed to run the server, but my databases use some extensions [1], then I will add postgresql12-devel and postgresql12-contrib to be able to compile and to install the extensions.

yum install postgresql12-server postgresql12-devel postgresql12-contrib

InitDB

After installation we need to setup new server with initdb:

~% /usr/pgsql-12/bin/postgresql-12-setup initdb
Initializing database … OK

Check upgrade consistency

We need to check compatibility. Turn to postgres user (su - postgres) and run the command:

~% /usr/pgsql-12/bin/pg_upgrade --old-bindir=/usr/pgsql-10/bin --new-bindir=/usr/pgsql-12/bin --old-datadir=/var/lib/pgsql/10/data --new-datadir=/var/lib/pgsql/12/data --check

Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               fatal

Your installation contains tables declared WITH OIDS, which is not supported
anymore. Consider removing the oid column using
    ALTER TABLE ... SET WITHOUT OIDS;
A list of tables with the problem is in the file:
    tables_with_oids.txt

Failure, exiting

As you may see, I got a fatal error, indicating that the upgrade is not possible. In my case, tables with OIDs are the culprit. In your case could be something else. In any case, we need to fix before upgrading.

I fixed tables removing OIDs on mentioned tables. And ran check again:

Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok

*Clusters are compatible*

Yay!

Set locale

There is a tricky configuration that is not detected by pg_upgrade check but it is very important to me. I use C locale on my databases [2], then I need to perform an extra step. If this is your case, you may follow the same steps applying yours.

I need to stop postgresql10 and start postgresql12:

systemctl stop postgresql-10.service
systemctl start postgresql-12.service

Then I run locale change at my template1 then locale will be enabled when my database will be upgraded.

UPDATE pg_database SET datcollate='C', datctype='C' WHERE datname='template1';

And stop again: systemctl stop postgresql-12.service to be ready to upgrade.

Upgrade

Upgrade command is the same that we run before, without --check flag.

~% /usr/pgsql-12/bin/pg_upgrade --old-bindir=/usr/pgsql-10/bin --new-bindir=/usr/pgsql-12/bin --old-datadir=/var/lib/pgsql/10/data --new-datadir=/var/lib/pgsql/12/data

Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows in the new cluster                        ok
Deleting files from new pg_xact                             ok
Copying old pg_xact to new server                           ok
Setting next transaction ID and epoch for new cluster       ok
Deleting files from new pg_multixact/offsets                ok
Copying old pg_multixact/offsets to new server              ok
Deleting files from new pg_multixact/members                ok
Copying old pg_multixact/members to new server              ok
Setting next multixact ID and offset for new cluster        ok
Resetting WAL archives                                      ok
Setting frozenxid and minmxid counters in new cluster       ok
Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster
                                                            ok
Copying user relation files
                                                            ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    ./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

Consider running analyze_new_cluster. Optional but nice to have.

vacuumdb: processing database "mydb": Generating minimal optimizer statistics (1 target)
vacuumdb: processing database "postgres": Generating minimal optimizer statistics (1 target)
vacuumdb: processing database "template1": Generating minimal optimizer statistics (1 target)
vacuumdb: processing database "mydb": Generating medium optimizer statistics (10 targets)
vacuumdb: processing database "postgres": Generating medium optimizer statistics (10 targets)
vacuumdb: processing database "template1": Generating medium optimizer statistics (10 targets)
vacuumdb: processing database "mydb": Generating default (full) optimizer statistics
vacuumdb: processing database "postgres": Generating default (full) optimizer statistics
vacuumdb: processing database "template1": Generating default (full) optimizer statistics

Done

Configurations

Before deleting your old cluster, remember to get some of your configurations.

mv /var/lib/pgsql/12/data/pg_hba.conf /var/lib/pgsql/12/data/pg_hba.conf.new
cp /var/lib/pgsql/10/data/pg_hba.conf /var/lib/pgsql/12/data/

I am not a big fan of writing directly to postgresql.conf file. Instead, I keep configuration files under version control and include the directory where those files are deployed. I treat them as code, then it becomes easier to maintain and manage.

Another advantage is that I don't have any mess about config file differences when a new version arises. I am automatically using new default configurations, my customized setting are loaded and I can quickly address any incompatibility caused by migration without touching the original conf file.

Let's go for it:

# Add settings for extensions here
include_dir = '/var/lib/pgsql/conf.d'   # include files ending in '.conf' from

Then you may delete your old cluster. 🙂

Links:

  1. Extensions: https://www.postgresql.org/docs/current/contrib.html
  2. Locale: https://www.postgresql.org/docs/current/locale.html
Categorias
Banco de dados

Precisamos de apoio das ferramentas para a paginação por conjunto de chaves

(Traduzido de We need tool support for keyset pagination)

Você sabia que a paginação via offset é muito problemática, mas fácil de evitar?

offset instrui os bancos de dados a pular os primeiros N resultados N de uma consulta. No entanto, o banco de dados ainda deve buscar essas linhas a partir do disco e trazê-los em ordem antes de ele pode enviar os seguintes.

Isto não é um problema de implementação, é a maneira na qual offset foi desenhado:

... As linhas são primeiro classificadas de acordo com a <cláusula order by> e, em seguida, limitada retirando-se o número de linhas especificadas na <cláusula offset> desde o início ...

— SQL:2011, Part 2, §4.15.3 Derived tables

Em outras palavras, grandes offsets impõe um grande trabalho para o banco de dados, não importa se SQL ou NoSQL.

Mas o problema com offset não pára aqui: já pensou sobre o que acontece se uma nova linha é inserida entre duas páginas buscadas?

offset-drifting

Quando offset➌ é usado para ignorar as entradas❶ anteriores, você terá duplicações no caso de existirem novas linhas inseridas entre as duas páginas➋. Há outras anomalias possíveis também, este é apenas o caso mais comum.

Este nem é um problema de banco de dados, é a maneira como os frameworks implementam paginação: eles apenas dizem qual é o número da página a ser recuperada ou quantas linhas devem ser ignoradas. Com estas informações apenas, nenhum banco de dados pode fazer melhor.

Vida sem OFFSET

Agora imagine um mundo sem estes problemas. Como se constata, viver sem offset é bem simples: apenas utilize uma cláusula where que selecione apenas os dados que você ainda não viu.

Para isso, exploraremos o fato de que trabalhamos com um conjunto ordenado - você tem uma cláusula order by, não é? Uma vez que há uma ordenação definida, podemos usar um filtro simples para somente selecionar o que é posterior a entrada que vimos anteriormente.

SELECT ...
FROM ...
WHERE ...
AND id < ?last_seen_id
ORDER BY id DESC
FETCH FIRST 10 ROWS ONLY

Esta é a receita básica. Ele fica mais interessante quando a classificação é por várias colunas, mas a idéia é a mesma. Esta receita também é aplicável a muitos sistemas NoSQL.

Esta abordagem - chamada seek method ou keyset pagination - resolve o problema de derivação de resultados como ilustrado acima e é ainda mais rápido do que offset. Se você quer saber o que acontece dentro do banco de dados ao usar offset ou keyset pagination, dê uma olhada nestes slides (benchmarks, benchmarks!):

No slide 43 você também pode ver que keyset pagination tem algumas limitações: mais notavelmente que você não pode navegar diretamente para páginas arbitrariamente. No entanto, isto não é um problema quando se utiliza rolagem infinita. Mostrar o número de páginas para serem clicadas é uma interface de navegação pobre, na minha humilde opinião.

Se você quiser ler mais sobre como implementar corretamente keyset pagination em SQL, por favor fetch-next-page. Mesmo que você não esteja envolvido com o SQL, vale a pena ler fetch-next-page antes de começar a implementar qualquer coisa.

No entando, os frameworks

A principal razão para preferir offset a paginação por conjunto de chaves (keyset pagination) é a falta de suporte. A maioria das ferramentas de paginação são baseadas em offset, mas não oferecem nenhuma maneira conveniente para a utilização de paginação por conjunto de chaves.

Por favor, note que a paginação por conjunto de chaves afeta toda a tecnologia envolvida na execução de JavaScript do navegador que esteja fazendo a requisição AJAX para rolagem infinita: ao invés de simplesmente passar um número de página para o servidor, você deve passar o conjunto de chaves completo (geralmente múltiplas colunas) para o servidor.

O hall da fama de frameworks que suportam paginação por conjunto de chaves é ainda pequeno:

É por isto que preciso da sua ajuda. Se você estiver mantendo um framework que tem algum envolvimento com paginação, eu peço, eu imploro, que você construa um suporte nativo para navegação por conjunto de chaves também. Se você tiver quaisquer perguntas sobre detalhes, ficarei feliz em ajudar (forum, contact form, Twitter)!

Mesmo que você esteja apenas utilizando um software que deveria suportar paginação por conjunto de chaves, como um gerenciador de conteúdos ou uma loja virtual, faça os mantenedores saberem sobre isso. Você poderia fazer uma requisitação da funcionalidade (link a esta página) ou, se possível, desenvolva um patch. Novamente, ficarei feliz em ajudar a ter todos os devidos detalhes.

Tome WordPress como um exemplo.

Espalhe a palavra

O problema com a paginação de conjunto de chaves não é técnico. O problema é que é pouquíssimo conhecido no meio e não há suporte das ferramentas. Se você gosta da idéia de evitar o uso de paginação por offset, por favor, ajude a espalhar a palavra. Use o Twitter, compartilhe, envie por e-mail, você pode até reproduzir este post (CC-BY-NC-ND). Traduções são também bem-vindas, apenas faça um contato prévio - eu também incluirei o link da tradução a esta página.

Ah, e se você estiver em um blog, você também pode acrescentar um banner para que seus leitores fiquem alertas a isto. Eu preparei uma a galeria de banner NoOffset com alguns formatos comuns. Escolha o que ficar melhor.

Categorias
Linux PostGreSQL

Backup de todos os bancos do servidor PostgreSQL

Extremamente útil, ainda mais quando há possibilidade de criação de banco de dados de forma automatizada (servidores de hospedagem, por exemplo).

Download

Categorias
PostGreSQL

Gerando 1000 linhas de dados aleatórios – PostgreSQL

Muito útil!

SELECT i, clock_timestamp() t1, random() r1, random() r2, random() r3, clock_timestamp() + (round(random()*1000)::text || ' days')::interval d1 
from generate_series(1,1000) i(i);
Categorias
PostGreSQL

Substituir conteúdo win1252 para utf-8

Não devo ser o primeiro a precisar exportar dados de um banco PostGreSQL instalado em Windows com codificação win1252 para um banco com codificação em utf-8 (no meu caso, em servidor Linux).

Não basta transformar o arquivo de importação para utf-8, pois os caracteres do win1252 (aspas duplas à esquerda, aspas duplas à direita, aspa simples e travessão) estarão lá, com um valor esquisito no seu banco. A minha solução foi importar assim mesmo e depois realizar um update usando uma função para corrigir.

Os exemplos de código a seguir são para: 1 - transformar para caracteres HTML; 2 - transformar para os caracteres simples.

HTML:

Simples:

Não se preocupe com os quadrados que aparecem. Se você copiar para um bom editor de texto, verá que possuem valores diferentes.

Categorias
Banco de dados Programação Technology

Aonde você deseja se conectar hoje?

O site ConnectionString vem com uma proposta simples e muito útil: fornecer linhas de conexão. Tem conexão para tudo. Há conexões bancos de dados (SQL Server, Informix, MySQL, Progress, Paradox, Firebird etc), arquivos de dados (Excel, TXT, SQL Lite etc) e também para outros tipos (MS Project, Active Directory, Exchange, DNS etc).

A idéia de ConnectionString é fornecer uma fácil referência para linhas de conexão.

Hoje, existem 213 linhas de conexão no banco de dados coletadas a partir de outros sites da internet, livros, arquivos de ajuda, msdn ou que tenham sido submetidos pelos colegas desenvolvedores de todo o mundo.

Se alguém conhecer algum projeto semelhante para outras linguagens, não deixe de colocar nos comentários, por favor.

Categorias
Banco de dados PHP Programação

Galvão bota a mão na massa em SP

Quem está em SP e estiver disponível em 1º de março (1ª edição) ou 31 de maio (2ª edição) terá uma ótima oportunidade de conhecer ainda mais sobre práticas de segurança no desenvolvimento em php. Recebi a seguinte mensagem do Er Galvão:

No dia primeiro de Março estarei em São Paulo ministrando um workshop sobre segurança em aplicações PHP, focando em tópicos específicos e técnicas 100% práticas de defesa.

Er Galvão entende muito de segurança e tem grande facilidade em passar seu conhecimento, como pode ser visto no artigo Segurança no PHP. Se eu estivesse em São Paulo, não perderia.

Segurança no desenvolvimento é fundamental para que a internet seja, verdadeiramente, uma ferramenta benéfica para o comércio. Conheço códigos de lojas virtuais que não foram desenvolvidas com preocupação nos tópicos de segurança. Se isso acontece por terem sido construídas antes de se conhecer as práticas atuais, está mais do que na hora de que sejam reconstruídas. Imagine o prejuízo que já se tem (só não se sabe) quando algum criminoso digital conhece essas falhas.

Use a tecnologia a seu favor. Ouça o que o Er Galvão tem a contribuir.

http://www.temporealeventos.com.br/?area=88

São Paulo - SP
1 de Março 31 de maio das 9h00 às 17h00 (2ª edição)

Aprenda: 1 profissional por máquina

PHP: Proteja sua Aplicação

técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries

Objetivo: Neste treinamento o profissional aprenderá técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries. Primeiramente serão apresentados exemplos práticos de funcionamento de cada um destes ataques de forma à compreender os pontos fracos de cada aplicação. Serão então colocadas em prática diversas técnicas, variando das mais simples às menos óbvias que axiliarão o desenvolvedor à diminuir consideravelmente o nível de vulnerabilidade de suas aplicações.

Público Alvo: Desenvolvedores PHP e demais interessados

Pré-requisitos: Conhecimentos básicos de HTML e Conhecimentos intermediários de PHP

Sistema operacional em que o curso será ministrado: Linux

Após o término deste treinamento o participante estará imediatamente apto a: Compreender o funcionamento dos ataques mais comuns que rondam a web, desenvolver aplicações mais seguras e robustas, menos vulneráveis à ataques.

Conteúdo Programático

Boas práticas:

O que todo o programador PHP deveria saber
O que é e como funciona um ataque de SQL Injection
SQL Injection - Técnicas de defesa: Porque addslashes não é o bastante
O que é e como funciona um ataque de Cross Side Scripting (XSS)
XSS - Técnicas de defesa
O que é e como funciona um ataque de Cross Site Request Forgeries (CSRF)
CSRF - Técnicas de defesa

Categorias
Banco de dados

Consultas case-insensitive e accent-insensitive no MySQL

Uma necessidade comum com dados em língua portuguesa são as buscas no bancos de dados insensível a caso e insensível a acentos.

No MySQL, até a versão 4.0, as consultas eram por padrão insensível ao caso (case-insensitive) e insensível ao acento (accent-insensitive). Isso mudou, porém, a partir da versão 4.1, que introduziu um suporte melhorado a comparações (collations) e definições de caracteres (charsets). Alguns desenvolvedores devem ter ficado surpresos com suas buscas que antes ignoravam acentos e maiúsculas e agora já exigiam que se colocasse.

A partir dessa versão, a sintaxe para uma consulta que ignora acentos e o caso seria a seguinte:

SELECT *
FROM `tab_municipios`
WHERE `NomeMunic` = _utf8 'SAO PAULO' COLLATE utf8_unicode_ci

Adaptado de Consultas case-insensitive no PostgreSQL e no MySQL