Guia de estudos DB2 - Prova 731 - Parte 5

Dando continuidade ao meu Guia de Estudos para o exame 731 (DBA DB2), falaremos aqui sobre os utilitários do DB2. Esta parte é realmente fácil de se entender, porém, demanda muita experiência diária de um DBA! Desconsidere erros de português, este guia foi escrito conforme eu estudava, então o foco era aprender, e não escrever bem. Vamos lá:

5.1 Movimentando dados no DB2
Antes de falar sobre qualquer utilitário, é importante ressaltar que a FONTE e o DESTINO dos dados precisam ser compatíveis, embora obvio, muitas pessoas erram nisso. Os utilitários trabalham com tipos de dados definidos, o mais famoso é o do tipo DEL (Delimited ASCII), por exemplo, quando exporto uma tabela, exporto para um arquivo .del, para importar, preciso ler esse .del.
   
5.2 Utilitários para movimentação de dados
5.2.1 Export
O export extrai dados de uma tabela para um arquivo utilizando uma clausula SQL ou XQuery. Você pode logar qualquer problema em um arquivo texto utilizando a clausula MESSAGES. Exemplo:
EXPORT TO myfile.del OF DEL
    MESSAGES msg.out
      SELECT *
        FROM staff;

5.2.2 Import
Obviamente o import recebe um arquivo que foi exportado pelo export e o importa em uma tabela ou view. O Import não importa os dados em tabelas do sistema ou tabelas temporárias. A sintaxe do import é:
IMPORT FROM file_name OF file_type
    MESSAGES message_file
    [ INSERT | INSERT_UPDATE | REPLACE | REPLACE_CREATE | CREATE ]
    INTO target_table_name
Como visto, existem 5 formas de se importar:

• INSERT: Destino deve existir, os dados serão inseridos na tabela.
• INSERT_UPDATE: Destino deve existir, os dados serão inseridos na tabela, caso algum já exista (verificando chave primária), ele sofrera um update. Destino precisa ter PK definida.
• REPLACE: Destino deve existir, todos os dados existentes na tabela serão removidos e os novos dados serão inseridos na tabela. Destino precisa ter PK definida.
• REPLACE_CREATE: Tabela destino não precisa existir. Neste caso a mesma será criada e suas chaves tambem. Caso já exista, o dado existente será substituido. só funciona com o tipo de arquivos IXF, pois ele armazena dados da estrutura da tabela.
• CREATE: Tambem só funciona com IXF. Ele cria a tabela com as chaves necessárias e insere os dados.

Exemplo:
IMPORT FROM emp.ixf OF IXF
    MESSAGES msg.out
CREATE INTO employee IN datatbsp INDEX IN indtbsp
Quando um import está sendo efetuado, ele obtem um Lock na tabela. Isso pode ser cancelado atraves da opcao "Allow write access". Tambem pode-se estabelecer uma contagem de linhas para commit ser efetuado, caso contrário, o mesmo será efetuado somente ao final da transação.
Tambem pode ser utilizado a clausula RESTARTCOUNT, no exemplo abaixo:
IMPORT FROM myfile.ixf OF IXF
    COMMITCOUNT 500 RESTARTCOUNT 30000 ROWCOUNT 100000
    MESSAGES msg.out
    INSERT INTO newtable
vamos supor que algum problema ocorra apos a importação da linha 30000. Se você executar o comando acima, o import será reiniciado a partir da linha 30000 do arquivo myfile.ixf e irá até a linha 100000.

5.2.3 Load
Faz exatamente o mesmo que o import, porem ele ignora constraints e nem dispara triggers, dessa forma é muito mais rápido, mas pode gerar alguma inconsistência no banco se utilizado sem cuidado.
Supondo que um DBA deseja deletar todos os dados armazenados em uma tabela employee em um server AIX, para atingir o seu objetivo ele poderia executar o seguinte comando:
LOAD FROM /dev/null OF DEL REPLACE INTO employee

5.2.4 db2move
É utilizado para mover grande numero de tabelas. Por exemplo, todas as tabelas de um banco de dados Sample:
db2move database_name
                     action
                     options
O db2move basicamente executa IMPORT/EXPORT/LOAD/COPY para várias tabelas ao invés de uma tabela só.

