IBM PureData System for Analytics, Version 7.1

Mudanças na linguagem SQL e no Banco de Dados

A Liberação 7.1.0.0 inclui as seguintes mudanças nas operações do banco de dados e na sintaxe de linguagem e nos comandos SQL.

Incluídos novos comandos SQL [CREATE | ALTER | SET | DROP | SHOW ] SCHEDULER RULE para gerenciar as regras do planejador e uma nova Regra de Planejamento de privilégio para conceder permissão aos usuários para gerenciarem as regras do planejador.
Para procedimentos armazenados, foi incluída a nova cláusula EXCEPTION para TRANSACTION ABORT para especificar as instruções a executar quando um procedimento armazenado falha com um erro de interrupção de transação.
Incluído o tipo de dados DSA_KEYPAIR_2048 para criar chaves criptográficas que suportam criptografia aprimorada SP 800-131a e que podem ser usadas para assinar digitalmente configurações de histórico de auditoria que são configurados para uso em um ambiente SP 800-131a.
Incluído um cache de resultados de snippet nos SPUs, que pode ajudar a melhorar o desempenho de consultas pequenas. O cache de resultados de snippet salva os resultados intermediários de snippets e pode reutilizá-los em vez de incorrer o tempo de processamento para recalculá-los quando necessário. O cache pode ajudar a melhorar o desempenho de consultas pequenas.
Atualizada a documentação para o comando SET AUTHENTICATION com exemplos e informações para usar o IBM® Tivoli Directory Server como um servidor LDAP para autenticação de conta do usuário do banco de dados do Netezza. O Netezza foi testado com o IBM Tivoli Directory Server, OpenLDAP e Microsoft Active Directory. A autenticação LDAP deve funcionar com qualquer servidor que esteja em conformidade com o protocolo LDAP.
Melhorado o comando DROP DATABASE para descartar um banco de dados que contenha até 260.000 objetos. Na liberação 7.0.4, o comando incluía um aviso para notificar os usuários quando um banco de dados não poderia ser descartado porque ele tinha mais de 64.000 objetos. Na Liberação 7.1.0.0 esse máximo aumentou para 260.000. Se um banco de dados tiver mais de 260.000 objetos, o comando DROP DATABASE exibe um erro semelhante à mensagem a seguir:
```
ERROR:  DROP DATABASE: O banco de dados "MYDB" tem 269968 tabelas e/ou sequências.
Os objetos devem ser manualmente descartados até que o número seja menor que 260000.
```
Para descartar um banco de dados com mais de 260.000 objetos, você deve descartar objetos manualmente no banco de dados até que o número seja inferior a 260.000 e, em seguida, será possível usar o comando DROP DATABASE para descartar o banco de dados.
Melhorado o processamento de matriz de transações para aumentar o limite no número de IDs de sequência e tabela que estão em uso de 65.534 para 262.142. Isso pode ajudar a reduzir os casos em que as transações em sistemas ocupados poderiam falhar com ERROR: … não há mais espaço para a matriz de tabelas TXMgr.
Incluída uma mensagem de aviso para contatar o Suporte do IBM Netezza no arquivo pg.log quando o sistema está baixo nos IDs de transação Postgres.
Incluído suporte para o tempo de suporte 24:00:00 da IBM DB2 nos tipos de dados de horário e registro de data e hora do Netezza. Com essa mudança, os usuários podem agora carregar esse formato utilizando INSERT ou carregamentos de tabela externa, descarregar o formato utilizando tabelas externas e eles podem utilizar este formulário nos valores de registro de data e hora e de consultas SELECT. A capacidade de suportar esse formato é por meio da definição postgresql.conf enable_time24, que é um valor Booleano. O padrão é false, que não permite 24:00:00 no banco de dados ou nas operações do Netezza. Os usuários devem incluir o valor no arquivo postgresql.conf com um valor true (e reiniciar o software NPS) para permitir suporte 24 horas. O JDBC não suporta o formato 24:00:00. Em vez disso, o JDBC usa o valor 23:59:59:999999 para 00:00:00 do dia seguinte.
Incluída uma opção nzsql \dO <table> que exibe as colunas da tabela classificadas em ordem alfabética.
Alterada a saída da opção \d para uma tabela externa para suportar valores NULL no catálogo para determinados campos. Para campos booleanos que tem false como um valor-padrão, observe que a saída agora mostra o valor padrão como NULL.
A Liberação 7.1.0.1 inclui suporta para permitir que o usuário administrativo restrinja e gerencie os locais no dispositivo Netezza em que os usuários podem criar tabelas externas. Por padrão, os usuários podem criar locais externos em qualquer diretório no host. O usuário administrativo ou qualquer usuário do banco de dados que tenha recebido privilégio de Gerenciar o Sistema pode, então, definir localizações da tabela externa no sistema em que os usuários que possuem o privilégio de Criar Tabela Externa podem gravar o arquivo do objeto de dados externo. Essa liberação inclui os comandos SQL [ADD | REMOVE | SHOW] EXTERNAL TABLE LOCATION para estabelecer e gerenciar os locais da tabela externa para quaisquer novas tabelas externas criadas no sistema.

Melhorias de alocação do ID do objeto

A Liberação 7.1.0.0 melhora a alocação e designação de IDs de objetos (OIDs) para objetos criados pelo usuário. Essas melhorias tornam a taxa de consumo para os valores OID mais eficientes e elas suportam a capacidade de agrupar no início do intervalo de OID quando um sistema atinge o valor máximo de OID. O sistema IBM Netezza suporta até dois bilhões de OIDs e embora esse intervalo suporte a maioria dos ambientes, é um caso raro, mas possível, que um sistema poderia atingir o valor máximo de OID, o que faz com que o sistema pare.

Em liberações anteriores, os usuários podiam fazer backup dos seus bancos de dados, reinicializar o sistema e recarregar seus dados para reiniciar os valores de OID no início do intervalo. Com a liberação 7.1.0.0, o sistema consome os OIDs com menor frequência do que em liberações anteriores, o que reduz a taxa de uso geral do OID. Quando um sistema atinge o limite OID, o sistema automaticamente agrupa para o início do intervalo OID e começa a alocar os OIDs não utilizados no intervalo. Depois do agrupamento dos contadores de OID, existe uma pequena sobrecarga para verificar se um OID não está em uso, mas o efeito não deveria ser perceptível. Se houver um impacto em seu ambiente, você pode executar o backup, reinicialização e operação de recarregamento para recomeçar e evitar as verificações do OID utilizado.

Atualização da versão do banco de dados de histórico de consulta

Na liberação 7.1.0.0, a versão de configuração do histórico de consulta aumentou de 2 para 3. As tabelas e visualizações de histórico da versão 3 possuem atualizações para suportar os campos de informações de cliente opcionais para sessões para o banco de dados e para as regras do planejador que podem ser aplicadas a consultas. Se você fizer upgrade para a liberação 7.1.0.0 ou posterior e o sistema tiver uma versão 1 ou versão 2 do banco de dados do histórico configurado, é possível continuar a efetuar os dados para esse banco de dados do histórico, mas nas informações podem estar ausentes detalhes de chaves relacionados aos campos 7.1.0.0. Após fazer upgrade do software, crie um novo banco de dados do histórico versão 3 e crie novas configurações de histórico para carregar dados no novo banco de dados. Para obter informações adicionais sobre as visualizações de histórico e o processo de configuração da versão 3, consulte o IBM Netezza.