Manual de Performance

EMPRESA BRASILEIRA DE CORREIOS E TELÉGRAFOS

METODOLOGIA PARA

AVALIAÇÃO DO DESEMPENHO

DE APLICATIVOS

Herbert Lopes da Silva (Consultor CTIS) Página 1/25 22/04/2023


1 - INTRODUÇÃO:

Desde o início dos anos 90 já se vislumbrava a tendência para a arquitetura Cliente-Servidor (Client-Server), visto o aumento progressivo da velocidade e capacidade de armazenamento dos até então chamados "Micro-Computadores". Ainda que as redes pioneiras pecassem por uma performance baixíssima, mesmo para os padrões da época, se comunicando em grande parte por portas seriais com taxa de 9600 bauds, esse era o caminho, contrariamente à antiga arquitetura (main-frames e terminais "burros"). Não cabe naturalmente maior discussão acerca da evolução dos sistemas de grande porte, primeiramente pelo fato do parque de equipamentos dos Correios ser quase em sua totalidade composto de computadores pessoais (Personal Computers) e também pelo fato das tecnologias envolvendo computadores de pequeno porte trabalharem cada vez mais no sentido de ultrapassarem seus "irmãos maiores". Continuando, vieram as primeiras redes de baixa velocidade com tecnologia de cabo coaxial, as quais evoluíram gradualmente para redes de alta performance, até chegarmos na era da fibra ótica e dos satélites de comunicação, o que nos proporciona desempenhos admiráveis, inacreditáveis para quem vivesse há apenas 15 anos atrás.Vieram (atreladas aos conceitos de redes locais e remotas de alta performance) um sem número de tecnologias visando a otimização dos tempos de resposta e da confiabilidade acerca da atualidade dos dados – e cada vez mais se percebeu a importância dos sistemas funcionarem on-line, e isso já não representava os custos exorbitantes do passado. Foi assim que assistimos ao florescer de paradigmas como:

- Crescente quantidade de executivos de nível médio tomando decisões importantes.- Bancos de Dados cada vez mais rápidos, para atualização e disponibilização de seus dados.- Aplicativos estruturados em componentes distribuídos- Distribuição de dados entre o servidor e as máquinas clientes.- Arquitetura de duas e três camadas – o servidor de aplicação.- Bancos de dados imensos funcionando na Web.- Uma "corrida armamentista" entre as grandes companhias fabricantes de software, a fim de colocar à

disposição dos usuários pacotes cada vez mais inteligentes e de fácil operação (user-friendly).- Interfaces visuais cada vez melhor elaboradas, de forma a permitir seu uso para praticamente qualquer

nível de usuário.- Estruturas de hardware de alta capacidade, as quais permitissem milhares e mesmo milhões de

acessos simultâneos, fossem eles locais ou remotos, a custos incrivelmente menores que seus antecessores.

- Reformulação das ferramentas de desenvolvimento de aplicativos e bancos de dados, bem como as técnicas empregadas nos mesmos – as ferramentas visuais.

- Os "cases" eficientes, os quais não somente apoiavam o desenvolvimento como cuidavam de forma quase intuitiva da documentação dos sistemas.

- Os clientes WEB, transformando o que seria no início um visualizador HTML em interfaces poderosas e confiáveis para manipulação e utilização de dados – o ASP, PHP, Cold Fusion, VBScript, JavaScript e outras estruturas de codificação.

- A Orientação a Objetos, da qual sempre se falara desde os anos 70, agora emergindo com literatura, técnicas, cursos, treinamentos e respectivas ferramentas de apoio ao desenvolvimento, não só no cenário acadêmico, mas também no universo profissional.

Com tantas tecnologias revolucionárias, como não poderia deixar de ser, muita coisa foi estruturada de forma desordenada, desprovida de critério, quando não até ferindo leis universais da Engenharia de Sistemas. O Departamento de Produção (subordinado à Diretoria de Tecnologia da ECT) achou por bem, em face do exposto acima, iniciar a construção de uma metodologia para avaliação de desempenho em todos os níveis conhecidos, seja de software, hardware ou middleware. Entendemos que, ainda que iniciantes em tais técnicas, é necessário o fomento do conhecimento a respeito, e é o que o presente trabalho irá buscar fazer, mais à guisa de se iniciar uma cultura de avaliação sistemática de desempenho – contrariamente aos "achismos" reinantes na maioria dos nichos de desenvolvimento. Em resumo, pretendemos estabelecer critérios para julgar a eficiência ou ineficiência dos tempos de resposta de uma aplicação, o que nos permita saber onde são necessárias melhorias e modificações. O consagrado costume de simplesmente pedir um servidor mais potente nos parece antiquado, bem como os ciúmes dos desenvolvedores e sua resistência em exibir o código construído pelos mesmos. Em vários casos, até a simples obtenção de um modelo de Herbert Lopes da Silva (Consultor CTIS) Página 2/25 22/04/2023


dados demandou esforços e burocracias incalculáveis, com um tráfego de comunicações internas muitas vezes maior que a documentação demandada em si. É esta forma de pensar que tentamos erradicar, por acreditarmos que nenhum produto é tão bom que não possa ser melhorado, e ao mesmo tempo encorajarmos uma autocrítica mais freqüente nas mentes de nossos técnicos, ao invés de simplesmente um dar-de-ombros culpando a rede, ou os servidores, ou as máquinas clientes, ou a aplicação, ou a ferramenta de desenvolvimento, ou o banco de dados, enfim... "os outros".

Houve uma idéia inicial de realizá-lo sem colocar em discussão quaisquer ferramentas de apoio, mas foi abandonada na medida que poderíamos terminar o trabalho com um punhado de idéias no papel e nenhuma ação pragmática. Destarte, as aqui indicadas foram as que encontramos para avaliação, estando certamente abertos a sugestões e discussões, bem como o apoio de todos os colegas que compõem um dos melhores quadros profissionais de Informática do país, quadro esse que certamente contribuiu para que a ECT fosse a grande empresa que é, não só no cenário nacional como no estrangeiro.

Brasília DF, em 24 de abril de 2002.



CAPÍTULO I - ARQUITETURAS CLIENTE - SERVIDOR - Conceitos e Modelos.

Tem sido propostos um sem-número de modelos, acerca da arquitetura cliente-servidor. Na impossibilidade de abordarmos todos, será feita menção dos mais conhecidos hoje em dia.

Histórico:

É razoável admitirmos que os primeiros ensaios documentados desta estrutura foram dados pela Sybase, fundada em 1984 e tendo como um dos principais objetivos lançar no mercado unicamente produtos para arquitetura client-server. Ao final dos anos 80, seu primeiro produto foi lançado para o grande segmento de mercado low-end em parceria com a Microsoft e consistia de um servidor de dados OS/2 acompanhado de uma ferramenta front-end básica chamada dBase IV, da Ashton Tate. O dBase IV não se mostrou uma ferramenta adequada desde o princípio... e William Henry Gates IV provavelmente pensava já em ter sua ferramenta exclusiva... no frigir dos ovos, houve uma série de desencontros comerciais entre a Sybase, Microsoft e a própria IBM (naquele momento sócia da Microsoft para o OS/2), o que terminou na conhecida ruptura, formalizada em 1991. A situação era totalmente diferente em 1994, quando os principais fabricantes tradicionais (Informix, Oracle, Sybase) tinham lançado no mercado poderosos servidores de dados e a eles se agregava a IBM com seu DB2 prometendo alcançar todos os sistemas operacionais de então (Além do seu clássico MVS e VM, agora com AIX, OS/2, Windows NT, HP Unix, Sun's Unix, Siemens Unix, etc...) e quase como emergente a Microsoft, que logo após formalizar a separação com a Sybase partiu para seu próprio Microsoft SQL-Server para Windows NT.Já existia uma diversidade de linguagens front-end, como Delphi, FoxPro, Powerbuilder, SQL-Windows, Visual Basic, etc...) E já então se dizia que o Visual Basic (apesar de seus poucos méritos como linguagem) era o favorito para dominar o mercado, o que aconteceu de fato até o presente momento (Abril de 2002). Com o golpe estratégico de Bill Gates contratando mais da metade do time da Borland responsável pelo Delphi, e agregando-os ao VB.Net (e para tanto pagando todas as multas contratuais dos técnicos à Borland), podemos ainda apostar no VB por alguns anos como ferramenta mais disseminada.Atualmente, os servidores de dados têm-se mostrado sólidos, rápidos e eficientes e seus otimizadores internos deram um verdadeiro show de tecnologia e competência, o que contribuiu na alavancagem de uma significativa quantidade de empresas para aplicações Cliente-Servidor. Estas empresas têm a cada dia comprovado o aspecto de que escolher um servidor pode ser uma tarefa árdua e complexa; para aplicações de pequeno e médio porte, todos eles se mostraram muito bons. O que então irá separar os bons dos “state of art” serão as ocasiões / aplicações que exijam altíssimos regimes transacionais, seja por grande número de conexões simultâneas ou pelo tráfego pesado de dados como também pela complexidade de queries extensas. Os fabricantes têm agregado às mesmas características novas, como paralelismo, head-ahead e outras, o que praticamente tem disponibilizado ao comprador uma versão nova a cada ano, ou até menos tempo, ainda que no geral as tecnologias acabem se mostrando sensivelmente equivalentes. E é por isso que podemos notar uma tendência menos técnica que subjetiva quando da escolha de um destes fabricantes - é mais considerada a confiança que nos desperta o fabricante, seu compromisso com o produto, sua tendência a se manter continuamente atualizado, sua situação econômico - financeira, a eficiência de seu suporte local, e até finalmente o preço. Não são (quase nunca, ao menos) feitas avaliações sérias com versões beta de qualquer de tais "candidatos a uma vaga em nosso servidor", muito menos algum tipo de medição comparativa. A quase totalidade das empresas sequer possui um time de profissionais ali colocados para este tipo de pesquisa, visto ser bem mais cômodo e barato acreditarmos nos benchmarks das revistas especializadas. Na ECT, por exemplo, adotamos o critério de elegermos os servidores Oracle quando estamos diante de uma aplicação mais pesada (e a própria definição de "pesada" é controversa), MS SQL-Server quando estivermos diante de algo pequeno ou médio e MS Access se nosso produto for simples, leve e pouco acessado. É fato que a própria Microsoft afirmou nas suas palestras de lançamento do SQL-Server 2000 que ela mesma recomendava o uso do Oracle quando estivéssemos lidando com tabelas contendo mais de um milhão de registros; mas isso não pode ser considerado zelo com o usuário, mas apenas estratégia de marketing (área na qual ela se revelou extremamente habilidosa) para conquistar todo o nicho de bancos de dados de muito pequeno, pequeno e médio porte - certamente a grande maioria dos bancos hoje existentes! Portanto, não é razoável meramente acreditarmos nela e seguirmos suas sugestões.

Hoje em dia, finalmente, a arquitetura Cliente - Servidor é considerada como fundamental na abordagem das necessidades das empresas. O processamento distribuído se reconhece atualmente como o novo paradigma para os sistemas de informação, em contraste com seus predecessores independentes.



Definição:

Definiremos arquitetura Client-Server como um modelo para desenvolvimento de sistemas de informação em que as transações se dividem em elementos independentes que cooperam entre si para troca de informações, serviços ou recursos. Em tal arquitetura, o computador de cada um dos usuários, chamada cliente inicia um processo de diálogo: produz uma demanda de informação ou solicita recursos. Ao Computador que irá responder a essa demanda do computador cliente chamamos servidor. Sob este modelo, cada usuário tem liberdade para obter a informação que deseje em um dado momento, proveniente de uma ou mais fontes locais ou remotas e de processá-la segundo lhe convenha. Servidores distintos também podem intercambiar estas informações conforme a necessidade, dentro de tal arquitetura. Os clientes e servidores podem estar conectados a uma rede local ou fechada e extensa como em uma empresa como a nossa, ou à rede mundial como a Internet. Cliente - Servidor é o modelo de interação mais comum entre as aplicações em execução numa rede. Na Internet, é correto afirmar que todas as aplicações de alto-nível foram modeladas com esta visão, mesmo que este tal arquitetônico não faça parte de seus conceitos básicos (como os protocolos IP, TCP e UDP).

Características mais importantes:

O Servidor apresenta a todos os seus clientes uma interface única e bem definida. O Cliente não precisa conhecer a lógica do Servidor, apenas sua interface externa. O Cliente não depende da localização física do Servidor, nem do tipo de equipamento do mesmo,

tampouco de seu sistema operacional. Mudanças nos Servidores acarretam na necessidade de pouca ou nenhuma mudança nos Clientes.

Peculiaridades da Arquitetura Cliente - Servidor diferentes de outras formas de software distribuído:

Serviços: O servidor é um provedor de serviços, ao passo que o cliente é um consumidor dos mesmos serviços.

Recursos Compartilhados: Um servidor pode atender a muitos clientes simultaneamente, e gerenciar o acesso destes aos mesmos recursos.

Protocolos Assimétricos: A relação cliente para servidor é de muitos para um; os clientes solicitam serviços, enquanto os servidores esperam suas solicitações passivamente.

Ambientes mesclados com eficiência: O software é independente do hardware ou das plataformas de software do sistema operacional; podem-se ter plataformas iguais ou diferentes no cliente e no servidor.

Troca de informações baseadas em mensagens: Os sistemas interagem através de um mecanismo de transmissão de mensagens, as quais se encarregam da entrega das solicitações e respostas.

Encapsulamento de serviços: Os servidores podem ser substituídos sem afetar os clientes desde que a interface para receber solicitações e oferecer serviços permaneça imutável.

Escalonamento fácil: Os sistemas Cliente - Servidor podem ser escalonados vertical e horizontalmente, ou seja, podem migrar para servidores maiores ou múltiplos servidores da mesma forma que podem ter corte ou acréscimo de clientes; ambas as ações ocorrem sem que haja grande diferença na performance do sistema.

Integridade: Tanto o código quanto os dados do servidor se conservam de maneira centralizada, o que vale dizer com menor custo de manutenção e proteção adequada à integridade dos dados compartilhados. Além disso, os clientes mantêm sua individualidade e independência.

Em suma, a arquitetura Cliente - Servidor é uma infra-estrutura versátil, modular e baseada em mensagens, visando sempre melhorar a portabilidade, interoperabilidade e escalabilidade do processamento, ao tempo em que elimina um grande problema devido à variedade de plataformas, hardware e software do sistema.



CAPÍTULO II - O CLIENTE - Características e definições

O cliente é a entidade por meio da qual um usuário solicita um serviço, realiza uma petição ou demanda o uso de recursos, e é o responsável pela apresentação dos dados e/ou informações, em ambiente gráfico. É conhecido simplisticamente como a parte do sistema que o usuário utiliza, e, portanto, o cliente é primariamente concebido para pessoas não-profissionais na área de informática, ao menos em princípio.Diferentemente dos predecessores da estrutura cliente - servidor, o cliente pode abrigar em suas instalações parte dos dados de que o sistema faça uso, técnica conhecida para que se diminua o tráfego na rede, desde que tais dados não sejam atualizáveis continuamente. Exemplo: Se fôssemos listar os estados brasileiros, poderíamos colocá-los num banco de dados local (no próprio cliente), visto ser bastante rara alguma atualização neste tipo de informação. Já as condições climáticas de uma determinada região jamais poderiam ficar hospedadas numa estrutura cliente, por serem passivas de alterações até mesmo de hora em hora ou menos.

O Cliente se comunica com processos auxiliares, os quais se encarregam de iniciar e manter a conexão com o servidor, enviar pedidos e receber respostas, administrar falhas, realizar tarefas de sincronização (o que vem a ser a segurança de que os dados estejam sempre atualizados de forma consolidada), e de segurança. Ele pode interagir com um ou mais servidores.

A este conjunto de tarefas chamamos de "front-end", a qual realiza atividades do tipo:

a) Manipulação da interface com o usuáriob) Captura (mediante digitação, cliques de mouse, scaneamento, etc.) e validação dos dados de entrada.c) Geração de consultas e relatórios acerca do conteúdo do banco de dados.

Basicamente, portanto, quando queremos avaliar a performance de um ambiente cliente, devemos levar em consideração tudo que faça parte do mesmo, a saber: O Hardware do Computador Cliente . Em uma estação típica do tipo Intel (ou um de seus concorrentes

Ciryx, AMD e outros) temos diversos fatores responsáveis pela maior ou menor agilidade da máquina, desde a quantidade de memória DRAM, como o cache (interno e externo ao processador), velocidade de acesso do disco rígido, tecnologia de DMA, SCSI, IDE e mesmo das placas aceleradoras de vídeo. O Clock do processador central, se temos um ou mais de um (Dual-Pentium, por exemplo), tipo de barramento (32, 64 ou mais bits), tipo de RAM-BUS (66, 100, 133 ou mais MHz) e até mesmo a qualidade do cartão de rede padrão Ethernet, Token-Ring ou assemelhada... tudo isso pode influenciar tremendamente (várias vezes mais ou menos, em alguns casos) a performance da estação. E realmente, melhorando estas características certamente melhoraremos o tempo de resposta da estação e por conseguinte a satisfação do usuário em particular e do time de pessoas que compõe o sistema como um todo. Quantas vezes ouvimos uma equipe inteira murmurando que "o sistema até tinha sido bem construído e atendia às necessidades propostas, mas era muito lento".

O Software de Base do Computador Cliente. Primeiramente enfocaríamos o sistema operacional utilizado. Sabemos hoje que a Microsoft e todas as suas versões de Windows não seriam talvez a melhor plataforma operacional, mas certamente tinham a melhor estrutura de marketing. Devido à sua estrutura gráfica tremendamente eivada de recursos, fomos descobrindo conforme o tempo passava, que precisávamos de máquinas cada vez mais velozes e otimizadas apenas para manter a performance original... e assim foi nas sucessivas versões a partir do Windows 3.11 for Workgroups (primeira versão com rede razoavelmente confiável da Microsoft) até o Windows XP dos nossos dias. Ficou provado (e não quero aqui realizar uma campanha anti-Microsoft) que até o Windows 2000 por exemplo, temos um processo de "entupimento" do registry da estação, o qual vai tornando a execução das aplicações mais lenta a cada dia. Se instalamos uma ferramenta pesada e depois a desinstalamos, verificamos consternados que ela saiu de funcionamento, mas não saiu do computador. Vestígios sempre ficam para trás, e isso vai depreciando os tempos de resposta na máquina. A boa notícia é que se apagarmos tudo que pertencer ao Windows (ou formatarmos o disco rígido) e reinstalarmos tudo de novo, a máquina volta a ter o desempenho original. E a má, naturalmente é que isso pode demandar até 3 dias de trabalho caso haja muita coisa no disco. Quem dá suporte em ambiente Windows já terá se acostumado ao descontentamento dos usuários quando à solicitação de uma melhora no desempenho da máquina recebem um PC "limpinho". Apesar dos Registry Cleaners que várias software houses lançaram (incluindo um da própria Microsoft), o problema sempre persistiu.