5.2.5 db2lock
É um utilitário que gera DDL de objetos do banco de dados, além disso,  gera updates para atualizar parametros do banco de dados, comandos db2set, gera estatísticas, etc.
Um bom exemplo de seu uso é grando se quer importar uma tabela em um banco, mas se necessida da estrutura da mesma, então utilizamos o db2lock no banco de origem para gerar o ddl da tabela. No exemplo abaixo, estamos gerando um ddl de todas as tabelas do peter no banco department:
db2look -d department -u peter -e -o alltables.sql

5.2.6 db2batch
Objetivamente, executa uma série de comando que você pode especificar em um arquivo e gera um output com detalhes de benchmarching, tais como tempo que demorou para executar a operação, etc.

5.3 Utilitários de manutenção
5.3.1 runstats
O DB2 mantém tabelas de sistema com dados estatísticos tais como número de linhas em uma tabela, tamanho, etc. Tais dados permitem que o SGBD aloque os recursos necessários para se efetuar alguma operação que manipule algo. Se estes dados estiverem errados, tal alocação de recursos pode ser erronea, o banco pode por exemplo alocar menos memória ou cpu que o necessário, assim, a operação irá demorar muito mais.
Para atualizar os estas estatísticas que o banco consula, o comando é o runstats. O comando tem varios parametros, é possível fazer isso por tabela, fazer para os indices ou não, colocar a mesma em modo somente leitura para otimizar a operação, etc.
A utilização do runstats é importante ser executada após um grande número de insert, update, delete, opereção de import, load, etc, para obter informações do status do SGDB e ter um maior controle dos recursos. Por padrão, a atualização das estatísticas é automática no DB2, mas pode ser desabilitada ou forçada a qualquer momento.
5.3.2 reorg e reorgchk
5.3.2 reorg e reorgchk: Assim como acontece com o sistema de arquivos de um sistema operacional, os dados de uma tabela ou index podem se fragmentar. O utilitário reorg desfragmenta os dados de uma tabela, deixando-os mais próximos ou em seguencia no disco (quando possível). Tais comandos podem lockar ou não a tabela na qual estiverem rodando. O reorgchk, checa se um reorg é necessário e gera estatisticas/um relatório completo. Exemplos são:
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

5.3.3 rebind
Recompila um pacote. Um pacote é um objeto de banco de dados que contem instruções já compiladas.
A sintaxe é: REBIND PACKAGE package_name

A figura a seguir ilustra o trabalho de um DBA para manter um banco de dados "up and running":

Voltar para o índice do Guia.

Ripando e Gerando DVDs no Linux

Não sou um profissional da área de edição de vídeo, porém, como todo bom pai de família (minha filha nasceu em 30/01/2010), tenho a obrigação de aprender a fazer o mínimo! :-)

No caso, eu tinha uns 10 DVDs com os ultra-sons gravados, cada um com uns 10 a 15 minutos de vídeo, e por questões de espaço/simplicidade no manuseio, quero ripar todos os 10 DVDs e criar só um.

Para o processo de "ripagem", utilizei um software chamado Handbrake, que é simples e vai direto ao ponto: você escolhe o source (DVD) e clica num botão START. Pronto, ele gera um arquivo MP4 com todo o conteúdo do DVD. Você também pode excluir algum capítulo, capturar só o som/vídeo, definir qualidade, formatos e algumas outras opções simples.

Feito isso, tive a necessidade de "cortar" alguns vídeo que ficaram grandes, pois a enfermeira no momento do ultrasom deu o "REC" 5 minutos antes do médico iniciar o procedimento, dessa forma, eu cortei este tempo com um software chamado OpenShot , que também é simples e vai direto ao ponto. Para a mesma finalidade o Linux também conta com o Kino.




Eu também fiz um slide show com fotos e criei um vídeo com os mesmo, simples e rápido, com o programa Imagination


Neste ponto eu tinha 10 vídeos prontos, agora queria gerar um DVD, bonitinho, com menu, musiquinhas e tudo o mais. Encontrei outro software magnífico de tão simples e fácil de usar chamado DVDStyler , com simples cliques do mouse, gerei um menu, com vídeo, botões animados e tudo o mais que gostaria de fazer, ai simplesmente cliquei no gravar DVD e voa-lá, minha superprodução estava pronta em menos de 1 hora!

