Vlad Mihalcea's questions

Me deparei com essa pergunta em uma conversa no Twitter com Lukas Eder .

Embora o comportamento correto seja aplicar a cláusula ORDER BY na consulta mais externa, porque, aqui, não estamos usando DISTINCT, GROUP BY, JOIN ou qualquer outra cláusula WHERE na consulta mais externa, por que um RDBMS não passaria apenas a dados de entrada como foram classificados pela consulta interna?

SELECT * 
FROM (
    SELECT * FROM table ORDER BY time DESC
) AS t

Ao executar este exemplo no PostgreSQL, pelo menos, você obtém o mesmo Plano de Execução para a consulta interna e este exemplo de tabela derivada, bem como o mesmo conjunto de resultados.

Então, eu diria que o Planner simplesmente descartará a consulta mais externa porque é redundante ou simplesmente passará pelos resultados da tabela interna.

Alguém acha que pode não ser assim?

Tenho alguns testes no GitHub que registram quanto tempo leva para executar uma consulta e buscar todos os resultados.

Se eu verificar o plano de execução, recebo:

Index Scan using post_comment_pkey on post_comment postcommen0_  (cost=0.29..2716.48 rows=34752 width=43) (actual time=6.767..14.352 rows=34880 loops=1)
  Filter: (post_id = 1)
  Rows Removed by Filter: 34880
Planning time: 0.659 ms
Execution time: 14.840 ms

Portanto, a consulta está usando um índice e sendo executada em 15 ms.

No entanto, no lado Java, após o ResultSet ser buscado e processado, a medição de tempo indica que demorou 90 ms.

A única explicação seria que o Explain Analyze não considera o tempo de busca e a busca de 34880 registros leva de 50 a 60 ms.

Isso está correto?

Ao testar o mecanismo de estabelecimento de conexão do Oracle XE, me deparei com o seguinte problema. Embora as conexões sejam fechadas em cada iteração, após 50 a 100 conexões, o Oracle começa a lançar intermitentemente a seguinte exceção:

java.sql.SQLException: Listener refused the connection with the following error:
ORA-12516, TNS:listener could not find available handler with matching protocol stack
 
    at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:489) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:553) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:254) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:528) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:280) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:207) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at oracle.jdbc.pool.OracleDataSource.getConnection(OracleDataSource.java:157) ~[ojdbc6-11.2.0.4.jar:11.2.0.4.0]
    at com.vladmihalcea.book.high_performance_java_persistence.jdbc.connection.OracleConnectionCallTest.test(OracleConnectionCallTest.java:57) [test-classes/:na]

O teste pode ser encontrado no GitHub :

for (int i = 0; i < callCount; i++) {
    try {
        long startNanos = System.nanoTime();
        try (Connection connection = dataSource.getConnection()) {
        }
        timer.update(System.nanoTime() - startNanos, TimeUnit.NANOSECONDS);
        sleep(waitMillis);
    } catch (SQLException e) {
        LOGGER.info("Exception on iteration " + i, e);
    }
}

Se eu tentar abrir/fechar conexões com um passo de espera de 35 ms, tudo funciona bem. Se eu diminuir a espera para 10 ms a exceção começa a ser lançada de vez em quando.

Um possível motivo pode ser explicado por este artigo: http://www-01.ibm.com/support/docview.wss?uid=swg21603472

Um dos motivos mais comuns para os erros TNS-12516 e/ou TNS-12519 serem relatados é o número máximo configurado de limitação de PROCESSES e/ou SESSIONS sendo atingido. Quando isso ocorre, os manipuladores de serviço para o ouvinte TNS ficam "Bloqueados" e nenhuma nova conexão pode ser feita. Uma vez que o TNS Listener recebe uma atualização do processo PMON associado à instância do banco de dados informando ao TNS Listener que os limites estão abaixo do limite configurado e o banco de dados agora está aceitando retomadas de conectividade de conexões.

• O PMON é responsável por atualizar o listener com informações sobre uma determinada instância, como informações de carga e despachante. A carga máxima para conexões dedicadas é determinada pelo parâmetro PROCESSES. A frequência com que o PMON fornece informações SERVICE_UPDATE varia de acordo com a carga de trabalho da instância. O intervalo máximo entre essas atualizações de serviço é de 10 minutos.
• O ouvinte conta o número de conexões que estabeleceu com a instância, mas não obtém imediatamente informações sobre as conexões que foram encerradas. Somente quando o PMON atualiza o listener via SERVICE_UPDATE o listener é informado da carga atual. Como isso pode levar até 10 minutos, pode haver uma diferença entre o carregamento da instância atual de acordo com o ouvinte e o carregamento real da instância.

Quando o ouvinte acredita que o número atual de conexões atingiu a carga máxima, ele pode definir o estado do manipulador de serviço para uma instância como "bloqueado" e começar a recusar conexões de cliente de entrada com um dos seguintes erros: ora-12519 ou ora-1251 "

Eu queria saber se isso é algum tipo de bug ou é simplesmente como o Oracle foi projetado para funcionar.

Atualizar

No Oracle 11g Enterprise Edition, ele funciona bem, então é uma limitação do XE.

Fixar

Usar o pool de conexões é provavelmente a melhor maneira de corrigir esse problema, o que também reduz o tempo de aquisição da conexão e aumenta os picos de tráfego.

O SQL Server 2016 e o ​​MySQL 5.7 usam manipulação de conexão baseada em thread.

O PostgreSQL 9.5 usa um processo de sistema operacional para cada conexão individual.

De acordo com a documentação do Oracle 12c, não está claro se um modelo baseado em thread ou baseado em processo é usado. Então, como o Oracle lida com as conexões do usuário?

O PostgreSQL suporta a recuperação do ID da transação em execução atual usando uma consulta como esta:

select txid_current();

O MySQL tem algum equivalente?

Para armazenar um UUID de 128 bits, existem várias opções de armazenamento:

1. uma coluna de byte[16]
2. duas colunas bigint/long(64 bits)
3. uma coluna CHAR(36) - 32 dígitos hexadecimais + 4 traços.
4. uma coluna específica do banco de dados UUID, se db suportar

Do ponto de vista da indexação, quais são os mais eficientes? Se o banco de dados não suportar um tipo uuid dedicado, qual de 1, 2, 3 são os melhores candidatos?