O Software dos Aplicativos do Computador Cliente. Naturalmente é sempre uma saída cômoda culparmos William Henry Gates por todas as nossas mazelas de lentidão. Muitas aplicações, em sua parte cliente, foram muito mal escritas, com erros de implementação grosseiros até. Outras, jamais sofreram uma revisão e limpeza após a versão de produção ter sido escrita (em alguns casos, descobrimos que 70% das variáveis declaradas simplesmente não faziam mais coisa alguma no sistema, porém permaneciam alegremente definidas, ocupando memória e recursos de máquina. Arrays dimensionados com muito mais instâncias do que são utilizadas, funções fora de uso de há muito, mas ainda ocupando espaço nos formulários, total ausência de programação modular e estruturada, quanto mais escrita orientada a componentes, a mesma função com nomes totalmente diferentes, dezenas de recordsets abertos ao mesmo tempo sem qualquer utilização, loops desenhados de forma a rodar até o final, mesmo que se buscasse um resultado já obtido na 3 ª iteração, enfim... um sem-número de falhas básicas. Acresce que quando da construção de queries, muitos programadores optam pelo cômodo SELECT * , ao invés de escrever cada atributo que deverá ser devolvido pelo servidor, esquecendo-se que na média o tempo gasto para processar dois atributos é pouca coisa menor que o dobro do tempo para se processar um atributo só. Muitos não acompanham a evolução das ferramentas de desenvolvimento, por mera preguiça de se reciclar, e assim permanecem usando bibliotecas ultrapassadas de acesso a dados, mesmo que tenham ouvido comentários que as mais recentes chegam a triplicar o tempo de resposta em um banco de dados. Outros usam objetos fáceis de manear na programação, mesmo que os tais redundem em várias vezes mais tempo no acesso a dados (O Data Control do Visual Basic, por exemplo). Embora quase todos que programam tenham passado algum tempo em cursos de programação, recusam-se teimosamente a realizar o "chinês" nos algoritmos. Alguns (por alguma razão desconhecida) consideram o código sua propriedade particular, e chegam a se tornar agressivos quando alguém pede vistas nele. Muitos outros, quando percebem a aproximação do pessoal da produção, vêem-nos mais como "fiscais", "depreciadores" e "críticos" do que como auxiliadores e parceiros, interessados tão somente no sucesso do sistema; razão pela qual fazem todo o possível para sonegar detalhes acerca do código, enviam modelos defasados, nunca tem tempo para comparecer às reuniões, enfim... tratam os da produção como verdadeiros inimigos ! Realmente, é sempre mais cômodo culpar a rede, a máquina servidora, o engine do banco de dados, o DCOM do Windows, o tráfego na rede, e até (como ouvimos certa vez) a qualidade da linha telefônica, que não permitia conexões acima de 42 KBps. Tudo isso precisa ser reavaliado pelos desenvolvedores, antes que se pronuncie a famosa frase "Precisamos de um servidor mais potente !". A estrutura de processamento de queries dos servidores Oracle (ao menos da versão 8.x em diante) faz distinção entre duas queries de sintaxe idêntica, se as mesmas tiverem diferenças entre maiúsculas ou minúsculas ou simplesmente pela ordem em que listemos os atributos requeridos; destarte, a query "SELECT Nome_Completo, CPF" é vista pelo servidor Oracle como algo diferente de "select Nome_Completo, CPF" e também de "SELECT nome_completo, cpf". Pela falta de uma orientação e/ou padronização, ou simplesmente por não envolverem o DBA nos trabalhos de definição de projeto, constantemente vemos dezenas de instâncias de uma query única, o que sobrecarrega o servidor tremendamente e degrada sua performance.

Distribua bem seus dados. Em quase nenhuma das empresas com as quais tivemos contato vimos um modelo sério da distribuição de dados, do fluxo de acessos simultâneos, do volume de bytes que iria trafegar e certamente, muito menos, uma normatização dos conceitos e variáveis influentes no desempenho dos sistemas.

Os cuidados com a construção de dispositivos que mantenham o banco de dados otimizado. É fato que os servidores de dados atuais possuem mecanismos cada vez mais inteligentes para tratar tabelas muito volumosas. E é fato também que existem servidores tão velozes que poderíamos armazenar em um deles todos os CPFs do povo brasileiro sem grande problemas; isto porém não justifica o descaso de muitos profissionais em manter dados antigos e já desnecessários nas bases em produção. Um determinado sistema do Departamento Financeiro de uma empresa guardava no mesmo banco toda a movimentação dos últimos 14 anos, embora o analista responsável tenha admitido que só trabalhavam com os dados do exercício corrente - "deixamos esse controle do arquivo morto para o final do projeto". No caso em pauta, o sistema estava em produção havia nada menos que seis anos, e suas tabelas começavam a querer atingir a casa de 1 milhão de lançamentos.

Estes são apenas os problemas mais correntes. Em um segundo trabalho sobre esse tema, aposto que poderemos apresentar mais um punhado deles; achamos mesmo assim mais importante começarmos de algum ponto do que construirmos um tratado tentando esgotar o assunto.



CAPÍTULO III - O SERVIDOR - Características e definições

O Servidor é a entidade que oferece serviços e devolve resultados: executa o processamento de dados, aplicações e manejo da informação ou recursos. No servidor se realiza o conjunto de tarefas às quais chamamos back end, o qual vem a ser a parte do sistema destinada a receber as requisições do cliente, e é onde os processos são executados.Em alguns casos, existem processos auxiliares que se encarregam de receber as solicitações do cliente, verificar a proteção, ativar um processo servidor para satisfazer o pedido, receber sua resposta e enviá-la ao cliente. Ademais, deve manejar os controles de acesso (segurança), a recuperação diante de falhas e outros aspectos afins como backups, replicações, mensagens a operadores, processos batch, etc. Pelas razões anteriores, a plataforma computacional associada aos servidores é mais poderosa que a dos clientes, via de regra PCs potentes, estações de trabalho, minicomputadores e mesmo sistemas de grande porte (mainframes).Os servidores realizam as seguintes funções: Controle de acessos concorrentes a bancos de dados compartilhados. Gerenciamento de periféricos compartilhados. Links de comunicação com outras redes locais ou remotas. Atender às solicitações de qualquer cliente para tanto autorizado, uma vez que o mesmo tenha sido

reconhecido.

No servidor, permanecem as aplicações que devem ser compartilhadas entre diversos usuários. Embora haja exceções, normalmente os clientes e o servidor estão em máquinas distintas, e não necessariamente da mesma família de hardware.

Os principais tipos de servidores são:

a) Servidor de Arquivos: O cliente envia solicitações de registros de arquivos ao servidor; este é um serviço simples de dados compartilhados por meio da rede. São úteis para armazenas arquivos (documentos, imagens, planejamentos, etc.) e aplicações de escritório (processadores de texto, planilhas de cálculo...). Ele não pode ser considerado um servidor de banco de dados, porque um Banco de Dados é, antes de mais nada, uma coleção logicamente coerente de dados com determinada significação intrínseca. Em outras palavras um arquivo contendo uma série de dados de um cliente, um arquivo com dados aleatoriamente gerados e dois arquivos padrão dbf (xBase) com relação definida entre ambos, não pode ser considerada uma Base de Dados Real, estando portanto na categoria de servidor de arquivos.

b) Servidor de Bases de Dados (SGBD)O cliente envia solicitações de SQL, na qualidade de mensagens (uma mensagem por instrução) e o servidor faz uso de sua própria capacidade de processamento para encontrar os dados solicitados e devolvê-los por meio da rede (não enviando todos os registros). Desta forma, podemos realizar consultas específicas e obter resultados flexíveis.

c) Servidor de Transações (Transactions Server)O cliente ativa procedimentos remotos que residem no servidor com um mecanismo de bases de dados, em SQL, ou seja, o intercâmbio de informações na rede consiste de uma só mensagem solicitação / resposta, a qual executa um grupo de instruções SQL (chamadas transações) no servidor. Ao ser criada a aplicação Cliente – Servidor, gera-se tanto código para o cliente quanto para o servidor. E estas aplicações chamamos Aplicação com Processamento de Transações em Linha (OLTP OnLine Transactions Processing). Para a construção de Data Warehouses precisamos de outra arquitetura (conhecida como Modelo Dimensional) mas não abordaremos tais conceitos no presente trabalho, por representarem uma tendência pouquíssimo empregada nas empresas convencionais e por envolver técnicas sofisticadas e específicas na construção e manuseio de Dados (Consultas AdHoc, Aplicações com desenho flexível, redundância de dados, etc).



Há seis regras práticas para que diferenciemos um genuíno Gerenciador de Bases de Dados (SGBD) de um Servidor de Arquivos, a saber:

Regra 1: Auto-Contenção- Um SGBD não contém apenas os dados em si, mas armazena completamente toda a descrição dos dados, seus relacionamentos e formas de acesso. Normalmente esta regra é chamada de Meta-Base de Dados. Em um GA, em algum momento ao menos, os programas aplicativos declaram estruturas (algo que ocorre tipicamente em C, COBOL e BASIC), ou geram os relacionamentos entre os arquivos (típicos do ambiente xBase). Por exemplo, quando você é obrigado a definir a forma do registro em seu programa, você não está lidando com um SGBD.

Regra 2: Independência dos Dados- Quando as aplicações estiverem realmente imunes a mudanças na estrutura de armazenamento ou na estratégia de acesso aos dados, podemos dizer que esta regra foi atingida. Portanto, nenhuma definição dos dados deverá estar contida nos programas da aplicação. Quando você resolve criar uma nova forma de acesso, um novo índice, se precisar alterar o código de seu aplicativo, você não está lidando com um SGBD.

Regra 3: Abstração dos Dados- Em um SGBD real é fornecida ao usuário somente uma representação conceitual dos dados, o que não inclui maiores detalhes sobre sua forma de armazenamento real. O chamado Modelo de Dados é um tipo de abstração utilizada para fornecer esta representação conceitual. Neste modelo, um esquema das tabelas, seus relacionamentos e suas chaves de acesso é exibido ao usuário, porém nada é afirmado sobre a criação dos índices, ou como serão mantidos, ou qual a relação existente entre as tabelas que deverá ser mantida íntegra. Assim se você desejar inserir um pedido em um cliente inexistente e esta entrada não for automaticamente rejeitada, você não está lidando com um SGBD.

Regra 4: Visões - Um SGBD deve permitir que cada usuário visualize os dados de forma diferente daquela existente previamente no Banco de Dados. Uma visão consiste de um subconjunto de dados do Banco de Dados, necessariamente derivados dos existentes no Banco de Dados, porém estes não deverão estar explicitamente armazenados. Portanto, toda vez que você é obrigado a replicar uma estrutura, para fins de acesso de forma diferenciada por outros aplicativos, você não está lidando com um SGBD.

Regra 5: Transações- Um SGBD deve gerenciar completamente a integridade referencial definida em seu esquema, sem precisar em tempo algum, do auxílio do programa aplicativo. Desta forma exige-se que o banco de dados tenha ao menos uma instrução que permita a gravação de uma série modificações simultâneas e uma instrução capaz de cancelar uma série de modificações. Por exemplo, imaginemos que estejamos cadastrando um pedido para um cliente, que este deseje reservar 5 itens de nosso estoque, que estão disponíveis e portanto são reservados, porém existe um bloqueio financeiro (duplicatas em atraso) que impede a venda. A transação deverá ser desfeita com apenas uma instrução ao Banco de Dados, sem qualquer modificações suplementares nos dados. Caso você se obrigue a corrigir as reservas, através de acessos complementares, você não está lidando com um SGBD.

Regra 6: Acesso Automático- Em um GA uma situação típica é o chamado dead-lock, o abraço mortal. Esta situação indesejável pode ocorrer toda vez que um usuário travou um registro em uma tabela e seu próximo passo será travar um registro em uma tabela relacionada à primeira, porém se este registro estiver previamente travado por outro usuário, o primeiro usuário ficará paralisado, pois, estará esperando o segundo usuário liberar o registro em uso, para que então possa travá-lo e prosseguir sua tarefa. Se por hipótese o segundo usuário necessitar travar o registro travado pelo primeiro usuário (!), afirmamos que ocorreu um abraço mortal, pois cada usuário travou um registro e precisa travar um outro, justamente o registro anteriormente travado pelo outro! Imaginemos um caso onde o responsável pelos pedidos acabou de travar o Registro Item de Pedido, e, necessita travar um registro no Cadastro de Produtos, para indicar uma nova reserva. Se concomitantemente estiver sendo realizada uma tarefa de atualização de pendências na Tabela de Itens, e para tanto, previamente este segundo usuário travou a Tabela de Produtos, temos a ocorrência do abraço mortal. Se a responsabilidade de evitar esta ocorrência for responsabilidade da aplicação, você não está lidando com um SGBD.

Conclusão: Um SGBD deve obedecer INTEGRALMENTE as seis regras acima. Caso contrário, estaremos diante de um GA ou de um “quase” SGBD.



d) Servidor de Groupware: Este tipo de servidor é usado para o rastreamento e acompanhamento de diversas operações dentro da rede. O Groupware controla a administração de informações semi-estruturadas como textos, imagens, correio, quadros de avisos e fluxo de trabalho, estabelecendo um contato direto entre as pessoas. Ex: Microsoft Outlook e Lotus Notes (este último praticamente deu origem ao conceito Groupware).

e) Servidor de Objetos: A aplicação Cliente – Servidor é gerada como um conjunto de objetos de comunicação, ou seja, os objetos do cliente se comunicam com os objetos do servidor, mediante um canal de solicitações de objetos (ORB – Object Request Broker). O Cliente chama um método de um objeto remoto. O ORB localiza uma instância dessa classe do servidor de objetos, chama o método solicitado e envia os resultados ao objeto cliente. Os objetos deste servidor devem oferecer suporte à concorrência e participação e o ORB se encarrega de reunir todos os elementos necessários para que isso aconteça.