Vale lembrar que eu utilizei o Ubuntu, e exceto o Handbrake (que tem um pacote para Ubuntu), os outros foram instalados com apt-get.

Enjoy!

Show Desktop / Mostrar Desktop no KDE 4

Na ultima versão do meu KDE o botão / widget Show Desktop / Mostrar Desktop simplesmente sumiu. Já tentei algumas coisas para fazer o mesmo "voltar", mas pelo que li, removeram por algum motivo dessa versão do KDE.

Então, meu workaround foi criar um botão, vamos aos passos:

• Crie um script onde achar conveniente com o seguinte conteúdo:

#!/bin/sh
target=on
if xprop -root  _NET_SHOWING_DESKTOP | fgrep '= 1' ; then
    target=off
fi
wmctrl -k ${target}
exit

• Eu dei o nome de showDesktop.sh para o mesmo.
• Instale o wmctrl (apt-get install wmctrl -> no ubuntu/debian)
• Digite alt + f2 e entre com o comando: kmenuedit , você vai abrir o editor de menus do KDE.
• Vá em utilitários ou onde achar mais conveniente e crie um novo item. Eu dei o nome de Mostrar Desktop e no comando coloquei o caminho para meu script, ex: /home/julianom/showDesktop.sh
• Pronto, este atalho já deve fazer todas suas janelas serem minimizadas. Ai você pode o adicionar na barra "iniciar" do KDE.
• Clicando com o botão direito no atalho, na aba aplicativo, em opções avançadas, desabilite "Habilitar retorno de Lançamento" e "colocar na área de notificação" se aplicável, dessa forma quando executar o comando, ele vai rodar rapidamente e nem aparecerá na barra de tarefas.

Enjoy!

Instalando o DB2 no Linux

Ótimo video criado pelo Thiago Rosseto, mostrando como instalar o DB2 Express no Linux:


DB2 on LINUX - instalation from thiago rossetto on Vimeo.

Meu projeto de vida mais importante

Pessoal, o blog ficará paradinho nas próximas semanas pois eu estarei me dedicando full time a meu projeto de vida mais importante!
É o "projeto Lívia", minha filhinha que chegou ao mundo no último sábado, dia 30 de janeiro!
Mãe e filha passam muito bem, gracas a Deus. O pai está doido e não de aguenta de felicidade.
Abração!

Guia de estudos DB2 - Prova 731 - Parte 4

Dando continuidade ao meu material de estudos para a prova 731 (DBA) do DB2, nesta parte falaremos de "Monitorando a atividade do DB2", que eu considero ser a parte mais teórica e fácil tratando-se do estudo para a prova, porém é a parte que demanda maior experiência no dia a dia para performar um bom trabalho. Desconsidere erros de português, este guia foi escrito conforme eu estudava, então o foco era aprender, e não escrever bem. Vamos lá:

4.1 O DB2 tem dois tipos de monitores
  Snapshot: Captura o estado do banco em um determinado momento. É configurável, você pode definir o que será capturado no snapshot.
  Event monitors: Pode ser um ou mais, eles ficam logando algum evento específico que acontece ou sobre um estado em específico.
 
4.2 Os tipos de monitores de eventos podem ser:

• Counters: Contam o numero de vezes que determinando evento acontece. É incremental.
• Gaufes: É uma espécie de contador, mas registra o número de vezes por um período, por exemplo: quantas aplicações estão conectadas no meu banco neste momento.
• Watermarks: Indica o maior e o menor número de um evento, exemplo: o maior número de linhas já afetadas por uma instrução.
• Information: Mostra informações sobre diferentes tipos de elementos.
• Timestamps: Mostra a data/hora que determinado evento ocorreu
• Time: Registra o tento de tempo que determinada atividade levou.

  Podemos criar monitores de eventos com a seguinte sintaxe:
CREATE EVENT MONITOR [Name]
FOR [DATABASE | BUFFERPOOLS | TABLESPACES | TABLES | DEADLOCKS |
    CONNECTIONS |
    STATEMENTS |
    TRANSACTIONS , ...]
