IBM i: Administração de Banco de Dados

IBM i
Versão 7.3
Banco de Dados
Administração
IBM
IBM i
Versão 7.3
Banco de Dados
Administração
IBM
Aviso
Antes de utilizar estas informações e o produto suportado por elas, leia as informações em “Avisos” na página 47.
Esta edição se aplica ao IBM i 7.3 (número do produto 5770-SS1) e a todas as liberações e modificações
subsequentes, até que seja indicado de outra forma em novas edições. Esta versão não é executada em todos os
modelos RISC (Reduced Instruction Set Computer), nem nos modelos CISC.
Este documento pode conter referências ao Código Interno Licenciado. O Código Interno Licenciado é um Código
de Máquina e é licenciado a você sob os termos do IBM License Agreement for Machine Code.
© Copyright IBM Corporation 1998, 2015.
Índice
Administração de Banco de Dados . . . 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
O que há de novo para o IBM i 7.3 . . . . . . . 1
Arquivo PDF para Administração de Banco de Dados 1
Administração de Banco de Dados . . . . . . . 2
Acessando Dados Através de Interfaces do Cliente 2
Acessando Dados com Java . . . . . . . 2
Acessando Dados com o Domino . . . . . 2
Acessando Dados com o ODBC . . . . . . 2
Acessando Dados com o IBM i PASE . . . . 2
Acessando Dados com o Provedor IBM i Access
para Windows OLE DB . . . . . . . . . 2
Acessando Dados com o IBM i Access para
Windows .Net Provider . . . . . . . . . 3
Acessando Dados com o Net.Data . . . . . 3
Acessando Dados Através de uma Partição do
Linux . . . . . . . . . . . . . . . 3
Acessando Dados Utilizando o DRDA
(Distributed Relational Database Architecture) . 3
Alterando e Gerenciando Objetos de Banco de
Dados . . . . . . . . . . . . . . . 3
Criando Objetos de Banco de Dados . . . . . 4
Assegurando a Integridade dos Dados. . . . . 4
Importando e Exportando Dados entre Sistemas . 4
Trabalhando com Vários Bancos de Dados . . . 4
Trabalhando com tabelas temporais de período do
sistema . . . . . . . . . . . . . . . 5
Tabelas Temporais de Período do Sistema. . . 5
Coluna de tempo inicial . . . . . . . 5
Coluna de tempo final . . . . . . . . 5
ID de início de transação . . . . . . . 6
Período SYSTEM_TIME. . . . . . . . 6
Tabelas de históricos . . . . . . . . . . 6
Criando uma tabela temporal de período do
sistema . . . . . . . . . . . . . . 7
Exemplos adicionais de CREATE TABLE da
tabela temporal de período do sistema. . . 8
Inserindo dados em uma tabela temporal de
período do sistema . . . . . . . . . . 9
Atualizando dados em uma tabela temporal
de período do sistema . . . . . . . . . 10
Excluindo dados em uma tabela temporal de
período do sistema . . . . . . . . . . 11
Usando uma tabela temporal de período do
sistema para controlar informações de
auditoria . . . . . . . . . . . . . 12
Conflitos de valor de registro de data e hora
da tabela temporal de período do sistema . . 14
Consultando os dados temporais do período
do sistema . . . . . . . . . . . . . 15
Especificando os critérios de tempo em
uma consulta . . . . . . . . . . . 15
Especificando os critérios de tempo usando
o registro especial CURRENT TEMPORAL
SYSTEM_TIME . . . . . . . . . . 17
Especifique os critérios de tempo para uma
visualização . . . . . . . . . . . 19
© Copyright IBM Corp. 1998, 2015
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Restrições ao inserir, atualizar ou excluir
dados em uma tabela temporal de período do
sistema . . . . . . . . . . . . . .
Considerações de E/S nativa com uma tabela
temporal de período do sistema . . . . .
Mantendo a tabela de históricos . . . . .
Particionando uma tabela temporal de período
do sistema . . . . . . . . . . . . .
Controle de acesso de linha e coluna com uma
tabela temporal de período do sistema . . .
Salvando e restaurando as tabelas temporais
de período do sistema . . . . . . . . .
Usando catálogos para localizar informações
sobre a tabela temporal de período do sistema.
Restrições da tabela temporal . . . . . .
Trabalhando com Acionadores e Restrições . . .
Gravando Programas do DB2 . . . . . . .
Backup e Recuperação do Banco de Dados . . . .
Administração de Banco de Dados Distribuída . .
Consultas e Relatórios . . . . . . . . . . .
Segurança . . . . . . . . . . . . . . .
Opções de Autoridade para Análise e Ajuste de
SQL . . . . . . . . . . . . . . . .
Row and Column Access Control (RCAC) . . . .
Visão Geral . . . . . . . . . . . . .
Permissões e Máscaras. . . . . . . . . .
Instruções SQL . . . . . . . . . . . .
Funções Protegidas . . . . . . . . . . .
Proteger Acionadores . . . . . . . . . .
Autoridade administrativa . . . . . . . .
Melhores Práticas ao Usar Permissões e Máscaras
Criando Permissões e Máscaras. . . . . .
Única Permissão com Todos os Usuários .
Única Permissão com um Perfil de Grupo
Única Permissão com uma Tabela
Dependente . . . . . . . . . . .
Única Permissão com um UDF . . . . .
Permissões para Cada Usuário . . . . .
Atributos de Diversas Permissões . . . .
Nomes de Objetos Não Qualificados . . .
Objetos Dependentes . . . . . . . . .
Propriedade . . . . . . . . . . .
Esquema . . . . . . . . . . . .
Autoridade de Esquema . . . . . . .
UDFs Protegidos . . . . . . . . .
ALWCPYDTA e Nível de Isolamento . . .
Restaurando Objetos . . . . . . . .
Operações Adicionais . . . . . . . . .
Incluindo o Perfil do Aplicativo em
Permissões e Máscaras. . . . . . . .
Recuperar o Armazenamento . . . . .
Relatórios de Consulta. . . . . . . .
MQTs . . . . . . . . . . . . .
Tabelas temporais . . . . . . . . .
Perfis de Grupo e QIBM_DB_SECADM . .
Parâmetros Copy File (CPYF) . . . . .
21
22
22
23
23
24
24
25
25
25
26
26
26
27
27
32
33
34
35
36
36
36
36
36
36
37
37
37
38
38
39
39
39
39
40
40
40
40
41
41
41
41
41
42
42
42
iii
OmniFind Text Search Server for DB2 for
Usando o RCAC em Arquivos Lógicos
Multiformatados. . . . . . . . . .
Propagação de Dados Mascarados . . . .
Classic Query Engine (CQE) e SQL Query Engine
(SQE) . . . . . . . . . . . . . . .
Diferenças entre nativo aberto e consulta SQL
envolvendo RCAC . . . . . . . . . .
iv
IBM i: Administração de Banco de Dados
i
43
. 43
. 44
. 46
. 46
Ordenação de Conjunto de Resultados .
.
.
. 46
Avisos . . . . . . . . . . . . . . . 47
Informações sobre a Interface de Programação.
Marcas Registradas . . . . . . . . . .
Terms and conditions . . . . . . . . .
.
.
.
. 49
. 49
. 49
Administração de Banco de Dados
O DB2 para IBM® i fornece funções de administração de banco de dados, de backup e recuperação, de
consulta e de segurança.
Você também pode explorar outras informações do banco de dados utilizando a árvore de navegação
principal ou o Localizador de Informações do Banco de Dados.
|
O que há de novo para o IBM i 7.3
|
|
Leia sobre informações novas ou significativamente alteradas para a coleta de tópicos de administração
de Banco de Dados.
|
Tabela Temporal de Período do Sistema
|
Uma tabela temporal de período do sistema é uma tabela que mantém versões históricas de suas linhas.
|
Como Saber o Que É Novo ou Que Foi Alterado
|
Para ajudar a ver onde as alterações técnicas foram feitas, o centro de informações utiliza:
|
v A imagem
marca onde começam as informações novas ou alteradas.
|
v A imagem
marca onde terminam as informações novas ou alteradas.
|
|
Nos arquivos PDF, você poderá ver barras de revisão (|) na margem esquerda das informações novas ou
alteradas.
|
|
Para localizar outras informações sobre as novidades ou alterações neste release, consulte Memorando
para Usuários.
Arquivo PDF para Administração de Banco de Dados
Você pode visualizar e imprimir um arquivo PDF dessas informações.
Para visualizar ou fazer o download da versão em PDF deste documento, selecione Administração do
banco de dados.
Salvando Arquivos PDF
Para salvar um PDF em sua estação de trabalho para exibição ou impressão:
1. Clique com o botão direito do mouse no link do PDF no seu navegador.
2. Clique na opção que salva o PDF localmente.
3. Navegue para o diretório no qual deseja salvar o PDF.
4. Clique em Salvar.
Fazendo Download do Adobe Reader
É necessário ter o Adobe Reader instalado em seu sistema para visualizar ou imprimir esses PDFs. É
possível fazer download de uma cópia gratuita a partir do website da Adobe
(http://get.adobe.com/reader/)
© Copyright IBM Corp. 1998, 2015
.
1
Administração de Banco de Dados
O DB2 for i fornece vários métodos para configurar e gerenciar bancos de dados.
Conceitos relacionados:
Gerenciamento de Diário
Acessando Dados Através de Interfaces do Cliente
É possível acessar os dados do DB2 for i através de interfaces do cliente no servidor, tais como driver
Java Database Connectivity (JDBC), o driver Open Database Connectivity (ODBC), o IBM i Portable
Application Solutions Environment (IBM i PASE), o OLE DB Provider, o .Net Provider, o Net.Data, ou a
Distributed Relational Database Architecture (DRDA).
Acessando Dados com Java
Você pode acessar dados do DB2 for i em seus programas Java™ utilizando o driver JDBC (Java Database
Connectivity) que está incluído com o programa licenciado IBM Developer Kit para Java.
O driver permite executar as seguintes tarefas:
v Acessar arquivos do banco de dados.
v Acessar funções do banco de dados JDBC com SQL (Linguagem de Consulta Estruturada) incorporada
para Java.
v Executar instruções SQL e processar resultados.
Conceitos relacionados:
Acessando o Banco de Dados do System i5 com o IBM Developer Kit para Driver JDBC do Java
Acessando Dados com o Domino
Você pode utilizar o IBM Lotus Domino para i5/OS para integrar dados dos bancos de dados do DB2 for
i e bancos de dados do Domino em ambas as direções.
Para obter vantagem dessa integração, você precisa entender e gerenciar como as autorizações funcionam
entre os dois tipos de bancos de dados.
Conceitos relacionados:
Lotus Domino para i5/OS
Acessando Dados com o ODBC
Você utiliza o driver ODBC (IBM i Access para Windows Open Database Connectivity) para permitir que
aplicativos clientes ODBC compartilhem efetivamente dados entre si e com o servidor.
Conceitos relacionados:
Administração do ODBC
Acessando Dados com o IBM i PASE
O IBM i Portable Application Solutions Environment (IBM i PASE) é um ambiente de tempo de execução
integrado para AIX, UNIX ou outros aplicativos que estão em execução no sistema operacional do IBM i.
O IBM i PASE suporta a CLI (Interface de Nível de Chamada) do DB2 for i.
Conceitos relacionados:
Banco de Dados
Acessando Dados com o Provedor IBM i Access para Windows OLE DB
O Provedor IBM i Access para Windows OLE DB, junto com o Kit de Ferramentas do Programador,
facilita o desenvolvimento de aplicativos cliente/servidor do IBM i a partir do PC do cliente Microsoft
Windows.
2
IBM i: Administração de Banco de Dados
O Provedor IBM i Access para Windows OLE DB fornece interfaces de acesso no nível de registro dos
programadores para arquivos de banco de dados do DB2 for i. Além disso, ele fornece suporte para SQL,
filas de dados, programas e comandos.
Referências relacionadas:
Provedor OLE DB do System i Access para Windows
Acessando Dados com o IBM i Access para Windows .Net Provider
O acesso ao IBM i Access para Windows .Net Provider.
O IBM i Access para Windows .Net Provider permite o acesso ao DB2 para IBM i através da interface
Microsoft ADO.NET.
Acessando Dados com o Net.Data
O Net.Data é um aplicativo executado em um servidor. Você pode utilizar o Net.Data para criar
facilmente documentos da Web dinâmicos que são chamados de macros da Web. As macros da Web
criadas para o Net.Data têm a simplicidade de HTML com a funcionalidade de aplicativos CGI-BIN.
O Net.Data facilita a inclusão de dados ativos em páginas da Web estáticas. Dados ativos incluem
informações que estão armazenadas em bancos de dados, arquivos, aplicativos e serviços do sistema.
Conceitos relacionados:
Aplicativos Net.Data para o Servidor HTTP
Acessando Dados Através de uma Partição do Linux
A IBM e vários distribuidores Linux cooperaram para integrar o sistema operacional Linux com a
confiabilidade da arquitetura IBM i.
O Linux traz uma nova geração de aplicativos baseados na Web para o produto IBM i. A IBM modificou
o kernel Linux PowerPC para executar em uma partição lógica secundária e contribuiu para a volta do
kernel à comunidade Linux.
Acessando Dados Utilizando o DRDA (Distributed Relational Database
Architecture)
Um banco de dados relacional distribuído consiste em um conjunto de objetos SQL que são espalhados entre
sistemas de computador interconectados. Cada banco de dados relacional tem um gerenciador de banco
de dados relacional para gerenciar as tabelas em seu ambiente.
Os gerenciadores de banco de dados comunicam-se e cooperam entre si de forma que um determinado
gerenciador de banco de dados acesse as instruções SQL em execução em um banco de dados relacional
em outro sistema.
Referências relacionadas:
Função do Banco de Dados Relacional Distribuído e SQL
Alterando e Gerenciando Objetos de Banco de Dados
O DB2 for i fornece métodos SQL (Linguagem de Consulta Estruturada) e de sistema para alterar e
gerenciar os objetos de bancos de dados.
Há vários métodos disponíveis para trabalhar com objetos de banco de dados. É possível usar a interface
IBM Navigator for i, instruções SQL ou comandos do IBM i.
Conceitos relacionados:
Tarefas de Banco de Dados do Navegador do System i
Referências relacionadas:
Terminologia: Acesso de Arquivo SQL versus Tradicional
Administração
3
Criando Objetos de Banco de Dados
A primeira etapa no desenvolvimento do banco de dados é criar objetos que conterão os dados. Você
pode criar tabelas, visualizações e índices com SQL. Também pode criar arquivos físicos e lógicos
utilizando a interface de sistema tradicional.
Você pode criar objetos de banco de dados utilizando o IBM Navigator for i, o SQL ou a interface de
sistema tradicional.
Conceitos relacionados:
Tarefas de Banco de Dados do Navegador do System i
Referências relacionadas:
Terminologia: Acesso de Arquivo SQL versus Tradicional
Assegurando a Integridade dos Dados
O DB2 for i fornece diversas medidas de integridade, incluindo limitações, programas do acionador e
controle de comprometimento.
Restrições, acionadores e controle de comprometimento podem proteger seu banco de dados contra
inserções, exclusões e atualizações inadvertidas. As restrições dizem basicamente como os valores de
dados podem ser alterados, enquanto os acionadores são ações automáticas que iniciam ou acionam um
evento, como uma atualização de uma tabela específica.
Conceitos relacionados:
Controle de Consolidação
“Trabalhando com Acionadores e Restrições” na página 25
Você pode utilizar acionadores ou restrições para gerenciar dados nas tabelas de bancos de dados.
Importando e Exportando Dados entre Sistemas
Importar dados é o processo de recuperação de dados de origens externas, enquanto exportar dados é o
processo de extrair dados de DB2 for i e copiá-los para outro sistema.
Importar dados para o DB2 for i pode ser um evento único ou pode ser uma tarefa contínua, como
atualizações semanais com o objetivo de fazer relatórios comerciais. Esses tipos de operações de
movimentação de dados são normalmente realizados por meio das funções importar, exportar ou
carregar.
Conceitos relacionados:
Copiando um Arquivo
Copiando Arquivos
Copiando Dados do Arquivo de Origem
Movendo um Arquivo
Tarefas relacionadas:
Importando e Exportando Dados
Carregando e Descarregando Dados de Sistemas Diferentes do System i
Trabalhando com Vários Bancos de Dados
O sistema fornece um banco de dados do sistema (identificado como SYSBAS) e a habilidade para
trabalhar com um ou mais bancos de dados de usuários.
Os bancos de dados do usuário são implementados através do uso de conjuntos de discos independentes,
que são configurados na função de gerenciamento de disco doSystem i Navigator. Depois que um
conjunto de discos independente é configurado, ele é exibido como outro banco de dados na pasta Banco
de dados do System i Navigator.
4
IBM i: Administração de Banco de Dados
Quando você expande um sistema no System i Navigator e, em seguida, expande os Bancos de Dados, é
exibida uma lista de bancos de dados com os quais você pode trabalhar. Para estabelecer uma conexão
com um banco de dados, expanda o banco de dados com o qual deseja trabalhar.
Conceitos relacionados:
Gerenciamento de Disco
|
Trabalhando com tabelas temporais de período do sistema
|
|
|
|
Definir uma tabela temporal de período do sistema permite manter versões históricas de linhas da tabela.
Uma tabela temporal de período do sistema armazena as versões atuais de seus dados e utiliza sua sua
tabela de históricos associada para armazenar versões anteriores de linhas que foram atualizadas ou
excluídas.
|
|
|
|
|
|
|
|
|
|
Uma tabela temporal de período do sistema é uma tabela SQL que pode ser criada utilizando as
instruções SQL CREATE TABLE ou ALTER TABLE. O gerenciamento de histórico para a tabela funciona
para as duas instruções SQL de Data Manipulation Language (DML) e também para operações de E/S do
DB nativo. O gerenciador do banco de dados utiliza o período SYSTEM_TIME para preservar as versões
históricas de cada linha que é afetada por uma operação de atualização ou de exclusão. O gerenciador do
banco de dados armazena as versões históricas das linhas em uma tabela de históricos, que está associada
à tabela temporal de período do sistema. Uma tabela de alteração para incluir a versão estabelece o link
entre a tabela temporal de período do sistema e sua tabela de históricos. Ao fazer referência a apenas
uma tabela temporal de período do sistema, suas consultas têm acesso a seus dados no momento atual e
nos momentos passados.
|
|
|
Tabelas Temporais de Período do Sistema
|
|
|
As colunas de tempo inicial, tempo final e ID de início da transação devem ser criadas usando a cláusula
GENERATED ALWAYS AS. Quando esta cláusula é usada, o DB2 for i mantém os valores de registro de
data e hora nessas colunas.
|
Coluna de tempo inicial:
|
|
A coluna de tempo inicial representa a hora em que os dados na linha se tornaram atuais. Ela é definida
como um TIMESTAMP(12).
|
|
|
|
|
O gerenciador de banco de dados gera um valor para esta coluna utilizando uma leitura do relógio do
sistema. Se várias linhas forem inseridas ou atualizadas em uma única transação SQL, o valor para a
coluna de tempo inicial é gerado apenas uma vez, no momento da primeira instrução de mudança de
dados, e é utilizado como o valor de tempo inicial para todas as operações de mudança de dados nessa
transação.
|
|
|
Quando uma tabela existente é alterada para incluir uma coluna de tempo inicial, a coluna de tempo
inicial é preenchida com o valor padrão 0001-01-01-00.00.00.000000000000 para todas as linhas
existentes.
|
Coluna de tempo final:
|
A coluna de tempo final representa a hora em que os dados na linha não eram mais atuais.
|
|
|
As linhas na tabela temporal de período do sistema são, por definição, atuais, portanto, a coluna de
tempo final é preenchida com um valor padrão, o 9999-12-30-00.00.00.000000000000. Para linhas em
uma tabela de históricos, o valor na coluna de tempo final representa quando a linha foi incluída na
Uma tabela temporal de período do sistema deve ter uma coluna de tempo inicial, uma coluna de tempo
final, uma coluna de ID de início da transação e um período SYSTEM_TIME.
Administração
5
| tabela de históricos. Para obter mais informações sobre como este valor é definido para as linhas do
| tempo, consulte Atualizando os dados em uma tabela temporal de período do sistema e Excluindo dados
| em uma tabela temporal de período do sistema.
| Quando uma tabela existente é alterada para incluir uma coluna de tempo final, a coluna de tempo final
| é preenchida com o valor padrão 9999-12-30-00.00.00.000000000000 para todas as linhas existentes.
| ID de início de transação:
| A coluna de ID de início de transação captura o horário da primeira operação de mudança de dados na
| transação.
|
|
|
|
|
|
|
|
Se várias linhas forem inseridas ou atualizadas em uma única transação SQL, então, os valores para a
coluna de ID de início de transação serão os mesmos para todas as linhas e serão exclusivos dos valores
gerados para esta coluna por outras transações. Quando a coluna de ID de início da transação não for
nula, é possível usá-la para identificar todas as linhas nas tabelas que foram gravadas pela mesma
transação. Se o ID de início da transação for definido para permitir o valor NULL, ele é definido para um
valor apenas quando o ID de início da transação não corresponder ao valor da coluna de tempo inicial. A
diferença entre a o ID de início da transação e a coluna de tempo inicial tem mais explicações no tópico
Conflitos de valores de registro de data e hora da tabela temporal de período do sistema.
| Período SYSTEM_TIME:
| O período SYSTEM_TIME indica o período de tempo quando a versão de uma linha é atual.
| O período SYSTEM_TIME é definido por uma coluna de tempo inicial e uma coluna de tempo final.
|
|
|
|
|
|
Tabelas de históricos
|
|
|
|
|
As colunas na tabela de históricos e tabela temporal de período do sistema devem ter os mesmos exatos
nomes, ordem e tipos de dados. É possível criar uma tabela de históricos com os mesmos nomes e
definições como as colunas da tabela temporal de período do sistema, usando a cláusula LIKE da
instrução CREATE TABLE. Exemplo:
Cada tabela temporal de período do sistema está ligada a uma tabela de históricos. Quando uma linha é
atualizada ou excluída de uma tabela temporal de período do sistema, o gerenciador de banco do dados
insere uma cópia da linha antiga em sua tabela de históricos associada, com um registro de data e hora
do tempo final atualizado. Este armazenamento de dados anteriores da tabela temporal de período do
sistema fornece a capacidade de recuperar dados de momentos passados.
CREATE TABLE hist_policy_info LIKE policy_info;
| Uma tabela de históricos será sujeita às seguintes regras e restrições quando o versionamento estiver
| ativado:
| v Uma tabela de históricos não pode ser explicitamente eliminada. Ela só pode ser implicitamente
|
eliminada quando a tabela temporal do período do sistema associada for eliminada.
| v As colunas da tabela de históricos não podem ser explicitamente incluídas, eliminadas ou mudadas.
| v Uma tabela de históricos não pode ser definida como pai, filho ou de autorreferência em uma restrição
|
de referência.
|
|
|
|
Quando o versionamento é estabelecido, uma mudança para uma tabela temporal de período do sistema
causa uma mudança correspondente implícita na tabela de históricos. Por exemplo, se uma tabela
temporal de período do sistema é alterada para incluir uma coluna, a mesma coluna é incluída na tabela
de históricos.
6
IBM i: Administração de Banco de Dados
|
|
|
|
Como excluir dados em uma tabela de históricos pode prejudicar sua habilidade de auditar o histórico de
dados da tabela temporal de período do sistema, deve-se restringir o acesso a uma tabela de históricos
para proteger seus dados.
Referências relacionadas:
|
|
CREATE TABLE
ALTER TABLE
|
|
|
|
Criando uma tabela temporal de período do sistema
|
Ao criar uma tabela temporal de período do sistema, deve-se:
|
|
v Definir sua tabela nova ou existente para que ela possa ser usada como uma tabela temporal de
período do sistema:
Criar uma tabela temporal de período do sistema e uma tabela de históricos correspondente que estejam
em um relacionamento de versionamento resulta em duas tabelas que controlam quando as mudanças de
dados ocorrerão e preserva versões históricas desses dados.
|
|
– Definindo as colunas de tempo inicial, tempo final e ID de início da transação para o gerenciador do
banco de dados usar para manter os horários histórios para cada linha.
|
– Definindo um período SYSTEM_TIME para controlar quando uma linha é atual.
|
v Criar uma tabela de históricos para receber linhas antigas da tabela temporal de período do sistema.
|
|
v Incluir o versionamento para estabelecer o link entre a tabela temporal de período do sistema e a
tabela de históricos.
|
|
O exemplo na seção a seguir mostra a criação de uma tabela que armazena informações de política para
os clientes de uma empresa de seguros
|
Para criar uma tabela temporal de período do sistema
|
|
1. Crie uma tabela com as colunas de tempo inicial, tempo final e ID de início da transação e um
período SYSTEM_TIME.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
No exemplo a seguir, a tabela POLICY_INFO armazena informações sobre a cobertura de seguro de um
cliente. As colunas do período SYSTEM_TIME, SYS_START e SYS_END, mostram quando uma linha é
atual. A coluna TS_ID mostra o horário da primeira operação de mudança de dados na transação que
afetou a linha.
CREATE TABLE policy_info
( policy_id CHAR(4) NOT NULL,
coverage
INT NOT NULL,
sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,
sys_end
TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,
ts_id
TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID,
PERIOD SYSTEM_TIME (sys_start, sys_end) );
2. Crie uma tabela de históricos correspondente. É possível criar uma tabela de históricos com os
mesmos nomes de coluna e descrições que as colunas da tabela temporal de período do sistema,
usando a cláusula LIKE da instrução CREATE TABLE. Exemplo:
CREATE TABLE hist_policy_info LIKE policy_info;
3. Inclua o versionamento na tabela temporal de período do sistema para estabelecer um link com a
tabela de históricos. Exemplo:
ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info;
|
|
Quando todas as três etapas estiverem concluídas, a tabela de históricos HIST_POLICY_INFO recebe as
linhas antigas da tabela POLICY_INFO.
|
|
|
|
|
A cláusula ON DELETE ADD EXTRA ROW pode ser opcionalmente especificada na instrução ALTER
TABLE ADD VERSIONING. Se a cláusula for especificada, uma linha extra será inserida na tabela de
históricos quando uma linha é excluída da tabela temporal de período do sistema. Quando a linha
adicional é gravada na tabela de históricos, os valores das colunas de expressão geradas, incluindo a
coluna de tempo inicial e de tempo final, são gerados. Para obter mais informações sobre como ON
Administração
7
|
|
|
|
|
DELETE ADD EXTRA ROW pode ser usado para controlar informações de auditoria, consulte Usando
uma tabela temporal de período do sistema para controlar informações de auditoria.
Referências relacionadas:
CREATE TABLE
ALTER TABLE
| Exemplos adicionais de CREATE TABLE da tabela temporal de período do sistema:
| Exemplos adicionais incluem ocultar colunas e mudar uma tabela existente para uma tabela temporal de
| período do sistema.
| Ocultando colunas
|
|
|
|
|
As colunas tempo inicial, tempo final e ID de início da transação podem ser definidas como IMPLICITLY
HIDDEN. As colunas definidas como IMPLICITLY HIDDEN não aparecem na lista de seleção, a menos
que explicitamente referenciadas. Como os valores das colunas tempo inicial, tempo final e ID de início
da transação são gerados pelo gerenciador do banco de dados, ocultá-las pode minimizar qualquer
impacto em seus aplicativos existentes.
| Exemplo:
| v Uma consulta SELECT * executada com relação a uma tabela não retorna quaisquer colunas
|
implicitamente ocultas na tabela de resultados.
| v Uma instrução INSERT sem uma lista de coluna não espera que o valor padrão seja especificado para
|
quaisquer colunas ocultas implicitamente.
| O exemplo a seguir cria a tabela POLICY_INFO com as colunas TIMESTAMP(12) SYS_START, SYS_END e
| TS_ID definidas como ocultas implicitamente.
| CREATE TABLE policy_info
|
( policy_id CHAR(4) NOT NULL,
|
coverage
INT NOT NULL,
|
sys_start TIMESTAMP(12) NOT NULL
|
GENERATED ALWAYS AS ROW BEGIN
|
IMPLICITLY HIDDEN,
|
sys_end
TIMESTAMP(12) NOT NULL
|
GENERATED ALWAYS AS ROW END
|
IMPLICITLY HIDDEN,
|
ts_id
TIMESTAMP(12) NOT NULL
|
GENERATED ALWAYS AS TRANSACTION START ID
|
IMPLICITLY HIDDEN,
|
PERIOD SYSTEM_TIME (sys_start, sys_end) );
|
|
|
|
|
|
Criar a tabela de históricos HIST_POLICY_INFO usando a cláusula LIKE da instrução CREATE TABLE
resulta na tabela de históricos herdando o atributo oculto implicitamente da tabela POLICY_INFO. Se você
não usar a cláusula LIKE ao criar a tabela de históricos, então, quaisquer colunas definidas como ocultas
na tabela temporal de período do sistema também deverá ser definida como oculta na tabela de históricos
associada. Se as definições de coluna não corresponderem, você não será capaz de incluir o
versionamento.
| Mudando uma tabela existente para uma tabela temporal de período do sistema
| No exemplo a seguir, as três colunas de registro de data e hora e um período SYSTEM_TIME são
| incluídas na tabela existente, EMPLOYEES, preparando-a para ser usada como uma tabela temporal de
| período do sistema.
| ALTER TABLE employees
|
ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN
|
ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END
|
ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID
|
ADD PERIOD SYSTEM_TIME(sys_start, sys_end);
8
IBM i: Administração de Banco de Dados
|
|
Uma tabela de históricos deve ser criada e o versionamento incluído para terminar de ativar o rastreio de
linhas do tempo.
|
|
|
Inserindo dados em uma tabela temporal de período do sistema
|
|
|
|
O gerenciador do banco de dados gera automaticamente os valores das colunas de registro de data e hora
de tempo inicial e tempo final quandos os dados são inseridos em uma tabela temporal de período do
sistema. O gerenciador do banco de dados também gera o valor de ID de início da transação que
identifica exclusivamente a transação que está inserindo a linha.
|
|
Neste exemplo, os seguintes dados foram inseridos em 31 de janeiro de 2015 (31-01-2015) na tabela criada
no exemplo em Criando uma tabela temporal de período do sistema.
|
|
|
|
|
|
|
|
|
Insira três linhas na tabela POLICY_INFO.
|
|
A tabela POLICY_INFO agora contém os dados de cobertura de seguro na tabela a seguir. As entradas de
colunas SYS_START, SYS_END e TS_ID foram geradas pelo gerenciador do banco de dados.
|
Tabela 1. Dados na tabela temporal de período do sistema, POLICY_INFO, depois das instruções INSERT
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
B345
18000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
|
C567
20000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
Os valores de registro de data e hora SYS_START são os mesmos para todas as três linhas inseridas
recentemente porque, neste exemplo, as linhas foram inseridas como parte da mesma transação.
|
|
A tabela de históricos HIST_POLICY_INFO permanecerá vazia porque nenhuma linha do tempo é gerada
por uma inserção.
|
|
|
|
|
|
|
|
A coluna de tempo inicial, SYS_START, representa o horário em que a linha se tornou atual. O gerenciador
do banco de dados gera esse valor usando uma leitura do relógio do sistema no momento em que ele
executa a primeira instrução de mudança de dados na transação que gera a linha. O gerenciador do
banco de dados também gera a coluna de ID de início da transação TS_ID, que captura o horário quando
a execução iniciou para uma transação que afeta a linha. Na maioria dos casos, os valores de registro de
data e hora para essas duas colunas são os mesmos, porque eles são resultados da execução da mesma
transação. Se a coluna de ID de início da transação for definida para permitir o valor NULL, ele será
NULL quando o valor da coluna de ID de início da transação for idêntico à coluna de tempo inicial.
|
|
|
|
|
Quando várias transações estão atualizando a mesma linha, podem ocorrer conflitos de registro de data e
hora. O gerenciador do banco de dados pode resolver esses conflitos, ajustando os valores de registro de
data e hora da coluna de tempo inicial. Em tais casos, os valores na coluna de tempo inicial e na coluna
de ID de início da transação diferem. O tópico Conflitos de valor de registro de data e hora da tabela
temporal de período do sistema fornece mais detalhes sobre ajustes de registro de data e hora.
Inserir dados em uma tabela temporal de período do sistema é semelhante a inserir dados em uma tabela
comum.
INSERT INTO policy_info (policy_id, coverage)
VALUES(’A123’,12000);
INSERT INTO policy_info (policy_id, coverage)
VALUES(’B345’,18000);
INSERT INTO policy_info (policy_id, coverage)
VALUES(’C567’,20000);
Administração
9
| Referências relacionadas:
| INSERT
| Atualizando dados em uma tabela temporal de período do sistema
| A atualização de dados em uma tabela temporal de período do sistema resulta em linhas incluídas na
| tabela de históricos associada da tabela temporal de período do sistema.
|
|
|
|
|
Além disso, para atualizar os valores em linhas da tabela temporal de período do sistema, a instrução
UPDATE faz com que o gerenciador do banco de dados insira uma cópia da linha existente na tabela de
históricos associada. A linha do tempo é gerada como parte da mesma transação que atualiza a linha. Se
uma única transação atualiza a mesma linha várias vezes, apenas uma linha do tempo será gerada, e essa
linha reflete o estado do registro antes de quaisquer mudanças feitas pela transação.
| No exemplo a seguir, a cobertura de seguro de um cliente é aumentada em 28 de fevereiro de 2016
| (28-02-2016). Este exemplo usa a tabela criada em Criando uma tabela temporal de período do sistema
| com linhas que foram incluídas em Inserindo dados em uma tabela temporal de período do sistema.
| A tabela a seguir contém os dados da tabela POLICY_INFO antes da atualização.
|
Tabela 2. Dados na tabela temporal de período do sistema POLICY_INFO, antes da instrução UPDATE
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
B345
18000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
|
C567
20000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
| Atualize a cobertura para a política C567 para 25000.
| UPDATE policy_info
|
SET coverage = 25000
|
WHERE policy_id = ’C567’;
| A atualização para a política C567 afeta a tabela temporal de período do sistema e sua tabela de
| históricos, fazendo com que o seguinte ocorra:
| 1. O valor de cobertura para a linha com a política C567 é atualizado para 25000.
| 2. Na tabela temporal de período do sistema, o gerenciador do banco de dados atualiza os valores
|
SYS_START e TS_ID para o registro de data e hora da atualização, e o valor SYS_END fica inalterado.
| 3. A linha original é inserida na tabela de históricos. O gerenciador do banco de dados atualiza o valor
|
SYS_END para o registro de data e hora da atualização. Esta linha pode ser interpretada como a
|
cobertura válida para a política C567 de 2015-01-31-22.31.33.495925000000 para 2016-02-28|
09.10.12.649592000000.
|
Tabela 3. Dados na tabela temporal de período do sistema, POLICY_INFO, após a instrução UPDATE
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
B345
18000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
2016-02-2809.10.12.649592000000
10
IBM i: Administração de Banco de Dados
|
Tabela 4. Dados na tabela de históricos, HIST_POLICY_INFO, após a instrução UPDATE
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
|
C567
20000
2015-01-3122.31.33.495925000000
2016-02-2809.10.12.649592000000
2015-01-3122.31.33.495925000000
|
|
|
Se uma ou mais atualizações ocorrerem durante a execução sob o controle de compromisso, e o usuário
recuperar a transação, então, as atualizações para a tabela temporal de período do sistema e as inserções
na tabela de históricos são recuperadas.
|
|
|
|
|
|
|
Quando várias transações estão atualizando a mesma linha, podem ocorrer conflitos de registro de data e
hora. Quando esses conflitos ocorrerem, a configuração para a opção SYSTIME_PERIOD_ADJ QAQQINI
determina se os ajustes registro de data e hora são feitos ou se a transação falha. O tópico Conflitos de
valor de registro de data e hora da tabela temporal de período do sistema fornece mais detalhes sobre
ajustes de registro de data e hora. Os programadores de aplicativos podem considerar o uso dos valores
SQLCODE ou SQLSTATE para manipular os códigos de retorno relacionados ao ajuste do valor de
registro de data e hora a partir das instruções de atualização SQL.
|
Referências relacionadas:
|
ATUALIZAR
|
|
|
|
|
Excluindo dados em uma tabela temporal de período do sistema
|
|
|
|
No exemplo a seguir, o proprietário da política B345 decide cancelar a cobertura de seguro. Os dados
para o cliente foram excluídos no dia 1 de setembro de 2016 (01-09-2016) da tabela de exemplo criada no
tópico Criando uma tabela temporal de período do sistema e atualizados no tópicoAtualizando os dados
em uma tabela temporal de período do sistema.
|
A tabela a seguir contém os dados da tabela POLICY_INFO antes da exclusão.
|
Tabela 5. Dados na tabela temporal de período do sistema, POLICY_INFO, antes da instrução DELETE
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
B345
18000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
2016-02-2809.10.12.649592000000
|
|
A instrução a seguir exclui as informações de política para o ID de política B345.
|
|
A exclusão da política B345 afeta a tabela temporal de período do sistema e sua tabela de históricos,
fazendo com que o seguinte ocorra:
|
|
|
1. A linha original é copiada para a tabela de históricos. O gerenciador do banco de dados atualiza o
valor da coluna SYS_END para o registro de data e hora da primeira operação de mudança de dados na
transação.
|
|
2. A linha na qual o valor da coluna policy_id é B345 é excluída da tabela temporal de período do
sistema.
A exclusão de uma linha de uma tabela temporal de período do sistema remove a linha da tabela e inclui
uma ou duas linhas na tabela de históricos associada. A instrução DELETE copia a linha existente na
tabela de históricos associada antes que a linha seja excluída da tabela temporal de período do sistema.
As linhas na tabela de históricos são incluídas com os registros de data e hora do sistema apropriados.
DELETE FROM policy_info WHERE policy_id = ’B345’;
Administração
11
|
Tabela 6. Dados na tabela temporal de período do sistema, POLICY_INFO, após a instrução DELETE
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
2016-02-2809.10.12.649592000000
|
Tabela 7. Dados na tabela de históricos HIST_POLICY_INFO após a instrução DELETE
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
C567
20000
2015-01-3122.31.33.495925000000
2016-02-2809.10.12.649592000000
2015-01-3122.31.33.495925000000
2015-01-3122.31.33.495925000000
2016-09-0112.18.22.959254000000
2015-01-3122.31.33.495925000000
| B345
18000
|
|
| Referências relacionadas:
| EXCLUIR
|
|
|
|
Usando uma tabela temporal de período do sistema para controlar informações de
auditoria
Uma trilha de auditoria das mudanças que foram feitas para a tabela temporal de período do sistema
pode se tornar mais informativa com a adição de um ou mais colunas de expressão geradas.
| Alguns exemplos de informações de auditoria que podem ser controladas são
| v quando os dados foram modificados
| v quem modificou os dados
| v qual operação SQL modificou os dados.
|
|
|
|
Para controlar quando os dados foram modificados, defina a tabela como uma tabela temporal de
período do sistema. Para controlar quem e qual instrução SQL modificou os dados, use uma coluna de
expressão gerada. Para obter mais informações sobre colunas de expressão geradas disponíveis, consulte
CREATE TABLE.
| No exemplo a seguir, a tabela POLICY_INFO contém duas colunas extras. AUDIT_USER controla quem
| modificou os dados usando o registro especial SESSION USER. AUDIT_OP controla a operação SQL que
| modificou os dados usando a DATA CHANGE OPERATION.
|
CREATE TABLE policy_info
|
(policy_id CHAR(4) NOT NULL,
|
coverage
INT NOT NULL,
|
audit_user VARCHAR(128) GENERATED ALWAYS AS (SESSION USER),
|
audit_op
CHAR(1) GENERATED ALWAYS AS (DATA CHANGE OPERATION),
|
sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,
|
sys_end
TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,
|
ts_id
TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID,
|
PERIOD SYSTEM_TIME (sys_start, sys_end) );
|
| CREATE TABLE hist_policy_info LIKE policy_info;
|
| ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info
|
ON DELETE ADD EXTRA ROW;
| Cada linha na tabela temporal do sistema e sua tabela de históricos correspondente rastreia se a linha foi
| mudada por uma operação de inserção, atualização ou exclusão, e o nome do usuário que modificou a
| linha pela última vez.
12
IBM i: Administração de Banco de Dados
|
ON DELETE ADD EXTRA ROW
|
|
|
|
Se a clásula ON DELETE ADD EXTRA ROW for especificada na instrução ALTER TABLE ADD
VERSIONING, uma linha extra será inserida na tabela de históricos quando uma linha é excluída de uma
tabela temporal de período do sistema. Esta linha adicional contém informações sobre a própria operação
de exclusão.
|
|
|
|
|
|
|
|
|
|
|
|
O exemplo a seguir ilustra o valor de ON DELETE ADD EXTRA ROW. Este exemplo mostra uma série de três
transações. Em junho de 2014, USER1 insere uma linha na tabela do POLICY_INFO. Então, em janeiro de
2015, USER2 atualiza a linha. Finalmente, em agosto de 2015, USER3 exclui a linha:
|
|
|
|
|
Sem a cláusula ON DELETE ADD EXTRA ROW, essa série de transações gravaria somente as seguintes
duas entradas na tabela de históricos. A primeira entrada registra a linha como era antes de o USER2 ter
feito sua atualização, e a segunda entrada registra a linha como ela era antes de o USER3 ter feito a
exclusão. A operação de exclusão de registra a linha como existia na tabela temporal na última vez. Sem a
cláusula ON DELETE ADD EXTRA ROW, não há registro de auditoria da própria operação de exclusão.
|
|
Tabela 8. Dados na tabela de históricos, HIST_POLICY_INFO, após a instrução DELETE quando ON DELETE ADD EXTRA
ROW não for especificado
|
POLICY_ID
COVERAGE
AUDIT_USER
AUDIT_OP
SYS_START
SYS_END
TS_ID
|
|
A123
12000
USER1
T
2014-06-3122.31.33.495925
2015-01-3122.31.33.857632
2014-06-3122.31.33.495925
|
|
|
A123
25000
USER2
i
2015-01-3122.31.33.857632
2015-08-3122.31.33.634521
2015-01-3122.31.33.857632
|
|
|
|
|
Com a cláusula DELETE ADD EXTRA ROW incluída na instrução ADD VERSIONING, uma linha extra
gravada na tabela de históricos. Como os valores de tempo inicial e tempo final são gerados para a linha
extra, eles são o mesmo valor de registro de data e hora. Este registro de data e hora também
corresponde ao valor de tempo final da primeira linha inserida para a exclusão. Na tabela a seguir, essa
linha adicional é mostrada:
|
|
Tabela 9. Os dados na tabela de históricos, HIST_POLICY_INFO, após a instrução DELETE, quando ON DELETE ADD
EXTRA ROW é especificado
|
POLICY_ID
COVERAGE
AUDIT_USER
AUDIT_OP
SYS_START
SYS_END
TS_ID
|
|
A123
12000
USER1
T
2014-06-3122.31.33.495925
2015-01-3122.31.33.857632
2014-06-3122.31.33.495925
|
|
A123
25000
USER2
i
2015-01-3122.31.33.857632
2015-08-3122.31.33.634521
2015-01-3122.31.33.857632
|
|
|
|
A123
25000
USER3
d
2015-08-3122.31.33.634521
2015-08-3122.31.33.634521
2015-08-3122.31.33.634521
Referências relacionadas:
|
Criando colunas de auditoria
INSERT INTO policy_info (policy_id, coverage)
VALUES (’A123’,12000);
UPDATE policy_info
SET coverage = 25000
WHERE policy_id = ’A123’
DELETE FROM policy_info
WHERE policy_id = 'A123'
Administração
13
|
|
|
|
|
|
Conflitos de valor de registro de data e hora da tabela temporal de período do
sistema
O gerenciador do banco de dados irá impedir que uma linha do tempo de uma tabela temporal de
período do sistema seja gerada com um registro de data e hora de tempo final menor do que o registro
de data e hora de tempo inicial. Esse tipo de conflito pode ocorrer quando várias transações atualizaram
a mesma linha de uma tabela temporal de período do sistema.
| Um cenário de exemplo é mostrado na tabela abaixo. Os registros de data e hora para este exemplo
| foram simplificados como um item temporário, em vez de uma leitura do relógio do sistema de amostra.
|
Tabela 10. Transações simultâneas em uma tabela temporal de período do sistema
|
|
|
Data e Hora
Atuais
Transação A
Transação
A, valor
SYS_START
Transação B
Transação
B, valor
SYS_START
|
|
|
|
T1
|
|
|
|
T2
INSERT INTO
policy_info (policy_id,
coverage)
VALUES (’T888’,8000)
T2
|
T3
COMMIT
T2
|
|
|
T4
UPDATE policy_info
SET policy_id = ’X999’
WHERE policy_id = ’T888’
T1
|
|
T5
COMMIT
T1
|
|
|
|
|
|
Quando várias linhas são inseridas ou atualizadas na mesma transação, a coluna de tempo inicial é a
mesma para todas as linhas afetadas. O valor para o início da linha vem de uma leitura do relógio do
sistema no momento da primeira mudança de dados na transação. Na tabela acima, todas as linhas
inseridas ou atualizadas pela transação A possuem um registro de data e hora de tempo inicial de T1, e a
linha inserida pela transação B possui um registro de data e hora de tempo inicial de T2. No tempo T3, a
inserção da linha dois é confirmada com um registro de data e hora de tempo inicial de T2.
|
|
|
|
|
|
|
Quando a transação A atualiza a linha em que o POLICY_ID é igual a 'T888' no tempo T4, o registro
atualizado de data e hora de tempo inicial da linha é mudado para T1 porque a atualização ocorreu na
transação A. A linha original é inserida na tabela de históricos e o valor do registro de data e hora de
tempo final para a linha do tempo é atualizado para corresponder ao valor de registro de data e hora de
tempo inicial da linha atualizada, T1. O valor de tempo inicial da linha do tempo é T2. Isso resultaria em
uma linha do tempo com um valor de registro de data e hora de tempo final, T1, que é anterior ao seu
valor de registro de data e hora de tempo inicial, T2. Isso não é permitido.
|
|
|
|
|
|
|
|
|
|
A opção SYSTIME_PERIOD_ADJ QAQQINI determina qual ação o sistema executa quando uma linha do
tempo possui um registro de data e hora de tempo final que é menor que o registro de data e hora de
tempo inicial. O valor QAQQINI pode ser configurado para *ERROR ou *ADJUST, com *ERROR sendo o
valor padrão. Quando *ERROR é utilizado, um erro com SQLCODE -20528 e SQLSTATE 57062 será
retornado quando o valor de registro de data e hora de tempo final for menor que o valor de registro de
data e hora de tempo inicial. Quando *ADJUST é utilizado, um ajuste é feito para o valor de registro de
data e hora de tempo inicial e o registro de data e hora de tempo final, em vez de retornar um erro. Em
tais casos, os valores na coluna inicial da linha e a coluna de ID de início da transação serão diferentes.
Para obter mais informações sobre a opção SYSTIME_PERIOD_ADJ QAQQINI, consulte Desempenho e
otimização de consulta.
14
INSERT INTO
policy_info (policy_id,
coverage)
VALUES (’S777’,7000)
IBM i: Administração de Banco de Dados
T1
|
|
|
|
Outro exemplo de quando esta situação pode ocorrer é quando o relógio do sistema é ajustado. Isso pode
acontecer ao mudar o horário da conta para o horário de verão. Como no caso anterior, o valor da opção
QAQQINI deve determinar se um erro é retornado ou se os valores de registro de data e hora são
ajustados.
|
|
|
Consultando os dados temporais do período do sistema
|
Para consultar uma tabela temporal, é possível especificar os critérios de tempo de várias maneiras:
|
v em uma consulta usando explicitamente uma especificação de período SYSTEM_TIME,
|
|
v em uma consulta usando implicitamente o registro do sistema CURRENT TEMPORAL SYSTEM_TIME,
ou
|
v em uma definição de visualização.
|
Especificando os critérios de tempo em uma consulta:
|
|
Ao consultar uma tabela temporal de período do sistema, é possível incluir FOR SYSTEM_TIME na
cláusula FROM para consultar o estado atual e passado de seus dados.
|
|
Os períodos de tempo podem ser especificados de três maneiras:
v valorAS OF
|
|
|
|
|
|
|
|
|
|
|
|
Consultar uma tabela temporal de período do sistema pode retornar resultados para um determinado
ponto ou período no tempo. Os resultados podem incluir valores atuais e valores históricos anteriores.
Inclui cada linha para a qual o valor de tempo inicial é menor ou igual ao valor e o valor de tempo
final é maior que valor. Zero linhas são retornadas se o valor for o valor nulo.
v FROM value1 TO value2
Inclui linhas que existem completamente dentro do período que é especificado de value1 a value2. Uma
linha é incluída se o valor de tempo inicial for menor que value2 e o valor de tempo final for maior
que value1. Zero linhas são retornadas se value1 for maior ou igual a value2, ou se value1 ou value2
forem o valor nulo.
v BETWEEN value1 AND value2
Inclui linhas que se sobrepõem em qualquer momento entre value1 e value2. Uma linha é incluída se
seu valor de tempo inicial for menor ou igual a value2 e se o valor de tempo final for maior que value1.
Zero linhas são retornadas se value1 for maior que value2, ou se value1 ou value2 forem o valor nulo. Se
value1 = value2, a expressão será equivalente a AS OF value1.
|
Para obter informações detalhadas sobre períodos de tempo, consulte referência de tabela e Consultas.
|
Referências relacionadas:
|
SELECT
|
Exemplo: critérios de tempo na consulta:
|
|
Essas consultas de amostra solicitam informações de política a partir de uma tabela temporal de período
do sistema. Cada consulta usa uma variação da especificação FOR SYSTEM_TIME.
|
|
A tabela temporal POLICY_INFO e sua tabela de históricos associada que é usada nos exemplos contêm
estas linhas:
|
Tabela 11. Tabela temporal de período do sistema POLICY_INFO
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
2016-02-2809.10.12.649592000000
Administração
15
|
|
Tabela 12. Tabela de históricos HIST_POLICY_INFO
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
C567
20000
2015-01-3122.31.33.495925000000
2016-02-2809.10.12.649592000000
2015-01-3122.31.33.495925000000
| B345
18000
2015-01-312016-09-012015-01-31|
22.31.33.495925000000
12.18.22.959254000000
22.31.33.495925000000
|
| v
|
Consulta sem período especificado
|
SELECT policy_id, coverage, sys_start, sys_end
|
FROM policy_info
|
WHERE policy_id = ’C567’
|
Esta consulta retorna uma linha. A instrução SELECT consulta apenas a tabela POLICY_INFO. A tabela de
|
históricos não é consultada porque FOR SYSTEM_TIME não foi especificado.
|
Tabela 13. Resultado da consulta sem período especificado
|
POLICY_ID
| C567
|
|
| v
|
|
|
|
|
|
|
|
COVERAGE
SYS_START
SYS_END
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
Consulta com a cláusula FOR SYSTEM_TIME AS OF especificada
SELECT policy_id, coverage, sys_start, sys_end
FROM policy_info
FOR SYSTEM_TIME AS OF ’2016-02-28-09.10.12.649592000000’
Essa consulta retorna três linhas. A instrução SELECT consulta as tabelas POLICY_INFO e
HIST_POLICY_INFO. A coluna de tempo inicial do período é inclusiva, enquanto a coluna de tempo final
é exclusiva. A linha da tabela de históricos com um valor de coluna SYS_END de 2016-02-2809.10.12.649592000000 é igual ao valor AS OF, mas deve ser menor do que o valor a ser retornado
|
Tabela 14. Resultado da consulta com um período FOR SYSTEM_TIME AS OF especificado
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
|
|
A123
12000
2015-01-3122.31.334959250000
9999-12-3000.00.00.000000000000
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
| B345
|
|
| v
18000
2015-01-3122.31.33.495925000000
2016-09-0112.18.22.959254000000
|
|
|
|
|
|
|
|
Consulta com FOR SYSTEM_TIME FROM...TO especificado.
SELECT policy_id, coverage, sys_start, sys_end
FROM policy_info
FOR SYSTEM_TIME FROM ’0001-01-01-00.00.00.000000000000’
TO ’9999-12-30-00.00.00.000000000000’
WHERE policy_id = ’C567’
Essa consulta retorna duas linhas. A instrução SELECT consulta as tabelas POLICY_INFO e
HIST_POLICY_INFO.
|
Tabela 15. Resultado da consulta com FOR SYSTEM_TIME FROM...TO especificado.
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
16
IBM i: Administração de Banco de Dados
|
Tabela 15. Resultado da consulta com FOR SYSTEM_TIME FROM...TO especificado. (continuação)
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
|
|
|
|
|
|
|
|
|
|
|
|
|
|
C567
20000
2015-01-3122.31.33.495925000000
2016-02-2809.10.12.649592000000
v
Consulta com FOR SYSTEM_TIME BETWEEN...AND especificado.
SELECT policy_id, coverage
FROM policy_info
FOR SYSTEM_TIME BETWEEN ’2016-02-28-09.10.12.649592000000’
AND ’9999-12-30-00.00.00.000000000000’
Essa consulta retorna três linhas. A instrução SELECT consulta as tabelas POLICY_INFO e
HIST_POLICY_INFO. As linhas com um valor de coluna SYS_START de 2016-02-28-09.10.12.649592000000
são iguais ao value1 e são retornadas porque o horário de início de um período é incluído. As linhas
com um valor de coluna SYS_END de 2016-02-28-09.10.12.649592000000 são iguais a value1 e não são
retornadas porque o horário de encerramento de um período não é incluído.
|
Tabela 16. Resultado da consulta com FOR SYSTEM_TIME BETWEEN...AND especificado.
|
POLICY_ID
COVERAGE
|
A123
12000
|
C567
25000
|
|
B345
18000
|
|
Especificando os critérios de tempo usando o registro especial CURRENT TEMPORAL
SYSTEM_TIME:
|
|
|
Usar o registro especial CURRENT TEMPORAL SYSTEM_TIME para especificar o tempo AS OF para
uma consulta pode reduzir ou eliminar as mudanças que são necessárias para executar um aplicativo em
momentos diferentes.
|
|
|
|
|
|
|
Quando você tem um aplicativo que deseja executar em uma tabela temporal de período do sistema para
consultar o estado de seus dados para várias datas diferentes, é possível configurar a data em um registro
especial. Se você precisar consultar os dados a partir de hoje, desde o final do último trimestre ou a partir
da mesma data do ano passado, poderá não ser possível mudar o aplicativo para incluir especificações
AS OF para cada instrução SQL. Esta restrição é provavelmente o caso em que você está usando
aplicativos empacotados. Para abordar tais cenários, é possível usar o registro especial SYSTEM_TIME
TEMPORALCURRENT para configurar o registro de data e hora no nível da tarefa.
|
|
|
Configurar o registro especial SYSTEM_TIME TEMPORAL CURRENT não afeta as tabelas não temporais.
Apenas consultas em tabelas temporais com versionamento ativado usam o tempo definido no registro
especial. Não há impacto também nas instruções DDL.
|
|
|
Quando o registro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor não
nulo, os aplicativos que emitem uma consulta em qualquer tabela temporal de período do sistema retorna
dados a partir dessa data ou registro de data e hora.
|
|
|
|
|
|
Quando o registro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor não
nulo, as instruções de modificação de dados, como INSERT, UPDATE e DELETE na tabela temporal de
período do sistema são bloqueadas, porque, se o registro especial for configurado para algum momento
no passado, por exemplo, há cinco anos, então, permitir as operações de modificação de dados pode
resultar em mudanças em seus registros de dados históricos. Modificar a tabela de históricos não é
permitido.
Administração
17
|
|
|
|
|
|
|
|
Os comandos do pré-compilador CRTSQLxxx possuem uma opção sensível à hora do sistema, que indica
se as referências às tabelas temporais de período do sistema em instruções SQL estáticas e dinâmicas são
afetadas pelo valor do registro especial CURRENT TEMPORAL SYSTEM_TIME. Esse comportamento
pode também ser especificado para os programas SQL, procedimentos ou funções pela opção SYSTIME
na instrução SET OPTION. O padrão é *SYSTIME. Todos os programas SQL e programas de serviço que
foram criados antes do 7.3 são considerados *NOSYSTIME. Quando o valor for *SYSTIME, o registro
especial será aplicado às instruções que fazem referência às tabelas temporais de período do sistema.
Quando o valor for *NOSYSTIME, o registro especial será ignorado.
| Referências relacionadas:
| CURRENT TEMPORAL SYSTEM_TIME
| Exemplo: critérios de tempo especificados usando o registro especial CURRENT TEMPORAL SYSTEM_TIME:
| Essas consultas de amostra solicitam informações de política de uma tabela temporal de período do
| sistema para um momento específico, usando o registro especial CURRENT TEMPORAL SYSTEM_TIME.
| A tabela temporal POLICY_INFO e sua tabela de históricos associada que é usada nos exemplos são:
|
Tabela 17. Tabela temporal de período do sistema POLICY_INFO
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
2016-02-2809.10.12.649592000000
|
Tabela 18. Tabela de históricos HIST_POLICY_INFO
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
C567
20000
2015-01-3122.31.33.495925000000
2016-02-2809.10.12.649592000000
2015-01-3122.31.33.495925000000
| B345
|
|
| v
18000
2015-01-3122.31.33.495925000000
2016-09-0112.18.22.959254000000
2015-01-3122.31.33.495925000000
|
|
|
|
|
|
|
|
|
|
|
|
Exemplo 1: Configure o registro especial CURRENT, TEMPORAL SYSTEM_TIME para um ano anterior
ao registro de data e hora. Suponha um registro de data e hora atual de 2016-05-1714.45.31.434235000000.
SET CURRENT TEMPORAL SYSTEM_TIME = CURRENT TIMESTAMP – 1 YEAR;
A consulta a seguir da tabela temporal de período do sistema retorna resultados a partir de um ano
atrás.
SELECT policy_id, coverage FROM policy_info;
Como POLICY_INFO é uma tabela temporal de período do sistema e o registro especial CURRENT
TEMPORAL SYSTEM_TIME não é nulo, a consulta é executada como:
SELECT policy_id, coverage FROM policy_info
FOR SYSTEM_TIME AS OF CURRENT TEMPORAL SYSTEM_TIME;
A instrução SELECT consulta as tabelas POLICY_INFO e HIST_POLICY_INFO, e retorna:
|
Tabela 19. Resultado de consulta com um registro especial configurado.
|
POLICY_ID
COVERAGE
|
A123
12000
|
C567
20000
|
|
B345
18000
18
IBM i: Administração de Banco de Dados
|
|
|
|
|
|
|
|
|
|
|
|
v
|
Tabela 20. Resultado de consulta com um registro especial configurado.
|
POLICY_ID
COVERAGE
|
A123
12000
|
C567
25000
|
|
|
|
|
|
|
|
|
|
|
|
B345
18000
|
|
|
|
Exemplo 2: Configure o registro especial CURRENT, TEMPORAL SYSTEM_TIME para um registro de
data e hora, e referencie uma tabela temporal de período do sistema nas definições de visualização.
CREATE VIEW coverage AS SELECT policy_id, coverage FROM policy_info;
SET CURRENT TEMPORAL SYSTEM_TIME = TIMESTAMP(’2016-02-28-09.10.12.649592000000’);
SELECT * FROM coverage;
Como a visualização faz referência a POLICY_INFO, que é uma tabela temporal de período do sistema, e
o CURRENT TEMPORAL SYSTEM_TIME está configurado, a referência de tabela na visualização
possui FOR SYSTEM_TIME AS OF CURRENT TEMPORAL SYSTEM_TIME implicitamente incluído nele. A
instrução SELECT consulta as tabelas POLICY_INFO e HIST_POLICY_INFO, e retorna:
v Exemplo 3: Configure o registro especial CURRENT TEMPORAL SYSTEM_TIME e faça referência a
uma tabela temporal de período do sistema em uma subseleção.
CREATE VIEW customer_policy AS SELECT * FROM customer_info
WHERE cust_policy_id IN (SELECT policy_id FROM policy_info);
SET CURRENT TEMPORAL SYSTEM_TIME = TIMESTAMP(’2016-02-28-09.10.12.649592000000’);
SELECT * FROM customer_policy;
A consulta neste exemplo envolve uma visualização em uma tabela não temporal de período do
sistema que faz referência a uma tabela temporal de período do sistema.
O registro especial CURRENT TEMPORAL SYSTEM TIME é aplicado a todas as tabelas temporais de
período do sistema em uma visualização. Ele é ignorado para qualquer outra referência de tabela. Para
esta consulta de uma visualização, FOR SYSTEM_TIME AS OF CURRENT TEMPORAL SYSTEM TIME é
implicitamente incluído na referência de tabela POLICY_INFO.
|
|
|
|
|
|
|
|
|
v Exemplo 4: Configure o registro especial e execute uma consulta que contém uma especificação de
período. Esta é uma consulta inválida.
|
Especifique os critérios de tempo para uma visualização:
|
|
|
|
Uma especificação de período A FOR SYSTEM_TIME que segue o nome de uma visualização em uma
referência de tabela se aplica a todas as referências de tabela temporal de período do sistema na definição
dessa visualização. Se a visualização não acessa nenhuma tabela temporal, a especificação do período não
entra em vigor na tabela de resultados da visualização.
|
|
Uma referência de visualização seguida por uma especificação de período não deve incluir uma função
externa que não seja NO SQL, ou uma função SQL que não seja capaz sequencialmente.
|
|
Para consultar uma visualização que faz referência a uma tabela temporal, use um dos seguintes
métodos:
|
|
v Especifique uma especificação de período SYSTEM_TIME seguindo o nome de uma visualização na
cláusula FROM de uma consulta.
SET CURRENT TEMPORAL SYSTEM_TIME = CURRENT TIMESTAMP - 1 YEAR;
SELECT * FROM policy_info FOR SYSTEM_TIME AS OF TIMESTAMP(’2016-02-28-09.10.12.649592000000’);
Um erro é retornado porque há várias especificações de período. O registro especial foi definido para
um valor não nulo e a consulta também especificou um horário. Quando a consulta usa uma cláusula
FOR SYSTEM_TIME, o registro especial CURRENT TEMPORAL SYSTEM_TIME deve ser o valor
NULL.
Administração
19
| v Use o registro especial CURRENT TEMPORAL SYSTEM_TIME. Neste caso, não se deve incluir uma
|
especificação de período na consulta.
| Exemple: critérios de tempo na visualização:
| Essas consultas de amostra solicitam informações de política a partir de uma visualização criada em uma
| tabela temporal de período do sistema.
| A tabela temporal POLICY_INFO e sua tabela de históricos associada que é usada nos exemplos são:
|
Tabela 21. Tabela temporal de período do sistema POLICY_INFO
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
A123
12000
2015-01-3122.31.33.495925000000
9999-12-3000.00.00.000000000000
2015-01-3122.31.33.495925000000
|
|
|
C567
25000
2016-02-2809.10.12.649592000000
9999-12-3000.00.00.000000000000
2016-02-2809.10.12.649592000000
|
Tabela 22. Tabela de históricos HIST_POLICY_INFO
|
POLICY_ID
COVERAGE
SYS_START
SYS_END
TS_ID
|
|
C567
20000
2015-01-3122.31.33.495925000000
2016-02-2809.10.12.649592000000
2015-01-3122.31.33.495925000000
|
|
|
B345
18000
2015-01-3122.31.33.495925000000
2016-09-0112.18.22.959254000000
2015-01-3122.31.33.495925000000
|
|
|
|
|
|
|
|
|
|
Exemplo 1: crie uma visualização COVERAGE que faz referência à tabela temporal de período do sistema
POLICY_INFO. Em seguida, consulte a visualização e identifique uma especificação de período FOR
SYSTEM_TIME para retornar linhas que eram atuais a partir de um ano atrás. Suponha um registro de
data e hora atual de 2016-05-17-14.45.31.434235000000.
CREATE VIEW coverage AS
SELECT policy_id, coverage
FROM policy_info;
SELECT * FROM coverage
FOR SYSTEM_TIME AS OF CURRENT TIMESTAMP - 1 YEAR;
| A instrução SELECT consulta as tabelas POLICY_INFO e HIST_POLICY_INFO, e retorna:
|
Tabela 23. Resultado da consulta de uma visualização que tem uma especificação de período.
|
POLICY_ID
COVERAGE
|
A123
12000
|
C567
20000
|
|
B345
18000
| Exemplo 2: crie uma visualização COVERAGE que faz referência a uma tabela temporal de período do
| sistema POLICY_INFO e retorna linhas que eram atuais a partir de um ano atrás.
| CREATE VIEW coverage AS
|
SELECT policy_id, coverage
|
FROM policy_info
|
FOR SYSTEM_TIME AS CURRENT TIMESTAMP - 1 YEAR;
|
| SELECT * FROM coverage;
| A consulta dessa visualização sempre retorna linhas que eram atuais A PARTIR DE um ano atrás.
| Assumindo um registro de data e hora atual de 2016-05-17-14.45.31.434235000000, a consulta retorna os
| mesmos resultados que os resultados que foram retornados no exemplo um.
20
IBM i: Administração de Banco de Dados
|
|
|
|
Restrições ao inserir, atualizar ou excluir dados em uma tabela temporal de
período do sistema
|
Restrições para cursores e UPDATE/DELETE WHERE CURRENT OF
|
|
|
|
|
|
Um cursor FOR UPDATE não pode ser definido se inclui uma especificação de período na tabela
identificada na cláusula FROM. O exemplo a seguir retorna um erro:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Se a cláusula FOR UPDATE for removida da instrução DECLARE CURSOR e uma especificação de
período for definida, o cursor se tornará somente leitura. Se uma instrução UPDATE WHERE CURRENT
OF ou DELETE WHERE CURRENT OF for usada para tentar atualizar ou excluir linhas na tabela
temporal de período do sistema e sua tabela de históricos associada, um erro será retornado. O exemplo a
seguir retorna um erro:
|
|
|
|
A atualização retorna um erro porque ela implicitamente tenta atualizar linhas do tempo. A instrução
SELECT consulta explicitamente a tabela POLICY_INFO e consulta implicitamente sua tabela de históricos
associada, HIST_POLICY_INFO. As linhas em uma tabela de históricos que são acessadas implicitamente não
podem ser atualizadas.
|
Restrições para inserir, atualizar e excluir dados em uma visualização
|
|
|
|
|
|
|
Inserções, atualizações e exclusões não são permitidas em relação a uma visualização que tem uma
especificação de período definida. Por exemplo, a instrução UPDATE a seguir retornaria um erro:
|
|
|
|
|
|
|
|
|
|
|
|
|
A atualização retorna um erro porque ela implicitamente tenta atualizar linhas do tempo. No entanto, é
possível criar, em vez disso, um acionador de atualização para atualizar a tabela temporal de período do
sistema. Exemplo:
|
|
Um erro não será retornado porque o acionador direciona a atualização para a tabela temporal de
período do sistema, em vez de direcionar para a visualização.
Uma inserção, atualização ou exclusão não pode ser feita quando a inserção, atualização ou exclusão
tentar mudar implicitamente as linhas do tempo.
DECLARE updateCursor CURSOR FOR
SELECT coverage
FROM policy_info FOR SYSTEM_TIME AS OF ’2015-01-31-22.31.33.495925000000’
FOR UPDATE;
CREATE OR REPLACE PROCEDURE updateProc
LANGUAGE SQL
BEGIN
DECLARE val1 INTEGER;
DECLARE updateCursor CURSOR FOR
SELECT coverage
FROM policy_info FOR SYSTEM_TIME AS OF ’2015-01-31-22.31.33.495925000000’;
OPEN updateCursor;
FETCH updateCursor INTO val1;
UPDATE policy_info SET coverage = coverage + 1000
WHERE CURRENT OF updateCursor;
CLOSE updateCursor;
END;
CREATE VIEW coverage AS
SELECT policy_id, coverage
FROM policy_info FOR SYSTEM_TIME AS OF TIMESTAMP(’2016-02-28-09.10.12.649592000000’);
UPDATE coverage SET coverage = coverage + 1000 WHERE policy_id = ’C567’;
CREATE TRIGGER coverage_update_iot INSTEAD OF UPDATE ON coverage
REFERENCING NEW AS N OLD AS O
FOR EACH ROW MODE DB2SQL
BEGIN
UPDATE policy_info
SET policy_id = n.policy_id, coverage = n.coverage
WHERE policy_id = o.policy_id AND coverage = o.coverage;
END;
UPDATE coverage SET coverage = coverage + 1000 WHERE policy_id = ’C567’;
Administração
21
| Considerações de E/S nativa com uma tabela temporal de período do sistema
| O processamento de E/S nativo de operações de leitura, gravação e atualização é, em geral, semelhante
| às operações SQL correspondentes. No entanto, há algumas considerações para se ter em mente.
|
|
|
|
|
|
|
|
|
|
|
As operações de atualização e exclusão nativas e de SQL relacionadas a uma tabela temporal de período
do sistema fazem com que as linhas do tempo sejam incluídas em uma tabela de históricos. Além disso,
se a cláusula ON DELETE ADD EXTRA ROW for especificada no comando ALTER TABLE, as operações
de exclusão de SQL e nativa incluirão uma linha extra quando um registro for excluído da tabela. Da
mesma forma, o valor QAQQINI para SYSTIME_PERIOD_ADJ tem o mesmo efeito sobre atualizações
simultâneas nativas, pois ele tem operações SQL de atualização simultâneas. Para nativo e SQL, o valor
QAQQINI faz com que o banco de dados crie um erro ou ajuste aos registros de data e hora de tempo
inicial e tempo final. Um aplicativo do DB nativo recebe uma exceção CPF503B, código de razão 3,
quando o valor SYSTIME_PERIOD_ADJ está definido como *DEFAULT ou *ERROR, e um UPDATE
nativo fará com que o valor do horário de encerramento da linha do tempo seja definido para um valor
que é menor que o horário inicial da linha do tempo.
| Dito isso, várias diferenças entre o processamento nativo e de SQL merecem atenção.
|
|
|
|
|
|
Enquanto as solicitações de leitura nativas trabalham em relação à tabela temporal e de históricos, elas
não mesclam os resultados. Apenas os registros do arquivo lido são retornados. Por exemplo, quando o
registro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor não nulo, uma
leitura de SQL da tabela temporal pode retornar as linhas que são desenhadas a partir da tabela temporal
e sua tabela de históricos correspondente. No entanto, para uma leitura nativa da tabela temporal, o
banco de dados ignora o registro especial e retorna valores apenas da tabela temporal.
|
|
|
|
|
Quando o registro especial CURRENT TEMPORAL SYSTEM_TIME é configurado como um valor não
nulo, a instruções SQL Data Manipulation (DML) falham com SQLCODE/SQLSTATE configurado como
-20535/51046. Um usuário SQL é incapaz de modificar os dados da tabela temporal. No entanto,
nenhuma restrição semelhante existe para um usuário nativo. As operações de gravação, atualização e
exclusão nativas modificam a tabela temporal se o registro especial estiver configurado ou não.
|
|
|
|
Finalmente, uma gravação ou atualização nativa pode especificar valores no buffer de E/S das colunas
geradas do período SYSTEM_TIME e outras colunas geradas, se existirem. No entanto,
independentemente de quais valores são fornecidos no buffer de E/S, o DB2 for i substitui os valores
corretos para quaisquer colunas geradas.
|
|
|
|
Mantendo a tabela de históricos
|
|
|
|
|
É necessário compreender o valor de suas linhas individuais. Algum conteúdo, como contratos do cliente,
pode ser intocável, nunca podendo ser excluído. Outros registros, como informações do visitante do
website, podem ser removidos sem preocupação. Muitas vezes não é a idade de uma linha que determina
quando ela pode ser removida e arquivada, em vez disso, uma lógica de negócios que é o fator decisivo.
A lista a seguir contém algumas regras possíveis para remoção:
Como as tabelas de históricos passam por mais inserções que exclusões, suas tabelas de históricoss
podem se tornar grandes. Decidir como remover suas tabelas de históricos para livrar-se das linhas que
não são mais necessárias pode ser uma tarefa complexa.
| v Remover linhas que são selecionadas por uma consulta fornecida pelo usuário, que reflete as regras de
|
negócios.
| v Remover linhas mais antigas do que uma certa idade.
| v Remover linhas do tempo quando mais de N versões existirem para esse registro (reter apenas as N
|
versões mais recentes).
| v Remover linhas do tempo quando o registro é excluído da tabela temporal do período de sistema
|
associada (quando versões atuais não existirem).
22
IBM i: Administração de Banco de Dados
|
|
|
|
Existem várias maneiras de remover dados antigos periodicamente a partir de uma tabela de históricos.
Uma maneira de remover dados é o particionamento de intervalo na tabela de históricos. Partições
antigas podem, então, ser removidas da tabela de históricos e arquivadas ou excluídas. Para obter mais
informações, consulte Particionando uma tabela temporal de período do sistema.
|
|
|
|
Particionando uma tabela temporal de período do sistema
|
|
Quando o versionamento está ativado, os seguintes comportamentos são aplicados ao conectar ou
desconectar uma partição a uma tabela temporal de período do sistema:
|
Conectando partições
|
|
v Em uma partição única, a tabela particionada pode ser conectada a uma tabela temporal de período do
sistema como uma partição enquanto o versionamento está ativado.
|
|
|
v A tabela conectada deve ter as mesmas definições de coluna que a tabela temporal de período do
sistema, incluindo as três colunas de registro de data e hora definidas como ROW BEGIN, ROW END
e START TRANSACTION ID.
|
v A tabela conectada não requer uma definição de período SYSTEM_TIME.
|
Desconectando partições
|
|
|
|
|
v Uma partição não pode ser desconectada de uma tabela temporal de período do sistema enquanto o
versionamento estiver ativado. É possível eliminar o versionamento e, em seguida, desconectar uma
partição da tabela base. A partição desconectada se torna uma partição única independente, tabela
particionada. Desconectar uma partição de uma tabela de históricos não requer que você elimine o
versionamento.
|
|
v Uma partição desconectada retém todas as três colunas de registro de data e hora (ROW BEGIN, ROW
END e START TRANSACTION ID), mas não a definição do período SYSTEM_TIME.
|
Referências relacionadas:
|
tabelas particionadas
|
|
|
|
Controle de acesso de linha e coluna com uma tabela temporal de período do
sistema
|
|
|
|
|
|
|
|
O controle de acesso de linha e coluna (RCAC) é uma camada de segurança de dados que controla o
acesso a uma tabela no nível de linha, nível de coluna, ou ambos. O RCAC pode ser aplicado às tabelas
temporais de período do sistema e às tabelas de históricos. Quando o RCAC é ativado para uma tabela
temporal de período do sistema, o gerenciador do banco de dados ativa automaticamente o controle de
acesso de linha na tabela de históricos e cria uma permissão de linha padrão para a tabela de históricos.
Esta permissão de linha padrão impede qualquer acesso direto à tabela de históricos. Quando a tabela de
históricos é protegida pela permissão de linha padrão, as atualizações e exclusões ainda geram linhas do
tempo na tabela de históricos.
|
|
|
|
|
|
Quando uma consulta temporal é executada com relação a uma tabela temporal de período do sistema, as
permissões de linha e as máscaras de coluna da tabela temporal de período do sistema também são
aplicadas às linhas retornadas da tabela de históricos. Por exemplo, se uma permissão de linha é definida
para uma tabela temporal de período do sistema e uma consulta com uma cláusula FOR SYSTEM_TIME AS
OF é executada, ambas as linhas atuais e do tempo são retornadas quando a linha atual ou do tempo
satisfaz a regra RCAC da tabela temporal e era atual desde o horário especificado.
Uma tabela temporal de período do sistema pode ter seus dados da tabela divididos em várias partições.
Uma tabela de históricos que está associada a uma tabela temporal de período do sistema também pode
ser particionada.
O controle de acesso de linha e coluna pode ser definido em uma tabela temporal de período do sistema
e sua tabela de históricos associada.
Administração
23
|
|
|
|
|
|
|
|
Se a tabela de históricos possui apenas uma permissão padrão, não será possível consultá-la diretamente.
No entanto, se uma regra de linha ou coluna diferente da permissão padrão também estiver definida na
tabela de históricos, essa regra será aplicada quando a tabela de históricos for acessada diretamente.
Portanto, se você precisar consultar a tabela de históricos diretamente, será possível criar uma permissão
de linha ou máscara de coluna na tabela de históricos que corresponde à permissão de linha ou máscara
que foi criada na tabela temporal de período do sistema. Quando a permissão de linha ou máscara de
coluna é criada, é possível consultar a tabela de históricos diretamente enquanto também controla o
acesso aos dados.
| Para obter mais informações sobre o RCAC, consulte Controle de acesso de linha e coluna (RCAC).
| Salvando e restaurando as tabelas temporais de período do sistema
| A tabela temporal de período do sistema e sua tabela de históricos devem ser explicitamente salvas. O
| gerenciador do banco de dados não salva os dois arquivos quando apenas um dos arquivos está salvo.
|
|
|
|
|
|
|
|
|
Quando uma tabela temporal de período do sistema é restaurada sem a sua tabela de históricos
correspondente, ou uma tabela de históricos é restaurada sem sua tabela temporal de período do sistema
correspondente, o relacionamento de versionamento da tabela restaurada permanece definido, mas não
está estabelecido. Quando isso acontece, o status do versionamento da tabela é mudado para o estado
definido. Uma mensagem informativa CPI3231 é emitida quando um status do versionamento da tabela
temporal de período do sistema é mudado para o estado definido. Há restrições para as ações que podem
ser executadas em uma tabela temporal de período do sistema ou uma tabela de históricos quando a
tabela está no estado definido. Inserções, atualizações e exclusões são evitadas. A maioria das mudanças
de DDL também são evitadas. As únicas operações que são permitidas são:
| v ALTER TABLE ADD VERSIONING
| v ALTER TABLE DROP VERSIONING
| v DROP TABLE
|
|
|
|
|
|
|
Para determinar se uma tabela temporal de período do sistema está no estado definido, é possível
consultar a visualização de catálogo QSYS2/SYSPERIODS. Para determinar se uma tabela de históricos
está no estado definido, é possível consultar a visualização de catálogo QSYS2/SYSHISTORYTABLES.
Ambas as visualizações possuem a coluna VERSIONING_STATUS, que contém um 'E' se um
relacionamento de versionamento entre a tabela temporal de período do sistema e a tabela de históricos
foi estabelecido, ou um 'D' se um relacionamento de versionamento entre a tabela temporal de período
do sistema e a tabela de históricos foi definido, mas não estabelecido.
| Para obter mais informações, consulte Salvando arquivos físicos que são temporais e Restaurando
| arquivos físicos que são temporais.
|
|
|
|
Usando catálogos para localizar informações sobre a tabela temporal de período
do sistema
Há várias visualizações de catálogo que contêm informações sobre a tabela temporal de período do
sistema.
| v QSYS2/SYSTABLES
|
|
|
Contém uma coluna denominada TEMPORAL_TYPE. Quando o valor é configurado como “S”, a tabela é
uma tabela temporal de período do sistema. Quando ele for configurado como “H”, a tabela é uma
tabela de históricos. O valor “N” é usado para todas as outras tabelas.
| v QSYS2/SYSCOLUMNS
|
Contém uma coluna chamada HAS_DEFAULT. Esta coluna indica o tipo de coluna gerada.
| v QSYS2/SYSPERIODS
|
|
Contém uma linha para cada tabela com um período do sistema e identifica as informações
temporárias e de versão.
| v QSYS2/SYSHISTORYTABLES
24
IBM i: Administração de Banco de Dados
|
Contém uma linha para cada tabela de históricos.
|
|
Restrições da tabela temporal
|
A seguir estão as restrições para tabelas temporais de período do sistema:
|
|
|
v A tabela temporal de período do sistema e sua tabela de históricos devem estar no mesmo esquema.
v Para atualizar ou excluir dados de uma tabela temporal de período do sistema com versionamento,
tanto a tabela temporal como seu arquivo histórico devem ser registrados.
|
|
v As instruções SQL ALTER ou CREATE OR REPLACE TABLE que causam uma perda potencial de
dados não são suportadas em tabelas temporais de período do sistema.
|
v As operações a seguir não são permitidas para tabelas temporais de período do sistema:
As tabelas temporais de período do sistema estão sujeitas a várias restrições.
|
– ALTER TABLE DROP COLUMN
|
– ALTER TABLE ADD GENERATED COLUMN
|
v A instrução TRUNCATE não é suportada em relação a uma tabela temporal de período do sistema.
|
|
|
v Uma tabela distribuída também não pode ser uma tabela temporal de período do sistema.
v As seguintes operações de consulta não são permitidas em relação a uma tabela temporal de período
do sistema:
|
|
|
– Uma especificação de período não pode ser feita dentro de uma consulta que faz referência a uma
tabela distribuída, uma tabela com um acionador de leitura, que usa a sequência de classificação do
ICU 2.6.1, ou se tiver mais de 1000 referências de tabela.
|
– Uma especificação de período não pode ser feita para um arquivo lógico nativo.
|
|
– Uma especificação de período não pode ser feita para uma tabela ou visualização que faz referência
a uma coluna em uma função CONTAINS ou SCORE.
|
|
|
– Uma especificação de período não pode ser feita para uma visualização em que a definição da
visualização inclui uma função externa que não seja NO SQL ou uma função SQL que não seja
capaz sequencialmente.
Trabalhando com Acionadores e Restrições
Você pode utilizar acionadores ou restrições para gerenciar dados nas tabelas de bancos de dados.
Um acionador é um tipo de programa que é chamado automaticamente sempre que uma ação especificada
é executada em uma tabela específica. Os acionadores são úteis para manter as trilhas de auditoria,
detectar condições excepcionais, manter relacionamentos no banco de dados e executar aplicativos e
operações que coincidem com a operação de alteração.
|
|
|
|
Como alternativa, as colunas geradas podem ser utilizadas em vez de um acionador manter informações
de auditoria. Para obter mais informações sobre como utilizar as colunas geradas para auditoria, consulte
“Usando uma tabela temporal de período do sistema para controlar informações de auditoria” na página
12.
Uma restrição é uma restrição ou limitação colocada no banco de dados. As restrições são implementadas
no nível da tabela. Você pode utilizar as restrições para criar integridade de referência no banco de dados.
Você pode trabalhar com acionadores e restrições utilizando o IBM Navigator for i, o SQL ou a interface
de sistema tradicional.
Conceitos relacionados:
Tarefas de Banco de Dados do Navegador do System i
Gravando Programas do DB2
O DB2 for i fornece vários métodos para gravação de aplicativos que acessam ou atualizam dados.
Administração
25
Você pode gravar programas de SQL incorporados, funções externas, procedimentos externos, aplicativos
CLI do DB2 for i e programas do acionador.
Conceitos relacionados:
Programação de SQL Integrada
Gravando um DB2 para Aplicativo CLI do i5/OS
Tarefas relacionadas:
Criando Programas do Acionador
Referências relacionadas:
Definindo um Procedimento Externo
Gravando UDFs como Funções Externas
Backup e Recuperação do Banco de Dados
Salvar os dados podem exigir tempo e requer disciplina. Entretanto, é crucial fazer o backup dos dados,
pois nunca se sabe quando será necessário fazer uma recuperação deles.
Conceitos relacionados:
Backup e Recuperação
Gerenciamento de Diário
Recuperando e Restaurando seu Banco de Dados
Administração de Banco de Dados Distribuída
Com o DB2 for i, você pode trabalhar com bancos de dados que são distribuídos entre vários sistemas.
Conceitos relacionados:
Programação do Banco de Dados Distribuído
Consultas e Relatórios
Você pode utilizar o SQL, o comando Abrir Arquivo de Consulta (OPNQRYF), a API de Consulta
(QQQQRY), o Open Database Connectivity (ODBC) ou o programa licenciado IBM Query for i para criar
e executar consultas.
Uma das tarefas mais comuns executadas com o banco de dados é a recuperação de informações. O
sistema fornece vários métodos para criar e executar consultas e relatórios.
Você pode utilizar uma instrução SQL para recuperar informações. Essa instrução SQL é chamada query.
A consulta faz procuras nas tabelas armazenadas no banco de dados para localizar a resposta à pergunta
enviada com a instrução SQL. A resposta é expressa como um conjunto de linhas, conhecido como
conjunto de resultados. Após a execução de uma consulta, você também pode criar um relatório para
exibir os dados fornecidos no conjunto de resultados.
Além disso, para utilizar o SQL, você pode utilizar outras funções e produtos para criar e executar
consultas e relatórios. Consulte as seguintes informações para obter detalhes.
v Visão Geral do IBM DB2 Web Query para IBM i
v Consulta para IBM i
v Query Management Programming
v Query Manager Use
26
IBM i: Administração de Banco de Dados
Além disso, você pode construir as instruções SQL SELECT, INSERT, UPDATE e DELETE na janela
Assistente de SQL do System i Navigator.
Conceitos relacionados:
Programação de SQL
Tarefas relacionadas:
Construindo Instruções SQL com o Assistente de SQL
Referências relacionadas:
comando Abrir Arquivo de Consulta (OPNQRYF)
API de Consulta (QQQQRY)
Segurança
Autorizar os usuários a dados no sistema e a níveis de dados permite controlar o acesso ao banco de
dados.
A proteção de banco de dados requer que você estabeleça o direito à propriedade e a autoridade pública
aos objetos e à autoridade específica para os aplicativos.
Conceitos relacionados:
Programas de Saída do Controle de Acesso do Servidor DRDA
Concedendo Autoridade de Arquivo e dos Dados
Limitando Acesso a Campos Específicos em um Arquivo de Banco de Dados
Segurança
Especificando Autoridade Pública
Utilizando Recursos de Arquivo de Banco de Dados para Controlar as Operações de E/S
Utilizando Arquivos Lógicos para Proteger os Dados
Opções de Autoridade para Análise e Ajuste de SQL
Este tópico descreve as opções de autoridade para análise e ajuste de SQL.
O DB2 for i possui um rico conjunto de comandos, procedimentos armazenados, APIs e ferramentas para
análise e ajuste dos aspectos de desempenho dos aplicativos de banco de dados. Anteriormente, um
responsável pela segurança do sistema precisaria conceder autoridade especial de usuário *JOBCTL para
possibilitar que analistas e administradores de banco de dados utilizassem as ferramentas de banco de
dados. Como a autoridade *JOBCTL permite que um usuário altere muitas configurações críticas do
sistema que não estão relacionadas à atividade do banco de dados, não era uma decisão fácil para os
responsáveis pela segurança conceder esta autoridade. Em alguns casos, esta era uma decisão fácil e
*JOBCTL não era concedido aos analistas de banco de dados, proibindo assim o uso do conjunto integral
das ferramentas de banco de dados.
Nota: Para obter mais informações sobre substituições de configuração para o arquivo QAQQINI,
consulte o link a seguir: Suporte para Substituição do Arquivo QAQQINI.
Agora, o responsável pela segurança possui a capacidade adicional de autorizar o acesso às ferramentas
de análise de banco de dados e ao Cache de Planos SQL. O DB2 for i que aproveita a vantagem da
capacidade de uso da função disponível no sistema operacional. Um novo grupo de uso da função
chamado QIBM_DB foi criado com os IDs de função no grupo QIBM_DB:
1. QIBM_DB_SQLADM (tarefas do Administrador de Banco de Dados)
2. QIBM_DB_SYSMON (tarefas de Informações do Banco de Dados)
3. QIBM_DB_DDMDRDA (Acesso de Servidor de Aplicativos DDM & DRDA)
4. QIBM_DB_ZDA (Acesso de Servidor de Aplicativos da Caixa de Ferramentas)
Administração
27
5. QIBM_DB_SECADM (Administrador de Segurança de Banco de Dados)
O responsável pela segurança agora tem a flexibilidade para conceder autoridades: conceder a autoridade
especial *JOBCTL ou autorizar um usuário ou grupo para a Função de Administrador de Banco de Dados
do IBM i através de Administração de Aplicativos no System i Navigator do IBM Navigator for i. O
comando Change Function Usage (CHGFCNUSG), com um ID de função de QIBM_DB_SQLADM,
também pode ser utilizado para alterar a lista de usuários que têm permissão para executar operações de
Administração de Banco de Dados. Os controles de uso de função permitem que grupos ou usuários
específicos tenham a autoridade permitida ou negada. O comando CHGFCNUSG também fornece um
parâmetro que pode ser utilizado para conceder autoridade de uso de função para qualquer usuário que
possua a autoridade especial de usuário *ALLOBJ. (por exemplo, ALLOBJAUT(*USED))
A função Administrador de Banco de Dados é necessária sempre que um usuário está analisando e
visualizando dados de desempenho de SQL. Algumas das funções mais comuns são a exibição de
instruções do Cache de Planos SQL, a análise dos Monitores de Desempenho de SQL e de Capturas
Instantâneas do Cache de Planos SQL e a exibição dos detalhes de SQL de uma tarefa que não a sua
própria.
O uso da função de administrador de banco de dados é uma alternativa para a concessão de *JOBCTL,
mas ela não substitui o requisito de possuir a autoridade de objeto correta. Para ativar tarefas do
administrador de banco de dados que não estão relacionadas à análise de desempenho, consulte a tarefa
específica para obter detalhes sobre os requisitos de autorização. Por exemplo, para permitir que um
administrador reorganize uma tabela, é necessário que ele tenha autoridades de objeto concedidas, que
não são cobertas pelo QIBM_DB_SQLADM.
Além do QIBM_DB_SQLADM, o comando Change Function Usage (CHGFCNUSG), com um ID de
função de QIBM_DB_SYSMON, também pode ser utilizado para alterar a lista de usuários que têm
permissão para executar operações de Informações do Banco de Dados.
A função Informações do Banco de Dados fornece muito menos autoridade do que a de Administrador
de Banco de Dados. O uso principal é permitir que um usuário examine propriedades de banco de dados
de alto nível. Por exemplo, um usuário que não possui *JOBCTL ou QIBM_DB_SQLADM, poderia ter
permissão para visualizar as propriedades do Cache de Planos SQL se recebesse a concessão de
autoridade para QIBM_DB_SYSMON.
Para trabalhar com o uso da função de grupo de bancos de dados QIBM_DB do System i Navigator, siga
estas etapas:
1. Ative Application Administration, conforme mostrado na figura 1.
2. Expanda as pastas ‘IBM i' e ‘Database' sob a guia Host Applications, conforme mostrado na figura 2.
3. Customize o uso da função Database Administrator (QIBM_DB_SQLADM), conforme mostrado na
figura 3.
Neste exemplo, o responsável pela segurança determinou que desejava configurar um grupo denominado
Dbagroup que conteria todos os usuários para os quais desejava fornecer este nível de autoridade. E ele
desejou explicitamente negar o acesso para Slfuser. Agora, o responsável pela segurança possui um local
conveniente e facilmente monitorado para visualizar e autorizar usuários a estas funções.
Figura 1. Ative Application Administration.
28
IBM i: Administração de Banco de Dados
Figura 2. Expanda o grupo Database
Administração
29
Figura 3. Altere as configurações de uso da função QIBM_DB_SQLADM
30
IBM i: Administração de Banco de Dados
A Tabela 1 descreve algumas das mudanças de autorização relacionadas aos comandos, Procedimentos
Armazenados e APIs do DB2.
Tabela 24. Requisitos de Autorização para Desempenho e Análise do Banco de Dados
Ação do Usuário
*JOBCTL
Sem
QIBM_DB_SQLADM QIBM_DB_SYSMON Autoridade
SET CURRENT DEGREE (instrução
SQL)
Permitido
Permitido
Não Permitido
Não Permitido
Comando CHGQRYA objetivando uma Permitido
tarefa de um usuário diferente
Permitido
Não Permitido
Não Permitido
Comandos STRDBMON ou
ENDDBMON objetivando uma tarefa
de um usuário diferente
Permitido
Permitido
Não Permitido
Não Permitido
Comandos STRDBMON ou
ENDDBMON objetivando uma tarefa
que corresponde ao usuário atual
Permitido
Permitido
Permitido
Permitido
API QUSRJOBI() formato 900 ou
Detalhes SQL do System i Navigator
para a Tarefa
Permitido
Permitido
Permitido
Não Permitido
Administração
31
Tabela 24. Requisitos de Autorização para Desempenho e Análise do Banco de Dados (continuação)
Ação do Usuário
*JOBCTL
Sem
QIBM_DB_SQLADM QIBM_DB_SYSMON Autoridade
Procedimento DUMP PLAN CACHE
PROPERTIES
Permitido
Permitido
Permitido
Não Permitido
Visual Explain dentro de Executar
Scripts SQL
Permitido
Permitido
Permitido
Permitido
Visual Explain fora de Executar Scripts Permitido
SQL
Permitido
Não Permitido
Não Permitido
Procedimento ANALYZE PLAN
CACHE
Permitido
Permitido
Não Permitido
Não Permitido
Procedimento DUMP PLAN CACHE
Permitido
Permitido
Não Permitido
Não Permitido
Procedimento MODIFY PLAN CACHE Permitido
Permitido
Não Permitido
Não Permitido
Procedimento MODIFY PLAN CACHE Permitido
PROPERTIES (atualmente não verifica
a autoridade)
Permitido
Não Permitido
Não Permitido
Procedimento CHANGE PLAN
CACHE SIZE (atualmente não verifica
a autoridade)
Permitido
Permitido
Não Permitido
Não Permitido
Procedimento START PLAN CACHE
EVENT MONITOR
Permitido
Permitido
Não Permitido
Não Permitido
Procedimento END PLAN CACHE
EVENT MONITOR
Permitido
Permitido
Não Permitido
Não Permitido
Procedimento END ALL PLAN
CACHE EVENT MONITORS
Permitido
Permitido
Não Permitido
Não Permitido
Row and Column Access Control (RCAC)
O Row and column access control (RCAC) fornece uma alternativa centralizada em dados para atingir a
segurança de dados.
O RCAC coloca o controle de acesso no nível da tabela em torno de si mesmo. As regras SQL criadas em
linhas e colunas são a base da implementação deste recurso.
Termos do RCAC
v Tabela base - A tabela (arquivo físico), a permissão ou máscara é incluída.
v Objeto dependente - Qualquer referência a objeto (arquivo, esquema, função ou outro objeto),
permissão ou máscara.
v QIBM_DB_SECADM – O uso da função identifica o usuário que deve estar autorizado para manipular
todas as ações relacionadas a permissões e máscaras.
v Row and Column Access Control (RCAC) – O controle de acesso é o recurso para controlar o acesso
aos dados usando permissões e máscaras.
v Permissão - Uma permissão de linha define uma regra de controle de acesso de linha para linhas de
uma tabela.
v Máscara - Uma máscara de coluna define uma regra de controle de acesso da coluna para uma coluna
específica em uma tabela.
v RULETEXT – A expressão a ser usada pela permissão ou máscara.
v 5770-SS1 IBM Advanced Data Security for i (Opção 47) – O produto que precisa ser solicitado e
instalado para poder:
– criar permissões de linha.
32
IBM i: Administração de Banco de Dados
– criar máscaras de coluna.
– executar acesso ao banco de dados por meio de objetos que têm RCAC ativo.
Visão Geral
IBM Advanced Data Security for i apresenta RCAC como uma camada extra de segurança de dados.
O RCAC fornece controle de acesso a uma tabela no nível baixo, nível da coluna ou ambos. O RCAC
pode ser usado para complementar o modelo de privilégios da tabela. Para estar em conformidade com
vários regulamentos do governo, é possível implementar procedimentos e métodos para assegurar que as
informações estejam protegidas adequadamente. Os indivíduos em sua organização têm acesso permitido
a somente o subconjunto de dados que é necessário para executar suas atividades de trabalho. Por
exemplo, os regulamentos do governo em sua área podem declarar que um médico está autorizado a
visualizar os registros médicos de seus próprios pacientes, mas não de outros pacientes. Os mesmos
regulamentos também podem declarar que, a menos que um paciente dê seu consentimento, um
provedor de assistência médica não terá acesso permitido a informações pessoais do paciente, como o
número do telefone residencial dos pacientes. É possível usar o RCAC para assegurar que seus usuários
só tenham acesso aos dados necessários para seu trabalho. Por exemplo, o RCAC pode filtrar informações
e dados do paciente para incluir somente esses dados, que um determinado médico está autorizado a
visualizar.
Outros pacientes não existem até onde sabe o médico. Da mesma forma, quando um representante de
serviço do paciente consulta a tabela do paciente no mesmo hospital, ele pode visualizar as colunas nome
do paciente e número de telefone, mas a coluna histórico médico é mascarada para eles. Se os dados
forem mascarados, um valor NULL ou alternativo será exibido em vez de o histórico médico real. O
RCAC possui as vantagens a seguir:
1. Nenhum usuário do banco de dados está isento inerentemente das regras do RCAC. Mesmo
autoridades de alto nível, como usuários com toda a autoridade de objeto (autoridade especial (como
*ALLOBJ)) não estão isentos dessas regras. Somente usuários com a autoridade QIBM_DB_SECADM
podem gerenciar o RCAC em um banco de dados. Portanto, é possível usar o RCAC para impedir
que os usuários com autoridade de objeto total acessem todos os dados em um banco de dados.
2. Os dados da tabela são protegidos independentemente de como uma tabela é acessada. Aplicativos,
ferramentas de consulta e de geração de relatórios improvisadas estão todas sujeitas às regras de
controle de acesso. A execução é centralizada nos dados.
3. Nenhuma mudança de aplicativo é necessária para aproveitar esta camada adicional de segurança de
dados. O RCAC é estabelecido e definido de modo que não fica aparente aos aplicativos existentes.
Entretanto, o RCAC representa uma mudança importante no paradigma no sentido de que não é mais
o que está sendo perguntado, mas sim quem perguntou. Mesmo que dois usuários possam executar o
que parece serem consultas idênticas, quando predicados de permissão de linha são incluídos na
consulta, esses dois usuários podem observar um conjunto de resultados diferente. Este
comportamento é o intento exato da solução. Significa que os editores de telas e DBAs devem estar
cientes de que as consultas não veem toda a imagem em termos de dados na tabela a menos que a
autorização ao RCAC seja concedida.
4. Antes dos controles do RCAC para a proteção de dados centralizada em dados, os usuários do DB2
for i protegeriam os dados por meio da criação de várias visualizações SQL ou arquivos lógicos
Select-omit. Embora esta técnica de confiar em uma visualização/arquivo lógico para limitar dados
atinja o objetivo, ela cria vários problemas:
a. Os aplicativos tinham de ser copiados para funcionar com visualizações especializadas, em vez de
um objeto comum.
b. Em grandes instalações, o número de visualizações que existem para este propósito cresce
rapidamente para um número grande, resultando em considerações de gerenciamento de objetos
adicional como Salvar/Restaurar.
c. O responsável pela segurança tem de passar um tempo ajustando autorizações para muitos
objetos.
Administração
33
d. Para arquivos lógicos select-omit, o DB2 for i tem de gastar ciclos de processamento para manter
cada arquivo lógico select-omit atualizado conforme o(s) objeto(s) subjacente(s) muda(m).
Além de atingir os benefícios dos dados naturalmente protegidos ao implementar o RCAC, os clientes do
DB2 for i podem aposentar as muitas visualizações que existem unicamente para proteger dados.
IBM Advanced Data Security for i
IBM Advanced Data Security for i é uma opção instalável que é usada para gerenciar políticas de
segurança reforçando o RCAC com permissões e máscaras.
Se o IBM Advanced Data Security for i não estiver instalado, consulte Instalando, Fazendo Upgrade ou
Excluindo o IBM i/OS® e Software Relacionado para obter informações sobre instalar programas
licenciados extra. Para instalar o IBM Advanced Data Security for i, use a opção 47 na lista de opções
instaláveis para o sistema operacional.
Tabelas que contêm permissões ou máscaras ativadas do RCAC podem ser restauradas
independentemente se o IBM Advanced Data Security for i está instalado ou não. Entretanto, se a opção
não estiver instalada, as permissões e máscaras não poderão ser criadas e as tabelas, visualizações ou
índices que contêm permissões ou máscaras ativas não poderão ser acessados.
Separação de Obrigações
A separação de obrigações ajuda as empresas a estarem em conformidade com os regulamentos do
mercado ou requisitos organizacionais e simplifica o gerenciamento de autoridades. A separação de
obrigações geralmente é usada para impedir atividades fraudulentas ou erros por uma única pessoa. Ela
fornece a capacidade para que funções administrativas sejam divididas entre indivíduos sem sobrepor as
responsabilidades, para que um usuário não possua autoridade ilimitada, como com a autoridade
*ALLOBJ.
Por exemplo, suponha que um negócio tenha designado a responsabilidade de gerenciar a segurança no
IBM i para Theresa. Antes da liberação do IBM i 7.2, para conceder privilégios, Theresa tinha de ter os
mesmos privilégios que estava concedendo. Assim, para conceder privilégios *USE à tabela PAYROLL,
Theresa tinha de ter as autoridades *OBJMGT e *USE (ou um nível superior de autoridade, como
*ALLOBJ). Este requisito permitiu que Theresa acessasse os dados na tabela PAYROLL mesmo que a
descrição do cargo dela fosse somente gerenciar a segurança.
No IBM i 7.2, o uso da função, QIBM_DB_SECADM, fornece a um usuário a capacidade de conceder a
autoridade, revogar a autoridade, alterar a propriedade ou alterar o grupo primário. Isso é feito sem dar
acesso ao objeto ou, no caso de uma tabela de banco de dados, aos dados que estão na tabela ou
permitindo outras operações na tabela. O uso da função QIBM_DB_SECADM só pode ser concedido por
um usuário com autoridade especial *SECADM e pode ser atribuído a um usuário ou grupo.
QIBM_DB_SECADM também é responsável por administrar o RCAC. O RCAC restringe quais linhas um
usuário tem permissão de acesso em uma tabela e se um usuário tem permissão de ver informações em
certas colunas de uma tabela.
A melhor prática é que o administrador do RCAC tenha o uso da função QIBM_DB_SECADM e
absolutamente nenhum privilégio de dados. O administrador do RCAC pode implementar e manter os
construtos do RCAC e seria incapaz de conceder a si mesmo o acesso não autorizado aos dados.
Permissões e Máscaras
O RCAC é um modelo no qual um administrador de segurança gerencia políticas de privacidade e
segurança.
34
IBM i: Administração de Banco de Dados
O RCAC permite que todos os usuários acessem a mesma tabela, ao contrário de visualizações
alternativas de uma tabela. RCAC, no entanto, restringe o acesso aos dados na tabela, baseada nas
permissões de usuário individual ou regras, conforme especificado por uma política que está associada à
tabela. Há dois conjuntos de regras. Um conjunto de regras opera em linhas (permissões) e o outro em
colunas (máscaras). Para criar permissões e máscaras, o IBM Advanced Data Security for i deve ser
instalado.
Permissão de linha
v Uma permissão de linha define uma regra de controle de acesso de linha para uma tabela específica.
v Uma regra de controle de acesso de acesso de linha é uma condição de procura SQL que descreve qual
conjunto de linhas um usuário pode acessar.
v A definição de cada permissão de linha pode referenciar o usuário ou grupo na condição de procura.
Se diversas permissões de linha forem definidas para uma tabela e o controle de acesso de linha estiver
ativado, a condição de procura em cada permissão de linha será conectada pelo operador OR lógico
para formar a condição de procura do controle de acesso de linha. Essa condição de procura de
controle de acesso de linha é aplicada sempre que a tabela é acessada. Ela atua como um filtro na
tabela antes de quaisquer outras operações especificadas pelo usuário, como predicados e ordenação
são processados. Ela atua como a cláusula WITH CHECK OPTION de uma visualização para assegurar
que uma linha seja inserida ou atualizada conforme as definições das permissões de linha em uma
instrução INSERT, UPDATE ou MERGE.
Máscara de coluna
v Uma máscara de coluna define uma regra de controle de acesso da coluna para uma coluna específica
em uma tabela.
v Uma regra de controle de acesso de coluna é uma expressão CASE SQL que descreve quais valores de
coluna um usuário tem permissão de ver e sob quais condições.
v A definição de cada máscara de coluna pode referenciar o usuário ou grupo nas condições de procura
na cláusula CASE WHEN. Embora diversas colunas em uma tabela possam ter máscaras de coluna,
somente uma máscara de coluna pode ser criada para uma única coluna. Quando o controle de acesso
de coluna é ativado para a tabela, a expressão CASE na definição de máscara de coluna é aplicada na
coluna de saída para determinar os valores mascarados retornados para um aplicativo. O aplicativo de
máscaras de coluna afeta o resultado final somente. Isso não impacta as operações, como predicados e
ordenação em uma instrução SQL.
O RCAC pode ser ativado para uma tabela antes ou após as permissões de linha ou máscaras de coluna
serem criadas para a tabela. Se as permissões de linha ou máscaras de coluna existirem, ativar o controle
de acesso de linha e coluna simplesmente torna as permissões ou máscaras efetivas. Se as permissões de
linha ainda não existirem, ativar o controle de acesso de linha para uma tabela significa que o DB2 for i
gera uma permissão de linha padrão que impede qualquer acesso aos dados na tabela.
Instruções SQL
As instruções criar, alterar e eliminar SQL suportam a implementação de RCAC com permissões e
máscaras.
v Criar Permissão
v Alterar Permissão
v Eliminar Permissão
v Criar Máscara
v Alterar Máscara
v Eliminar Máscara
v Alterar Função
v Alterar Acionador
v Alterar Tabela
Administração
35
Autorização
O ID de autorização da instrução SQL deve estar autorizado à função de Administrador de Segurança do
Banco de Dados do IBM i. Consulte Autoridade administrativa.
Funções Protegidas
As funções devem ser definidas como protegidas antes de poderem ser chamadas nas definições do
RCAC.
O atributo SECURED é necessário se o UDF for referenciado na definição de uma permissão de linha ou
máscara de coluna, porque o UDF terá acesso aos dados antes do aplicativo do RCAC. O atributo
SECURED também é necessário para um UDF que é chamado em uma instrução SQL quando os
argumentos da função referenciam colunas que estão ativadas com o controle de acesso da coluna.
Proteger Acionadores
Os acionadores definidos em uma tabela com o RCAC ativado devem estar protegidos.
O atributo SECURED é necessário para um acionador quando a tabela associada possui o RCAC ativado
ou a visualização associada cuja tabela subjacente está ativada com o RCAC. Se um acionador existir, mas
não estiver protegido, o RCAC não poderá ser ativado para a tabela associada.
Autoridade administrativa
A autorização para a função de Administrador de Segurança de Banco de Dados do IBM i pode ser
designado por meio de um Administração do Aplicativo em IBM Navigator for i.
O comando Change Function Usage Information (CHGFCNUSG), com um ID da função de
QIBM_DB_SECADM, pode ser usado para alterar a lista de usuários autorizados.
Melhores Práticas ao Usar Permissões e Máscaras
As permissões e máscaras podem ser criadas para uma tabela em um número de implementações
diferentes. Esta seção explicará algumas das implementações que podem ser usadas para criar permissões
e máscaras.
Criando Permissões e Máscaras
Um número de considerações precisa ser determinado para decidir a melhor forma de criar permissões
ou máscaras.
Criar permissões ou máscaras quando o row or column access control está ativo
A tarefa que está criando a permissão ou máscara obtém um bloqueio restrito na tabela base. Se o row or
column access control estiver ativo, a tabela base não terá permissão de leitura até a criação da permissão
ou máscara estar concluída. Os aplicativos que leem a tabela base precisam ser encerrados até que as
permissões ou máscaras sejam incluídas.
Criando permissões ou máscaras quando o row or column access control não está ativo
A tarefa que está criando a permissão ou máscara obtém um bloqueio restrito na tabela base. Entretanto,
a tabela base tem permissão de ser lida até que o row or column access control seja ativado. Os
aplicativos que leem a tabela base não têm de ser encerrados.
Única Permissão com Todos os Usuários:
Exemplo 1: Usando uma única permissão com todos os usuários definidos na permissão.
36
IBM i: Administração de Banco de Dados
CREATE SCHEMA MY_LIB
CREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)
CREATE PERMISSION MY_LIB.PERM1 ON MY_LIB.PERMISSION_TABLE FOR ROWS WHERE
VERIFY_GROUP_FOR_USER(CURRENT_USER,’USER1’,’USER2’,’USER3’) = 1
ENFORCED FOR ALL ACCESS ENABLE
ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL
/***************************************************************/
/*
Conecte-se como USER1
*/
/***************************************************************/
INSERT INTO MY_LIB.PERMISSION_TABLE VALUES(1) /* Permitido.
*/
A vantagem de uma única permissão é o melhor desempenho da consulta para aplicativos. A
desvantagem é incluir outro usuário, a permissão tem de ser eliminada e criada para incluir o novo
usuário.
Única Permissão com um Perfil de Grupo:
Exemplo 2: usando uma única permissão com todos os usuários definidos em um perfil de grupo na
permissão.
CREATE SCHEMA MY_LIB
CREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)
CREATE PERMISSION MY_LIB.PERM1 ON MY_LIB.PERMISSION_TABLE
AS P_GROUP FOR ROWS WHERE
VERIFY_GROUP_FOR_USER(SESSION_USER,’PERM_GROUP’) = 1
ENFORCED FOR ALL ACCESS ENABLE
ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL
/********************************************************************/
/* Conecte-se como USER1 que é um membro do grupo de usuários PERM_GROUP
/********************************************************************/
INSERT INTO MY_LIB.PERMISSION_TABLE VALUES(1) /* Permitido.
*/
*/
A vantagem de uma única permissão verificando um perfil do grupo significa que a permissão não tem
de alterar a inclusão de outro usuário. A desvantagem de cada consulta da tabela base, a função
VERIFY_GROUP_FOR_USER é verificada.
Única Permissão com uma Tabela Dependente:
Exemplo 3: Usando uma única permissão que os usuários definiram em uma tabela dependente.
CREATE SCHEMA MY_LIB
CREATE SCHEMA RCAC_DEPENDENT
CREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)
CREATE TABLE RCAC_DEPENDENT.USERS (USERNAME CHAR (10))
INSERT INTO RCAC_DEPENDENT.USERS
VALUES(’USER1
’),(’USER2
’),(’USER3
’)
CREATE TABLE MY_LIB.PERMISSION_TABLE (FIELD1 INT)
CREATE PERMISSION MY_LIB.PERM1 ON MY_LIB.PERMISSION_TABLE
FOR ROWS WHERE
CURRENT_USER IN (SELECT USERNAME FROM RCAC_DEPENDENT.USERS)
ENFORCED FOR ALL ACCESS ENABLE
ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL
/***********************************************************************/
/* Conecte-se como USER1
*/
/***********************************************************************/
INSERT INTO MY_LIB.PERMISSION_TABLE VALUES(1) /* Permitido.
*/
A vantagem de uma única permissão verificar uma tabela dependente é que, ao incluir outro usuário, a
permissão não precisa ser mudada. A desvantagem é a consideração de desempenho de consultar a tabela
dependente.
Única Permissão com um UDF:
Exemplo 4: Usando uma única permissão com um User Defined Function (UDF).
CREATE SCHEMA RCAC_DEPENDENT
CREATE SCHEMA MY_LIB
CREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)
CREATE OR REPLACE FUNCTION RCAC_DEPENDENT.UDF_PERMISSION
()
RETURNS CHAR(10)
LANGUAGE SQL
Administração
37
MODIFIES SQL DATA
NO EXTERNAL ACTION
DETERMINISTIC
NOT FENCED
SECURED
BEGIN
DECLARE ALLOWS CHAR(10);
IF (CURRENT_USER = ’USER1’) THEN
SET ALLOWS = ’ALLOWED
’;
ELSE
SET ALLOWS = ’DISALLOWED’;
END IF;
RETURN ALLOWS;
END
CREATE PERMISSION MY_LIB.PERMISSION_USER
ON MY_LIB.PERMISSION_TABLE
FOR ROWS WHERE
RCAC_DEPENDENT.UDF_PERMISSION() = ’ALLOWED
ENFORCED FOR ALL ACCESS ENABLE
’
ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL
A vantagem de uma única permissão que verifica um UDF é incluir outro usuário, a permissão não tem
de se alterar. A desvantagem aparece quando o UDF é alterado. Durante a próxima abertura da tabela
com a permissão, a verificação deve ser feita para permitir que o novo UDF seja usado com a permissão.
A verificação faz com que a permissão ou máscara seja gerada novamente uma vez para a tabela.
Permissões para Cada Usuário:
Exemplo 5: Usando diversas permissões, uma permissão para cada usuário.
CREATE SCHEMA MY_LIB
CREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)
CREATE PERMISSION MY_LIB.P1 ON MYLIB.PERMISSION_TABLE
FOR ROWS WHERE
CURRENT_USER = ’USER1
’
ENFORCED FOR ALL ACCESS ENABLE
CREATE PERMISSION MY_LIB.P2 ON MY_LIB.PERMISSION_TABLE
FOR ROWS WHERE
CURRENT_USER = ’USER2
’
ENFORCED FOR ALL ACCESS ENABLE
CREATE PERMISSION MY_LIB.P3 ON MY_LIB.PERMISSION_TABLE
FOR ROWS WHERE
CURRENT_USER = ’USER3
’
ENFORCED FOR ALL ACCESS ENABLE
ALTER TABLE MY_LIB.PERMISSION_TABLE ACTIVATE ROW ACCESS CONTROL
A vantagem de diversas permissões é a facilidade de uso de ter permissões individuais. A desvantagem é
ter de incluir outro usuário, uma nova permissão tem de ser incluída. A nova permissão causa uma
regeneração da permissão composta usada para a tabela.
Atributos de Diversas Permissões:
Os atributos para cada permissão da tabela base precisam ser os mesmos.
Os atributos precisam ser os mesmos, porque quando a permissão é executada, os dados (linhas da tabela
base) são verificados para cada permissão. Por exemplo, o caso em que uma permissão está usando um
*PERIOD como o ponto decimal e outra permissão está usando uma*COMMA. As permissões são
diferentes, porque o tipo de ponto decimal esperado por cada permissão não é o mesmo. Os atributos a
seguir podem alterar a execução da permissão:
v DATFMT, TIMFMT, DATSEP, TIMSEP DECMPT
v SRTSEQ e LANGID
v DECFLTRND
v Ponto decimal e DECRESULT
38
IBM i: Administração de Banco de Dados
Se os atributos listados não forem os mesmos para cada permissão, um resultado inesperado poderá ser
retornado.
Nomes de Objetos Não Qualificados:
Os nomes de objetos não qualificados no RULETEXT se tornam qualificados para esquema durante a
criação das permissões ou máscaras.
Por exemplo, criar permissões ou máscaras em um ambiente de teste faz com que os nomes de objetos se
tornem qualificados com o nome do esquema de teste. Portanto, é melhor qualificar o nome do esquema
para evitar confusão do nome do esquema.
CREATE SCHEMA MY_LIB
CREATE SCHEMA RCAC_LIB
CREATE TABLE MY_LIB.PERMISSION_TABLE (COLUMN1 INT)
CREATE TABLE RCAC_LIB.DEPENDENT_TABLE (COLUMN1 INT)
SET SCHEMA RCAC_LIB
CREATE PERMISSION MY_LIB.PERMISSION_USE
ON MY_LIB.PERMISSION_TABLE FOR ROWS
WHERE
COLUMN1 IN (SELECT COLUMN1 FROM DEPENDENT_TABLE)
ENFORCED FOR ALL ACCESS ENABLE
/*******************************************************************/
/* A instrução selecionar mostrará RULETEXT como sendo qualificado. */
/*******************************************************************/
SELECT CHAR(RULETEXT,200) FROM QSYS2.SYSCONTROL
WHERE SCHEMA = ’MY_LIB’
/*******************************************************************/
/* O RULETEXT agora está qualificado.
*/
/*******************************************************************/
PERMISSION_TABLE.COLUMN1 IN
(SELECT RCAC_LIB.DEPENDENT_TABLE.COLUMN1 FROM RCAC_LIB.DEPENDENT_TABLE)
Objetos Dependentes
Um número de considerações deve ser determinado para decidir como manipular objetos dependentes
das permissões e máscaras.
Propriedade:
Objetos dependentes de uma permissão ou máscara devem ser possuídos pelo perfil do usuário com a
autoridade funcional QIBM_DB_SECADM e nenhuma autoridade de gerenciamento de objetos deve ser
concedida a outros usuários.
Isso restringe a possibilidade de o objeto dependente ser manipulado por um usuário autorizado para
alterar uma permissão ou máscara para permitir acesso indesejado a dados.
Esquema:
Todas as tabelas dependentes ou visualizações de uma permissão ou máscara devem ser criadas em um
esquema diferente do esquema da tabela base.
Se o usuário executar um Create Duplicate Object (CRTDUPOBJ) ou Restore (RSTOBJ) da tabela base para
um novo esquema, os nomes do esquema dos objetos dependentes não são alterados. Ao manter as
tabelas dependentes e visualizações em um esquema diferente após CRTDUPOBJ ou RSTOBJ da tabela
base, a tabela base recém-criada referencia os mesmos objetos dependentes que a tabela base original.
Se os objetos dependentes das permissões e máscaras estiverem no mesmo esquema, se o usuário
duplicar o esquema, as permissões e máscaras duplicadas referenciarão os objetos do esquema original.
Portanto, ao clonar um esquema e os objetos nele, a melhor prática é usar o recurso Gerar SQL em um
IBM i Navigator. Ao cancelar a seleção da opção "Objetos de Qualificação de Esquema", o script SQL
Administração
39
resultante não conterá mais referências qualificadas do esquema nas permissões e máscaras. O usuário
pode preceder a execução do script SQL com uma instrução SET SCHEMA especificando o esquema de
destino.
Autoridade de Esquema:
O esquema que contém os objetos dependentes não deve permitir a autoridade de gerenciamento de
objetos para usuários.
Ao não conceder a autoridade de gerenciamento de objetos aos usuários, os objetos dependentes não
terão permissão de serem manipulados por usuários.
UDFs Protegidos:
Uma função definida pelo usuário (UDF) SQL usada no RULETEXT de uma permissão ou máscara deve
ser marcada como SECURE.
Esta mesma regra se aplica a qualquer função que possa ser chamada com uma coluna mascarada
especificada como um argumento. O atributo SECURE está armazenado no executável *PGM ou
*SRVPGM que é chamado quando o UDF é chamado. Quando o *PGM/*SRVPGM para uma função SQL
SECURED é restaurado, o atributo SECURE associado à função pode ser perdido a menos que um dos
seguintes seja true:
v O usuário que está fazendo a restauração está autorizado à função QIBM_DB_SECADM.
v O usuário que está fazendo a restauração possui a autoridade especial *SAVSYS.
v O usuário chamado QSECOFR está fazendo a restauração.
Os programas Old Program Model (OPM) não podem ser usados para funções (UDFs) definidas em
permissões ou máscaras. Isso ocorre porque o sistema não pode verificar o programa durante outras
operações do banco de dados, como a restauração ou renomeação.
Ao criar um UDTF ou UDF, o padrão é FENCED, significando que UDTF ou UDF é executado em um
encadeamento secundário. Certos registros especiais SQL como CURRENT USER não podem se
comportar conforme o esperado quando referenciados em um UDF FENCED. Portanto, quando UDTFs
ou UDFs forem usados no texto do RCAC, use NOT FENCED.
ALWCPYDTA e Nível de Isolamento:
As expressões no RULETEXT da permissão ou máscara são executadas com o mesmo ALWCPYDTA e
atributos de nível de isolamento ao abrir uma tabela base, índice ou visualização com uma permissão ou
máscara ativa.
Para aberturas nativas o atributo ALWCPYDTA é *NO. Isso impede que as cópias temporárias dos dados
sejam usadas para executar as expressões de permissão ou máscara. Se a permissão ou máscara requerer
uma cópia temporária dos dados, é recomendável que as expressões correspondentes sejam movidas para
um UDF seguro que é executado com um atributo ALWCPYDTA de *YES ou *OPTIMIZE. O RULETEXT
da permissão ou máscara poderia ser alterado para referenciar o UDF em vez da expressão que precisava
de uma cópia temporária dos dados.
Restaurando Objetos:
Restaurar uma versão diferente de um objeto dependente da tabela base pode impactar as permissões e
máscaras existentes.
O processo de verificar os objetos dependentes para permissões e máscaras é feito pela primeira vez que
a tabela base é aberta e não durante o processo de restauração.
40
IBM i: Administração de Banco de Dados
Portanto, após restaurar os objetos dependentes para as permissões ou máscaras,o administrador do
sistema deve incluir no processo uma operação aberta simples da tabela base. Isso permite que a
verificação seja concluída e evita a verificação no tempo de execução do aplicativo.
É importante se assegurar de que os objetos dependentes adequados das permissões e máscaras são
restaurados ao restaurar as tabelas base com as permissões e máscaras.
Operações Adicionais
Um número de considerações deve ser revisto criando permissões ou máscaras para uma tabela.
Incluindo o Perfil do Aplicativo em Permissões e Máscaras:
Alguns aplicativos existentes podem precisar incluir o perfil da tarefa que executa o aplicativo nas
permissões e máscaras da tabela base.
Alguns exemplos desses aplicativos seriam Data Propagator, software High Availability (HA) e aplicativos
semelhantes. Se o perfil do aplicativo não for incluído nas permissões e máscaras, as permissões e
máscaras serão reforçadas e o aplicativo poderá usar linhas parciais e dados mascarados.
Recuperar o Armazenamento:
Após concluir um Reclaim Storage (RCLSTG), quaisquer espaços de dados que sejam órfãos e localizados
pela operação de recuperação de armazenamento serão incluídos na biblioteca QRCL como uma tabela.
Como esses espaços para dados poderiam ser o resultado de uma tabela base que tinha o RCAC, os
espaços para dados que agora são tabelas no QRCL não têm nenhum RCAC. Após o RCLSTG ser
concluído, o administrador do sistema precisará consultar as tabelas em QRCL e manipular (copiar os
dados e excluir a tabela) as tabelas que precisam ser protegidas com o RCAC.
Relatórios de Consulta:
Esta recomendação se aplica a funções de relator de consulta, como Query for i ou DB2 for i Query
Manager.
Ao usar uma função de relator de consulta da web, é recomendado, para resultados consistentes, que
uma classificação também seja aplicada a qualquer coluna usada para processamento de quebra de
relatório. Com o aplicativo de máscaras de coluna, a classificação é feita em uma coluna antes de as
máscaras serem aplicadas, mas o processamento da quebra que é feito pela função de relator pode ser
feito usando valores mascarados. Como resultado, os agrupamentos de quebra inconsistente e valores de
resumo diferentes podem ser vistos ao executar um relatório de consulta após as máscaras serem
definidas na tabela baseada.
MQTs:
Ao preencher ou atualizar um MQT, ele não considera predicados ou expressões de máscaras ou
permissões em tabelas dependentes.
Quando o MQT é usado para otimização em uma consulta, as permissões de linha subjacentes e máscaras
de coluna são construídas na consulta que usa o MQT. Para que o MQT seja usado para otimização, o
MQT deve incluir quaisquer colunas que sejam usadas pelas máscaras ou permissões.
No exemplo a seguir, o MQT TOTALSALES não pode ser usado por nenhuma consulta que inclua
CreditCardNum porque CustID é usado pela máscara para CreditCardNum, mas não está na lista de
seleção do MQT.
CREATE SCHEMA MY_LIB
CREATE TABLE MY_LIB.SALES(CustID INT,
CreditCardNum VARCHAR(12),
Administração
41
Amount DEC(6,2))
CREATE MASK MY_LIB.CCN_MASK ON SALES FOR COLUMN CreditCardNum
RETURN
CASE
WHEN (CustID < 10) THEN CreditCardNum
ELSE 'b*******' || SUBSTR(CreditCardNum, 9, 4)
END
ENABLE;
CREATE TABLE MY_LIB.TOTALSALES
AS (SELECT CreditCardNum AS SCCN, SUM(Amount) AS SSUM
FROM SALES
GROUP BY CreditCardNum)
DATA INITIALLY DEFERRED
REFRESH DEFERRED
MAINTAINED BY USER
SELECT CreditCardNum, Sum(Amount)
FROM MY_LIB.SALES
GROUP BY CreditCardNum
| Tabelas temporais:
| Uma tabela temporal de período do sistema pode ter uma permissão de linha ou uma máscara de coluna.
| Para obter mais informações sobre tabelas temporaise RCAC, consulte “Controle de acesso de linha e
| coluna com uma tabela temporal de período do sistema” na página 23.
Perfis de Grupo e QIBM_DB_SECADM:
IDs de autorização que estão autorizados à função QIBM_DB_SECADM não devem ser incluídos em um
perfil do grupo.
Esse ID de autorização pode transferir a propriedade ou conceder privilégios para um objeto a qualquer
ID de autorização que não ele mesmo. Entretanto, o ID autorizado ainda pode transferir ou conceder ao
grupo do qual o ID autorizado é um membro.
Os usuários que têm autoridades necessárias para excluir, mover, copiar, renomear ou substituir os
objetos *PGM/*SRVPGM não podem fazer essas operações quando o objeto *PGM/*SRVPGM
corresponde a um SECURE FUNCTION e o usuário está autorizado à função QIBM_DB_SECADM. Um
usuário que tem permissão de usar a função QIBM_DB_SECADM pode usar os comandos Create SQL
ILE CL (CRTSQLCBLI, CRTSQLCI, CRTSQLCCPPI ou CRTSQLRPGI) ou qualquer um dos comandos
Create Bound Program CL (CRTBNDC, CRTBNDCBL, CRTBNDCL, CRTBNDCPP, CRTBNDRPG) para
substituir um *PGM/*SRVPGM associado à SECURE FUNCTION.
Após o objeto ser criado, ele pode ser copiado para a biblioteca QRPLOBJ. A cópia QRPLOBJ da SECURE
FUNCTION pode ser copiada ou movida para outra biblioteca, mas não terá permissão para ser usada
como uma SECURE FUNCTION, a menos que o programa seja renomeado, movido, copiado ou
salvo/restaurado por um usuário com a autoridade QIBM_DB_SECADM. Lembre-se, um usuário sem a
autoridade QIBM_DB_SECADM tem permissão de excluir, mover ou copiar o objeto em QRPLOBJ, mas
não tem permissão de excluí-lo da biblioteca à qual foi movida ou copiada.
Parâmetros Copy File (CPYF):
O comando Copy File (CPYF) pode comparar valores retornados dos parâmetros FROMFILE TOKEY,
INCCHAR e INCREL.
Se uma máscara for definida para a coluna que é usada por qualquer um desses parâmetros, o valor da
máscara será retornado de FROMFILE e usado pelo parâmetro que pode resultar em resultados
inesperados.
42
IBM i: Administração de Banco de Dados
OmniFind Text Search Server for DB2 for i:
O OmniFind Text Search Server for DB2 for i (5733-OMF) versão 1.3 ou superior permite que os clientes
criem um índice de procura de texto por meio de uma coluna de uma tabela que está protegida pelo
RCAC.
Após um índice de procura de texto ser criado, as funções SQL integradas CONTAINS e SCORE podem
ser usadas para executar procuras de texto completo por meio da coluna indexada. Os clientes devem
estar cientes das considerações a seguir ao criar um índice de procura de texto por meio de uma coluna
que está protegida por um RCAC.
v Um servidor de procura de texto executa a tarefa de indexação e procura de documentos; os dados
indexados são armazenados fora do DB2 como arquivos de fluxos no sistema de arquivo integrado.
Como os dados indexados são armazenados fora do DB2, os usuários que têm acesso ao servidor de
procura de texto poderia possivelmente reconstruir documentos confidenciais a partir do índice.
v Os dados são trocados com o servidor de procura de texto usando protocolos de rede que não são
criptografados, os certificados digitais não serão verificados.
v Um índice de procura de texto requer que a tabela base contenha uma ou mais colunas de identificação
que são uma chave primária, índice exclusivo ou ROWID. A coluna de identificação é usada para
identificar uma linha específica ao interagir com o servidor de procura de texto ou um administrador;
os valores serão armazenados na tabela de migração de dados e poderão ser retornados dos
procedimentos administrativos. Quando um índice de procura de texto for criado por meio de uma
tabela que é protegida por RCAC, a coluna de identificação deve conter um valor gerado, como um
ROWID ou uma coluna de identidade. Isso permite que linhas individuais sejam identificadas usando
informações não confidenciais. Para obter mais informações, consulte o OmniFind Text Search Server
for DB2 for i .
Usando o RCAC em Arquivos Lógicos Multiformatados
Um arquivo lógico de multiformato contém mais um formato de registro ou mais de um arquivo
especificado na palavra-chave PFILE (DDS) de um arquivo lógico.
Para abrir um arquivo lógico que tem mais de um arquivo especificado na palavra-chave PFILE, os
critérios a seguir devem ser atendidos:
1. Cada permissão ou máscara no mesmo arquivo físico baseado deve ter um nome de correlação
exclusivo.
2. Como os nomes de permissões e máscaras na mesma biblioteca devem ser exclusivos e não podem
usar o nome da máscara ou permissão para determinar uma correspondência entre duas tabelas. Em
vez disso, a correspondência está usando o nome de correlação. O nome de correlação que é usado
para a "mesma" permissão ou máscara que é aplicado a diversos arquivos físicos baseados deve ser o
mesmo para cada arquivo.
3. O RULETEXT para uma permissão ou máscara correspondente deve ser o mesmo. Em casos em que
nenhum nome de correlação está especificado na permissão ou máscara, o RULETEXT é normalizado
para usar o nome da tabela como o nome de correlação. Portanto, a única forma de forçar RULETEXT
a ser o mesmo entre duas permissões e máscaras é usar o mesmo nome de correlação explícito.
4. Cada máscara ou permissão correspondente entre as tabelas deve ser definida com as mesmas opções
de analisador:
v Formato de data/hora e separador
v SRTSEQ e LANGID
v DECFLTRND
v Ponto decimal e DECRESULT
v CCSID de RULETEXT
5. O RCAC para cada arquivo físico baseado deve estar no mesmo estado ativo ou inativo.
6. Cada máscara ou permissão deve estar no mesmo estado ENABLED/DISABLED como sua
correspondência nos outros arquivos físicos baseados.
Administração
43
Neste exemplo, LF1 está baseado em PF1, PF2 e PF3 e cada definição usa o nome de correlação PERM1
para que o código de verificação SQL possa identificá-los como sendo equivalente.
CREATE SCHEMA MY_LIB
SET
SCHEMA MY_LIB
CREATE TABLE MY_LIB.PF1
CREATE TABLE MY_LIB.PF2
CREATE TABLE MY_LIB.PF3
(COLUMN1 INT)
(COLUMN1 INT)
(COLUMN1 INT)
DDS for LF1
FMT LF .....A..........T.Name++++++.Len++TDp......Functions++++++++++++++
R RECORD1
PFILE(PF1 PF2 PF3)
COLUMN1
K COLUMN1
ADDLIBLE MY_LIB
CRTLF FILE(MY_LIB/LF1) SRCFILE(MY_LIB/QDDSSRC)
CREATE PERMISSION PF1_P1 ON MY_LIB.PF1 AS PERM1 FOR ROWS WHERE
CURRENT_USER = ’USER3’ ENFORCED FOR ALL ACCESS
CREATE PERMISSION PF2_P2 ON MY_LIB.PF2 AS PERM1 FOR ROWS WHERE
CURRENT_USER = ’USER3’ ENFORCED FOR ALL ACCESS
CREATE PERMISSION PF3_P3 ON MY_LIB.PF3 AS PERM1 FOR ROWS WHERE
CURRENT_USER = ’USER3’ ENFORCED FOR ALL ACCESS
CREATE MASK PF1_M1 ON MY_LIB.PF1 AS MASK1
FOR COLUMN COLUMN1 RETURN
CASE WHEN COLUMN1 > 55000 THEN
0 END
CREATE MASK PF2_M2 ON MY_LIB.PF2 AS MASK1
FOR COLUMN COLUMN1 RETURN
CASE WHEN COLUMN1 > 55000 THEN
0 END
CREATE MASK PF3_M3 ON MY_LIB.PF3 AS MASK1
FOR COLUMN COLUMN1 RETURN
CASE WHEN COLUMN1 > 55000 THEN
0 END
ALTER TABLE PF1 ACTIVATE ROW ACCESS CONTROL
ALTER TABLE PF2 ACTIVATE ROW ACCESS CONTROL
ALTER TABLE PF3 ACTIVATE ROW ACCESS CONTROL
ALTER TABLE PF1 ACTIVATE COLUMN ACCESS CONTROL
ALTER TABLE PF2 ACTIVATE COLUMN ACCESS CONTROL
ALTER TABLE PF3 ACTIVATE COLUMN ACCESS CONTROL
Propagação de Dados Mascarados
Executar uma operação de inserção ou atualização em uma tabela base com o controle de acesso de
coluna ativo, a operação pode falhar, porque os dados são os dados mascarados.
Isso pode acontecer quando os dados a serem inseridos ou atualizados contêm o valor mascarado e os
dados mascarados foram selecionados em uma tabela com o controle de acesso da coluna ativa e a
seleção foi feita na mesma instrução SQL. Como um exemplo, presuma que TABLE1 e TABLE2 tenham o
controle de acesso da coluna ativa e para a inserção, selecionar na TABLE2 retornaria os dados
mascarados. A instrução a seguir retornaria um erro:
INSERT INTO TABLE1 SELECT * FROM TABLE2
A instrução falharia com SQ20478 – O controle de acesso de linha ou coluna não é válido.
Entretanto, suponha que para este exemplo, TABLE1 e TABLE2 contenham duas colunas, NAME e SSN.
Para o usuário que está fazendo o INSERT, a máscara é definida para retornar a sequência
‘XXX-XX-nnnn’ ao consultar TABLE2.
SELECT NAME, SSN INTO :name, :ssn FROM TABLE2;
INSERT INTO TABLE1 VALUES(:name, :ssn);
Este mesmo tipo de problema também pode ocorrer se o usuário estiver executando um aplicativo de
banco de dados nativo. Um READ da TABLE2 seguido de um WRITE na TABLE1 poderia resultar nos
dados mascarados gravados no arquivo. Ou no caso de uma atualização, mesmo se a coluna SSN não se
destinar a alterar na UPDATE, o registro que está sendo atualizado contém o valor mascarado para a
coluna SSN e ela é alterada.
44
IBM i: Administração de Banco de Dados
Duas soluções para evitar que os dados mascarados sejam fornecidos:
1. Acionador BEFORE.
2. Restrição CHECK.
Solução de Acionador Before
A solução do acionador verifica os novos dados gravados em uma coluna e configura condicionalmente a
coluna para o valor atual ou o configura como DEFAULT.
Este é um exemplo de um acionador before de inserção/atualização para evitar dados mascarados:
CREATE SCHEMA MY_LIB
CREATE TABLE MY_LIB.EMP_INFO
(COL1_name CHAR(10) WITH DEFAULT ’DEFAULT’,
COL2_ssn CHAR(11) WITH DEFAULT ’DEFAULT’)
/********************************************************************/
/* Crie uma máscara para dar COL2_ssn para DBMGR, mas para qualquer outro usuário */
/* mascare a coluna. Esta tabela conterá um acionador para assegurar que */
/* a coluna possa nunca conter um valor mascarado.
*/
/********************************************************************/
CREATE MASK MASK_SSN ON MY_LIB.EMP_INFO
FOR COLUMN COL2_ssn
RETURN
CASE
WHEN VERIFY_GROUP_FOR_USER(SESSION_USER, ’DBMGR’) = 1
THEN COL2_ssn
ELSE ’XXX-XX-’||SUBSTR(COL2_ssn,8,4)
END
ENABLE
ALTER TABLE MY_LIB.EMP_INFO ACTIVATE COLUMN ACCESS CONTROL
CREATE TRIGGER PREVENT_MASK_SSN BEFORE INSERT OR UPDATE ON MY_LIB.EMP_INFO
REFERENCING NEW ROW AS N OLD ROW AS O
FOR EACH ROW MODE DB2ROW
SECURED
WHEN(SUBSTR(N.COL2_ssn,1,7) = ’XXX-XX-’)
BEGIN
IF INSERTING THEN SET N.COL2_ssn = DEFAULT;
ELSEIF UPDATING THEN SET N.COL2_ssn = O.COL2_ssn;
END IF;
END
Tentar uma operação de inserção ou atualização faz com que o acionador BEFORE seja executado e
assegure-se dos dados corretos na coluna COL2_ssn.
Solução de Restrição de Verificação
A solução baseada na restrição de verificação fornece uma nova sintaxe SQL para permitir que a
especificação de uma ação seja executada quando uma violação da condição de verificação de restrição de
verificação ocorrer em vez de retornar um erro irrecuperável. Entretanto, se a condição de verificação
continuar falhando após a ação ser tomada, um erro irrecuperável será retornado e a instrução SQL
falhará com a falha de restrição existente, (SQLSTATE=23513, SQLCODE=-545).
Uma restrição de verificação com a cláusula sobre violação está permitida em ambas as instruções
CREATE TABLE e ALTER TABLE.
No exemplo a seguir, a máscara está definida para retornar um valor de ‘XXX-XX-nnnn’ para qualquer
consulta que não seja feita por um perfil do usuário no grupo ‘DBMGR’. A restrição verifica que a coluna
SSN não tem o valor mascarado.
CREATE SCHEMA MY_LIB
SET
SCHEMA MY_LIB
CREATE TABLE MY_LIB.EMP_INFO
(COL1_name CHAR(10) WITH DEFAULT ’DEFAULT’,
COL2_ssn CHAR(11) WITH DEFAULT ’DEFAULT’)
Administração
45
CREATE MASK MASK_ssn ON MY_LIB.EMP_INFO
FOR COLUMN COL2_ssn RETURN
CASE
WHEN VERIFY_GROUP_FOR_USER ( SESSION_USER , ’DBMGR’ ) = 1
THEN COL2_ssn
ELSE ’XXX-XX-’||SUBSTR(COL2_ssn,8,4)
END
ENABLE
/* Restrição de verificação para a atualização e inserção.*/
ALTER TABLE MY_LIB.EMP_INFO
ADD CONSTRAINT MASK_ssn_preserve
CHECK(SUBSTR(COL2_ssn,1,7)<>'XXX-XX-')
ON UPDATE VIOLATION PRESERVE COL2_ssn
ON INSERT VIOLATION SET COL2_ssn = DEFAULT
Classic Query Engine (CQE) e SQL Query Engine (SQE)
A seção explica as diferenças de processamento de consulta nativas e abertas entre CQE e SQE.
| Para obter mais informações sobre as diferenças gerais entre CQE e SQE, consulte o artigo do IBM
| developerWorks Diferenças entre o Mecanismo de Consulta Clássico (CQE) e o Mecanismo de Consulta
| SQL (SQE)
.
Diferenças entre nativo aberto e consulta SQL envolvendo RCAC
Alguns arquivos com RCAC não têm permissão de serem acessados.
Uma tentativa de usar o ambiente nativo para abrir um arquivo com RCAC ativo que envolve qualquer
um dos seguintes não é permitida:
v Um arquivo lógico com diversos formatos se a tentativa de abrir for para mais de um formato.
v Um arquivo distribuído.
v Um arquivo com acionadores de leitura.
v Um arquivo descrito no programa.
v Um arquivo ou consulta que especifica uma sequência de classificação ICU 2.6.1.
Uma tentativa de usar o SQL para consultar uma tabela com o RCAC ativo que envolve qualquer um dos
seguintes não está permitida:
v Um arquivo distribuído.
v Um arquivo com acionadores de leitura.
v Um arquivo ou consulta que especifica uma sequência de classificação ICU 2.6.1.
Ordenação de Conjunto de Resultados
A implementação de SQE pode resultar em uma ordenação do conjunto de resultados diferente para
WRKQRY, RUNQRY ou OPNQRYF.
Quando uma consulta é executada sem especificar explicitamente que os resultados sejam retornados em
uma ordem específica, ambos os otimizadores SQE e CQE escolherão qualquer plano que melhor se
executar. Isso significa que ambos SQE e CQE podem ou não retornar os resultados em uma ordem de
arquivo-chave. Como o CQE tem muito menos recurso avançado que o SQE, é mais provável que retorne
resultados em uma ordem em chave e que o SQE tem menos probabilidade de retornar os resultados em
uma ordem em chave. Assim, se uma consulta for especificada com WRKQRY, RUNQRY ou OPNQRYF e
a ordenação da linha for importante, especifique explicitamente o(s) campo(s) chave e a ordenação do
campo de chave.
46
IBM i: Administração de Banco de Dados
Avisos
Estas informações foram desenvolvidas para produtos e serviços oferecidos nos Estados Unidos.
É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos nesta publicação em outros
países. Consulte um representante IBM local para obter informações sobre produtos e serviços disponíveis
atualmente em sua área. Qualquer referência a produtos, programas ou serviços IBM não significa que
apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer produto, programa ou
serviço funcionalmente equivalente, que não infrinja nenhum direito de propriedade intelectual da IBM
(ou quaisquer outros direitos da IBM) poderá ser utilizado em substituição a este produto, programa ou
serviço. Entretanto, a avaliação e verificação da operação de qualquer produto, programa ou serviço não
IBM são de responsabilidade do Cliente.
A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos tratados nesta
publicação. O fornecimento desta publicação não lhe garante direito algum sobre tais patentes. Pedidos
de licença devem ser enviados, por escrito, para:
Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP 22290-240
Para pedidos de licença relacionados a informações de DBCS (Conjunto de Caracteres de Byte Duplo),
entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou envie pedidos
de licença, por escrito, para:
IBM World Trade Asia Corporation
2-31 Roppongi 3-chome,
Minato-ku
Tokyo 106,
Japan
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a
legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA
PUBLICAÇÃO “NO ESTADO EM QUE SE ENCONTRA”, SEM GARANTIA DE NENHUM TIPO, SEJA
EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS A ELAS NÃO SE LIMITANDO, AS GARANTIAS
IMPLÍCITAS (OU CONDIÇÕES) DE NÃO INFRAÇÃO, COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM
DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de garantias expressas ou
implícitas em certas transações, portanto, esta disposição pode não se aplicar ao Cliente.
Estas informações podem incluir imprecisões técnicas ou erros tipográficos. Periodicamente, são feitas
alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta
publicação. A IBMpode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas
descritos nesta publicação, sem aviso prévio.
Referências nestas informações a Web sites não IBM são fornecidas apenas por conveniência e não
representam de forma alguma um endosso a esses Web sites. Os materiais contidos nesses Web sites não
fazem parte dos materiais desse produto IBM e a utilização desses Web sites é de inteira responsabilidade
do Cliente.
A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar apropriada sem incorrer
em qualquer obrigação para com o Cliente.
© Copyright IBM Corp. 1998, 2015
47
Licenciados deste programa que desejam obter informações sobre este assunto com objetivo de permitir:
(i) a troca de informações entre programas criados independentemente e outros programas (incluindo
este) e (ii) a utilização mútua das informações trocadas, devem entrar em contato com:
IBM Corporation
Av. Pasteur, 138-146
Botafogo,
Rio de Janeiro, RJ
CEP 22290-240
Tais informações podem estar disponíveis, sujeitas a termos e condições apropriadas, incluindo em alguns
casos o pagamento de uma taxa.
O programa licenciado descrito nesta publicação e todo o material licenciado disponível são fornecidos
pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato Internacional de Licença do
Programa IBM ou de qualquer outro contrato equivalente.
Todos os dados de desempenho aqui contidos foram determinados em um ambiente controlado. Portanto,
os resultados obtidos em outros ambientes operacionais poderão variar significativamente. Algumas
medidas podem ter sido tomadas em sistemas de nível de desenvolvimento e não há garantia de que
estas medidas serão iguais em sistemas geralmente disponíveis. Além disso, algumas medidas podem ter
sido estimadas por extrapolação. Os resultados reais podem variar. Os usuários deste documento devem
verificar os dados aplicáveis para o ambiente específico.
As informações relativas a produtos não IBM foram obtidas junto aos fornecedores dos respectivos
produtos, de seus anúncios publicados ou de outras fontes disponíveis publicamente. A IBM não testou
estes produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra
reivindicação relacionada a produtos não IBM. Dúvidas sobre os recursos de produtos não IBM devem
ser encaminhadas diretamente a seus fornecedores.
Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão sujeitas a alterações ou
cancelamento sem aviso prévio e representam apenas metas e objetivos.
Estas informações foram projetadas apenas com o propósito de planejamento. As informações aqui
contidas estão sujeitas a alterações antes que os produtos descritos estejam disponíveis.
Estas informações contêm exemplos de dados e relatórios utilizados em operações comerciais diárias.
Para ilustrá-los da forma mais completa possível, os exemplos incluem nomes de pessoas, empresas,
marcas e produtos. Todos esses nomes são fictícios e qualquer semelhança com os nomes e endereços
utilizados por uma empresa real é mera coincidência.
LICENÇA DE COPYRIGHT:
Estas informações contêm programas de aplicativos de amostra na linguagem fonte, ilustrando as técnicas
de programação em diversas plataformas operacionais. O Cliente pode copiar, modificar e distribuir estes
programas de amostra sem a necessidade de pagar à IBM, com objetivos de desenvolvimento, utilização,
marketing ou distribuição de programas aplicativos em conformidade com a interface de programação de
aplicativo para a plataforma operacional para a qual os programas de amostra são criados. Esses
exemplos não foram testados completamente em todas as condições. Portanto, a IBM, não pode garantir
ou implicar a confiabilidade, manutenção ou função destes programas. Os programas de amostra são
fornecidos "NO ESTADO EM QUE SE ENCONTRAM", sem garantia de nenhum tipo. A IBM não deve
ser responsabilizada por nenhum dano causado pelo uso dos programas de amostra.
Cada cópia ou parte destes programas de amostra ou qualquer trabalho derivado deve incluir um aviso
de copyright com os dizeres:
48
IBM i: Administração de Banco de Dados
© (nome da empresa) (ano). Partes deste código são derivadas dos IBM Corp. Sample Programs.
© Copyright IBM Corp. _insira o ano ou anos_.
Informações sobre a Interface de Programação
Esta publicação de Administração do banco de dados documenta Interfaces de Programação desejadas
que permitem que o cliente grave programas para obter os serviços do IBM i.
Marcas Registradas
IBM, o logotipo IBM e ibm.com são marcas ou marcas registradas da International Business Machines
Corp., registradas em vários países no mundo todo. Outros nomes de produto e serviço podem ser
marcas registradas da IBM ou de outras empresas. Uma lista atual de marcas registradas da IBM está
disponível na Web em “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.
Adobe, o logotipo Adobe, PostScript e o logotipo PostScript são marcas ou marcas registradas da Adobe
Systems Incorporated nos Estados Unidos e/ou outros países.
Linux é uma marca registrada da Linus Torvalds nos Estados Unidos e/ou em outros países.
Microsoft, Windows, Windows NT e o logotipo Windows são marcas registradas da Microsoft
Corporation nos Estados Unidos e/ou em outros países.
UNIX é uma marca registrada da The Open Group nos Estados Unidos e em outros países.
Java e todas as marcas registradas e logotipos baseados em Java são marcas registradas da Oracle, Inc.
nos Estados Unidos e/ou em outros países.
Outros nomes de produtos e serviços podem ser marcas registradas da IBM ou de outras empresas.
Terms and conditions
Permissions for the use of these publications is granted subject to the following terms and conditions.
Personal Use: You may reproduce these publications for your personal, noncommercial use provided that
all proprietary notices are preserved. You may not distribute, display or make derivative works of these
publications, or any portion thereof, without the express consent of IBM.
Commercial Use: You may reproduce, distribute and display these publications solely within your
enterprise provided that all proprietary notices are preserved. You may not make derivative works of
these publications, or reproduce, distribute or display these publications or any portion thereof outside
your enterprise, without the express consent of IBM.
Except as expressly granted in this permission, no other permissions, licenses or rights are granted, either
express or implied, to the publications or any information, data, software or other intellectual property
contained therein.
IBM reserves the right to withdraw the permissions granted herein whenever, in its discretion, the use of
the publications is detrimental to its interest or, as determined by IBM, the above instructions are not
being properly followed.
You may not download, export or re-export this information except in full compliance with all applicable
laws and regulations, including all United States export laws and regulations.
Avisos
49
IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE PUBLICATIONS. THE
PUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.
50
IBM i: Administração de Banco de Dados
Avisos
51
IBM®
Número do Programa: 5770-SS1
Impresso no Brasil