Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
código fonteTrabalhando com o SGBD DB2 Revista SQL Magazine 99 - Parte 2
Este artigo demonstra a configuração do DB2 para que seja utilizado como o banco de dados de uma aplicação. Será demonstrado como o administrador de banco de dados pode se conectar ao DB2 e executar comandos de manutenção.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
SQL Magazine 99
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 99
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 99
No artigo anterior, apresentamos um resumo do DB2 e da própria linguagem SQL, conhecendo a evolução deste excelente Sistema Gerenciador de Banco de Dados (SGBD). Vimos também a respeito das diferentes edições e funcionalidades do DB2, qual sua posição no competitivo mercado atual, e finalmente instalamos sua edição gratuita, o DB2 Express-C, e criamos um banco de dados de testes, o SAMPLE.
O DB2 é um SGBD (Sistema Gerenciador de Banco de Dados) desenvolvido pela IBM. Hoje ele pode ser executado tanto para sistemas operacionais de mainframe quando na chamada baixa plataforma, que utiliza os sistemas operacionais Unix, Linux e Windows.
Para conseguir atender ambientes tão distintos, a IBM desenvolve dois produtos separados (e desenvolvidos por equipes separadas), o DB2 para z/OS e System i e o DB2 LUW. O DB2 possui todas as funcionalidades avançadas esperadas de um SGBD que são necessárias em aplicações de missão crítica, como compressão de dados e índices, auditoria, e alta disponibilidade através de particionamento, replicação e cluster.
Os bancos de dados relacionais nasceram na IBM. O DB2 possui uma longa história que se confunde com a própria linguagem SQL, e que possui desdobramentos pelas principais áreas da computação, e por conta disso, este produto participou ativamente da definição de todo o mercado de SGBDs. Ele foi o primeiro SGBD a utilizar a linguagem SQL (também desenvolvida inicialmente pela IBM), embora a Oracle tenha lançado um produto comercial similar antes da IBM. Ou seja, a IBM fez primeiro, mas a Oracle vendeu antes.
Neste artigo iremos executar algumas tarefas básicas de administração do DB2, focando no conhecimento mínimo necessário para iniciar sua utilização, como um guia de sobrevivência. Iremos executar todas estas tarefas via linha de comando, pois temos certeza que este tipo de ferramenta sempre está disponível para um administrador, ao contrário de ferramentas gráficas ou de terceiros.
A principal ferramenta de acesso ao DB2 é o utilitário CLP ou Command Line Processor (“Processador de Linha de Comando”), que é invocado digitando-se “db2” no terminal, com o usuário proprietário da instância DB2. No nosso caso, o usuário é o db2inst1, que é o padrão fornecido pela instalação.
O CLP pode ser utilizado no modo interativo, de comando, ou batch (alimentado por arquivos de lote). Vamos então ver as diferenças entre os dois primeiros tipos de utilização do CLP, usando como exemplo a tarefa mais importante que deve ser executada em um banco de dados: sabemos que a maior responsabilidade do administrador de bancos de dados é a recuperação e para que esta seja possível, é necessário antes possuir um backup (ver Nota DevMan 1), esta será nossa primeira tarefa com o DB2.
Nota DevMan 1: Backup
Em tecnologia da informação, um backup (cópia de segurança) ou o processo de backup é fazer cópias de dados que podem ser utilizados para restaurar o estado original dos dados após um evento de perda de dados.
Backups têm duas finalidades distintas. O objetivo principal é recuperar os dados após a sua perda, seja por exclusão de dados ou corrupção. O objetivo secundário de um backup é o de recuperar dados de um determinado momento no tempo, de acordo com a política de retenção de dados definida pelo usuário (ou corporação), geralmente configurado dentro de um aplicativo de backup por quanto tempo cópias de dados são necessários.
Se um sistema está em uso enquanto estiver sendo feito o backup, a possibilidade de os arquivos serem abertos para leitura ou gravação é real. Se um arquivo é aberto, o conteúdo do disco não pode representar corretamente o que o dono do arquivo pretende. Isto é verdade para os arquivos de banco de dados de todos os tipos. O termo backup pode ser usado para descrever um backup de dados em tempo real que parece que funcionou corretamente, mas não representa o estado dos dados em qualquer ponto único no tempo. Isso ocorre porque os dados que estão sendo copiados também foram (ou estão sendo) alterados no período de tempo entre o momento em que o backup começou e quando terminou.
O primeiro exemplo utilizará o modo interativo do CLP, como está na Listagem 1. Primeiramente iniciamos o CLP (linha 1), para então executar o comando de execução do backup do banco de dados SAMPLE (linha 17). A mensagem de retorno do comando indica qual é o timestamp do backup (linha 19), ou seja, sua data e hora exata de execução (29-02-2012 às 13:36:01). Por padrão, o backup será armazenado em disco, e no mesmo diretório em que o administrador estava quando o CLP foi executado. Após sair do modo interativo do CLP com o comando QUIT (linha 20), verificamos quais os arquivos existentes no diretório onde estamos, e lá está nosso backup (linha 26). Veja que o nome do arquivo inclui o timestamp, além de outras informações muito úteis, como o nome do banco de dados. O timestamp será especialmente útil durante uma possível recuperação.
"
Este é um post disponível para assinantes MVP
O DB2 é um SGBD (Sistema Gerenciador de Banco de Dados) desenvolvido pela IBM. Hoje ele pode ser executado tanto para sistemas operacionais de mainframe quando na chamada baixa plataforma, que utiliza os sistemas operacionais Unix, Linux e Windows.
Para conseguir atender ambientes tão distintos, a IBM desenvolve dois produtos separados (e desenvolvidos por equipes separadas), o DB2 para z/OS e System i e o DB2 LUW. O DB2 possui todas as funcionalidades avançadas esperadas de um SGBD que são necessárias em aplicações de missão crítica, como compressão de dados e índices, auditoria, e alta disponibilidade através de particionamento, replicação e cluster.
Os bancos de dados relacionais nasceram na IBM. O DB2 possui uma longa história que se confunde com a própria linguagem SQL, e que possui desdobramentos pelas principais áreas da computação, e por conta disso, este produto participou ativamente da definição de todo o mercado de SGBDs. Ele foi o primeiro SGBD a utilizar a linguagem SQL (também desenvolvida inicialmente pela IBM), embora a Oracle tenha lançado um produto comercial similar antes da IBM. Ou seja, a IBM fez primeiro, mas a Oracle vendeu antes.
Neste artigo iremos executar algumas tarefas básicas de administração do DB2, focando no conhecimento mínimo necessário para iniciar sua utilização, como um guia de sobrevivência. Iremos executar todas estas tarefas via linha de comando, pois temos certeza que este tipo de ferramenta sempre está disponível para um administrador, ao contrário de ferramentas gráficas ou de terceiros.
A principal ferramenta de acesso ao DB2 é o utilitário CLP ou Command Line Processor (“Processador de Linha de Comando”), que é invocado digitando-se “db2” no terminal, com o usuário proprietário da instância DB2. No nosso caso, o usuário é o db2inst1, que é o padrão fornecido pela instalação.
O CLP pode ser utilizado no modo interativo, de comando, ou batch (alimentado por arquivos de lote). Vamos então ver as diferenças entre os dois primeiros tipos de utilização do CLP, usando como exemplo a tarefa mais importante que deve ser executada em um banco de dados: sabemos que a maior responsabilidade do administrador de bancos de dados é a recuperação e para que esta seja possível, é necessário antes possuir um backup (ver Nota DevMan 1), esta será nossa primeira tarefa com o DB2.
Nota DevMan 1: Backup
Em tecnologia da informação, um backup (cópia de segurança) ou o processo de backup é fazer cópias de dados que podem ser utilizados para restaurar o estado original dos dados após um evento de perda de dados.
Backups têm duas finalidades distintas. O objetivo principal é recuperar os dados após a sua perda, seja por exclusão de dados ou corrupção. O objetivo secundário de um backup é o de recuperar dados de um determinado momento no tempo, de acordo com a política de retenção de dados definida pelo usuário (ou corporação), geralmente configurado dentro de um aplicativo de backup por quanto tempo cópias de dados são necessários.
Se um sistema está em uso enquanto estiver sendo feito o backup, a possibilidade de os arquivos serem abertos para leitura ou gravação é real. Se um arquivo é aberto, o conteúdo do disco não pode representar corretamente o que o dono do arquivo pretende. Isto é verdade para os arquivos de banco de dados de todos os tipos. O termo backup pode ser usado para descrever um backup de dados em tempo real que parece que funcionou corretamente, mas não representa o estado dos dados em qualquer ponto único no tempo. Isso ocorre porque os dados que estão sendo copiados também foram (ou estão sendo) alterados no período de tempo entre o momento em que o backup começou e quando terminou.
O primeiro exemplo utilizará o modo interativo do CLP, como está na Listagem 1. Primeiramente iniciamos o CLP (linha 1), para então executar o comando de execução do backup do banco de dados SAMPLE (linha 17). A mensagem de retorno do comando indica qual é o timestamp do backup (linha 19), ou seja, sua data e hora exata de execução (29-02-2012 às 13:36:01). Por padrão, o backup será armazenado em disco, e no mesmo diretório em que o administrador estava quando o CLP foi executado. Após sair do modo interativo do CLP com o comando QUIT (linha 20), verificamos quais os arquivos existentes no diretório onde estamos, e lá está nosso backup (linha 26). Veja que o nome do arquivo inclui o timestamp, além de outras informações muito úteis, como o nome do banco de dados. O timestamp será especialmente útil durante uma possível recuperação.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Com 20 anos de experiência profissional, Ricardo Portilho Proni é Oracle ACE e já trabalhou em grande parte dos maiores bancos de dados Oracle e MySQL do Brasil. É certificado em Oracle, MySQL, SQL Server, DB2, Sybase e WebSphere. Arquiteto na UOLDIVEO e Instrutor da Nerv Informática Ltda, também é ...
O que você achou deste post?
Cursos relacionados
Publicidade