f) Servidor Web: São usados como uma forma inteligente de comunicação entre empresas através da Internet. Esta família de servidores permite transações com o acondicionamento de um browser. Este modelo (extremamente difundido atualmente) é integrado por clientes compactos e portáteis em comunicação com grandes servidores. Esta comunicação se dá mediante um protocolo chamado HTTP (Hyper Text Transfer Protocol) o qual define um conjunto simples de ordens, cujos parâmetros se transmitem em cadeias sem a necessidade de dados digitados. No processo de ampliação da Internet, já existem combinações com objetos distribuídos (Java) a fim de oferecer modalidades mais interativas com menor tráfego de rede.

g) Servidor de Impressoras: Este dispositivo tão somente administra as solicitações de uso de impressoras na rede, gerenciando requisições, níveis de acesso aos clientes e controle de prioridades para os jobs no spool de impressão. Está algo em desuso na sua forma dedicada, uma vez que as modernas redes corporativas facilitam a configuração de qualquer estação cliente simples com uma impressora conectada para compartilhamento com qualquer outro usuário.

h) Servidor de Aplicação: Neste meio se armazenam e executam as aplicações de software utilizadas pelos usuários, evitando assim duplicidade das mesmas, e permitindo melhor controle para a atualização de versões e produtos.

i) Servidor de Respaldo (ou redirecionamento): É inovador na arquitetura Cliente – Servidor; administra a execução de respaldos on-line, ou seja, assegura que as tarefas se realizem mesmo em caso de erro, já que se um dispositivo falha, automaticamente pode-se redirecionar o processo que estava em andamento para outro dispositivo operante, e com isso se criar um suporte ativo pré-programado. Este processo, portanto, é totalmente reativo, ou seja, realiza uma ação com base em instruções prévias.

Ao avaliarmos a performance de um ambiente Servidor, devemos levar em consideração os seguintes tópicos: Hardware do Computador Servidor . Já há alguns anos têm-se acirrado a competição entre os

servidores CISC (vulgarmente chamados de máquinas Intel - ainda que seu processador seja de outro fabricante) e os RISC (aparentemente poucos conhecem o fato das indústrias Intel também fabricarem processadores desta arquitetura), mas hoje encabeçadas pela Sun Microsystems, Integrated Device Technology, Inc. (IDT), ARM Holdings PLC, e empresas do segmento da Quantum Effect Design e ARC RISC Cores , que tem desenvolvido processadores customizáveis e expansíveis, segundo a necessidade do usuário. As máquinas de arquitetura RISC são construídas para alta performance, e possuem também preços bem superiores aos que custam suas "irmãs" CISC. Faz-se necessário um estudo avaliando custo-benefício, outra tarefa pouco praticada nas empresas.


http://srd.yahoo.com/srst/8566977/RISC+PROCESSOR/1/4/T=1020876405/F=8604d82b260e991f28ed537e9dd057cc/*http://www.arccores.com/

http://srd.yahoo.com/srst/8566977/RISC+PROCESSOR/1/4/T=1020876405/F=8604d82b260e991f28ed537e9dd057cc/*http://www.arccores.com/

http://srd.yahoo.com/srst/53677/RISC/6/33/T=1020877444/F=61500ac59ccabc08451c19c4f6b1ea65/*http://www.qedinc.com/

http://srd.yahoo.com/srst/11529802/RISC+PROCESSOR/2/4/T=1020876405/F=1c6b6d6d752f0608ffa29ee5050a9774/*http://www.arm.com/

http://srd.yahoo.com/srst/2285386/RISC+PROCESSOR/3/4/T=1020876405/F=dcb62cde494172e667298f6efda37a13/*http://www.idt.com/

http://srd.yahoo.com/srst/2285386/RISC+PROCESSOR/3/4/T=1020876405/F=dcb62cde494172e667298f6efda37a13/*http://www.idt.com/


A maioria dos gestores de sistemas manuseia uma revista Computter Shopper em busca das máquinas "última palavra" (Leia-se State of Art), despreocupados em realizar uma pré-análise de pontos fundamentais como:

A) Por quanto tempo esta aplicação desempenhará suas funções sem que se faça necessário um pacote significativo de alterações sejam elas funcionais ou no volume de dados processados. Por quanto tempo nosso parque de clientes permanecerá com números aproximadamente parecidos com os previstos para a data de entrada em produção do sistema. E finalmente, que previsão podemos fazer acerca da continuação da necessidade destes serviços. A toda esta gama de conhecimentos chamamos "Administração do Ciclo de Vida Útil do Sistema". Em nossos levantamentos, nos deparamos com diversos CPDs que nunca haviam sequer escutado a menção desta expressão. Deram de ombros ao ouvir os conceitos e retrucaram: "Quando o sistema não serve mais, tiramos de produção e fazemos outro".

B) Levando em conta meu volume de dados previsto e a taxa de crescimento (seja ela mensal, semestral, anual, etc...) de quanto espaço em disco irei necessitar realmente? A maioria dos gestores compra o maior disco que encontrar, e justifica tal posição com respostas do tipo "Bom, se o disco estiver com espaço sobrando, sempre podemos colocar mais coisas nele".

C) Praticamente ninguém faz um levantamento sério acerca de quantos usuários simultâneos estarão conectados ao seu servidor, e, portanto, encontramos aberrações como a compra de uma máquina RISC de US$ 80,000 para hospedar um site de e-commerce com produtos tão específicos, que passavam até um dia inteiro sem realizar uma única venda. Isso representava um aproveitamento menor que 1% do que a máquina poderia oferecer.

D) O lado oposto também é praticado. Monta-se uma base de dados com todo o protocolo de um ministério inteiro e descobre-se que quase ninguém consegue recuperar alguma informação dele, nos horários de pico. Razão? Está hospedado num Pentium MMX 166 com 64Mbytes de RAM. "Ah, mas o disco rígido é de 30 Gigabytes, e não estamos usando nem 10% dele!". Nem nos demos ao trabalho de perguntar qual teria sido o critério para escolha daquele disco rígido.

O Papel dos Data Bases Administrators

Pouca gente sabe, mas a pessoa com função de Database Administrator (leia-se DBA) em uma empresa tem muito mais atribuições que colocar um servidor no ar e estruturar as áreas de trabalho de cada aplicação, ou direitos de acesso aos usuários. Segundo documentação da Oracle, um DBA tem como deveres (além do citado acima) todas as tarefas abaixo:

(1) Realizar o planejamento de capacidade requerido para criação e manutenção das bases de dados. O DBA deve trabalhar bem próximo à equipe de administração dos sistemas, porque os computadores freqüentemente tem aplicações e/ou ferramentas não - Oracle rodando em si próprios.

(2) Realizar a sintonia permanente das instâncias de bancos de dados, ou seja, manter sempre todas as bases sintonizadas.

(3) Instalar novas versões do Gerenciador de Bancos de Dados Oracle e suas ferramentas, bem como quaisquer outras ferramentas que acessem as bases de dados Oracle. Isto deve ser feito de forma criteriosa, sempre avaliando impactos no que já exista instalado e em produção. Aplique-se aos outros SGBDs não-Oracle.

(4) Controlar migrações de programas, mudanças de bases de dados, mudanças de referências aos dados e mudanças de menu durante o período de desenvolvimento. Raramente as equipes de desenvolvimento envolvem o DBA em alguma outra fase que não a definição da base no servidor real, já para entrada em produção.

(5) Executar reorganizações das bases de dados, segundo se faça necessário, para manter uma boa performance e assegurar o máximo rendimento das mesmas. Em nenhum dos sistemas que acompanhamos percebemos este tipo de preocupação.



(6) Estabelecer padrões para o desenvolvimento da aplicação e seu código, com o objetivo de assegurar a integridade, segurança e performance dos bancos. O DBA fará revisões freqüentes no desenvolvimento e no código para assegurar-se de que os padrões estabelecidos estão sendo seguidos. NUNCA vimos isso acontecer nos sistemas avaliados e/ou acompanhados.

(7) Avaliar versões do Oracle (ou da Microsoft, se aplicarmos essa cultura ao SQL-Server) e suas ferramentas, bem como produtos de terceiros, para se assegurar de que as instalações estejam funcionando com o que existir de mais apropriado. O Planejamento também é feito pelo DBA, em conjunto com os desenvolvedores de aplicação e administradores do sistema, a fim de que exista a certeza de que quaisquer novos produtos ou versões advindas de upgrades sejam implantadas com o mínimo de impacto. A expressão "IMPACTO" parece não constar do dicionário de quase a totalidade dos desenvolvedores. Isso explica em boa parte a incidência de sistemas que "começaram tão bem, mas acabaram se tornando quase inúteis, tal a lentidão com que rodam hoje em dia".

(8) Suprir de suporte técnico todos os times de desenvolvimento de aplicações. Isto é usualmente feito através de um help desk. O DBA normalmente é o contato entre os usuários e a Oracle Corporation (ou no caso, a software house criadora do SGBD, seja ela a Microsoft, Sybase, IBM, etc...).

(9) Estabelecer e manter as restrições e limitações no uso do banco de dados, para assegurar a integridade do mesmo. Esta decisão freqüentemente é tomada pelo meio político e não pelo técnico.

(10) Administrar TODOS os objetos do banco de dados, incluindo tabelas, clusters, índices, consultas, seqüências, pacotes e procedimentos.

(11) Dar suporte a todas as mudanças aplicadas aos objetos de base de dados, fazendo uma análise de impacto destas mudanças. Quase sempre fazemos estas tarefas sem ao menos comunicarmos ao DBA (e ainda assim, isso quando existe de fato um DBA no contexto).

(12) Detectar e corrigir problemas envolvendo bases de dados, aplicações e ferramentas de desenvolvimento. Uma vez escolhida a plataforma de desenvolvimento, é tomado quase como um insulto qualquer crítica a ela. E, pior do que isso, forma-se dentro da empresa verdadeiros clãs tecnológicos, como, por exemplo, os defensores do Oracle e os do SQL-Server. Uma reunião para se escolher uma das plataformas pode se tornar um bate-boca semelhante ao de torcedores do Vasco e do Flamengo, com muito despejo de adrenalina e pouca argumentação técnica ou lógica. Nestes casos, normalmente quem dá a decisão final é o chefe do projeto (conhecendo ou não as plataformas propostas).



CAPÍTULO IV - O MIDDLEWARE

Para que os clientes e servidores possam comunicar-se, é necessária uma estrutura lógica que proporcione os mecanismos básicos de direcionamento e transporte; a esta estrutura chamamos Middleware, expressão usada para encampar todo o software distribuído necessário ao suporte de interações entre clientes e servidores.O Middleware é um módulo intermediário que não pertence nem às instalações do servidor, nem às interfaces com o usuário e nem à lógica da aplicação que é executada no cliente. Tampouco devemos confundi-la com a rede física em si (cabeamento, sinais de rádio ou infravermelho, hubs, switches, etc...). Entendamos o Middleware como uma interface lógica padrão, a qual gerencia os serviços de rede. Suas principais atribuições são: Tornar independentes as duas entidades: O cliente e o servidor não necessitam saber comunicar-se

