DB2 Express-C 9.5 Sistemas de Bancos de Dados - Univates Bruno Dadalt Zambiazi
DB2 Gerenciador de bancos relacionais com suporte a XML; Lançado em 1983 pela  IBM ; SGBD de grande porte e alto desempenho; Stored Procedures podem ser escritas em diversas linguagens; Versões para servidores Windows, Linux, Unix, Mainframes e PDA’s; Versão gratuita:  Express-C  (2006).
DB2 - Versões
Controle de Transações
Transações “ Executar uma rotina e, durante a mesma, parar o servidor. Iniciar novamente o servidor, verificando se a transação funcionou corretamente.” Método : execução de um rotina responsável pela inserção de 425 registros na tabela  retiradas ; Mensagem : "Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram terminados, ou este pedido específico foi terminado devido a condições de erro inesperadas detectadas no sistema de destino. ERRORCODE=-4499, SQLSTATE=58009"; Nº de registros na tabela  antes de parar o servidor :  0 ; Nº de registros na tabela  após parar o servidor :  0 ; Conclusão : passou no teste, pois nenhum registro foi inserido ao ocorrer algum problema durante a transação.
Transações “ Executar duas rotinas de forma simultânea e, quando uma delas indicar que terminou, parar o servidor. Iniciar novamente o servidor e verificar se a transação que terminou teve os dados efetivados e se a outra teve as atualizações desfeitas.” Método : execução de um rotina para inserção de 25 registros na tabela  exemplares  e outra pela pela inserção de 440 registros na tabela  retiradas ; Mensagem : "Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram terminados, ou este pedido específico foi terminado devido a condições de erro inesperadas detectadas no sistema de destino. ERRORCODE=-4499, SQLSTATE=58009"; Nº de registros na tabela  exemplares  antes de parar o servidor :  500 ; Nº de registros na tabela  retiradas  antes de parar o servidor :  0 ; Nº de registros na tabela  exemplares  após parar o servidor :  525 ; Nº de registros na tabela  retiradas  após parar o servidor :  0 ; Conclusão : passou no teste, pois a transação que estava aberta no momento da interrupção do servidor não teve as suas atualizações efetivadas.
Controle de Concorrência
Concorrência – Níveis de Isolamento Uncommited Read  (Leitura de dados não finalizados) Menor nível de isolamento, maior nível de concorrência; Não há bloqueios em operações de consultas; Operações de atualizações ocorrem da mesma forma que o Cursor Stability; Também conhecido como Dirty Read (Leitura Suja).   Cursor Stability  (Estabilidade do cursor) É o nível de isolamento padrão do DB2; Oferece o menor nível de bloqueio; Operações de consulta bloqueiam a linha até a captura; Operações de atualização bloqueiam até o fim da transação.
Concorrência – Níveis de Isolamento Read Stability   (Estabilidade da leitura) Todas as linhas que fazem parte da operação são bloqueadas até o fim da transação; Usa um grau moderado de bloqueio. Repeatable Read   (Leitura repetida) Maior nível de isolamento, menor nível de concorrência; O bloqueio é feito em qualquer linha, mesmo que esta não faça parte do resultado final; Nada pode ser feito antes do término da primeira operação em processamento.
Concorrência – Bloqueio Podem ocorrer à nível de tabela ou de linhas; Existem dois tipos: Bloqueios Divididos (Share Locks) Acontecem quando uma aplicação/transação realiza a leitura de dados e impede que os mesmos sofram alterações por outras aplicações/transações. Bloqueios Exclusivos (Exclusive Locks) Acontecem quando uma aplicação/transação quer atualizar, inserir ou remover alguma linha.
Concorrência – Níveis de Isolamento
Concorrência “ Executar duas rotinas simultâneas que alteram dados na tabela  retiradas , para verificar se uma transação interfere em outra.” Método : a primeira rotina consultou as  retiradas  do mês  03/2010 , de dois em dois dias, adicionando um dia à data de retirada e atualizando o registro. A segunda rotina consultou as  retiradas  de  20 usuários  sorteados, subtraindo um dia à data da retirada; Registro : retirada  29780 ; Datas (antiga e nova) da retirada na primeira rotina : 01/03 e 02/03; Horário da atualização : 09:48: 32:609 ; Datas (antiga e nova) da retirada na segunda rotina : 02/03 e 01/03; Horário da atualização : 09:48: 33:484 ; Conclusão : passou no teste, visto que cada processo de consulta e atualização era uma nova transação.
Otimização de Consultas
Otimização de Consultas select  reti.id_retirada ,  usua.nm_usuario ,  aten.nm_atendente ,  reti.id_livro ,  cida.nm_cidade from  user.retiradas reti ,  user.usuarios usua ,  user.atendentes aten ,  user.cidades cida where (  reti.id_usuario  = usua.id_usuario and reti.id_atendente = aten.id_atendente and usua.id_cidade  = cida.id_cidade ) and  (  usua.id_cidade = aten.id_cidade or usua.id_cidade = 1416 ) Tempo decorrido : Sem índices: 0:00: 05:81 Com índices: 0:00: 01:12 Índices criados: reti.id_usuario reti.id_atendente usua.id_cidade aten.id_cidade
Plano – Sem Índices
Plano – Com Índices
Otimização de Consultas select  aten.id_atendente ,  aten.nm_atendente ,  count( reti.id_retirada ) from  user.atendentes aten ,  user.retiradas  reti Where aten.id_atendente = reti.id_atendente group  by aten.id_atendente ,  aten.nm_atendente having  count( reti.id_retirada )  >=  all( select count( reti2.id_retirada ) from  user.retiradas reti2 group  by reti2.id_atendente ) Tempo decorrido : Original:  0:00: 10:39 Alterada: 0:00: 06:57 select aten.id_atendente ,  aten.nm_atendente ,  count( reti.id_retirada ) from  user.atendentes aten ,  user.retiradas  reti where aten.id_atendente = reti.id_atendente group  by aten.id_atendente ,  aten.nm_atendente order  by qt_atendimentos desc fetch  first 1 rows only
Replicação de Dados
Replicação Bidirecional com um mestre Igual ao modelo Master-Slave; Nomenclatura: Source e Target; O source (mestre) precisa ter um Capture rodando para capturar as alterações; Todos os targets (escravos) precisam de um Apply para aplicar as alterações;
Replicação – Master-Slave
Replicação Bidirecional sem um mestre Igual ao modelo Multi-Master; Nomenclatura: Source e Target; Ambas as partes precisam ter um Capture rodando para capturar as alterações; Ambas as partes precisam ter um Apply para aplicar as alterações nos outros servidores; Ocorre de forma assíncrona.
Replicação – Multi-Master
Suporte/recursos XML
XML - Armazenamento XML – Enabled Possui como núcleo o modelo relacional; Modelo  CLOB/Varchar : Armazena uma String não analisada sintaticamente; Na consulta, é necessário analisar a String para trabalhar com os dados; Modelo  Shredding (Fragmentação) : Documento é dividido em pequenas partes que serão armazenadas em tabelas; Mudanças no XML não são aplicadas facilmente.
XML - Armazenamento XML - Enabled
XML - Armazenamento XML Nativo (pureXML) Possui como núcleo o modelo de dados hierárquico; Acesso aos dados:  SQL ,  SQL/X ,  XQuery ,  XPath ; Instruções são processadas nativamente, ao invés de serem convertidas para SQL; DB2 é o único SGBD que dá suporte ao XML Nativo.
XML - Exemplos CREATE TABLE clientes(  id_cliente INT PRIMARY KEY NOT NULL , nm_cliente VARCHAR( 100 ) NOT NULL , xml_contatos XML ); INSERT INTO  clientes( id_cliente, nm_cliente, xml_contatos )  VALUES( 1, ‘Bruno’, ‘<endereco>Rua Sem fim, nº 666</endereco>’ );
XML – Funções e Exemplos SELECT nm_livro FROM livros WHERE XMLEXISTS( ‘$autores/autor[nome=“Bruno”]’ ); SELECT XMLQUERY( ‘$autores/autor’ ) FROM livros WHERE nm_livro = ‘Sistemas de Bancos de Dados’; SELECT nm_usuario, XMLQUERY( ‘for $x in $contatos/emails return <p>{$x}</p>’ ) AS emails FROM usuarios WHERE nm_usuario LIKE ‘Bruno%’; SELECT XMLELEMENT( NAME “id_usuario”, id ), XMLELEMENT( NAME “nm_usuario”, nome ) FROM usuarios;