WRITE TO [TABLE [GroupName] (TABLE [TableName]) | PIPE [PipeName] | FILE
[DirectoryName]]
[MANUALSTART | AUTOSTART]

A qualquer momento podemos parar ou iniciar um monitor, e ainda forçar que ele gere um output mesmo não sendo o momento "agendado" para isso.

4.3 Health Monitor
É um serviço do DB2 que fica rodando e monitorando a saúde do banco de dados, enviando mensagens, logando e tomando ações se alguma coisa errada for ocorrer com o banco de dados. Por padrão, o monitor é desativado quando cria-se uma base. Para ativa-lo temos que setar o parâmetro health_mon para ON.
O Health Center é uma ferramenta do DB2 que manipula especificamente o Health Monitor e os logs gerados pelo mesmo.

4.4 Analisando SQL com Explain
Aqui vou passar realmente rápido pois escreverei em um futuro próximo um artigo específico sobre esse tema.
Basicamente, quando executamos algo (um select, insert, etc), o DB2 faz um plano de execução, estudando os passos por onde vai passar, possíveis locks, etc.
Você pode capturar informações sobre isso e as estudar para otimizar o desempenho de sua query.
A sintaxe do comando explain é:
EXPLAIN [ALL | PLAN | PLAN SELECTION]

FOR [SQLStatement]
Onde será gerado um output para o comando "SQMStatement".
Feito isso, você pode estudar o output com os utilitários db2expln, db2exfmt ou o Visual Explain.
O dado mais importante gerado pelo explain é o TIMERONS, que é a unidade de medida utilizada pelo DB2 para computar o tempo e recursos que uma query vai levar.

Para poder efetuar explain, um conjunto de tabelas devem ser criadas. Tipicamente, tais tabelas NÃO SÃO CRIADAS em ambientes de produção, mas sim, em ambientes de desenvolvimento.

Voltar para o índice.

Guia de estudos DB2 - Prova 731 - Parte 3

Esta parte de nosso estudo para a certificação DBA DB2 (731) cobre o Centro de Tarefas, gerência de índices, constraints, view e tabelas do catálogo do sistema.
Por favor, ignore erros de português. Esse guia foi escrito conforme eu ia estudando, portanto, a preocupação era aprender, e não escrever bem. :-)

3.1 Centro de tarefas
O centro de tarefas do DB2 permite que sejam criadas tarefas agendadas que podem executar comandos do DB2, comandos do SO, comandos JCL ou MVC e ainda uma combinação dos comandos anteriores. Para pode utilizar o centro de tarefas, o banco de dados tools catalog deve ser criado com o comando:

db2 create tools catalog cc create new database toolsdb

Para iniciar o centro de tarefas o comando é db2tc. As tarefas podem ser de vários tipo, podem por exemplo executar rotinas de backup, limpeza, cálculos, etc. Elas podem ser agendadas e usuários podem ser notificados via email ao final da execução.


3.2 Índices
Índices são utilizados para garantir valores únicos em tabelas e para melhorar a performance de consultas.

Podemos criar um index com o comando "create index" ou ainda quando criamos um tipo UNIQUE em uma tabela, quando criamos um campo referenciando outro campo em uma outra tabela ou ainda quando criamos uma tabela com mais que uma dimensão, um índice é criado.

Um DBA tem que pesar muito bem o benefício de se criar um índice. Quando qualquer dado de uma tabela á alterado, o índice tem que ser alterado também, e isso toma tempo de processador além de espaço em disco.

Um índice pode ser criado no momento da criação da tabela ou ainda criado a qualquer outro momento. As sintaxes são:

CREATE TABLE TEST (
 column 1 definition, column 2 definition, ...
) IN INDEX IN
     
CREATE INDEX ON
( column 1 , column 2 ... )
É possível adicionar colunas em um índice:
CREATE UNIQUE INDEX IX ON EMPLOYEE (EMPNO) INCLUDE(LASTNAME,FIRSTNME)