entre eles, apenas devem saber como fazê-lo com o Middleware. Traduzir as informações de uma aplicação e passá-la a uma outra: aceita consultas e dados,

recuperando-os da aplicação cliente, os transmite e envia a resposta de retorno. Também gera os códigos de erro, em caso de algum problema nestas tarefas ocorrer.

Controlar as comunicações: dá à rede as características adequadas de desempenho, confiabilidade, transparência e administração.

Existem dois tipos de Middleware:

1. O Middleware geral é a essência da maioria das interações entre cliente e servidor, incluindo as pilhas de comunicação, diretórios distribuídos, serviços de autenticação, horários de funcionamento da rede, chamadas a procedimentos remotos (RPC's) e serviços em paralelo (multi-tarefas). Inclui também as extensões do sistema operacional de redes, como os serviços distribuídos de arquivos e impressão, bem como produtos de Middleware orientados a mensagens (MOM - Messages Oriented Middleware).

2. O Middleware de serviços específicos é necessário para suportar um tipo particular de serviços Cliente - Servidor; de forma que exista um middleware específico para os servidores dedicados: Middleware para bases de dados, Middleware para OLTP, Middleware para groupware, para objetos, etc...

O Middleware é portanto uma ferramenta adequada, a qual não só é flexível e segura como também protege os sistemas de engenharia reversa (por exemplo, os módulos escritos em ASP não são visíveis para os clientes, nem quaisquer arquivos aos quais não queiramos dar visibilidade para qualquer pessoa.) O mesmo permite manejar diferentes ambientes de computação.



CAPÍTULO IV - PENSANDO EM SOLUÇÕES E METODOLOGIAS.

Após toda esta explanação sobre papéis dos diversos elementos que vêm a compor um ambiente Cliente - Servidor, passemos às técnicas para avaliação de performance em cada segmento apresentado e para as providências cabíveis, quando detectarmos um desempenho deficiente nos mesmos segmentos.

Segmento Cliente:

Dividiremos este segmento em outros sub-segmentos, a saber:

O Hardware do Computador Cliente - Talvez a que oferece maiores dificuldades, no caso de se fazerem necessárias quaisquer mudanças, primeiramente por não estar sempre ao alcance do suporte avaliar todo o parque cliente, e em segundo por ser freqüentemente operada por usuários leigos o suficiente para sequer se atreverem a abrir o Painel de Controle do Windows. Mas vamos aos problemas mais usuais:

1. Se estamos lidando com plataforma Windows, precisamos de uma noção básica acerca da versão do Windows que temos em nosso PC e quais são os requisitos mínimos - leia-se, a plataforma de hardware recomendada como "desejável" e nunca a "mínima") de memória e de clock de processador para uma utilização saudável. Recomendo fortemente o aumento de memória RAM, como principal estratégia para melhoria no desempenho do PC. Felizmente, o problema das limitações na memória-base (Base Memory) foram praticamente eliminados, pelo que vamos nos abster de falar nisso. Se você ainda está usando Windows 3.11 for Workgroups ou inferior, recomendo um up-grade de versão do Windows. E se sua máquina é algo abaixo de Pentium 90 com 16 Megabytes de memória, pouco poderemos fazer sem um up-grade de hardware também. Consulte técnicos especializados de confiança, no caso, para obter uma tabela de hardware recomendado para as diversas versões de Windows e aplicações que rodem sob o mesmo. Toda a família NT/2000 é mais pesada que seus "primos" 9X, e portanto, mais recomendáveis para sistema operacional de máquinas clientes, a não ser por outras razões extras (principalmente segurança). Não recomendamos o Windows-ME (Millenium) para nenhuma configuração de hardware, por causa de uma série de limitações do mesmo em ambiente de rede e na interação com dispositivos periféricos, a não ser que seu PC tenha como únicas finalidades escutar música e lazer com jogos.

2. Tem havido de algum tempo para cá um aumento considerável de aperfeiçoamentos na tecnologia IDE de acesso a discos rígidos, zip-drives, cd-roms, etc..., o que me leva a não recomendar o uso de Discos Rígidos com tecnologia SCSI para máquinas clientes. Ao invés de gastar com um disco SCSI e respectiva controladora, coloque 4 vezes mais memória na sua máquina e ainda vai gastar menos.

3. Se estiver considerando uma rede de média para grande (acima de 50 clientes), não queira economizar nas placas de rede (Ethernet Cards), pois ainda que todas as atuais sejam de 100 Megabits ou mais, as mais baratas geram problemas de colisão, o que força o envio e recebimento dos pacotes a se repetir (algumas ocasiões por dezenas de vezes). Recomendo (após muitos benchmarks em redes grandes, e em provedores de acesso à Internet) a marca 3-Com, ainda que ela custe bem mais caro que suas irmãs menos famosas. Pela simples substituição de algumas dezenas de placas de rede (de placas não 3-Com para placas 3-Com) já conseguimos quase dobrar o desempenho da mesma rede.

4. Para testar de forma primária, algo como uma triagem inicial para detecção das "tartarugas da rede", há pacotes de software de baixo custo, os quais testam não só a integridade do hardware, como seu desempenho. Fizemos algumas avaliações usando o Burnin-Test e PassMark, da Passmark Software (www.passmark.com) e os achamos bastante satisfatórios, seja por serem pequenos (o que evita over-head de arquivos), compactos, fáceis de operar, e além de tudo baratos. Há naturalmente muitos outros, mas este trabalho é um esforço inicial, como mencionado na introdução. A próxima revisão deverá estar mais rica de produtos e suas avaliações.

5. Até aqui consideramos máquinas estáveis, ou seja, PCs sem problema crônico de travamento. Se o seu anda travando, melhor nem considerá-lo para avaliação de desempenho, porque os PCs normalmente "travam" quando alguns serviços essenciais para o interfaceamento (envio das imagens para a placa de vídeo e entradas de mouse e teclado) entre a máquina e o usuário falham.


http://www.passmark.com/


Se estes serviços estão falhando por defeitos no hardware, isso quer dizer que há mal-funcionamento de outros serviços, além dos citados essenciais. E alguns destes serviços podem estar cuidando do tráfego de informações, detecção de máquinas na rede, gravação dos dados solicitados e envio para a placa de vídeo das consultas solicitadas de forma precária - e portanto, passível de degradação no desempenho - mesmo que a máquina ainda não tenha travado.

6. As placas aceleradoras de vídeo podem proporcionar alguma melhoria na performance... mas apenas em casos onde a estação cliente está fazendo uso de gráficos "pesados", o que não corresponde à grande maioria dos casos. Normalmente nossas clientes precisam principalmente lidar com dados em formato texto, e assim, as video-acellerators não darão grande contribuição. Um mínimo de 4Megabytes de Ram de vídeo já atende quase todos os casos satisfatoriamente.

Software de Base do Computador Cliente - O primeiro problema é o desconhecimento. Muitos usuários (sem qualquer formação técnica acerca de tais assuntos) fazem a instalação do Windows ou Linux sem sequer entender qual a versão mais apropriada para o Hardware de que ele dispõe. Afora portanto as aberrações óbvias deste tipo (Como pessoas instalando Windows 2000 Advanced Server em Pentiums 100 com 24 Megabytes de memória RAM) ainda é interessante consultar um técnico qualificado sobre esse assunto, e é porque não vou tentar esgotar essa matéria. Ela é extensa e evolui quase diariamente, com novos hardwares e novas versões de software. Mesmo assim, podemos mencionar que:

1. A maioria dos clientes está funcionando em plataformas Microsoft Windows (seja lá qual for a versão) e portanto sofrem de um mal crônico, por muitos considerados um "bug" - o problema do Registry do Windows. O registry é uma estrutura de controle do sistema operacional, que gerencia todos os componentes de sistema instalados, sejam DLLs (Dynamic Link Libraries), OCX (Active-X Objects) ou quaisquer outras modalidades de bibliotecas e componentes (Consultar literatura sobre o Windows Registry e sobre a aplicação RegEdit, para maior riqueza de detalhes). Tais componentes têm que ser registrados em uma estrutura a que a Microsoft chamou "Registry". O problema é que esta estrutura vai crescendo conforme vamos trabalhando no Windows e, por alguma razão, se instalamos algum pacote de software e depois o desinstalamos, o Registry não volta ao que era antes, crescendo sempre. O simples "passeio" por sites da Internet nos convida vez por outra a instalar Add-Ins nos sites A ou B, sem o que não obteremos o efeito desejado para aquela página... e isso também vai "engordando" nosso Registry. Algumas empresas já afirmaram que isso gera o efeito do Windows ir degradando de performance sozinho, com o simples passar do tempo em operação. Que fazer então ? Reinstalar o Windows seja por cima da mesma versão ou fazendo up-grade, nada resolve. Isto porque o registry é mantido, com a finalidade de não termos que reinstalar todos os pacotes extra-Windows - Office, Real Player, Visual Basic, Dicionário Aurélio, SQL-Server Client, Oracle Client, Netscape, Delphi, ou seja lá o que estivermos usando em nossa máquina. Uma das opções é deletar as pastas com o sistema operacional (Atenção! NUNCA é necessário formatar o Disco Rígido por causa disso!), mas isso nos força a reinstalar tudo que estivera na mesma, incluindo o Windows, o qual virá sem qualquer configuração anterior, inclusive. Não há outro caminho? Felizmente, de poucos anos para cá foram desenvolvidos Registry Cleaners, pequenos pacotes de software que lêem todo o Registry e se oferecem para limpar o mesmo de tudo que não estiver em uso, ou cujos arquivos tenham sido apagados do disco. Podemos encontrar alguns deles nas URLs...

2. Os anti-virus com tecnologia Shield (estrutura que deixa detectores de vírus vigiando as operações de entrada na memória RAM e no disco) podem ser muito práticos e dar até algum descanso ao usuário, por sua atividade contínua - mas consomem recursos de máquina preciosos, podendo estar entre o time dos "suspeitos" de lentidão na máquina. Desativar a função Shield e ordenar, por exemplo, a execução do anti-virus toda vez que se inicializar o PC praticamente nos livra de ataques viróticos, e em compensação aumenta nossa velocidade de processamento. É mais importante manter a versão do anti-virus atualizada do que deixá-la residente na memória, vigiando tudo que entra na memória e no disco. Isso inclui também uma tecnologia de detecção de escrita direta em disco nas áreas FAT, Partição e Diretório, o que nos faculta podermos confirmar qualquer dessas operações - e também nos faculta esperarmos até o dobro do tempo por uma resposta, tamanha a quantidade de recursos que esse dispositivo consome. E, naturalmente, jamais nos esqueçamos do inestimável backup periódico e organizado de todas as nossas informações importantes.



3. A configuração do Setup de baixo nível do computador nem sempre é tarefa simples. Confie-a a alguém experiente e se possível avalie o desempenho da máquina antes e depois dos ajustes no Setup de baixo nível.