DB2 Express-C

  • 1.
    DB2 Express-C 9.5Sistemas de Bancos de Dados - Univates Bruno Dadalt Zambiazi
  • 2.
    DB2 Gerenciador debancos relacionais com suporte a XML; Lançado em 1983 pela IBM ; SGBD de grande porte e alto desempenho; Stored Procedures podem ser escritas em diversas linguagens; Versões para servidores Windows, Linux, Unix, Mainframes e PDA’s; Versão gratuita: Express-C (2006).
  • 3.
  • 4.
  • 5.
    Transações “ Executaruma rotina e, durante a mesma, parar o servidor. Iniciar novamente o servidor, verificando se a transação funcionou corretamente.” Método : execução de um rotina responsável pela inserção de 425 registros na tabela retiradas ; Mensagem : &quot;Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram terminados, ou este pedido específico foi terminado devido a condições de erro inesperadas detectadas no sistema de destino. ERRORCODE=-4499, SQLSTATE=58009&quot;; Nº de registros na tabela antes de parar o servidor : 0 ; Nº de registros na tabela após parar o servidor : 0 ; Conclusão : passou no teste, pois nenhum registro foi inserido ao ocorrer algum problema durante a transação.
  • 6.
    Transações “ Executarduas rotinas de forma simultânea e, quando uma delas indicar que terminou, parar o servidor. Iniciar novamente o servidor e verificar se a transação que terminou teve os dados efetivados e se a outra teve as atualizações desfeitas.” Método : execução de um rotina para inserção de 25 registros na tabela exemplares e outra pela pela inserção de 440 registros na tabela retiradas ; Mensagem : &quot;Erro fatal: [jcc][t4][2055][11259][4.8.87] O gerenciador de banco de dados não está apto a aceitar novos pedidos, todos os pedidos em progresso foram terminados, ou este pedido específico foi terminado devido a condições de erro inesperadas detectadas no sistema de destino. ERRORCODE=-4499, SQLSTATE=58009&quot;; Nº de registros na tabela exemplares antes de parar o servidor : 500 ; Nº de registros na tabela retiradas antes de parar o servidor : 0 ; Nº de registros na tabela exemplares após parar o servidor : 525 ; Nº de registros na tabela retiradas após parar o servidor : 0 ; Conclusão : passou no teste, pois a transação que estava aberta no momento da interrupção do servidor não teve as suas atualizações efetivadas.
  • 7.
  • 8.
    Concorrência – Níveisde Isolamento Uncommited Read (Leitura de dados não finalizados) Menor nível de isolamento, maior nível de concorrência; Não há bloqueios em operações de consultas; Operações de atualizações ocorrem da mesma forma que o Cursor Stability; Também conhecido como Dirty Read (Leitura Suja). Cursor Stability (Estabilidade do cursor) É o nível de isolamento padrão do DB2; Oferece o menor nível de bloqueio; Operações de consulta bloqueiam a linha até a captura; Operações de atualização bloqueiam até o fim da transação.
  • 9.
    Concorrência – Níveisde Isolamento Read Stability (Estabilidade da leitura) Todas as linhas que fazem parte da operação são bloqueadas até o fim da transação; Usa um grau moderado de bloqueio. Repeatable Read (Leitura repetida) Maior nível de isolamento, menor nível de concorrência; O bloqueio é feito em qualquer linha, mesmo que esta não faça parte do resultado final; Nada pode ser feito antes do término da primeira operação em processamento.
  • 10.
    Concorrência – BloqueioPodem ocorrer à nível de tabela ou de linhas; Existem dois tipos: Bloqueios Divididos (Share Locks) Acontecem quando uma aplicação/transação realiza a leitura de dados e impede que os mesmos sofram alterações por outras aplicações/transações. Bloqueios Exclusivos (Exclusive Locks) Acontecem quando uma aplicação/transação quer atualizar, inserir ou remover alguma linha.
  • 11.
  • 12.
    Concorrência “ Executarduas rotinas simultâneas que alteram dados na tabela retiradas , para verificar se uma transação interfere em outra.” Método : a primeira rotina consultou as retiradas do mês 03/2010 , de dois em dois dias, adicionando um dia à data de retirada e atualizando o registro. A segunda rotina consultou as retiradas de 20 usuários sorteados, subtraindo um dia à data da retirada; Registro : retirada 29780 ; Datas (antiga e nova) da retirada na primeira rotina : 01/03 e 02/03; Horário da atualização : 09:48: 32:609 ; Datas (antiga e nova) da retirada na segunda rotina : 02/03 e 01/03; Horário da atualização : 09:48: 33:484 ; Conclusão : passou no teste, visto que cada processo de consulta e atualização era uma nova transação.
  • 13.
  • 14.
    Otimização de Consultasselect reti.id_retirada , usua.nm_usuario , aten.nm_atendente , reti.id_livro , cida.nm_cidade from user.retiradas reti , user.usuarios usua , user.atendentes aten , user.cidades cida where ( reti.id_usuario = usua.id_usuario and reti.id_atendente = aten.id_atendente and usua.id_cidade = cida.id_cidade ) and ( usua.id_cidade = aten.id_cidade or usua.id_cidade = 1416 ) Tempo decorrido : Sem índices: 0:00: 05:81 Com índices: 0:00: 01:12 Índices criados: reti.id_usuario reti.id_atendente usua.id_cidade aten.id_cidade
  • 15.
    Plano – SemÍndices
  • 16.
    Plano – ComÍndices
  • 17.
    Otimização de Consultasselect aten.id_atendente , aten.nm_atendente , count( reti.id_retirada ) from user.atendentes aten , user.retiradas reti Where aten.id_atendente = reti.id_atendente group by aten.id_atendente , aten.nm_atendente having count( reti.id_retirada ) >= all( select count( reti2.id_retirada ) from user.retiradas reti2 group by reti2.id_atendente ) Tempo decorrido : Original: 0:00: 10:39 Alterada: 0:00: 06:57 select aten.id_atendente , aten.nm_atendente , count( reti.id_retirada ) from user.atendentes aten , user.retiradas reti where aten.id_atendente = reti.id_atendente group by aten.id_atendente , aten.nm_atendente order by qt_atendimentos desc fetch first 1 rows only
  • 18.
  • 19.
    Replicação Bidirecional comum mestre Igual ao modelo Master-Slave; Nomenclatura: Source e Target; O source (mestre) precisa ter um Capture rodando para capturar as alterações; Todos os targets (escravos) precisam de um Apply para aplicar as alterações;
  • 20.
  • 21.
    Replicação Bidirecional semum mestre Igual ao modelo Multi-Master; Nomenclatura: Source e Target; Ambas as partes precisam ter um Capture rodando para capturar as alterações; Ambas as partes precisam ter um Apply para aplicar as alterações nos outros servidores; Ocorre de forma assíncrona.
  • 22.
  • 23.
  • 24.
    XML - ArmazenamentoXML – Enabled Possui como núcleo o modelo relacional; Modelo CLOB/Varchar : Armazena uma String não analisada sintaticamente; Na consulta, é necessário analisar a String para trabalhar com os dados; Modelo Shredding (Fragmentação) : Documento é dividido em pequenas partes que serão armazenadas em tabelas; Mudanças no XML não são aplicadas facilmente.
  • 25.
    XML - ArmazenamentoXML - Enabled
  • 26.
    XML - ArmazenamentoXML Nativo (pureXML) Possui como núcleo o modelo de dados hierárquico; Acesso aos dados: SQL , SQL/X , XQuery , XPath ; Instruções são processadas nativamente, ao invés de serem convertidas para SQL; DB2 é o único SGBD que dá suporte ao XML Nativo.
  • 27.
    XML - ExemplosCREATE TABLE clientes( id_cliente INT PRIMARY KEY NOT NULL , nm_cliente VARCHAR( 100 ) NOT NULL , xml_contatos XML ); INSERT INTO clientes( id_cliente, nm_cliente, xml_contatos ) VALUES( 1, ‘Bruno’, ‘<endereco>Rua Sem fim, nº 666</endereco>’ );
  • 28.
    XML – Funçõese Exemplos SELECT nm_livro FROM livros WHERE XMLEXISTS( ‘$autores/autor[nome=“Bruno”]’ ); SELECT XMLQUERY( ‘$autores/autor’ ) FROM livros WHERE nm_livro = ‘Sistemas de Bancos de Dados’; SELECT nm_usuario, XMLQUERY( ‘for $x in $contatos/emails return <p>{$x}</p>’ ) AS emails FROM usuarios WHERE nm_usuario LIKE ‘Bruno%’; SELECT XMLELEMENT( NAME “id_usuario”, id ), XMLELEMENT( NAME “nm_usuario”, nome ) FROM usuarios;