Normalmente cria-se 1 ou 2 índices por tabela em um banco OLTP, para um banco misto são 2 a 4, e finalmente para um DW são 5 ou mais. As tabelas de índices são residentes no mesmo table space que a tabela reside por padrão, mas você pode especificar um outro table space, o que é até uma boa prática. No momento de criar um indice UNIQUE em uma tabela existente o banco verifica se o mesmo pode ser criado, ou seja, verifica se não existe algum dado que quebre, caso exista uma quebra o indice não é criado.

3.3 Constraints
São restrições definidas pelo DBA para garantir integridade ao banco, por exemplo: validar se um campo chave não se repita, validar se um campo filho tem seu correspondente, validar o conteúdo a ser inserido, etc. Podem ser definidos na criação da tabela ou na alteração da mesma:
 
ALTER TABLE EMPLOYEE       ADD CONSTRAINT check_job  CHECK (      JOB IN ('Engineer','Sales','Manager'))    CREATE TABLE EMPLOYEE  (     EMPNO INT NOT NULL PRIMARY KEY,     JOB VARCHAR(10) CONSTRAINT CHECK_JOB        CHECK (JOB IN ('Engineer','Sales','Manager')),   ...  )

No momento de criar uma constraint o banco verifica se a mesma pode ser criada, vendo se não existe algum dado que a quebre. É possível criar uma constraint "not forced", o que quer dizer, que o valor não tem que ser obrigatoriamente o que está sendo inserido, alterado:  

SEX CHAR(1) NOT NULL    CONSTRAINT  SEXOK    CHECK (SEX IN ('M','F'))    NOT ENFORCED    ENABLE QUERY OPTIMIZATION,

O ENABLE QUERY OPTIMIZATION vai otimizar a query para os valores que estão no check, então, quando se efetuar um select filtrando por um valor diferente de M ou F, o resultado não será trazido, pois a query estará otimizada para os valores M e F. (Essa é fatal cair na prova de certificação) É possível desabilitar a otimização:

ALTER TABLE EMPDATA  ALTER CHECK SEXOK DISABLE QUERY OPTIMIZATION
 
3.4 Views
Uma view é uma "tabela virtual" derivada de uma ou mais tabelas. Quando você altera os dados em uma view, o campo da tabela original, também é alterado, desde que o DB2 possa determinar a origem do dado, porém, você pode definir se a view poderá sofrer operações tais como update, delete, etc. Sintaxe do comando:
 
CREATE VIEW view-name (column list) AS (fullselect)

Exemplo de comando de criação:

CREATE VIEW TELEPHONE_BOOK AS  (  SELECT FIRST_NAME, LAST_NAME, EXTENSION FROM PERSONNEL  )

Podemos criar views a partir da união de duas ou mais tabelas. É possível alterar dados de uma view, porém tenha em mente que ao fazer isso, você estará automaticamente alterando a tabela da qual a view é originada.Quando criamos uma view utilizando o parâmetro "WITH CHECK OPTION", garantimos que só será feito um update na mesma se for utilizado a cláusula where. Uma View inoperante é uma view que não tem mais função, por exemplo, a tabela a qual a mesma se referencia foi deletada ou não se tem privilégios sobre a mesma.
 
3.5 Tabelas do catálogo so sistema
Estas tabelas são utilizadas para manter nosso banco de dados e contem informações tais como definição das tabelas, permissões, etc. Elas ficam no esquema SYSCATSPACE. Quando um banco é criado, é dado permissão de select para todo mundo (public) nestas tabelas.Para remover o privilégio de select em uma tabela o comando é:  

REVOKE SELECT ON SYSCAT.DBAUTH FROM PUBLIC

Para dar permissão, trocamos o Revoke por Grant. As tabelas do catálogo mais úteis são:

• SYSCAT.COLUMNS: Onde estão as colunas de TODAS as tabelas do banco.
• SYSCAT.INDEXCOLUSE: Mostra as colunas que são índice.
• SYSCAT.INDEXES: Mostra os índices de cada tabela.
• SYSCAT.TABLES: Mostra todas as tabelas do sistema.
• SYSCAT.VIEWS: Mostra todas as tabelas do sistema.