4. Não faça partições muito grandes! Acima de 10 Gigabytes, as partições começam a consumir muitos recursos de máquina para serem gerenciadas. Em um HD de 40 Gbytes, por exemplo, veremos um aumento significativo de velocidade se dividirmos o disco em 4 partições de 10G ao invés de uma única de 40Gbytes.

5. Desative os recursos de Power-Saving (economia de energia - dispositivos que desligam periféricos de funções da própria placa-mãe, se a mesma passa algum tempo ociosa). Além de o PC perder tempo, reativando o funcionamento do periférico, ainda corre o risco de aumentar a memória já utilizada, com outras instâncias do software de gerenciamento do dispositivo.

Software dos Aplicativos do Computador Cliente - Temos problemas estruturais envolvendo a mão de obra para desenvolvimento a qual via de regra é escassa, os cronogramas dificilmente são definidos com acuracidade, devido a pressões políticas e falta de experiência específica para tanto. Muitas vezes assisti a reuniões onde alguns técnicos apresentavam uma proposta para a construção de um sistema, e seu chefe reduzia o prazo em digamos 30%, sem que a equipe tivesse direito à réplica. Quando interpelada a respeito de tal imprudência, a chefia dava de ombros e respondia que "Eles conseguem sim, só precisamos usar de um pouco de energia com a equipe". Raramente vi uma preocupação clara das mesmas chefias quanto ao aspecto de que os técnicos desenvolvedores estivessem sendo por demais otimistas e para tanto se fizesse necessária uma reserva de segurança, digamos de 20% do prazo oferecido. As alegações eram sempre as mesmas: O Diretor não vai aceitar que se faça em tanto tempo, o usuário fulano disse que se o sistema não entrar em produção até março próximo, de nada lhe servirá mais, ou até um desdenhoso "Não acredito que vocês levem tanto tempo para realizar uma tarefa tão simples". Consequentemente, mesmo hoje, os prazos vivem sendo redefinidos, recolocando continuamente cada projeto no status de "Incêndio a ser apagado". Ora, com tais ambientes e situações, não deve nos causar estranheza que a entrega de um projeto seja semelhante a tirar um horrível fardo das costas de várias pessoas - elas querem se livrar o mais depressa possível do problema. E é talvez por estes fatores - menos do que por falta de conhecimento a respeito da necessidade das revisões - que muitos sistemas acabam entrando em produção com uma estrutura tal que seria reprovada pelo professor mais benevolente de qualquer instituição de ensino universitário. Mas vamos aos problemas em si:

1. Todo o modelo e código devem ser revisados antes que o sistema entre em produção . Para tanto, dispomos de ferramentas de apoio bem elaboradas, aplicáveis tanto no código das procedures e funções que ficam rodando no cliente quanto nas stored procedures que permanecem no servidor SQL-Server, por exemplo - a maioria de baixo custo e fácil utilização. Estas ferramentas não só nos proporcionam uma documentação melhor estruturada como nos apontam as parte do código que estão escritas, mas nunca são chamadas. Tome-se como exemplo o VBCode Print e o SQL7-Print ambas da Joginder Nahil Software (http://www.jn-software.com). Versões de demonstração estão disponíveis no Site, mas dado o baixo custo (menos de R$ 150.00 o jogo, da última vez que adquirimos) talvez fosse interessante já comprar as versões full, para colocação como piloto nos computadores digamos, de duas equipes de desenvolvimento. Deve ser feito o levantamento do modelo de dados previsto pelo pessoal de modelagem, em confronto com o modelo obtido por engenharia reversa da base de dados pronta. A intenção aqui é clara: Muitas tabelas são modificadas na fase de testes, e acabam permanecendo no banco, bem como triggers e stored procedures, views obsoletas, enfim, um monte de lixo inoperante. Como estas tabelas não fazem parte da documentação, acaba se optando por não mexer nelas (imaginem se a aplicação parasse de funcionar pela exclusão de alguma coisa cuja função não temos certeza). A filosofia de construção de bases de dados relacionais afirma que todo banco deve estar normalizado. Portanto, visto as estruturas modernas dos servidores de bases de dados terem sido voltadas para este princípio, já não justifica termos um punhado de dados redundantes com o objetivo de "otimizar o tempo na execução de alguns processos". Normalize seu banco ! Nada de tabelas sem chave primária, ou tabelas soltas sem relacionamentos com outras apenas porque "daria muito trabalho verificar a integridade das mesmas e depois, são tabelas pouco usadas no sistema". Se existem


http://www.jn-software.com/


tabelas "soltas" tem que haver uma boa razão para isso, e estas razões devem constar da documentação do sistema. Desenvolvedores Oracle, não se esqueçam da forma como os servidores armazenam as queries: Cada vez que houver um único caracter diferente em uma nova query, o Oracle a entenderá como outra query e a armazenará de novo. Estabeleçam um padrão para a escrita de queries e obedeçam ao mesmo, antes até da revisão final para colocação em produção. Um sistema eficiente neste processo de revisão é colocar um profissional que fez uma parte do sistema para revisar outra parte feita por um colega de equipe, e vice-versa. Isso não consome tempo adicional para entendimento dos processos como um todo e ao mesmo tempo facilita uma mente nova descobrir problemas onde o criador não os podia enxergar, devido ao fenômeno de limitação humana conhecido: Tendemos a passar por coisas que fizemos erradas repetidamente, sem nos apercebermos do erro.

2. Mantenha a sua documentação do sistema atualizada. Certa feita, ao observar numa reunião que a documentação estava defasada com relação ao sistema atual, ouvi do chefe de projeto que "Pode até estar, mas ainda estamos bem melhores do que o sistema A e o B, que sequer tem documentação". Sabemos da existência de profissionais em todos os segmentos que tentam se assenhorear dos produtos que desenvolvem, deixando "caixas-pretas" e partes do sistema sem documentação - uma tentativa clara de se tornarem insubstituíveis. Dilbert afirmou que " jamais devemos trabalhar no sentido de sermos insubstituíveis, pois quem não pode ser substituído, também não pode ser promovido.". E sabemos também que muitas vezes o prazo anda tão exíguo que a equipe acaba por negligenciar algumas tarefas, especialmente aquelas que não serão testadas pelos usuários. Isso gera sistemas de difícil manutenção, aumentando a dificuldade em avaliarmos seu desempenho e quando não, sua manutenção para correções não de funcionamento ou estrutura, mas melhoria de performance.

3. Faça ferramentas para cronometragem de processos. Gere pequenas ferramentas para cronometragem dos tempos de resposta que considere críticos e coloque-os para avaliar o desempenho nas tarefas sabidamente demoradas. Algumas estarão disponíveis para uso, com toda a documentação atinente na seção de download do site da Analysts Associates, (www.analysts.com.br), a partir de agosto de 2002. No caso de verificar que o processo está inaceitavelmente moroso, repense a distribuição de dados, a distribuição de processos, a otimização de algumas rotinas ou a mudança da ocasião ou periodicidade com que são disparadas.

4. Busque a excelência. Não se conforme em abrir mão das recomendações acima, se seu sistema já está com desempenho satisfatório, tendo em mente que quanto mais experiência você tiver, tanto mais complexas serão as tarefas que lhe serão passadas. Busque a qualidade total desde o início de sua carreira, ainda que você seja um programador júnior com menos de um ano de experiência. E se tiver que entregar alguma coisa sem a qualidade mínima que você pretendia, deixe isso claro em algum lugar da documentação (na seção "Sugestões para versões futuras", por exemplo).

5. Busque a unidade com toda a equipe. Reuniões e mais reuniões são feitas para tomada de algumas decisões. Não alegue estar muito ocupado ou não se tratar de uma discussão específica acerca da área que está sob sua responsabilidade. Faça sempre a ponderação: Isto pertence ao projeto X, no qual estou trabalhando? Então, tenho interesse nesta reunião! Em mais de uma ocasião, apenas assistir a uma reunião com o time de digitadores nos mostrou erros grosseiros em nossas interfaces de entradas de dados. Sei da cultura separatista e excludente, que defende que digitadores não devem participar dos diálogos dos programadores, estes não devem se envolver com as discussões dos analistas e projetistas, e, por fim, que estes últimos não devem participar dos planejamentos da chefia. Minha sugestão sempre será que as reuniões sejam o mais curtas possível (muitas delas com 30 minutos ou menos) e convocadas para tratar de assuntos específicos. Sugestões técnicas mais longas devem ser passadas por escrito, bem como reclamações. E esta documentação (pouco convencional, mas extremamente útil) deve ficar em um local de fácil acesso por todos os envolvidos no projeto. As reuniões devem ser moderadas por alguém com experiência no assunto, a fim de que sejam objetivas e produtivas. E finalmente, devemos encorajar sempre a cada profissional dar uma olhada no trabalho dos colegas. Isto gera não somente troca de tecnologia (com conseqüentes aperfeiçoamentos dos profissionais) como um clima de revisão contínua e maior camaradagem entre os participantes. Tudo isso nos encaminha à geração de sistemas com maior qualidade, estabilidade e desempenho.



6. Distribua bem seus dados. Se estiver construindo aplicações para Intranet ou redes locais, lembre-se que a melhor estratégia para evitar o congestionamento do tráfego na rede e a sobrecarga de requisições aos servidores ainda é colocar os dados que sofram pouca ou nenhuma alteração ao longo do ciclo de vida útil do sistema nas máquinas cliente. Por mais velozes que sejam sua rede e seus servidores, jamais poderão competir com o acesso local a um disco rígido. Há excelente literatura acerca da distribuição de dados, e não creio ser o caso de explaná-las neste trabalho.

7. Evite as aplicações pseudo - 3 camadas. A construção Three-Thier perde significativamente sua eficiência, quando colocamos numa mesma máquina as tarefas de servidor de dados e servidor de aplicações. Use máquinas distintas, sempre que possível. E em caso de ainda não atender às especificações mínimas de desempenho, use máquinas exclusivas para sua aplicação. Quando compartilhamos no mesmo hardware de servidor diversas aplicações, devemos ter em mente que é como se dividíssemos os recursos por 2, 3, 4 ou mais (dependendo de quantas aplicações compartilhem o mesmo hardware). Embora estes números não sejam nem exatos nem linearmente proporcionais, o princípio continua válido.

8. Esteja atento às novas versões de servidores de bases de dados e ferramentas. Uma forma prática e pouco dispendiosa de acompanhar as evoluções tecnológicas é ler com assiduidade as revistas e artigos especializados. A Internet é rica em tais assuntos, e sempre se pode assinar algum periódico (journal) ou fazer parte de listas de discussão de profissionais no assunto. Na verdade a lição encerrada aqui é: Não tente fazer tudo sozinho, e muito menos partindo do zero! Dê mais importância aos comentários de comunidades de profissionais do que às jactâncias das software houses que anunciam seus produtos. O paradigma da "conversa de vendedor" também funciona em grandes empresas como a Microsoft, Sun, Oracle, Dell Computers e Hewlett Packard. Se tiver acesso enfim a algum benchmark ou pesquisa que alguma pessoa ou equipe de sua confiança já realizou, tanto melhor! Por que haveríamos de “reinventar a roda”?

9. Os cuidados com a construção de dispositivos que mantenham o banco de dados otimizado. A figura do DBA foi muito negligenciada nos anos anteriores, e mesmo hoje em dia a cultura de diversas empresas não conseguiu entender sua importância. É um profissional VITAL para o bom andamento não só na fase de projeto como na de produção para qualquer sistema de porte significativo. Coloquei em algumas páginas atrás diversos atributos que mereciam os cuidados do DBA, mas a grande verdade é que a maioria das organizações sequer tem um funcionário com esse perfil. Em não havendo mão de obra especializada, a solução é alocar quem se disponha (às vezes com parcos recursos e domínio da tecnologia em foco) para realizar o mínimo para que o projeto "funcione". Para melhor superarmos estas lacunas, é sempre bom pensarmos em mecanismos de "enxugamento" das bases de dados, bem como arquivamento de dados obsoletos ou meramente em desuso diário. Se um sistema de controle de estoque tem 20.000 itens, e descobrimos que menos de 3.000 deles consiste de produtos com os quais realmente trabalhamos, desloquemos os 17.000 produtos restantes para uma base de dados auxiliar, que não estará em produção porém acessível, no caso de precisarmos "importar" alguns itens para o banco de produção. Mecanismos de software podem ser criados para otimização periódica dos dados inúteis. Prefira esse caminho do que "pedir ao André para verificar o que está enchendo demais o banco de dados e colocar tudo em algum arquivo morto". Alguns considerariam esta tarefa como parte da distribuição de dados, mas eu a reputo como uma matéria nova e distinta, visto todos os dados distribuídos estarem em franca produção, e serem vitais para o funcionamento contínuo do sistema.



Segmento Servidor:

Listamos acima grande variedade de tipos de servidores, e uma próxima revisão no presente trabalho certamente cuidaria de outros membros da família; para esta primeira versão porém, vamos nos limitar aos servidores de dados convencionais, enfocando apenas os principais tópicos que fazem parte de um SGBD.

Hardware do Computador Servidor: Pouca coisa evolui tão rapidamente quando o hardware hoje em dia, e seria impossível cobrir todas as novidades; vamos pois falar de algumas tecnologias:

1. Os discos rígidos alcançaram velocidades inacreditáveis, se pensássemos em termos de cinco anos atrás, além de grandes capacidades (80 GigaBytes, em fevereiro de 2002) no mesmo espaço em que colocávamos uma leitora de diskettes convencionais de 3 1/2 polegadas. Além do mais, qualquer placa-mãe profissional vem com memória cache de 1Megabytes ou mais. Tais características aliadas ao Ultra-DMA tem contribuído para o surgimento de uma geração de tecnologia de discos capaz de suplantar os "packs" do grande porte em velocidade de acesso. A tecnologia SCSI permite também multi-session, o que facilita em muito o acesso de vários usuários ao mesmo disco, lendo e gravando simultaneamente. Porém, talvez nada se compare à tecnologia RAD, capaz de gerenciar diversos HDs SCSI, enxergando-os como se fossem um só. Quase todos os provedores de acesso à Internet, hospedeiros de grandes bases de dados, têm feito uso desta arquitetura. Num provedor por nós visitado, o contador de acessos mostrava mais de 1300 usuários logados no mesmo banco, e o monitor de sistema indicava que mal estavam sendo usados 20% da capacidade máxima do mesmo.

2. As placas-mãe também não ficaram atrás, seja por suportarem processadores cada vez mais sofisticados, algumas delas com vários processadores, como por virem com memória cache escalonável (vimos uma com 8 Megabytes de cache L2). A memória RAM máxima alocável nestas mother-boards de há muito superou a casa dos 1GigaBytes e percebendo essa tendência, os desenvolvedores de SGBDs investiram em bancos que trabalham quase o tempo todo com a memória eletrônica (o banco Oracle, por excelência), se permitindo fazer alterações nos discos rígidos apenas quando convém ao SGBD. A tecnologia RISC oferece também performances inacreditáveis, ainda que não permita o funcionamento das plataformas servidoras Windows, que rodam exclusivamente nas máquinas CISC (comumente chamadas de máquinas Intel, ainda que a Intel tenha fabricado processadores RISC também). A arquitetura RISC sob os sistemas operacionais Unix permite ainda a replicação de discos - ou mirroring (espelhamento) executada fisicamente e praticamente sem degradação de desempenho.

O que poderíamos concluir é que não existe um "Hardware Ideal" para nenhum projeto, como uma receita pré-definida. O que é necessário fazermos é um planejamento confiável de qual será a demanda de acessos a esses servidores, e com isso definirmos uma máquina (ou mais) de forma a sermos atendidos. Recentemente, os provedores de acesso à Internet começaram a mensurar seus custos de hospedagem não mais apenas pelo volume de dados residente, mas também pelo tráfego e número de usuários logados simultaneamente no domínio. Veja por exemplo, as tabelas de preços da Telebrasília (www.brturbo.com). Como correção de problemas no hardware, podemos apontar:a) Hardware com pouca memória, ou simplesmente com muita coisa carregada na memória, o que

