Portabilidade SQL Server Por que Portar ranking de

Portabilidade SQL Server

Por que Portar? Ø ranking de bancos com melhor performance e sempre ficou muito bem colocado no quesito custo/benefício (www. tpc. org) Ø solução o que faz com que a Datasul acompanhe esta tendência Ø Nossos concorrentes já oferecem esta portabilidade

Informações de Mercado que o SQL Server ocupa em nível nacional Fonte: Microsoft

Informações de Mercado que o SQL Server ocupa sob plataforma NT Fonte: Microsoft

Performance SQL Server 2000 07/03/02

Custo/Performance SQL Server 2000 07/03/02

Projeto Envolvidos Anderson Alves (Gerente do Projeto) Karen de Freitas Machado (Consultor Tech Solutions) Início do Projeto - Jan/2001 Previsão Término - Mar/2002 Divulgação Palestras para todo o Network Treinamentos em laboratório Relatório Técnico do projeto na Intranet

Projeto Produtos Convertidos Ø Datasul-HR Ø Versão 2. 06 Ø 5 bancos convertidos Ø Datasul-EMS 2 Ø Versão 2. 04 Ø 24 bancos convertidos Ø Datasul-EMS 5 Ø Versão 5. 05 Ø 5 bancos convertidos

Arquitetura Dataserver Progress Application Progress Enterprise Data. Server for SQL Server ODBC Driver Manager ODBC Driver DATA Source Manager SQL Server

Soluções Ø Campo Raw do Progress não possui equivalente no SQL Solução: Converter os campos Raw para Character e atualizar da mesma forma que já é para o Oracle Ø Campo Character não pode ser atualizado ou comparado com valor maior que o formato definido para o campo Solução: Rodar um filtro que substitui valores iniciais de variáveis por “zz”. Além disto, equipe DDK está analisando a possibilidade de controlar os valores iniciais conforme formato do campo Ø O SQL Server não trabalha com Share-Lock Solução: No acesso/leitura registros deixar explícito a utilização de EXCLUSIVE-LOCK ou NO-LOCK

Soluções Ø Estouro Segmento de Memória Solução: Programas com este problema é necessário que se divida o código em mais programas Ø Limitação do valor para campos do tipo Date. O SQL só aceita gravar e comparar valores para data que estejam na faixa de 01/01/1753 a 31/12/9999 Solução: Alteração dos initial dos campos no dicionário de 01/01/0001 para 01/01/1800; Inclusão de um Field Validation para todos os campos do tipo Date; Filtro que acrescenta na trigger de write das tabelas uma verificação para cada campo do tipo Date que for atualizado (*)

Soluções (*) Uso de triggers para resolver o problema da data O uso de triggers não é considerada pela equipe EMS 5. 05, a melhor solução, pois atualmente existem muitos triggers que foram desativados para evitar problemas de performance. Caso os triggers fossem ativados novamente, consequentemente teríamos um problema muito grande de performance. Com isso, para o produto EMS 5. 05 fica inviável a utilização de tratamentos dentro dos triggers para a troca de datas inferiores a 01/01/1800. Já existe uma outra forma de contornar o problema sem a utilização de triggers e estamos analisando a possibilidade de adotar esta mesma solução para os demais produtos.

Soluções Ø Perda de performance na configuração para acesso remoto ao ambiente SQL. Na forma escolhida, os clients se conectam a um broker que acessa o dataserver e que faz a conexão com o driver ODBC. Isto ocasiona uma grande perda de performance, pois são vários clients conectando o mesmo broker Solução: Configurar driver ODBC no client (cada máquina que vai acessar o banco no servidor). Desta forma, obtemos ganhos em performance Ø Na conexão com broker, a vantagem é que a manutenção é centralizada, configura-se o ODBC apenas no servidor. A desvantagem é que as conexões sobrecarregam o broker o que acarreta em grande perda de performance

Soluções Ø Na conexão sem broker, a vantagem é que obtém-se ganhos em performance, porém a manutenção é difícil pois são várias máquinas para configurar ODBC, e além disto, cada client precisa ter uma licença do dataserver; Ø O comportamento de alguns programas era diferente quando executado contra banco SQL Server. As includes incorporadas ao fonte dos programas tinham códigos específicos para Progress e Oracle sem testar se o tipo de banco era SQL Server Solução: A equipe DDK alterou os includes necessários para testar se o tipo de banco de dados era igual a SQL Server

Dificuldades Ø A carga dos dados básicos foi feita através do programa de inicialização do produto. Os demais dados foram através de dump-load. Vários registros apresentaram erro durante o processo de load; Ø Os acertos necessários para resolver o problema da data inicialmente tornaram o projeto inviável pelo número de horas de retrabalho. Abrimos um chamado para a Progress nos fornecer uma solução; Ø Demora na resolução do chamado referente ao problema da data (aproximadamente 3 meses);

Dificuldades Ø A solução dada pela Progress atendeu parcialmente o problema; Ø Por causa deste problema, as datas estipuladas no cronograma tornaram-se comprometidas, o que atrasou o início dos testes; Ø Testes foram realizados em períodos descontínuos e sem foco;