3.6 Forçando dados únicos
A clausula UNIQUE força que determinado campo em uma tabela tenha um valor único, por exemplo, o CPF, não será repetido nas outras linhas da tabela. Quando uma primary key é criada, o campo automaticamente será do tipo UNIQUE. Também pode-se criar um campo que não seja PK mas seja do tipo Unique, por exemplo:
CREATE TABLE EMPLOYEE  (  ....,  SOCINS CHAR(11) NOT NULL UNIQUE,  ...,  )

Finalmente pode ser criado um índice único, como em:
CREATE UNIQUE INDEX UNIQUE_EMPLOYEE ON EMPLOYEE(EMPNO)

Voltar para o índice do guia.

Executando comandos do Sistema Operacional em uma aplicação WEB Java

Criei uma aplicação muito simples que demonstra como um Servlet pode invocar uma classe que efetua um comando qualquer no sistema operacional.

O projeto foi testado em Linux, Unix e Solaris. Caso testem em Windows e puderem me dar um feedback, fico grato.

O mesmo foi criado no Eclipse e utiliza o Tomcat 6 como servidor de aplicação, foi utilizado o Java 6. Deve funcionar com outras versões.

A estrutura do projeto é:

onde:

• DiskFree: classe java que executa o comando df no sistema operacional que está rodando o tomcat e retorna um BufferedReader.
• ExecuteCommand: classe java que executa qualquer comando que for enviada para ela no host do tomcat.
• ServletDF: É o servlet que invoca a classe DiskFree.
• ServletExecuteCommand: É o servlet que invoca a classe Executar comando.
• index.html: Página principal da aplicação que invoca os servlets e permite que o usuário entre com um comando a ser executado.
  

Vale lembrar que a aplicação tem finalidade didática, portanto, não foram observados padrões de projeto, boas práticas, etc.


Para baixar o projeto, clique aqui.

Enjoy!

Guia de estudos DB2 - Prova 731 - Parte 2

Esta é a continuação do guia de estudos para o exame 731 (DBA DB2). Deve ser utilizado como um complemento para os estudos, e não como a fonte principal. Nesta parte focaremos na criação e gerenciamento de objetos do bancos de dados.

2.1 - Criação de banco de dados e table spaces
Comando "db2 create database"
Este comando tem N parametros, dentre eles, o Codeset (linguagem do banco), as tablespaces, o diretório onde o banco vai ficar, etc.
Por padrão, este comando cria 3 table spaces:
SYSCATSPACE: é onde se armazena o catálogo do sistema (system catalog), ou seja, onde as informações sobre o banco serão armazenadas. Não pode ser apagada.
TEMPSPACE1: Tabela temporária. Pode ser dropada desde que outra seja criada.
USERSPACE1: O padrão onde os objetos do usuário serão criados. Pode ser deletada se existir outro table space com a mesma finalidade.

Ao efetuar o comando create table, o banco de dados é criado no diretório apontado pela variável DFTDBPATH por padrão. Se esta variável for vazia e se o usuário não especificar manualmente a localização da base de dados, a mesma será criada exatamente onde o comando foi executado.

Para especificar o local de criação de uma base, a sintaxe é:
"db2 create database test on /home/julianom/base1"
no caso, /database é onde a mesma será criada.

Explorando os arquivos criados, vemos que o comando criou um diretório db2inst1 e dentro dele um chamado NODE0000 DENTRO do base1:

 base1/db2inst1/NODE0000/

NODE0000 representa um diretório de uma base não particionada, se fosse algo particionado, seria um número correspondente a partição.
db2inst1 representa a instância na qual a base foi criada.

Dentro do diretório NODE0000 podemos observar outros 3 diretórios:

SQL00001  sqldbdir  TEST

Nossa base está dentro de SQL00001. Podemos ter inúmeras bases no mesmo diretório, então, este número corresponde a uma base, para ter certeza qual a sua base, efetuamos o comando "db2 list database directory on /home/julianom".

Uma table space pode ser do tipo DMS - Database Managed Space, onde, a mesma vai crescendo sob demanda e não tem interação do usuário neste crescimento, para se criar uma dessa forma sendo armazenada em dois arquivos diferentes (e até em diretórios diferentes):
create database sample2 user table space managed by database
            using(file '/dbfiles/cont0' 5000, file '/dbfiles/cont1' 5000)

Outro tipo de gerenciamento de Table Spaces é o SMS: System Managed Space, onde a adição de mais espaço deve ser feita manualmente, comando:

create database sample3 temporary tablespace managed by system
            using('/dbfiles/cont0', '/dbfiles/cont1')


2.2 Automatic Storage
Basicamente é a gerência de espaço em disco automaticamente pelo DB2. Você seta como automático, e quando vai criar uma table space, não precisa especificar localização, o DB2 cria automaticamente nos caminhos setados pelo usuário:
db2 create database db_name automatic storage yes
db2 create database db_name on db_path1, db_path2

Mesmo se um DB não está setado para Automatic Storage, podemos setar uma Table Space para ser gerenciada dessa forma:
db2 create tablespace ts_name managed by automatic storage

2.3 Schemas
É um meio lógico de gerenciar objetos do seu banco de dados. Por exemplo, podemos ter tabelas no esquema FINANCEIRO, onde somente determinados usuários poderão fazer insert, updates, etc. Nos referimos a um objeto do esquema da seguinte forma: esquema.objeto.
Alguns esquemas são criados por padrão quando se cria um DB:

• SYSIBM: O esquema com os objetos básicos do BD.
• SYSCAT: Views do catálogo públicas.
• SYSSTAT: Views do catalogo que influenciam o otimizador.
• SYSFUN: Funções definidas pelo usuário.
  

Normalmente temos um esquema com o nome do usuário no BD.

2.4 Tablespaces
Espaço em disco onde os dados são armazenados, o disco físico é também conhecido como container.
Para ver o estado das tablespaces, o comando é:
db2 list tablespaces show detail

2.5 Objetos do banco de dados
O DB2 tem alguns objetos muito importantes para seu funcionamento, e um DBA precisa conhecer muito bem estes objetos, seguem os principais:

2.5.1 Buffer pools: Área em memória onde ficam os dados em cache, ou seja, que estão sendo lidos do disco. O disco é lento, já a memória é rápida, então o BD tenta manter o máximo de dados possível em memória.

Para criar um buffer pool: db2 create bufferpool , onde você estabelece nome, tamanho, entre outros, exemplo:
create bufferpool BP1 size 25000

2.5.2 Tabelas: São onde as informações residem. Você pode especificar manualmente em qual tablespace sua tabela vai ser alocada, além disso você pode colocar os índices e certos tipos de dados como long, em outras table spaces.
O comando para se criar uma tabela é "create table".

Mais comandos úteis:

• list tables - Lista as tabelas do usuário
• list tables for all - Listar todas as tabelas de uma base
• list tables for schema x - Listar todas as tabelas do esquema X
• describe table tablename - Mostra a estrutura de uma determinada tabela
  

2.5.3 Índices
São a chave de busca/acesso aos dados em uma tabela. Alguns exemplos:
create unique index itemno on albums (itemno) desc
create index clx1 on stock (shipdate) cluster allow reverse scans
create unique index incidx on stock (itemno) include (itemname)
create index item on stock (itemno) disallow reverse scans collect detailed statistics

2.5.4 Colunas identidade (identity)
São as conhecidas chaves sequenciais. Podem ser gerados pelo DB2 ou passados pelo usuário (caso não seja passado, o DB2 irá gerar automaticamente). Não pode ser repetido em uma tabela. Comando de criação:
create table inventory (partno INTEGER GENERATED ALWAYS AS IDENTITY
          (START WITH 100 INCREMENT BY 1), description CHAR(20) )
         
2.5.5 Views
Uma view é uma espécie de tabela derivada de uma consulta em uma ou mais tabelas/views.

Quando uma alteração é feita em uma view, a alteração é feita na tabela correspondente a ela também.

Os dados de uma view não são armazenados separadamente dos dados de uma tabela. As definições de uma view ficam no catálogo do sistema.

Exemplo de criação de uma view:
create view DEPTSALARY AS SELECT DEPTNO, DEPTNAME, SUM(SALARY)
          AS TOTALS FROM PAYROLL GROUP BY DEPTNO,DEPTNAME
create view EMPSALARY AS SELECT EMPNO, EMPNAME, SALARY FROM PAYROLL,
          PERSONNEL WHERE EMPNO=EMPNUMB
         
