Início > 731, certificação, DB2 / Banco de dados > Guia de estudos DB2 – Prova 731 – Parte 1

Guia de estudos DB2 – Prova 731 – Parte 1

Esta á a primeira parte do Guia de Estudos para a prova de certificação para DBA DB2 (731). Utilize-o como um complemento para seus estudos. Na introdução recomendo o livro oficial e uma página mais detalhada na Internet (em inglês). Desconsidere erros de gramática.

1.1. Trabalhando com instâncias
Instância é um contexto lógico onde os comandos e funções são executados no DB2. Podemos tem N instâncias em um mesmo servidor e N bancos de dados em cada instância. As instâncias são independentes, dessa forma, podem ser administradas isoladamente. Uma instância é uma espécie de serviço que fica rodando no servidor.

Criando uma instância: db2icrt nome_da_instancia

Criando atribuindo o usuário fenced: db2icrt -u fenced_usuaer nome_da_instancia

Dropando uma instância: db2idrop -f nome_da_instancia

Listando as instâncias em um servidor: db2ilist

Migrando uma instância (fez alguma alteração de proc. de 32 para 64 bits por exemplo): db2imgr nome_da_instância

Upgrade (quando instalou algum fixpack): db2iupdt nome_da_instância

1.2. Configurando o ambiente do DB2

Basicamente podemos configurar:
– Variáveis de ambiente do SO
– O profile do DB2
– Parâmetros da instância
– Parâmetros do banco de dados em si
Uma figura que ilustra esses parâmetros é:

Variáveis do profile afetam todas as instâncias do DB2. Normalmente você precisa reiniciar sua instância pra que as alterações tenham efeito.
Um parâmetro de instância afeta todos os bancos que fazem parte desta instância, e finalmente um parâmetro do BD vai afetar somente ele mesmo.

Comandos:

Ver todas as variáveis possíveis do profile: db2set -lr
Ver todas as variáveis que estão setadas no server: db2set -all
onde
• [e] represents a registry setting for the current session or environment
• [u] represents a user-level registry
• [n] represents a node-level registry
• [i] represents an instance-level registry
• [g] represents a global-level registry

Setar uma variável: db2set variavel=valor
Resetar uma variavel: db2set variavel=

A principal variável de ambiente é a instance, ela define qual instância estamos manipulando. Para ver ela podemos utilizar o comando “db2 get instance”

Para ver os parâmetros da instância e do banco de dados, respectivamente, utilizamos os comandos:
db2 get database manager configuration
db2 get database configuration for database_name

Para alterar os valores de algum parâmetro de instância ou do banco de dados, utilizamos os respectivos comandos:
db2 update database manager configuration using parameter new_value
db2 update database configuration for database_name using parameter new_value

Alguns parâmetros alterados só passam a fazer efeito quando o banco/instância é reiniciado, porém, podemos tentar forçar a alteração imediata de alguns parâmetros incluindo “immediate” no comando de alteração, por exemplo:

db2 update database manager configuration using parameter new_value immediate

Também podemos forçar que algum parâmetro somente seja alterado quando reiniciarmos a instância ou o banco, para isso utilizamos “deferred” na sintaxe, por exemplo:
db2 update database manager configuration using parameter new_value deferred

Para ver as alterações que foram feitas nas variáveis, inclusive verificando se existem pendências, adicionamos “show detail” ao comando de verificação de variáveis, por exemplo:

db2 attach to instance_name
db2 get database manager configuration show detail

Se for necessário efetuar uma alteração para um parâmetro que não pode ser alterado sem um restart, você pode forçar o DB2 a se reiniciar, “chutando” os usuários ativos:
db2stop force

É possível ver as aplicações que estão conectadas no banco com o comando:
db2 list applications
E se quiser matar somente esta determinada aplicação, utilize o comando:
force application (appl handle)
Onde Appl Handle é uma espécie de número do processo que pode ser obtido com o comando list applications.

1.3 —- Conectividade cliente / servidor

Preparando o servidor para receber conexões:
db2set DB2COMM=TCPIP

Cada instância do DB2 “escuta” em uma porta, você pode definir a porta manualmente com o comando:
db2 update database manager configuration using svcename 50000

Isso pode ser feito de outra forma também, a mais comum (em unix) é no arquivo services que costuma ficar em etc, você reservar a porta para a instância do db2, adicionando uma linha como:
db2icdb2 50000/tcp
Onde db2icb2 é sua instância. Feito isso, ao invés de setar a porta na qual a instância vai escutar, nos setamos o serviço:
db2 update database manager configuration using svcename db2icdb2

Toda alteração feita com portas e serviços requer o restart da instância, pois isso não é dinâmico.

Utilizando o Configuration Assistant (db2ca) você pode facilmente configurar estes elementos.

Para se conectar com um servidor, você precisa primeiro localizar o mesmo. Do lado do servidor, para habilitar que o mesmo seja localizado, é necessário que o DASAdmin (DB2 Administration Server) esteja rodando. Para isso efetuamos os seguintes comandos no servidor:
db2admin start
db2 update admin configuration using discover search

Feito isso, os clientes poderão “descobrir” seu servidor. Algo importante é que o DBA pode restringir a descoberta por Instância ou ainda por banco de dados com os seguintes comandos:
db2 update database manager configuration using discover_inst enable
db2 update database configuration for database_name using discover_db enable

A figura2.png ilustra muito bem este processo. É importante salientar que estes parâmetros somente dizem respeito a descoberta do processo em uma rede, e não tem relação com conectividade ou não remota, ou seja, se você desabilitar, as pessoas continuarão aptas a se conectar em seu servidor.

