A maioria dos fornecedores de serviços de suporte a hardware reconhece o impacto do processo de Gerenciamento de Configurações (conforme descrito pelo ITIL) na qualidade do serviço prestado, entretanto, quando se trata fornecimento de serviço de suporte a sistemas, a importância desse processo é um tanto quanto subestimada.
Gerenciamento de Configurações
O Gerenciamento de Configurações, em poucas palavras, consiste na identificação e controle de cada um dos itens individuais que compõem um determinado serviço, os chamados Itens de Configuração (ICs), e seus atributos. Num sistema de relatórios gerenciais, por exemplo, alguns itens de configuração poderiam ser:
- O servidor que suporta o banco de dados;
- O banco de dados;
- Cada uma das tabelas do banco de dados;
- Cada um dos processos que fornecem dados aos relatórios;
- Cada um dos relatórios.
Ter todos os itens de configuração identificados e armazenados em um Banco de Dados de Gerenciamento de Configurações (BDGC) é fundamental para a qualidade dos servidos prestados por uma empresa ou departamento de TI.
Implementação do BDGC
O banco de dados de gerenciamento de configurações, na área de serviços de suporte de sofware, deve ser planejado e implementado preferencialmente ainda durante o projeto de desenvolvimento do sistema.
Ao se implementar um BDGC, alguns critérios devem ser levados em consideração:
Escopo. Devem fazer parte do BDGC os componentes que forem fundamentais para a manutenção da disponibilidade do serviço – e apenas estes. Por exemplo, se um determinado serviço depender de uma linha de telefone para funcionar esta linha deverá fazer parte do BDGC. Agora, se esta mesma linha ficar muda e isso não influenciar a disponibilidade do serviço, ela não deve fazer parte do BDGC.
Granularidade. Diz respeito ao maior nível de detalhe ao qual devemos nos aprofundar ao identificar os itens de configuração. É aí que definimos se é necessário criar um item de configuração para cada relatório do sistema ou criamos apenas um item de configuração abrangendo todos os relatórios. Quando se trata de definir a granularidade, cada caso é um caso e o que é bom para um sistema pode não ser bom para outro. Entretanto, é bom ter em mente que a lista de ICs serve, acima de tudo, para atender a outros processos de gerenciamento como o Service Desk, o Gerenciamento de Mudanças ou o Gerenciamento de Capacidade e, por isso, são as necessidades destes que irão determinar o nível de granularidade necessário.
Dependência. As relações de dependência entre os ICs devem ser registradas no BDGC. Para o processo de Gerenciamento de Mudanças, por exemplo, é muito importante saber quais relatórios podem ser afetados por uma alteração em uma tabela.
Manutenção do BDGC
A manutenção de um BDGC voltado para suporte a aplicações é uma atividade que deverá ser bem coordenada entre a equipe de desenvolvimento, o pessoal de infra-estrutura, os DBAs, os responsáveis pelos processos de Gerenciamento de Mudanças, de Gerenciamento de Liberação, Gerenciamento de Configuração, e outros. Pode ser também interessante criar processos de revisão e auditoria periódicos. O objetivo é manter o BDGC sempre atualizado e confiável. As atividades envolvidas estão descritas no processo Gerenciamento de Configuração do ITIL e algumas serão desempenhadas pelo Gerenciamento de Liberação (Release Management).
Vantagens do Gerenciamento de Configurações
Provavelmente a essa altura você já percebeu alguns dos benefícios da utilização do Gerenciamento de Configuração no suporte de software, mas vamos citá-los novamente aqui e ainda acrescentar mais outros. Alguns desses benefícios serão poderão ser percebidos de forma mais acentuada quando o Gerenciamento de Configurações for utilizado em conjunto com outros processos ITIL.
• A definição do escopo realizada por ocasião da implementação do BDGC facilita os processos de implementação do contrato de SLA e posterior gerenciamento dos níveis de serviço.
• A lista de ICs pode ser utilizada pelo sistema de controle do Service Desk para registro dos chamados.
• O Service Desk pode ser habilitado para resolver problemas conhecidos cujas soluções podem ser associadas aos itens de IC do BDGC.
• O pessoal do Gerenciamento de Mudanças adquire maior segurança para executar as mudanças graças à análise de impacto que é possível graças ao controle de dependências do BDGC.
• O processo de Gerenciamento de Problemas poderá identificar com maior facilidade a causa-raiz de problemas recorrentes baseando-se em informações do BDGC.
• O processo de Gerenciamento de Liberações, que compreende todas as fases de liberação de novas versões de software utiliza intensamente as informações do BDGC.
• O Gerente do projeto pode ter uma noção clara do impacto de mudanças no projeto solicitadas pelos clientes antes de fornecer o cronograma e orçamento dos serviços.
Existem ainda muitos outros benefícios secundários para cada um dos pontos citados e que poderão ser observados em uma análise mais profunda de diversos aspectos do Gerenciamento de Serviços.
Seja qual for o tipo de aplicação que sua organização desenvolva, se você oferece suporte a essa aplicação, é importante que você saiba o Gerenciamento de Configurações pode ser utilizado como a base para a implementação de uma estrutura de serviços de qualidade e sucesso.
quarta-feira, 2 de maio de 2007
Outer Joins no Data Integrator
Implementando um outer join no Oracle
Outer joins são aquelas consultas baseadas em duas tabelas (digamos, A e B) em que o resultado apresenta todas as linhas da tabela A, mesmo que estas não possuam correspondência em B (+), que nesse caso, é expandida com nulos . Ex:
select departments.department_id, count(employees.employee_id)
from hr.departments departments, hr.employees employees
where departments.department_id = employees.department_id (+)
group by departments.department_id
O resultado dessa consulta é:
Observe, na imagem, que todos os departamentos da tabela departments foram exibidos mesmo quando não houve nenhum registro correspondente na tabela employees. Nesses casos a função count retornou o número 0, que foi exibido nas linhas correspondentes a esses departamentos.
Outro exemplo parecido:
select departments.department_id, count(employees.employee_id)
from hr.departments departments, hr.employees employees
where departments.department_id(+) = employees.department_id
group by departments.department_id
O resultado, desta vez, é:
No exemplo acima, havia um registro na tabela employees cujo departamento não existia na tabela departments. A query então retorna todos os registros de funcionários, inclusive aquele. Porém, não encontrando correspondência na tabela departments, retorna um null.
Implementando um outer join no Data Integrator
Para implementar o primeiro exemplo no Data Integrator, preencha a aba “Where” com o texto abaixo e configure a aba “Outer Join” conforme a figura a seguir:
where departments.department_id = employees.department_id
Em outras palavras, após definir uma query comum, preencha a aba “Outer Join” com o nome das duas tabelas, sendo que a tabela que teria o sinal (+) no Oracle deve ficar no campo “Inner Source”.
Considerações sobre performance:
Data Integrator Performance Optimization Manual, pagina 28:
Data Integrator implements joins as nested loop joins. The source with the
higher join rank or the one specified as an outer source becomes an outer loop.
If all the ranks are equal or not set (defaults to 0), then Data Integrator picks an
inner and outer source at random. During job execution, Data Integrator reads
the source in the outer loop one time; and reads the source in the inner loop for
each row in the outer loop. Performance improves when fewer rows are read.
Wikipedia (http://en.wikipedia.org/wiki/Join_(SQL)):
Nested loops
Main article: Nested loop join
This is the simplest join algorithm. For each tuple in the outer join relation, the entire inner join relation is scanned, and any tuples that match the join condition are added to the result set. Naturally, this algorithm performs poorly if either the inner or outer join relation is very large. The performance though can be enhanced if the inner relation has an index on joining column.
A refinement to this technique is called "block nested loops" (BNL): for every block in the outer relation, the entire inner relation is scanned. For each match between the current inner tuple and one of the tuples in the current block of the outer relation, a tuple is added to the join result set. This variant means that more computation is done for each tuple of the inner relation, but far fewer scans of the inner relation are required.
Jeff
Outer joins são aquelas consultas baseadas em duas tabelas (digamos, A e B) em que o resultado apresenta todas as linhas da tabela A, mesmo que estas não possuam correspondência em B (+), que nesse caso, é expandida com nulos . Ex:
select departments.department_id, count(employees.employee_id)
from hr.departments departments, hr.employees employees
where departments.department_id = employees.department_id (+)
group by departments.department_id
O resultado dessa consulta é:
Observe, na imagem, que todos os departamentos da tabela departments foram exibidos mesmo quando não houve nenhum registro correspondente na tabela employees. Nesses casos a função count retornou o número 0, que foi exibido nas linhas correspondentes a esses departamentos.
Outro exemplo parecido:
select departments.department_id, count(employees.employee_id)
from hr.departments departments, hr.employees employees
where departments.department_id(+) = employees.department_id
group by departments.department_id
O resultado, desta vez, é:
No exemplo acima, havia um registro na tabela employees cujo departamento não existia na tabela departments. A query então retorna todos os registros de funcionários, inclusive aquele. Porém, não encontrando correspondência na tabela departments, retorna um null.
Implementando um outer join no Data Integrator
Para implementar o primeiro exemplo no Data Integrator, preencha a aba “Where” com o texto abaixo e configure a aba “Outer Join” conforme a figura a seguir:
where departments.department_id = employees.department_id
Em outras palavras, após definir uma query comum, preencha a aba “Outer Join” com o nome das duas tabelas, sendo que a tabela que teria o sinal (+) no Oracle deve ficar no campo “Inner Source”.
Considerações sobre performance:
Data Integrator Performance Optimization Manual, pagina 28:
Data Integrator implements joins as nested loop joins. The source with the
higher join rank or the one specified as an outer source becomes an outer loop.
If all the ranks are equal or not set (defaults to 0), then Data Integrator picks an
inner and outer source at random. During job execution, Data Integrator reads
the source in the outer loop one time; and reads the source in the inner loop for
each row in the outer loop. Performance improves when fewer rows are read.
Wikipedia (http://en.wikipedia.org/wiki/Join_(SQL)):
Nested loops
Main article: Nested loop join
This is the simplest join algorithm. For each tuple in the outer join relation, the entire inner join relation is scanned, and any tuples that match the join condition are added to the result set. Naturally, this algorithm performs poorly if either the inner or outer join relation is very large. The performance though can be enhanced if the inner relation has an index on joining column.
A refinement to this technique is called "block nested loops" (BNL): for every block in the outer relation, the entire inner relation is scanned. For each match between the current inner tuple and one of the tuples in the current block of the outer relation, a tuple is added to the join result set. This variant means that more computation is done for each tuple of the inner relation, but far fewer scans of the inner relation are required.
Jeff
Assinar:
Postagens (Atom)