2.5.6 Constraints
Como o nome diz, RESTRINGE algo. Uma constraint não pode ser alterada. Ela deve ser removida e criada em caso de necessidade de alteração. Existem diferentes tipos de constraints:

a) Integridade referencial: Pode ser primary key, unique, foreign e references.
b) Unique: não permite repetir um valor para uma coluna.
c) Check: Força que um valor de um campo obedeça a um padrão.
d) Informational: São regras utilizadas pelo otimizador para definir comportamento, por exemplo, se uma chave será verificada num load de dados.

2.5.7 Triggers
Define-se como uma série de ações que serão disparadas por uma ação. Pode ser disparada antes ou depois de inserts, updates ou deletes.

2.6 Multi-dimensional clustering
Fazendo uma analogia é como se armazenar dados, ao invés de em estruturas como uma planilha (tabela), numa matriz multidimensional. Para se criar uma tabela MDC, utilizamos o organize by:

CREATE TABLE MDCTABLE(
Year INT,
Nation CHAR(25),
Colour VARCHAR(10),
... )
ORGANIZE BY(Year, Nation, Color)

2.7 Particionamento de tabelas
Basicamente consiste em dividir tabelas para obter maior desempenho. Por exemplo, podemos ter uma tabela de vendas dividida por data, no caso abaixo, estamos dividindo de dois em dois anos:

CREATE TABLE fact
(txn_id char(7), purchase_date date, ...)
IN tbsp1, tbsp2, tbsp3, tbsp4
PARTITION BY RANGE (purchase_date)
(
STARTING FROM ('2005-01-01')
ENDING ('2006-12-31')
EVERY 1 MONTH
)

Não podemos particionar uma tabela utilizando campos Logs ou Long Varchar. Podemos utilizar múltiplos campos na partição.

É possível atachar uma partição a uma tabela com o comando ATTACH:
ALTER TABLE FACT_TABLE ATTACH PARTITION
STARTING '06-01-2006'
ENDING '06-30-2006'
FROM TABLE FACT_NEW_MONTH

2.8 Compactação de tabelas (compression)
Basicamente Strings repetidas são substituídas e colocadas num dicionário. Sintaxe:
create table table_name ... compress yes
Ou
alter table tablename compress yes

Na primeira vez que for compactar uma tabela, utilizamos a sintaxe para criar o dicionário:
reorg table table_name resetdictionary

Nas próximas vezes, não precisamos criar o mesmo:
reorg table table_name keepdictionary

É possível estimar o quanto de espaço liberaremos com a compactação com o comando:
db2 inspect rowcompestimate table name table_name results keep file_name
E então (para converter o arquivo de binário para texto):
db2inspf file_name output_file_name

2.9 XML
DB2 trabalha com XML como um tipo de dados NATIVO. Para se criar uma tabela com um tipo XML:
create table table_name (col1 data_type, ..., xml_col_name XML)

É possível que um campo XML seja um index.

Para ver o índice do guia de estudos, clique aqui.

IBM vai encerrar o suporte ao Websphere 6.0(WAS)

A IBM vai encerrar o suporte ao WebSphere Application Server versão 6.0 em 30 de setembro de 2010.

Fonte: http://www-01.ibm.com/software/support/lifecycle/index_w.html

Para os usuário insteressados em migração, pode-se escolher o WAS 7.0 ou o 6.1. Eu particularmente sugiro o 7 pois o mesmo já suporta Java 6.

Os sites para informações sobre requisitos de sistema são:

WebSphere Application Server Deployment Manager V7.0
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27012453
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27012474
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27012473

WebSphere Application Server Deployment Manager V6.1:
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27007686
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27007689
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27007688

Enjoy!

Livro grátis: HPC for dummies

A Sun Microsystems e AMD, junto com a famosa editora “For Dummies”, estão oferecendo de forma gratuita, o e-book "High Performance Computing for Dummies", com o qual você poderá aprender o ABC do HPC, conhecimento que lhe proporcionará uma ferramenta a mais para alcançar a vantagem profissional.

Eu baixei e li e apesar de notar certa tendência em alguns pontos, o livro é muito bom! Vale a pena para se iniciar no tema!

Para baixar, clique aqui.

Enjoy!

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.

Enjoy!