DB2 Express-C

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).

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.

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 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

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 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 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.

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

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a DB2 Express-C (20)

Mais de Bruno Dadalt Zambiazi (7)

Último (19)

DB2 Express-C