começa a causar "travamentos" nos horários de pico de acessos. Com alguns pacotes de software estatísticos podemos facilmente acompanhar o comportamento do servidor.

b) Disco rígido muito cheio. Quando estoura a capacidade de memória RAM, os sistemas operacionais realizam um processo chamado de disk-swapping, que consiste em enxergar parte do disco como extensão da RAM. Ora, se o disco estiver trabalhando muito cheio, a área para swapping se torna restrita, e isso pode causar não só demoras homéricas como até travamentos no sistema.

c) Em servidores NT, registry muito carregado ou simplesmente mal dimensionado. No caso, podemos alocar mais espaço para o registry, se tudo que está carregado nele é necessário, no Painel de Controle/ Sistema/Avançado/Opções de Desempenho e/ou utilizarmos um Registry Cleaner, de forma análoga à que usaríamos numa estação cliente.

d) Também em servidores NT é adequado realizarmos a desfragmentação dos discos rígidos, toda vez que pudermos colocar o sistema off-line. É verdade que nem todo servidor pode se dar a esse luxo.

e) Dispormos de fontes redundantes (ao menos uma) em todos os servidores hospedeiros de bases de dados vitais para a empresa.



Software de Base do Computador Servidor:1. As arquiteturas centralizadas e clusterizadas:

Arquitetura de Bases de Dados: Centralizados X Clusterizados (Agrupados).

VISÃO GERAL EXECUTIVA:

O Mercado de Bases de Dados paralelas é de má qualidade, com propagandas competitivas, onde cada vendedor tenta persuadir os clientes acerca dos benefícios de sua própria arquitetura. O comprador precisa fazer sua escolha da plataforma de software em regime de missão crítica, enquanto perdido numa pilha de relatórios de benchmarking, contrastando revisões de análise e posicionamentos favoráveis de usuários.Este documento é o resultado de uma avaliação técnica entre duas arquiteturas diferentes de Bases de Dados: A centralizada, como a representada pelo Microsoft SQL-Server e a arquitetura de disco compartilhado em cluster do Oracle 9i RAC (Real Application Clusters). Também explanamos como interpretar e utilizar resultados de avaliação de desempenho, seja dos vendedores de hardware, seja dos de Bases de Dados, e como várias características nas Bases de Dados podem ser relevantes, nas diversas situações do usuário real.Este relatório não abrange as bases de dados com tecnologia de disco nada-compartilhado em cluster. Os Bancos centralizados constituem um passo, através dos clusters nada-compartilhados, mas na verdade não passam de Bases de Dados Distribuídas. Desta forma, uma Base de Dados nada-compartilhada clusterizada, como a IBM DB2 7.2 é uma Base de Dados simples, com um dicionário de dados simples, e não uma coleção de Bases de Dados acopladas independentemente. Clusters nada-compartilhados são comparados com clusters em disco compartilhado, em outro boletim emitido pela Oracle: Comparações Técnicas da Oracle Real Application Clusters contra o IBM DB2 UDB, também disponível no endereço http://www.oracle.com


http://www.oracle.com/


INTRODUÇÃO:

O que é uma base de dados centralizada ?

Uma base de dados centralizada é a unificação lógica de bases de dados distintas rodando em servidores independentes, sem compartilhamento de recursos (incluindo disco) e conectados por uma Rede.O dado é particionado horizontalmente através de cada servidor participante. Tanto para o DBA quanto para o Desenvolvedor de Aplicação, há uma distinção clara entre o que são dados "locais" e dados "remotos" (princípio da distribuição de dados tradicional). As aplicações vêem uma consulta lógica simples de dados mediante consultas UNION ALL e SQL distribuído - a Microsoft chama isto de Tecnologia de Consultas Particionadas Distribuídas (Distributed Partitioned Views - DPVs). O DPV é construído de forma diferente para cada nó, pois ele precisa considerar explicitamente quais lotes de dados são locais e quais são remotos.

Figura 1 - Arquitetura de Bases de Dados Centralizadas.

Por exemplo, eis um resumo de como você particionaria seus usuários através de múltiplos servidores em tecnologia Microsoft SQL-Server (O código foi obtido do endereço http://msdn.microsoft.com/library/en-us/createdb/cm_8_des_06_17zr.asp)

1. Primeiro, crie partições independentes para cada nó:


http://msdn.microsoft.com/library/en-us/createdb/cm_8_des_06_17zr.asp


2. Em seguida, defina as informações acerca da conectividade ("linked server definitios") e as opções de otimização para as queries de cada servidor participante.

3. Finalmente, crie uma DPV para cada nó. Eis o código para o servidor I

Observe-se como as instruções de SELECT, referenciando a consulta Customers, especificam uma condição de busca sobre a coluna da partição (CustomerID), o otimizador de query usa as definições de constrições CHECK para determinar qual membro da tabela contém as linhas. Através de algumas constrições, os DPVs podem ser atualizados da mesma forma que filtrados, e o otimizador de queries usa a mesma metodologia para determinar a tabela membro destino, para um UPDATE. As Bases de Dados Centralizadas não possuem um dicionário de dados global, e assim o otimizador precisa acessar todos os nós para determinar o plano de execução de uma query.Portanto, uma Base de Dados Centralizada é uma Base de Dados Distribuída, revestida pela tecnologia DPV.Os DPVs estendem as consultas UNION ALL por servidores distribuídos, com base nas características de uma chave de particionamento.



O que é a Arquitetura de Bases de Dados com Disco Compartilhado em Clusters ?

Um cluster (cacho, ramalhete, grupo) consiste de servidores (normalmente SMPs), uma interconexão de cluster e um subsistema de disco compartilhado. As arquiteturas de Bases de Dados em discos compartilhados rodam em um hardware também agrupado (clusterizado) o que dá a cada servidor participante igual acesso a todos os discos, por mais que os servidores não compartilhem sua memória RAM. A maioria dos vendedores de hardware oferecem discos compartilhados em clusters hoje em dia.

Figura 2 - Configuração de uma Base de Dados modelo Discos Compartilhados em Clusters.(Bases de Dados modelo Disco Compartilhado em Clusters implementam sofisticados algoritmos de compartilhamento de cache, a fim de mascarar as complexidades do hardware clusterizado.)

Uma instância de Base de Dados roda em qualquer nó do cluster. As transações sendo executadas em uma instância podem ler ou escrever em qualquer parte da Base de Dados, não existe uma noção de dados "pertencentes" a um nó. O desempenho do sistema é baseado na utilização efetiva de uma interconexão rápida entre os servidores da Base de Dados, como a Arquitetura de Interface Virtual - VIA (Virtual Interface Architeture), entre os nós do cluster. O Oracle 9i Real Application Clusters (RAC) é a primeira arquitetura de disco-compartilhado em clusters bem sucedida, e utiliza sofisticados algoritmos de compartilhamento de cache (Cache Fusion) com a finalidade de permitir alta performance e escalabilidade sem que se faça necessário o particionamento de dados ou aplicações.

O Cache Fusion trabalha por: Utilização dos caches coletivos da Base de Dados, considerando cada nó no sistema para

satisfazer as requisições de dados para a aplicação em qualquer nó - "fundindo" efetivamente os caches de todos os nós no cluster interno de um cache.

Removendo as operações em disco (lentas) do caminho crítico para uma sincronização de dados entre os nós - se dois nós operam no mesmo bloco de dados, sincronizam as informações em seus caches e não através de gravação no disco.

Redução drástica do número de mensagens requeridas, por causa da tecnologia de sincronização entre os nós.

Tirando proveito dos protocolos de interconexão de clusters, dotados de baixa latência, tanto para mensagens através da Base de Dados como para o tráfego de dados entre os caches.



As aplicações vêem a mesma interface de programação tanto na versão Oracle SMP como no RAC, uma vez que a tecnologia Cache Fusion torna a arquitetura de clusters transparente para a aplicação.

A Microsoft também abraçou a tecnologia de clusterização, embora com algumas diferenças (parte imposta pelo Hardware CISC, parte pelas características da arquitetura NT). O SQL-Server 2000 suporta alguns princípios interessantes de redundância (ou seja, dotar uma Base de Dados de dispositivos que evitem a saída do ar de uma aplicação, em caso de falha de um servidor, substituindo em tempo real os serviços do servidor com problemas pelo redirecionamento dos mesmos serviços para um outro servidor.Vamos enfatizar a clusterização à prova de falhas, a qual é diferente da clusterização de balanceamento de carga. Em um cluster de servidores onde se implementou a tecnologia de balanceamento de cargas, as requisições de processamento são distribuídas através dos servidores. Os diferentes servidores compartilham a carga do processamento, porém não compartilham recursos, como um array de discos ou memória RAM.Se um dos servidores acusa uma falha ou mesmo sai do ar, a carga de processamento pode ser simplesmente redistribuída entre os nós "sobreviventes" do cluster. Em contraste, um cluster à prova de falhas é um grupo de dois ou mais computadores independentes, que compartilham recursos, de forma que se um dos servidores falhar um outro servidor no mesmo cluster irá assumir os recursos do falhado, bem como toda a sua carga de processamento. Este gerenciamento de recursos pelos nós do cluster é requerido para implementar a redundância em aplicações estabelecidas tais quais as que fornecem serviços de mensagens e acesso às Base de Dados.Na arquitetura de clusters á prova de falhas, os recursos são compartilhados entre os servidores. Devido a este compartilhamento de recursos, hoje em dia muito comum em arrays de disco, a maioria de soluções de clusterização é baseada em modelos nada-compartilhados e modelos disco-compartilhado.No modelo Nada-Compartilhado (Como no IBM DB2) cada servidor em um cluster controla um diferente conjunto de recursos, como por exemplo, uma partição de disco diferente em um array de discos. Nesta arquitetura, apenas um servidor pode acessar um recurso ou partição particular de cada vez. No caso de uma falha, outro servidor sobrevivente no cluster assume os recursos do servidor falhado e assim, todas as requisições subsequentes dos clientes são redirecionadas para este servidor. A estrutura do Windows 2000 (serviços de cluster) é baseada neste modelo de Nada-Compartilhado. Já no modelo de Disco-Compartilhado, muitos servidores em um cluster podem acessar simultaneamente um disco compartilhado. A sincronização lógica requerida para manter a integridade de dados neste modelo é muito complexa, e não é utilizada nos serviços de cluster do Windows 2000. Desta forma, ainda que as plataformas Microsoft (especialmente o Windows 2000 Advanced Server e o Windows 2000 Datacenter Server) trabalham amplamente com a tecnologia de clusterização, mas no modelo Nada-Compartilhado. Funcionam também com arrays de discos, mas com ótica bem mais simplificada se comparada à arquitetura Unix-Oracle, a qual emprega algoritmos sofisticados para sincronização dos dados, obtendo assim performances bem superiores, ainda que ofereça pouca ou nenhuma vantagem em matéria de integridade dos mesmos dados. Os arrays de discos atingem desempenhos invejáveis com a tecnologia RAC, mas por outro lado exigem custos muitas vezes maiores, seja pelo hardware RISC (muitas vezes mais caro que o CISC) seja pelo ambiente UNIX, o qual embora seja fornecido gratuitamente em algumas situações (o LINUX sempre o foi, e ultimamente, o Solaris tem usado esta estratégia em diversos casos) demandam uma mão de obra escassa no mercado, mais dispendiosa. As interfaces para desenvolvimento também continuam muito pobres no ambiente UNIX, o que acarreta prazos bem mais dilatados, em qualquer processo de desenvolvimento. A conclusão provável de todos quantos estão avaliando as duas vertentes é que não existe uma "plataforma ideal". Cada uma tem seus prós e contras, vantagens e desvantagens, dependendo do projeto que se pretende desenvolver, o público-alvo de clientes, recursos financeiros, tamanho do banco de dados e volume de acessos, tráfego de dados, etc.

1. Mesmo sob o aspecto de que é bastante subjetivo afirmar que um sistema está "rápido" ou "lento", cabe a nós como empresa montarmos uma base de dados contendo informações comparativas - sem compararmos nosso servidor a algo que já exista, como afirmar se ele está adequado ou não? Embora algumas medidas possam ser feitas simplesmente a nível de tempo de resposta a uma consulta, por exemplo, vimos acima que o principal causador da demora poderia ser o segmento cliente ou mesmo o MiddleWare. O mais correto é fazermos uma análise pura do servidor, ou seja, não dependermos de outro segmento para nossas medições. A Oracle já fornece alguns medidores estatísticos, na aquisição de seus SGBDs, mas eu indicaria fortemente alguns produtos de terceiros para tal tarefa (in-off, os profissionais da Oracle também o fariam, mas é inútil pretendermos uma declaração oficial no sentido). Recomendo pois (além dos mencionados acima, para máquinas clientes, os quais nos dão ao menos a certeza de integridade da máquina) o Spotlighting for Oracle (Produzido pela Quest Software) e o Spotlighting for SQL-Server - roda para o 2000 e para o 7 -



como ferramentas de avaliação de desempenho do banco. Eles nos dão um espelho completo de tudo que está acontecendo com o servidor, vale a pena dar uma olhada na versão trial (pode-se fazer download no mesmo site). Além da avaliação de desempenho, a família Spotlight ainda nos ajuda a na sintonia da Base de Dados, realizando uma pré-sintonia e nos apontando que variáveis e/ou parâmetros estão inadequados ao funcionamento do SGBD.

2. Estejamos atentos para o lançamento de service-packs dos ambientes operacionais. Embora tenhamos que admitir que a maioria das correções de bugs se localiza no tratamento do ambiente gráfico (o que certamente faz com que o Unix seja mais veloz e menos sujeito aos travamentos que as máquinas sob Windows), é fato também que algumas correções e melhorias são feitas no próprio Kernel do Windows e mesmo nas bibliotecas do DCOM.

3. Melhor expormos de uma vez por todas o problema do DCOM, para bases de dados Oracle rodando sob plataforma Windows: O Oracle só merece ser comparado em termos de performance ao SQL-Server, se estiver hospedado em máquinas Unix ! Em uma máquina com Windows NT-Server, em um benchmark sumário com queries de médio porte, ele gastou em torno de 40 vezes mais tempo (não estou falando de 40% mais, são 40 VEZES mais mesmo) que o mesmo banco, com os mesmos índices, mesmas chaves primárias e mesmas tabelas e relacionamentos hospedada num servidor SQL-Server versão 7. O Oracle só é um SGBD de alta performance em ambiente UNIX, e é inócuo nos debatermos contra esse fato. Para maior compreensão destes aspectos, sugiro uma leitura de matérias abordando o confronto CORBA X DCOM, o que evitaremos fazer neste trabalho.

4. Para bases de dados onde nossas tabelas estejam atingindo a casa de 1 milhão de registros, os próprios engenheiros da Microsoft recomendam a migração para Oracle (em ambiente Unix, bem entendido).

5. Capriche na sintonia do seu servidor, especialmente em se tratando de um servidor Oracle ! Se não souber fazê-la, não saia experimentando mudar valores no Init.ORA, nem entre em Wizards de sintonia, se não souber exatamente o que está fazendo! O risco consiste inclusive na situação de o servidor não dar mais boot.

Procedures e Funções que rodam no Servidor de Dados:1. Procedures armazenadas e triggers: Quando temos tabelas com muitos registros (a Oracle os

chama de linhas) é recomendável limitarmos o número de linhas que uma query armazenada possa devolver. Quando ainda não tínhamos esse entendimento, passamos algumas vezes pelo constrangimento de ver um sistema de contabilidade inteiro fora do ar porque algum usuário pedira inadvertidamente todos os lançamentos iniciados por 1. A linguagem SQL possui cláusulas para coibir estas ocorrências (a TOP e a MAXLINES por exemplo), e suas extensões (Transact-SQL e PL/SQL, para o SQL-Server e Oracle, respectivamente) também nos permitem filtrar os resultados. Sem tais cuidados, podemos cair na situação de cruzar os braços enquanto o servidor processa 2.000.000 de registros... em um banco Centralizado como o SQL-Server, o servidor virtualmente para ! Em um clusterizado, como o Oracle 9i, o processamento cai até menos da metade da velocidade em condições regulares.

2. Consulte um DBA se estiver na dúvida se uma procedure ou query está bem escrita. Muitos DBAs receiam definir valores de Time-Out pequenos, com medo de alguma query mais longa ser abortada e isso causar problemas na produção. Interaja com o profissional responsável pela Base de Dados, e recorra ao mesmo em qualquer situação dúbia.

3. Leia os manuais do fabricante para codificação de stored procedures e triggers. Sempre são expostas ali técnicas para melhoria de performance e evito de "gargalos" de processamento.


Manual de Performance

Documents

Transcript of Manual de Performance