O processo de encontrar e se conectar com o servidor não precisa ser feito em todas as máquinas de uma rede, existe um meio mais fácil, você pode trabalhar com arquivos chamados “access profiles”, que nada mais são do que arquivos com as informações de conectividade com o servidor.

Para exportar o arquivo, utilizamos o comando db2cfexp, para importar db2cgimp.

Se você tem todos os dados para se conectar no servidor, você não precisa descobrir o mesmo, pode simplesmente catalogar o nó e depois o banco de dados com os comandos abaixo:

db2 catalog tcpip node mynode remote db2server.mycompany.com server db2icdb
db2 catalog database sample as mysamp at node mynode

É importante saber que um nó (node) é a mesma coisa que um servidor DB2.

Visualizando os servidores e bases de dados que você tem catalogado:
db2 list node directory
db2 list database directory

1.4. Segurança
Basicamente um usuário para ter acesso ao DB2 precisa poder ter acesso ao servidor, isso quer dizer, precisa que o servidor valide o acesso do usuário a nível de Sistema Operacional. No caso do Linux, você precisa criar um usuário no SO para que ele tenha acesso no DB2.

O tipo de autenticação é definido por instância através do parâmetro AUTHENTICATION, e pode ser:
• SERVER (default)
• SERVER_ENCRYPT
• KERBEROS
• KRB_SERVER_ENCRYPT
• CLIENT
Para alterar este parametro no servidor:
db2 update database manager configuration authentication auth_type
Para setar no cliente:
db2 catalog database db_name at node node_name authentication auth_type

O tipo de autenticação Cliente nos diz que o usuário que consegue logar em uma máquina que já tem acesso ao DB2, terá acesso ao banco de dados.

– Níveis de autoridade: quer dizer basicamente o que um usuário pode fazer no banco. A figura abaixo mostra um organograma dos tipos de usuários.

SYSADM: Tem praticamente todos os privilégios em uma instância e pode acessar dados.
SYSCTRL e SYSMAINT
Tem alguns privilégios na instância, nos seus bancos e objetos dos bancos. Não tem acesso a dados.
DBADM
Tem privilégios administrativos em bancos de dados especificados. Também tem total acesso aos dados no seu banco.
LOAD
Tem privilégio de carregar dados.
SYSMON
Tem privilégio de resetar monitores e capturar snapshots.
SECADM
Administra proprietários, manipula sessões e labels.

Os usuários do tipo SYS*, são setados a nível de instância. Para isso, temos que colocar ou remover um determinado usuário do grupo, ex: SYSADM, SYSCTRL e SYSMAINT. Com o comando:

db2 update dbm cfg using sysadm_group adm1

DBADM e LOAD são autoridades de nível do banco de dados, para eles utilizamos ddl para definições, exemplo:

connect to  sample;
grant dbadm on database to user  john;
grant load on database to group  dbagrp;
revoke load on database from group  dbagrp;

– Privilégios: temos vários tipos de privilégios no DB2, dos quais os mais comuns são:

De Banco de dados:
• CONNECT: permite que um usuário se conecte ao banco.
• BINDADD: Permissão para criar pacotes.
• CREATETAB: Criar tabelas.
• CREATE_NOT_FENCED Criar funções e stored procedures não fenced.
• QUIESCE_CONNECT: PErmissão para se conectar em uma base em QUIESCE.
• CREATE_EXTERNAL_ROUTINE: Criar stored procedures em linguagens tais como C, JAVA, OLE e Cobol

De schema:
• CREATEIN: permite ao usuário criar objetos num esquema.
• ALTERIN: permite ao usuário alterar objetos num esquema.
• DROPIN: permite ao usuário dropar objetos num esquema.

Table space: Permite utilizar o TS

Tabela e View: Basicamente temos o Insert, Update, Select, delete, etc…

Dando privilégios (Granting):
grant select, update, delete on table employee to user Juliano
Dando privilégios e permitindo que o usuário os de também:
grant select, update, delete on table employee to user Juliano with grant option

Alguns privilégios vem automaticamente para o usuário conforme cria-se o mesmo e o aloca em um grupo.

Para remover um privilégio, a instrução é a REVOKE.

1.5. Agendamento de tarefas
Este tópico é muito simples então nem vou cobrir decentemente, mas, basciamente nos diz respeito a tarefas que podem ser agendadas, tarefas tais como REORG e RUNSTATS. Cria-se um script que será executado em horários/dias pré agendados.
Para se trabalhar com tarefas é necessário termos um banco chamado tools catalog, pois é nele que o DB2 vai armazenar os dados sobre nossas tarefas. Para criar o mesmo damos o comando:
db2 create tools catalog toolscat create new database toolsdb

1.6. Logs e notificação
Cada instancia tem um notification log: db2diag.log , ele armazena os eventos que o DB2 loga.

O parametro NOTIFYLEVEL define o nível de log que será feito no arquivo, seu valor vai de 0 a 4, onde 0 é não loga nada, e 4 loga todo tipo de erros e informações.
Uma nova entrada no log sempre tem um time stamp junto com mais informações sobre o erro.

1.7. Instalação
No momento da criação de um banco de dados, é possível fazer com que o bd2 se auto configure, dessa forma, ele vai calcular os valores de memória e se instalar:
db2 create database db_name autoconfigure using config-keyword value,config-keyword value, …
Também, é possível setar uma flag para tunning de memória automático, dessa forma o DB2 gerencia a memoria conforme necessário.

Em breve publicarei a parte 2 do Guia de estudos para certificação!

Voltar para a Introdução.

  1. agosto 25, 2016 às 6:03 pm

    Grande página, excelente trabalho Juliano.

  1. janeiro 6, 2010 às 10:01 am

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: