Manual de Performance

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS
METODOLOGIA PARA
AVALIAO DO DESEMPENHO
DE APLICATIVOS
Herbert Lopes da Silva (Consultor CTIS)
Pgina 1/26
31/12/2015
1 - INTRODUO:
Desde o incio dos anos 90 j se vislumbrava a tendncia para a arquitetura Cliente-Servidor (ClientServer), visto o aumento progressivo da velocidade e capacidade de armazenamento dos at ento
chamados "Micro-Computadores". Ainda que as redes pioneiras pecassem por uma performance
baixssima, mesmo para os padres 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"). No cabe naturalmente maior discusso acerca da evoluo 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 tambm pelo fato das tecnologias envolvendo
computadores de pequeno porte trabalharem cada vez mais no sentido de ultrapassarem seus "irmos
maiores". Continuando, vieram as primeiras redes de baixa velocidade com tecnologia de cabo coaxial, as
quais evoluram gradualmente para redes de alta performance, at chegarmos na era da fibra tica e dos
satlites de comunicao, o que nos proporciona desempenhos admirveis, inacreditveis para quem
vivesse h apenas 15 anos atrs.
Vieram (atreladas aos conceitos de redes locais e remotas de alta performance) um sem nmero de
tecnologias visando a otimizao dos tempos de resposta e da confiabilidade acerca da atualidade dos
dados e cada vez mais se percebeu a importncia dos sistemas funcionarem on-line, e isso j no
representava os custos exorbitantes do passado. Foi assim que assistimos ao florescer de paradigmas
como:
-
Crescente quantidade de executivos de nvel mdio tomando decises importantes.

Bancos de Dados cada vez mais rpidos, para atualizao e disponibilizao de seus dados.
Aplicativos estruturados em componentes distribudos
Distribuio de dados entre o servidor e as mquinas clientes.
Arquitetura de duas e trs camadas o servidor de aplicao.
Bancos de dados imensos funcionando na Web.
Uma "corrida armamentista" entre as grandes companhias fabricantes de software, a fim de colocar
disposio dos usurios pacotes cada vez mais inteligentes e de fcil operao (user-friendly).
Interfaces visuais cada vez melhor elaboradas, de forma a permitir seu uso para praticamente qualquer
nvel de usurio.
Estruturas de hardware de alta capacidade, as quais permitissem milhares e mesmo milhes de
acessos simultneos, fossem eles locais ou remotos, a custos incrivelmente menores que seus
antecessores.
Reformulao das ferramentas de desenvolvimento de aplicativos e bancos de dados, bem como as
tcnicas empregadas nos mesmos as ferramentas visuais.
Os "cases" eficientes, os quais no somente apoiavam o desenvolvimento como cuidavam de forma
quase intuitiva da documentao dos sistemas.
Os clientes WEB, transformando o que seria no incio um visualizador HTML em interfaces poderosas e
confiveis para manipulao e utilizao de dados o ASP, PHP, Cold Fusion, VBScript, JavaScript e
outras estruturas de codificao.
A Orientao a Objetos, da qual sempre se falara desde os anos 70, agora emergindo com literatura,
tcnicas, cursos, treinamentos e respectivas ferramentas de apoio ao desenvolvimento, no s no
cenrio acadmico, mas tambm no universo profissional.
Com tantas tecnologias revolucionrias, como no poderia deixar de ser, muita coisa foi estruturada de
forma desordenada, desprovida de critrio, quando no at ferindo leis universais da Engenharia de
Sistemas.
O Departamento de Produo (subordinado Diretoria de Tecnologia da ECT) achou por bem, em face do
exposto acima, iniciar a construo de uma metodologia para avaliao de desempenho em todos os nveis
conhecidos, seja de software, hardware ou middleware. Entendemos que, ainda que iniciantes em tais
tcnicas, necessrio o fomento do conhecimento a respeito, e o que o presente trabalho ir buscar
fazer, mais guisa de se iniciar uma cultura de avaliao sistemtica de desempenho contrariamente aos
"achismos" reinantes na maioria dos nichos de desenvolvimento. Em resumo, pretendemos estabelecer
critrios para julgar a eficincia ou ineficincia dos tempos de resposta de uma aplicao, o que nos
permita saber onde so necessrias melhorias e modificaes. O consagrado costume de simplesmente
pedir um servidor mais potente nos parece antiquado, bem como os cimes dos desenvolvedores e sua
resistncia em exibir o cdigo construdo pelos mesmos. Em vrios casos, at a simples obteno de um
modelo de dados demandou esforos e burocracias incalculveis, com um trfego de comunicaes
internas muitas vezes maior que a documentao demandada em si. esta forma de pensar que tentamos
Pgina 2/26
31/12/2015

erradicar, por acreditarmos que nenhum produto to bom que no possa ser melhorado, e ao mesmo
tempo encorajarmos uma autocrtica mais freqente nas mentes de nossos tcnicos, ao invs de
simplesmente um dar-de-ombros culpando a rede, ou os servidores, ou as mquinas clientes, ou a
aplicao, ou a ferramenta de desenvolvimento, ou o banco de dados, enfim... "os outros".
Houve uma idia inicial de realiz-lo sem colocar em discusso quaisquer ferramentas de apoio, mas foi
abandonada na medida que poderamos terminar o trabalho com um punhado de idias no papel e
nenhuma ao pragmtica. Destarte, as aqui indicadas foram as que encontramos para avaliao, estando
certamente abertos a sugestes e discusses, bem como o apoio de todos os colegas que compem um
dos melhores quadros profissionais de Informtica do pas, quadro esse que certamente contribuiu para que
a ECT fosse a grande empresa que , no s no cenrio nacional como no estrangeiro.
Braslia DF, em 24 de abril de 2002.
Pgina 3/26
31/12/2015

CAPTULO I - ARQUITETURAS CLIENTE - SERVIDOR - Conceitos e Modelos.
Tem sido propostos um sem-nmero de modelos, acerca da arquitetura cliente-servidor. Na impossibilidade
de abordarmos todos, ser feita meno dos mais conhecidos hoje em dia.
Histrico:
razovel admitirmos que os primeiros ensaios documentados desta estrutura foram dados pela Sybase,
fundada em 1984 e tendo como um dos principais objetivos lanar no mercado unicamente produtos para
arquitetura client-server. Ao final dos anos 80, seu primeiro produto foi lanado 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 bsica chamada dBase IV, da Ashton Tate. O dBase IV no se mostrou uma
ferramenta adequada desde o princpio... e William Henry Gates IV provavelmente pensava j em ter sua
ferramenta exclusiva... no frigir dos ovos, houve uma srie de desencontros comerciais entre a Sybase,
Microsoft e a prpria IBM (naquele momento scia da Microsoft para o OS/2), o que terminou na conhecida
ruptura, formalizada em 1991. A situao era totalmente diferente em 1994, quando os principais
fabricantes tradicionais (Informix, Oracle, Sybase) tinham lanado no mercado poderosos servidores de
dados e a eles se agregava a IBM com seu DB2 prometendo alcanar todos os sistemas operacionais de
ento (Alm do seu clssico 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 aps formalizar a separao com a Sybase
partiu para seu prprio 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 ento se dizia que o Visual Basic (apesar de seus poucos mritos como linguagem)
era o favorito para dominar o mercado, o que aconteceu de fato at o presente momento (Abril de 2002).
Com o golpe estratgico de Bill Gates contratando mais da metade do time da Borland responsvel pelo
Delphi, e agregando-os ao VB.Net (e para tanto pagando todas as multas contratuais dos tcnicos
Borland), podemos ainda apostar no VB por alguns anos como ferramenta mais disseminada.
Atualmente, os servidores de dados tm-se mostrado slidos, rpidos e eficientes e seus otimizadores
internos deram um verdadeiro show de tecnologia e competncia, o que contribuiu na alavancagem de
uma significativa quantidade de empresas para aplicaes Cliente-Servidor.
Estas empresas tm a cada dia comprovado o aspecto de que escolher um servidor pode ser uma tarefa
rdua e complexa; para aplicaes de pequeno e mdio porte, todos eles se mostraram muito bons. O que
ento ir separar os bons dos state of art sero as ocasies / aplicaes que exijam altssimos regimes
transacionais, seja por grande nmero de conexes simultneas ou pelo trfego pesado de dados como
tambm pela complexidade de queries extensas. Os fabricantes tm agregado s mesmas caractersticas
novas, como paralelismo, head-ahead e outras, o que praticamente tem disponibilizado ao comprador uma
verso 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 tendncia menos tcnica que subjetiva
quando da escolha de um destes fabricantes - mais considerada a confiana que nos desperta o
fabricante, seu compromisso com o produto, sua tendncia a se manter continuamente atualizado, sua
situao econmico - financeira, a eficincia de seu suporte local, e at finalmente o preo. No so
(quase nunca, ao menos) feitas avaliaes srias com verses beta de qualquer de tais "candidatos a uma
vaga em nosso servidor", muito menos algum tipo de medio comparativa. A quase totalidade das
empresas sequer possui um time de profissionais ali colocados para este tipo de pesquisa, visto ser bem
mais cmodo e barato acreditarmos nos benchmarks das revistas especializadas. Na ECT, por exemplo,
adotamos o critrio de elegermos os servidores Oracle quando estamos diante de uma aplicao mais
pesada (e a prpria definio de "pesada" controversa), MS SQL-Server quando estivermos diante de
algo pequeno ou mdio e MS Access se nosso produto for simples, leve e pouco acessado. fato que a
prpria Microsoft afirmou nas suas palestras de lanamento do SQL-Server 2000 que ela mesma
recomendava o uso do Oracle quando estivssemos lidando com tabelas contendo mais de um milho de
registros; mas isso no pode ser considerado zelo com o usurio, mas apenas estratgia de marketing
(rea na qual ela se revelou extremamente habilidosa) para conquistar todo o nicho de bancos de dados de
muito pequeno, pequeno e mdio porte - certamente a grande maioria dos bancos hoje existentes!
Portanto, no razovel meramente acreditarmos nela e seguirmos suas sugestes.
Hoje em dia, finalmente, a arquitetura Cliente - Servidor considerada como fundamental na abordagem
das necessidades das empresas. O processamento distribudo se reconhece atualmente como o novo
paradigma para os sistemas de informao, em contraste com seus predecessores independentes.
Pgina 4/26
31/12/2015

Definio:
Definiremos arquitetura Client-Server como um modelo para desenvolvimento de sistemas de informao
em que as transaes se dividem em elementos independentes que cooperam entre si para troca de
informaes, servios ou recursos.
Em tal arquitetura, o computador de cada um dos usurios, chamada cliente inicia um processo de dilogo:
produz uma demanda de informao ou solicita recursos. Ao Computador que ir responder a essa
demanda do computador cliente chamamos servidor. Sob este modelo, cada usurio tem liberdade para
obter a informao que deseje em um dado momento, proveniente de uma ou mais fontes locais ou
remotas e de process-la segundo lhe convenha. Servidores distintos tambm podem intercambiar estas
informaes 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 interao mais comum entre as aplicaes em
execuo numa rede. Na Internet, correto afirmar que todas as aplicaes de alto-nvel foram modeladas
com esta viso, mesmo que este tal arquitetnico no faa parte de seus conceitos bsicos (como os
protocolos IP, TCP e UDP).
Caractersticas mais importantes:
O Servidor apresenta a todos os seus clientes uma interface nica e bem definida.
O Cliente no precisa conhecer a lgica do Servidor, apenas sua interface externa.
O Cliente no depende da localizao fsica do Servidor, nem do tipo de equipamento do mesmo,
tampouco de seu sistema operacional.
Mudanas nos Servidores acarretam na necessidade de pouca ou nenhuma mudana nos Clientes.
Peculiaridades da Arquitetura Cliente - Servidor diferentes de outras formas de software distribudo:
Servios: O servidor um provedor de servios, ao passo que o cliente um consumidor dos mesmos
servios.
Recursos Compartilhados: Um servidor pode atender a muitos clientes simultaneamente, e gerenciar o
acesso destes aos mesmos recursos.
Protocolos Assimtricos: A relao cliente para servidor de muitos para um; os clientes solicitam
servios, enquanto os servidores esperam suas solicitaes passivamente.
Ambientes mesclados com eficincia: 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 informaes baseadas em mensagens: Os sistemas interagem atravs de um mecanismo de
transmisso de mensagens, as quais se encarregam da entrega das solicitaes e respostas.
Encapsulamento de servios: Os servidores podem ser substitudos sem afetar os clientes desde que a
interface para receber solicitaes e oferecer servios permanea imutvel.
Escalonamento fcil: Os sistemas Cliente - Servidor podem ser escalonados vertical e horizontalmente,
ou seja, podem migrar para servidores maiores ou mltiplos servidores da mesma forma que podem ter
corte ou acrscimo de clientes; ambas as aes ocorrem sem que haja grande diferena na
performance do sistema.
Integridade: Tanto o cdigo quanto os dados do servidor se conservam de maneira centralizada, o que
vale dizer com menor custo de manuteno e proteo adequada integridade dos dados
compartilhados. Alm disso, os clientes mantm sua individualidade e independncia.
Em suma, a arquitetura Cliente - Servidor uma infra-estrutura verstil, 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.
Pgina 5/26
31/12/2015
Pgina 6/26
31/12/2015

CAPTULO II - O CLIENTE - Caractersticas e definies
O cliente a entidade por meio da qual um usurio solicita um servio, realiza uma petio ou demanda o
uso de recursos, e o responsvel pela apresentao dos dados e/ou informaes, em ambiente grfico.
conhecido simplisticamente como a parte do sistema que o usurio utiliza, e, portanto, o cliente
primariamente concebido para pessoas no-profissionais na rea de informtica, ao menos em princpio.
Diferentemente dos predecessores da estrutura cliente - servidor, o cliente pode abrigar em suas
instalaes parte dos dados de que o sistema faa uso, tcnica conhecida para que se diminua o trfego na
rede, desde que tais dados no sejam atualizveis continuamente. Exemplo: Se fssemos listar os estados
brasileiros, poderamos coloc-los num banco de dados local (no prprio cliente), visto ser bastante rara
alguma atualizao neste tipo de informao. J as condies climticas de uma determinada regio
jamais poderiam ficar hospedadas numa estrutura cliente, por serem passivas de alteraes at mesmo de
hora em hora ou menos.
O Cliente se comunica com processos auxiliares, os quais se encarregam de iniciar e manter a conexo
com o servidor, enviar pedidos e receber respostas, administrar falhas, realizar tarefas de sincronizao (o
que vem a ser a segurana de que os dados estejam sempre atualizados de forma consolidada), e de
segurana. Ele pode interagir com um ou mais servidores.
A este conjunto de tarefas chamamos de "front-end", a qual realiza atividades do tipo:
a) Manipulao da interface com o usurio
b) Captura (mediante digitao, cliques de mouse, scaneamento, etc.) e validao dos dados de entrada.
c) Gerao de consultas e relatrios acerca do contedo do banco de dados.
Basicamente, portanto, quando queremos avaliar a performance de um ambiente cliente, devemos levar
em considerao tudo que faa parte do mesmo, a saber:
O Hardware do Computador Cliente. Em uma estao tpica do tipo Intel (ou um de seus concorrentes
Ciryx, AMD e outros) temos diversos fatores responsveis pela maior ou menor agilidade da mquina,
desde a quantidade de memria DRAM, como o cache (interno e externo ao processador), velocidade
de acesso do disco rgido, tecnologia de DMA, SCSI, IDE e mesmo das placas aceleradoras de vdeo.
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 carto de rede padro Ethernet, Token-Ring ou assemelhada... tudo isso pode influenciar
tremendamente (vrias vezes mais ou menos, em alguns casos) a performance da estao. E
realmente, melhorando estas caractersticas certamente melhoraremos o tempo de resposta da estao
e por conseguinte a satisfao do usurio em particular e do time de pessoas que compe o sistema
como um todo. Quantas vezes ouvimos uma equipe inteira murmurando que "o sistema at tinha sido
bem construdo e atendia s necessidades propostas, mas era muito lento".
O Software de Base do Computador Cliente. Primeiramente enfocaramos o sistema operacional
utilizado. Sabemos hoje que a Microsoft e todas as suas verses de Windows no seriam talvez a
melhor plataforma operacional, mas certamente tinham a melhor estrutura de marketing. Devido sua
estrutura grfica tremendamente eivada de recursos, fomos descobrindo conforme o tempo passava,
que precisvamos de mquinas cada vez mais velozes e otimizadas apenas para manter a
performance original... e assim foi nas sucessivas verses a partir do Windows 3.11 for Workgroups
(primeira verso com rede razoavelmente confivel da Microsoft) at o Windows XP dos nossos dias.
Ficou provado (e no quero aqui realizar uma campanha anti-Microsoft) que at o Windows 2000 por
exemplo, temos um processo de "entupimento" do registry da estao, o qual vai tornando a execuo
das aplicaes mais lenta a cada dia. Se instalamos uma ferramenta pesada e depois a desinstalamos,
verificamos consternados que ela saiu de funcionamento, mas no saiu do computador. Vestgios
sempre ficam para trs, e isso vai depreciando os tempos de resposta na mquina. A boa notcia que
se apagarmos tudo que pertencer ao Windows (ou formatarmos o disco rgido) e reinstalarmos tudo de
novo, a mquina 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 usurios quando solicitao de uma melhora no
desempenho da mquina recebem um PC "limpinho". Apesar dos Registry Cleaners que vrias
software houses lanaram (incluindo um da prpria Microsoft), o problema sempre persistiu.
O Software dos Aplicativos do Computador Cliente. Naturalmente sempre uma sada cmoda
culparmos William Henry Gates por todas as nossas mazelas de lentido. Muitas aplicaes, em sua
Pgina 7/26
31/12/2015

parte cliente, foram muito mal escritas, com erros de implementao grosseiros at. Outras, jamais
sofreram uma reviso e limpeza aps a verso de produo ter sido escrita (em alguns casos,
descobrimos que 70% das variveis declaradas simplesmente no faziam mais coisa alguma no
sistema, porm permaneciam alegremente definidas, ocupando memria e recursos de mquina.
Arrays dimensionados com muito mais instncias do que so utilizadas, funes fora de uso de h
muito, mas ainda ocupando espao nos formulrios, total ausncia de programao modular e
estruturada, quanto mais escrita orientada a componentes, a mesma funo com nomes totalmente
diferentes, dezenas de recordsets abertos ao mesmo tempo sem qualquer utilizao, loops
desenhados de forma a rodar at o final, mesmo que se buscasse um resultado j obtido na 3 iterao,
enfim... um sem-nmero de falhas bsicas. Acresce que quando da construo de queries, muitos
programadores optam pelo cmodo SELECT * , ao invs de escrever cada atributo que dever ser
devolvido pelo servidor, esquecendo-se que na mdia o tempo gasto para processar dois atributos
pouca coisa menor que o dobro do tempo para se processar um atributo s. Muitos no acompanham a
evoluo das ferramentas de desenvolvimento, por mera preguia de se reciclar, e assim permanecem
usando bibliotecas ultrapassadas de acesso a dados, mesmo que tenham ouvido comentrios que as
mais recentes chegam a triplicar o tempo de resposta em um banco de dados. Outros usam objetos
fceis de manear na programao, mesmo que os tais redundem em vrias 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 programao, recusam-se teimosamente a realizar o
"chins" nos algoritmos. Alguns (por alguma razo desconhecida) consideram o cdigo sua propriedade
particular, e chegam a se tornar agressivos quando algum pede vistas nele. Muitos outros, quando
percebem a aproximao do pessoal da produo, vem-nos mais como "fiscais", "depreciadores" e
"crticos" do que como auxiliadores e parceiros, interessados to somente no sucesso do sistema;
razo pela qual fazem todo o possvel para sonegar detalhes acerca do cdigo, enviam modelos
defasados, nunca tem tempo para comparecer s reunies, enfim... tratam os da produo como
verdadeiros inimigos ! Realmente, sempre mais cmodo culpar a rede, a mquina servidora, o
engine do banco de dados, o DCOM do Windows, o trfego na rede, e at (como ouvimos certa vez) a
qualidade da linha telefnica, que no permitia conexes 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 verso
8.x em diante) faz distino entre duas queries de sintaxe idntica, se as mesmas tiverem diferenas
entre maisculas ou minsculas 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 tambm de "SELECT nome_completo, cpf". Pela falta de uma
orientao e/ou padronizao, ou simplesmente por no envolverem o DBA nos trabalhos de definio
de projeto, constantemente vemos dezenas de instncias 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 srio da distribuio de dados, do fluxo de acessos simultneos, do volume de bytes que iria
trafegar e certamente, muito menos, uma normatizao dos conceitos e variveis influentes no
desempenho dos sistemas.
Os cuidados com a construo 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 tambm que existem servidores to velozes que poderamos armazenar em
um deles todos os CPFs do povo brasileiro sem grande problemas; isto porm no justifica o descaso
de muitos profissionais em manter dados antigos e j desnecessrios nas bases em produo. Um
determinado sistema do Departamento Financeiro de uma empresa guardava no mesmo banco toda a
movimentao dos ltimos 14 anos, embora o analista responsvel tenha admitido que s trabalhavam
com os dados do exerccio corrente - "deixamos esse controle do arquivo morto para o final do projeto".
No caso em pauta, o sistema estava em produo havia nada menos que seis anos, e suas tabelas
comeavam a querer atingir a casa de 1 milho de lanamentos.
Estes so 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 comearmos de
algum ponto do que construirmos um tratado tentando esgotar o assunto.
Pgina 8/26
31/12/2015

CAPTULO III - O SERVIDOR - Caractersticas e definies
O Servidor a entidade que oferece servios e devolve resultados: executa o processamento de dados,
aplicaes e manejo da informao 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 requisies do cliente, e
onde os processos so executados.
Em alguns casos, existem processos auxiliares que se encarregam de receber as solicitaes do cliente,
verificar a proteo, ativar um processo servidor para satisfazer o pedido, receber sua resposta e envi-la
ao cliente. Ademais, deve manejar os controles de acesso (segurana), a recuperao diante de falhas e
outros aspectos afins como backups, replicaes, mensagens a operadores, processos batch, etc. Pelas
razes anteriores, a plataforma computacional associada aos servidores mais poderosa que a dos
clientes, via de regra PCs potentes, estaes de trabalho, minicomputadores e mesmo sistemas de grande
porte (mainframes).
Os servidores realizam as seguintes funes:
Controle de acessos concorrentes a bancos de dados compartilhados.
Gerenciamento de perifricos compartilhados.
Links de comunicao com outras redes locais ou remotas.
Atender s solicitaes de qualquer cliente para tanto autorizado, uma vez que o mesmo tenha sido
reconhecido.
No servidor, permanecem as aplicaes que devem ser compartilhadas entre diversos usurios. Embora
haja excees, normalmente os clientes e o servidor esto em mquinas distintas, e no necessariamente
da mesma famlia de hardware.
Os principais tipos de servidores so:
a) Servidor de Arquivos: O cliente envia solicitaes de registros de arquivos ao servidor; este um
servio
simples de dados compartilhados por meio da rede. So teis para armazenas arquivos (documentos,
imagens, planejamentos, etc.) e aplicaes de escritrio (processadores de texto, planilhas de
clculo...). Ele no pode ser considerado um servidor de banco de dados, porque um Banco de Dados
, antes de mais nada, uma coleo logicamente coerente de dados com determinada significao
intrnseca. Em outras palavras um arquivo contendo uma srie de dados de um cliente, um arquivo
com dados aleatoriamente gerados e dois arquivos padro dbf (xBase) com relao definida entre
ambos, no 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 solicitaes de SQL, na qualidade de mensagens (uma mensagem por instruo) e o
servidor faz uso de sua prpria capacidade de processamento para encontrar os dados solicitados e
devolv-los por meio da rede (no enviando todos os registros). Desta forma, podemos realizar
consultas especficas e obter resultados flexveis.
c) Servidor de Transaes (Transactions Server)
O cliente ativa procedimentos remotos que residem no servidor com um mecanismo de bases de
dados, em SQL, ou seja, o intercmbio de informaes na rede consiste de uma s mensagem
solicitao / resposta, a qual executa um grupo de instrues SQL (chamadas transaes) no servidor.
Ao ser criada a aplicao Cliente Servidor, gera-se tanto cdigo para o cliente quanto para o servidor.
E estas aplicaes chamamos Aplicao com Processamento de Transaes em Linha (OLTP OnLine
Transactions Processing). Para a construo de Data Warehouses precisamos de outra arquitetura
(conhecida como Modelo Dimensional) mas no abordaremos tais conceitos no presente trabalho, por
representarem uma tendncia pouqussimo empregada nas empresas convencionais e por envolver
tcnicas sofisticadas e especficas na construo e manuseio de Dados (Consultas AdHoc, Aplicaes
com desenho flexvel, redundncia de dados, etc).
Pgina 9/26
31/12/2015

H seis regras prticas para que diferenciemos um genuno Gerenciador de Bases de Dados (SGBD) de
um Servidor de Arquivos, a saber:
Regra 1: Auto-Conteno- Um SGBD no contm apenas os dados em si, mas armazena completamente
toda a descrio 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 (tpicos do ambiente xBase). Por exemplo, quando voc obrigado a definir a forma do
registro em seu programa, voc no est lidando com um SGBD.
Regra 2: Independncia dos Dados- Quando as aplicaes estiverem realmente imunes a mudanas na
estrutura de armazenamento ou na estratgia de acesso aos dados, podemos dizer que esta regra foi
atingida. Portanto, nenhuma definio dos dados dever estar contida nos programas da aplicao.
Quando voc resolve criar uma nova forma de acesso, um novo ndice, se precisar alterar o cdigo de seu
aplicativo, voc no est lidando com um SGBD.
Regra 3: Abstrao dos Dados- Em um SGBD real fornecida ao usurio somente uma representao
conceitual dos dados, o que no inclui maiores detalhes sobre sua forma de armazenamento real. O
chamado Modelo de Dados um tipo de abstrao utilizada para fornecer esta representao conceitual.
Neste modelo, um esquema das tabelas, seus relacionamentos e suas chaves de acesso exibido ao
usurio, porm nada afirmado sobre a criao dos ndices, ou como sero mantidos, ou qual a relao
existente entre as tabelas que dever ser mantida ntegra. Assim se voc desejar inserir um pedido em um
cliente inexistente e esta entrada no for automaticamente rejeitada, voc no est lidando com um SGBD.
Regra 4: Vises - Um SGBD deve permitir que cada usurio visualize os dados de forma diferente daquela
existente previamente no Banco de Dados. Uma viso consiste de um subconjunto de dados do Banco de
Dados, necessariamente derivados dos existentes no Banco de Dados, porm estes no devero estar
explicitamente armazenados. Portanto, toda vez que voc obrigado a replicar uma estrutura, para fins de
acesso de forma diferenciada por outros aplicativos, voc no est lidando com um SGBD.
Regra 5: Transaes- Um SGBD deve gerenciar completamente a integridade referencial definida em seu
esquema, sem precisar em tempo algum, do auxlio do programa aplicativo. Desta forma exige-se que o
banco de dados tenha ao menos uma instruo que permita a gravao de uma srie modificaes
simultneas e uma instruo capaz de cancelar uma srie de modificaes. Por exemplo, imaginemos que
estejamos cadastrando um pedido para um cliente, que este deseje reservar 5 itens de nosso estoque, que
esto disponveis e portanto so reservados, porm existe um bloqueio financeiro (duplicatas em atraso)
que impede a venda. A transao dever ser desfeita com apenas uma instruo ao Banco de Dados, sem
qualquer modificaes suplementares nos dados. Caso voc se obrigue a corrigir as reservas, atravs de
acessos complementares, voc no est lidando com um SGBD.
Regra 6: Acesso Automtico- Em um GA uma situao tpica o chamado dead-lock, o abrao mortal. Esta
situao indesejvel pode ocorrer toda vez que um usurio travou um registro em uma tabela e seu
prximo passo ser travar um registro em uma tabela relacionada primeira, porm se este registro estiver
previamente travado por outro usurio, o primeiro usurio ficar paralisado, pois, estar esperando o
segundo usurio liberar o registro em uso, para que ento possa trav-lo e prosseguir sua tarefa. Se por
hiptese o segundo usurio necessitar travar o registro travado pelo primeiro usurio (!), afirmamos que
ocorreu um abrao mortal, pois cada usurio travou um registro e precisa travar um outro, justamente o
registro anteriormente travado pelo outro! Imaginemos um caso onde o responsvel 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 atualizao de
pendncias na Tabela de Itens, e para tanto, previamente este segundo usurio travou a Tabela de
Produtos, temos a ocorrncia do abrao mortal. Se a responsabilidade de evitar esta ocorrncia for
responsabilidade da aplicao, voc no est lidando com um SGBD.
Concluso: Um SGBD deve obedecer INTEGRALMENTE as seis regras acima. Caso contrrio, 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 operaes dentro da rede. O Groupware controla a administrao de informaes semiHerbert Lopes da Silva (Consultor CTIS)
Pgina 10/26
31/12/2015

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 aplicao Cliente Servidor gerada como um conjunto de objetos de
comunicao, ou seja, os objetos do cliente se comunicam com os objetos do servidor, mediante um
canal de solicitaes de objetos (ORB Object Request Broker). O Cliente chama um mtodo de um
objeto remoto. O ORB localiza uma instncia dessa classe do servidor de objetos, chama o mtodo
solicitado e envia os resultados ao objeto cliente. Os objetos deste servidor devem oferecer suporte
concorrncia e participao e o ORB se encarrega de reunir todos os elementos necessrios para que
isso acontea.
f)
Servidor Web: So usados como uma forma inteligente de comunicao entre empresas atravs da
Internet. Esta famlia de servidores permite transaes com o acondicionamento de um browser. Este
modelo (extremamente difundido atualmente) integrado por clientes compactos e portteis em
comunicao com grandes servidores. Esta comunicao se d mediante um protocolo chamado HTTP
(Hyper Text Transfer Protocol) o qual define um conjunto simples de ordens, cujos parmetros se
transmitem em cadeias sem a necessidade de dados digitados. No processo de ampliao da Internet,
j existem combinaes com objetos distribudos (Java) a fim de oferecer modalidades mais
interativas com menor trfego de rede.
g) Servidor de Impressoras: Este dispositivo to somente administra as solicitaes de uso de

impressoras na rede, gerenciando requisies, nveis de acesso aos clientes e controle de prioridades
para os jobs no spool de impresso. Est algo em desuso na sua forma dedicada, uma vez que as
modernas redes corporativas facilitam a configurao de qualquer estao cliente simples com uma
impressora conectada para compartilhamento com qualquer outro usurio.
h) Servidor de Aplicao: Neste meio se armazenam e executam as aplicaes de software utilizadas
pelos usurios, evitando assim duplicidade das mesmas, e permitindo melhor controle para a
atualizao de verses e produtos.
i)
Servidor de Respaldo (ou redirecionamento): inovador na arquitetura Cliente Servidor; administra a

execuo 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 ao com base em instrues prvias.
Ao avaliarmos a performance de um ambiente Servidor, devemos levar em considerao os seguintes

tpicos:
Hardware do Computador Servidor. J h alguns anos tm-se acirrado a competio entre os
servidores CISC (vulgarmente chamados de mquinas Intel - ainda que seu processador seja de outro
fabricante) e os RISC (aparentemente poucos conhecem o fato das indstrias Intel tambm fabricarem
processadores desta arquitetura), mas hoje encabeadas 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 customizveis e expansveis, segundo a
necessidade do usurio. As mquinas de arquitetura RISC so construdas para alta performance, e
possuem tambm preos bem superiores aos que custam suas "irms" CISC. Faz-se necessrio um
estudo avaliando custo-benefcio, outra tarefa pouco praticada nas empresas.
A maioria dos gestores de sistemas manuseia uma revista Computter Shopper em busca das mquinas
"ltima palavra" (Leia-se State of Art), despreocupados em realizar uma pr-anlise de pontos
fundamentais como:
A) Por quanto tempo esta aplicao desempenhar suas funes sem que se faa necessrio um
pacote significativo de alteraes sejam elas funcionais ou no volume de dados processados. Por
Pgina 11/26
31/12/2015

quanto tempo nosso parque de clientes permanecer com nmeros aproximadamente parecidos
com os previstos para a data de entrada em produo do sistema. E finalmente, que previso
podemos fazer acerca da continuao da necessidade destes servios. A toda esta gama de
conhecimentos chamamos "Administrao do Ciclo de Vida til do Sistema". Em nossos
levantamentos, nos deparamos com diversos CPDs que nunca haviam sequer escutado a meno
desta expresso. Deram de ombros ao ouvir os conceitos e retrucaram: "Quando o sistema no
serve mais, tiramos de produo 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 espao em disco irei necessitar realmente? A maioria dos
gestores compra o maior disco que encontrar, e justifica tal posio com respostas do tipo "Bom, se
o disco estiver com espao sobrando, sempre podemos colocar mais coisas nele".
C) Praticamente ningum faz um levantamento srio acerca de quantos usurios simultneos estaro
conectados ao seu servidor, e, portanto, encontramos aberraes como a compra de uma mquina
RISC de US$ 80,000 para hospedar um site de e-commerce com produtos to especficos, que
passavam at um dia inteiro sem realizar uma nica venda. Isso representava um aproveitamento
menor que 1% do que a mquina poderia oferecer.
D) O lado oposto tambm praticado. Monta-se uma base de dados com todo o protocolo de um
ministrio inteiro e descobre-se que quase ningum consegue recuperar alguma informao dele,
nos horrios de pico. Razo? Est hospedado num Pentium MMX 166 com 64Mbytes de RAM. "Ah,
mas o disco rgido de 30 Gigabytes, e no estamos usando nem 10% dele!". Nem nos demos ao
trabalho de perguntar qual teria sido o critrio para escolha daquele disco rgido.
O Papel dos Data Bases Administrators
Pouca gente sabe, mas a pessoa com funo de Database Administrator (leia-se DBA) em uma empresa
tem muito mais atribuies que colocar um servidor no ar e estruturar as reas de trabalho de cada
aplicao, ou direitos de acesso aos usurios. Segundo documentao da Oracle, um DBA tem como
deveres (alm do citado acima) todas as tarefas abaixo:
(1) Realizar o planejamento de capacidade requerido para criao e manuteno das bases de dados. O
DBA deve trabalhar bem prximo equipe de administrao dos sistemas, porque os computadores
freqentemente tem aplicaes e/ou ferramentas no - Oracle rodando em si prprios.
(2) Realizar a sintonia permanente das instncias de bancos de dados, ou seja, manter sempre todas as
bases sintonizadas.
(3) Instalar novas verses 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 produo. Aplique-se aos outros
SGBDs no-Oracle.
(4) Controlar migraes de programas, mudanas de bases de dados, mudanas de referncias aos dados
e mudanas de menu durante o perodo de desenvolvimento. Raramente as equipes de desenvolvimento
envolvem o DBA em alguma outra fase que no a definio da base no servidor real, j para entrada em
produo.
(5) Executar reorganizaes das bases de dados, segundo se faa necessrio, para manter uma boa
performance e assegurar o mximo rendimento das mesmas. Em nenhum dos sistemas que
acompanhamos percebemos este tipo de preocupao.
(6) Estabelecer padres para o desenvolvimento da aplicao e seu cdigo, com o objetivo de assegurar a
integridade, segurana e performance dos bancos. O DBA far revises freqentes no desenvolvimento e
no cdigo para assegurar-se de que os padres estabelecidos esto sendo seguidos. NUNCA vimos isso
acontecer nos sistemas avaliados e/ou acompanhados.
(7) Avaliar verses 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 instalaes estejam
funcionando com o que existir de mais apropriado. O Planejamento tambm feito pelo DBA, em conjunto
Pgina 12/26
31/12/2015

com os desenvolvedores de aplicao e administradores do sistema, a fim de que exista a certeza de que
quaisquer novos produtos ou verses advindas de upgrades sejam implantadas com o mnimo de impacto.
A expresso "IMPACTO" parece no constar do dicionrio de quase a totalidade dos desenvolvedores. Isso
explica em boa parte a incidncia de sistemas que "comearam to bem, mas acabaram se tornando quase
inteis, tal a lentido com que rodam hoje em dia".
(8) Suprir de suporte tcnico todos os times de desenvolvimento de aplicaes. Isto usualmente feito
atravs de um help desk. O DBA normalmente o contato entre os usurios 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 restries e limitaes no uso do banco de dados, para assegurar a integridade
do mesmo. Esta deciso freqentemente tomada pelo meio poltico e no pelo tcnico.
(10) Administrar TODOS os objetos do banco de dados, incluindo tabelas, clusters, ndices, consultas,
seqncias, pacotes e procedimentos.
(11) Dar suporte a todas as mudanas aplicadas aos objetos de base de dados, fazendo uma anlise de
impacto destas mudanas. 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, aplicaes e ferramentas de
desenvolvimento. Uma vez escolhida a plataforma de desenvolvimento, tomado quase como um insulto
qualquer crtica a ela. E, pior do que isso, forma-se dentro da empresa verdadeiros cls tecnolgicos,
como, por exemplo, os defensores do Oracle e os do SQL-Server. Uma reunio 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 argumentao tcnica ou lgica. Nestes casos, normalmente quem d
a deciso final o chefe do projeto (conhecendo ou no as plataformas propostas).
Pgina 13/26
31/12/2015

CAPTULO IV - O MIDDLEWARE
Para que os clientes e servidores possam comunicar-se, necessria uma estrutura lgica que proporcione
os mecanismos bsicos de direcionamento e transporte; a esta estrutura chamamos Middleware, expresso
usada para encampar todo o software distribudo necessrio ao suporte de interaes entre clientes e
servidores.
O Middleware um mdulo intermedirio que no pertence nem s instalaes do servidor, nem s
interfaces com o usurio e nem lgica da aplicao que executada no cliente. Tampouco devemos
confundi-la com a rede fsica em si (cabeamento, sinais de rdio ou infravermelho, hubs, switches, etc...).
Entendamos o Middleware como uma interface lgica padro, a qual gerencia os servios de rede. Suas
principais atribuies so:
Tornar independentes as duas entidades: O cliente e o servidor no necessitam saber comunicar-se
entre eles, apenas devem saber como faz-lo com o Middleware.
Traduzir as informaes de uma aplicao e pass-la a uma outra: aceita consultas e dados,
recuperando-os da aplicao cliente, os transmite e envia a resposta de retorno. Tambm gera os
cdigos de erro, em caso de algum problema nestas tarefas ocorrer.
Controlar as comunicaes: d rede as caractersticas adequadas de desempenho, confiabilidade,
transparncia e administrao.
Existem dois tipos de Middleware:
1.
2.
O Middleware geral a essncia da maioria das interaes entre cliente e servidor, incluindo as pilhas
de comunicao, diretrios distribudos, servios de autenticao, horrios de funcionamento da rede,
chamadas a procedimentos remotos (RPC's) e servios em paralelo (multi-tarefas). Inclui tambm as
extenses do sistema operacional de redes, como os servios distribudos de arquivos e impresso,
bem como produtos de Middleware orientados a mensagens (MOM - Messages Oriented Middleware).
O Middleware de servios especficos necessrio para suportar um tipo particular de servios Cliente
- Servidor; de forma que exista um middleware especfico 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 no s flexvel e segura como tambm
protege os sistemas de engenharia reversa (por exemplo, os mdulos escritos em ASP no so visveis
para os clientes, nem quaisquer arquivos aos quais no queiramos dar visibilidade para qualquer pessoa.)
O mesmo permite manejar diferentes ambientes de computao.
Pgina 14/26
31/12/2015

CAPTULO IV - PENSANDO EM SOLUES E METODOLOGIAS.
Aps toda esta explanao sobre papis dos diversos elementos que vm a compor um ambiente Cliente Servidor, passemos s tcnicas para avaliao de performance em cada segmento apresentado e para as
providncias cabveis, 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 necessrias quaisquer mudanas, primeiramente por no estar sempre ao alcance do suporte
avaliar todo o parque cliente, e em segundo por ser freqentemente operada por usurios 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 noo bsica acerca da verso
do Windows que temos em nosso PC e quais so os requisitos mnimos - leia-se, a plataforma de
hardware recomendada como "desejvel" e nunca a "mnima") de memria e de clock de
processador para uma utilizao saudvel. Recomendo fortemente o aumento de memria RAM,
como principal estratgia para melhoria no desempenho do PC. Felizmente, o problema das
limitaes na memria-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 verso do Windows. E se sua mquina algo abaixo de Pentium 90
com 16 Megabytes de memria, pouco poderemos fazer sem um up-grade de hardware tambm.
Consulte tcnicos especializados de confiana, no caso, para obter uma tabela de hardware
recomendado para as diversas verses de Windows e aplicaes que rodem sob o mesmo. Toda a
famlia NT/2000 mais pesada que seus "primos" 9X, e portanto, mais recomendveis para
sistema operacional de mquinas clientes, a no ser por outras razes extras (principalmente
segurana). No recomendamos o Windows-ME (Millenium) para nenhuma configurao de
hardware, por causa de uma srie de limitaes do mesmo em ambiente de rede e na interao
com dispositivos perifricos, a no ser que seu PC tenha como nicas finalidades escutar msica e
lazer com jogos.
2. Tem havido de algum tempo para c um aumento considervel de aperfeioamentos na tecnologia
IDE de acesso a discos rgidos, zip-drives, cd-roms, etc..., o que me leva a no recomendar o uso
de Discos Rgidos com tecnologia SCSI para mquinas clientes. Ao invs de gastar com um disco
SCSI e respectiva controladora, coloque 4 vezes mais memria na sua mquina e ainda vai gastar
menos.
3. Se estiver considerando uma rede de mdia para grande (acima de 50 clientes), no 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 coliso, o que fora o envio e recebimento
dos pacotes a se repetir (algumas ocasies por dezenas de vezes). Recomendo (aps muitos
benchmarks em redes grandes, e em provedores de acesso Internet) a marca 3-Com, ainda que
ela custe bem mais caro que suas irms menos famosas. Pela simples substituio de algumas
dezenas de placas de rede (de placas no 3-Com para placas 3-Com) j conseguimos quase dobrar
o desempenho da mesma rede.
4. Para testar de forma primria, algo como uma triagem inicial para deteco das "tartarugas da
rede", h pacotes de software de baixo custo, os quais testam no s a integridade do hardware,
como seu desempenho. Fizemos algumas avaliaes usando o Burnin-Test e PassMark, da
Passmark Software (www.passmark.com) e os achamos bastante satisfatrios, seja por serem
pequenos (o que evita over-head de arquivos), compactos, fceis de operar, e alm de tudo
baratos. H naturalmente muitos outros, mas este trabalho um esforo inicial, como mencionado
na introduo. A prxima reviso dever estar mais rica de produtos e suas avaliaes.
5. At aqui consideramos mquinas estveis, ou seja, PCs sem problema crnico de travamento. Se
o seu anda travando, melhor nem consider-lo para avaliao de desempenho, porque os PCs
normalmente "travam" quando alguns servios essenciais para o interfaceamento (envio das
imagens para a placa de vdeo e entradas de mouse e teclado) entre a mquina e o usurio falham.
Se estes servios esto falhando por defeitos no hardware, isso quer dizer que h malHerbert Lopes da Silva (Consultor CTIS)
Pgina 15/26
31/12/2015

funcionamento de outros servios, alm dos citados essenciais. E alguns destes servios podem
estar cuidando do trfego de informaes, deteco de mquinas na rede, gravao dos dados
solicitados e envio para a placa de vdeo das consultas solicitadas de forma precria - e portanto,
passvel de degradao no desempenho - mesmo que a mquina ainda no tenha travado.
6. As placas aceleradoras de vdeo podem proporcionar alguma melhoria na performance... mas
apenas em casos onde a estao cliente est fazendo uso de grficos "pesados", o que no
corresponde grande maioria dos casos. Normalmente nossas clientes precisam principalmente
lidar com dados em formato texto, e assim, as video-acellerators no daro grande contribuio.
Um mnimo de 4Megabytes de Ram de vdeo j atende quase todos os casos satisfatoriamente.
Software de Base do Computador Cliente - O primeiro problema o desconhecimento. Muitos usurios

(sem qualquer formao tcnica acerca de tais assuntos) fazem a instalao do Windows ou Linux sem
sequer entender qual a verso mais apropriada para o Hardware de que ele dispe. Afora portanto as
aberraes bvias deste tipo (Como pessoas instalando Windows 2000 Advanced Server em Pentiums
100 com 24 Megabytes de memria RAM) ainda interessante consultar um tcnico qualificado sobre
esse assunto, e porque no vou tentar esgotar essa matria. Ela extensa e evolui quase
diariamente, com novos hardwares e novas verses de software. Mesmo assim, podemos mencionar
que:
1. A maioria dos clientes est funcionando em plataformas Microsoft Windows (seja l qual for a
verso) e portanto sofrem de um mal crnico, 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 aplicao RegEdit, para maior riqueza de detalhes). Tais
componentes tm 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 razo, se instalamos algum pacote de software e depois o desinstalamos, o Registry no
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 no obteremos o efeito desejado para
aquela pgina... e isso tambm 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 operao. Que fazer ento ? Reinstalar o Windows seja por cima da mesma verso ou
fazendo up-grade, nada resolve. Isto porque o registry mantido, com a finalidade de no termos
que reinstalar todos os pacotes extra-Windows - Office, Real Player, Visual Basic, Dicionrio
Aurlio, SQL-Server Client, Oracle Client, Netscape, Delphi, ou seja l o que estivermos usando
em nossa mquina. Uma das opes deletar as pastas com o sistema operacional (Ateno!
NUNCA necessrio formatar o Disco Rgido por causa disso!), mas isso nos fora a reinstalar
tudo que estivera na mesma, incluindo o Windows, o qual vir sem qualquer configurao anterior,
inclusive. No h outro caminho? Felizmente, de poucos anos para c foram desenvolvidos
Registry Cleaners, pequenos pacotes de software que lem todo o Registry e se oferecem para
limpar o mesmo de tudo que no 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 vrus vigiando as operaes
de entrada na memria RAM e no disco) podem ser muito prticos e dar at algum descanso ao
usurio, por sua atividade contnua - mas consomem recursos de mquina preciosos, podendo
estar entre o time dos "suspeitos" de lentido na mquina. Desativar a funo Shield e ordenar, por
exemplo, a execuo do anti-virus toda vez que se inicializar o PC praticamente nos livra de
ataques virticos, e em compensao aumenta nossa velocidade de processamento. mais
importante manter a verso do anti-virus atualizada do que deix-la residente na memria, vigiando
tudo que entra na memria e no disco. Isso inclui tambm uma tecnologia de deteco de escrita
direta em disco nas reas FAT, Partio e Diretrio, o que nos faculta podermos confirmar qualquer
dessas operaes - e tambm nos faculta esperarmos at o dobro do tempo por uma resposta,
tamanha a quantidade de recursos que esse dispositivo consome. E, naturalmente, jamais nos
esqueamos do inestimvel backup peridico e organizado de todas as nossas informaes
importantes.
3. A configurao do Setup de baixo nvel do computador nem sempre tarefa simples. Confie-a a
Pgina 16/26
31/12/2015

algum experiente e se possvel avalie o desempenho da mquina antes e depois dos ajustes no
Setup de baixo nvel.
4. No faa parties muito grandes! Acima de 10 Gigabytes, as parties comeam a consumir
muitos recursos de mquina para serem gerenciadas. Em um HD de 40 Gbytes, por exemplo,
veremos um aumento significativo de velocidade se dividirmos o disco em 4 parties de 10G ao
invs de uma nica de 40Gbytes.
5. Desative os recursos de Power-Saving (economia de energia - dispositivos que desligam perifricos
de funes da prpria placa-me, se a mesma passa algum tempo ociosa). Alm de o PC perder
tempo, reativando o funcionamento do perifrico, ainda corre o risco de aumentar a memria j
utilizada, com outras instncias do software de gerenciamento do dispositivo.
Software dos Aplicativos do Computador Cliente - Temos problemas estruturais envolvendo a mo de

obra para desenvolvimento a qual via de regra escassa, os cronogramas dificilmente so definidos
com acuracidade, devido a presses polticas e falta de experincia especfica para tanto. Muitas vezes
assisti a reunies onde alguns tcnicos apresentavam uma proposta para a construo de um sistema,
e seu chefe reduzia o prazo em digamos 30%, sem que a equipe tivesse direito rplica. Quando
interpelada a respeito de tal imprudncia, 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 preocupao clara
das mesmas chefias quanto ao aspecto de que os tcnicos desenvolvedores estivessem sendo por
demais otimistas e para tanto se fizesse necessria uma reserva de segurana, digamos de 20% do
prazo oferecido. As alegaes eram sempre as mesmas: O Diretor no vai aceitar que se faa em tanto
tempo, o usurio fulano disse que se o sistema no entrar em produo at maro prximo, de nada
lhe servir mais, ou at um desdenhoso "No acredito que vocs levem tanto tempo para realizar uma
tarefa to simples". Consequentemente, mesmo hoje, os prazos vivem sendo redefinidos, recolocando
continuamente cada projeto no status de "Incndio a ser apagado". Ora, com tais ambientes e
situaes, no deve nos causar estranheza que a entrega de um projeto seja semelhante a tirar um
horrvel fardo das costas de vrias pessoas - elas querem se livrar o mais depressa possvel do
problema. E talvez por estes fatores - menos do que por falta de conhecimento a respeito da
necessidade das revises - que muitos sistemas acabam entrando em produo com uma estrutura tal
que seria reprovada pelo professor mais benevolente de qualquer instituio de ensino universitrio.
Mas vamos aos problemas em si:
1. Todo o modelo e cdigo devem ser revisados antes que o sistema entre em produo . Para
tanto, dispomos de ferramentas de apoio bem elaboradas, aplicveis tanto no cdigo das
procedures e funes que ficam rodando no cliente quanto nas stored procedures que permanecem
no servidor SQL-Server, por exemplo - a maioria de baixo custo e fcil utilizao. Estas
ferramentas no s nos proporcionam uma documentao melhor estruturada como nos apontam
as parte do cdigo que esto escritas, mas nunca so chamadas. Tome-se como exemplo o
VBCode Print e o SQL7-Print ambas da Joginder Nahil Software (http://www.jnsoftware.com). Verses de demonstrao esto disponveis 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
verses full, para colocao 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
inteno aqui clara: Muitas tabelas so 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 no fazem parte da documentao, acaba se optando por no
mexer nelas (imaginem se a aplicao parasse de funcionar pela excluso de alguma coisa cuja
funo no temos certeza). A filosofia de construo 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 princpio, j no justifica termos um punhado de
dados redundantes com o objetivo de "otimizar o tempo na execuo de alguns processos".
Normalize seu banco ! Nada de tabelas sem chave primria, ou tabelas soltas sem
relacionamentos com outras apenas porque "daria muito trabalho verificar a integridade das
mesmas e depois, so tabelas pouco usadas no sistema". Se existem tabelas "soltas" tem que
haver uma boa razo para isso, e estas razes devem constar da documentao do sistema.
Desenvolvedores Oracle, no se esqueam 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. Estabeleam um padro para a escrita de queries e
Pgina 17/26
31/12/2015

obedeam ao mesmo, antes at da reviso final para colocao em produo. Um sistema
eficiente neste processo de reviso colocar um profissional que fez uma parte do sistema para
revisar outra parte feita por um colega de equipe, e vice-versa. Isso no consome tempo adicional
para entendimento dos processos como um todo e ao mesmo tempo facilita uma mente nova
descobrir problemas onde o criador no os podia enxergar, devido ao fenmeno de limitao
humana conhecido: Tendemos a passar por coisas que fizemos erradas repetidamente, sem nos
apercebermos do erro.
2. Mantenha a sua documentao do sistema atualizada. Certa feita, ao observar numa reunio
que a documentao estava defasada com relao 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
documentao". Sabemos da existncia de profissionais em todos os segmentos que tentam se
assenhorear dos produtos que desenvolvem, deixando "caixas-pretas" e partes do sistema sem
documentao - uma tentativa clara de se tornarem insubstituveis. Dilbert afirmou que " jamais
devemos trabalhar no sentido de sermos insubstituveis, pois quem no pode ser substitudo,
tambm no pode ser promovido.". E sabemos tambm que muitas vezes o prazo anda to exguo
que a equipe acaba por negligenciar algumas tarefas, especialmente aquelas que no sero
testadas pelos usurios. Isso gera sistemas de difcil manuteno, aumentando a dificuldade em
avaliarmos seu desempenho e quando no, sua manuteno para correes no de funcionamento
ou estrutura, mas melhoria de performance.
3. Faa ferramentas para cronometragem de processos. Gere pequenas ferramentas para
cronometragem dos tempos de resposta que considere crticos e coloque-os para avaliar o
desempenho nas tarefas sabidamente demoradas. Algumas estaro disponveis para uso, com toda
a documentao atinente na seo 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 distribuio de dados, a distribuio de processos, a
otimizao de algumas rotinas ou a mudana da ocasio ou periodicidade com que so disparadas.
4. Busque a excelncia. No se conforme em abrir mo das recomendaes acima, se seu sistema
j est com desempenho satisfatrio, tendo em mente que quanto mais experincia voc tiver,
tanto mais complexas sero as tarefas que lhe sero passadas. Busque a qualidade total desde o
incio de sua carreira, ainda que voc seja um programador jnior com menos de um ano de
experincia. E se tiver que entregar alguma coisa sem a qualidade mnima que voc pretendia,
deixe isso claro em algum lugar da documentao (na seo "Sugestes para verses futuras", por
exemplo).
5. Busque a unidade com toda a equipe. Reunies e mais reunies so feitas para tomada de
algumas decises. No alegue estar muito ocupado ou no se tratar de uma discusso especfica
acerca da rea que est sob sua responsabilidade. Faa sempre a ponderao: Isto pertence ao
projeto X, no qual estou trabalhando? Ento, tenho interesse nesta reunio! Em mais de uma
ocasio, apenas assistir a uma reunio 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 no devem participar dos dilogos dos programadores, estes no devem se envolver
com as discusses dos analistas e projetistas, e, por fim, que estes ltimos no devem participar
dos planejamentos da chefia. Minha sugesto sempre ser que as reunies sejam o mais curtas
possvel (muitas delas com 30 minutos ou menos) e convocadas para tratar de assuntos
especficos. Sugestes tcnicas mais longas devem ser passadas por escrito, bem como
reclamaes. E esta documentao (pouco convencional, mas extremamente til) deve ficar em
um local de fcil acesso por todos os envolvidos no projeto. As reunies devem ser moderadas por
algum com experincia 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
no somente troca de tecnologia (com conseqentes aperfeioamentos dos profissionais) como um
clima de reviso contnua e maior camaradagem entre os participantes. Tudo isso nos encaminha
gerao de sistemas com maior qualidade, estabilidade e desempenho.
Pgina 18/26
31/12/2015

6. Distribua bem seus dados. Se estiver construindo aplicaes para Intranet ou redes locais,
lembre-se que a melhor estratgia para evitar o congestionamento do trfego na rede e a
sobrecarga de requisies aos servidores ainda colocar os dados que sofram pouca ou nenhuma
alterao ao longo do ciclo de vida til do sistema nas mquinas cliente. Por mais velozes que
sejam sua rede e seus servidores, jamais podero competir com o acesso local a um disco rgido.
H excelente literatura acerca da distribuio de dados, e no creio ser o caso de explan-las neste
trabalho.
7. Evite as aplicaes pseudo - 3 camadas. A construo Three-Thier perde significativamente sua
eficincia, quando colocamos numa mesma mquina as tarefas de servidor de dados e servidor de
aplicaes. Use mquinas distintas, sempre que possvel. E em caso de ainda no atender s
especificaes mnimas de desempenho, use mquinas exclusivas para sua aplicao. Quando
compartilhamos no mesmo hardware de servidor diversas aplicaes, devemos ter em mente que
como se dividssemos os recursos por 2, 3, 4 ou mais (dependendo de quantas aplicaes
compartilhem o mesmo hardware). Embora estes nmeros no sejam nem exatos nem linearmente
proporcionais, o princpio continua vlido.
8. Esteja atento s novas verses de servidores de bases de dados e ferramentas. Uma forma
prtica e pouco dispendiosa de acompanhar as evolues tecnolgicas ler com assiduidade as
revistas e artigos especializados. A Internet rica em tais assuntos, e sempre se pode assinar
algum peridico (journal) ou fazer parte de listas de discusso de profissionais no assunto. Na
verdade a lio encerrada aqui : No tente fazer tudo sozinho, e muito menos partindo do zero!
D mais importncia aos comentrios de comunidades de profissionais do que s jactncias das
software houses que anunciam seus produtos. O paradigma da "conversa de vendedor" tambm
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
confiana j realizou, tanto melhor! Por que haveramos de reinventar a roda?
9. Os cuidados com a construo 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 no conseguiu entender sua importncia. um profissional VITAL
para o bom andamento no s na fase de projeto como na de produo para qualquer sistema de
porte significativo. Coloquei em algumas pginas atrs diversos atributos que mereciam os
cuidados do DBA, mas a grande verdade que a maioria das organizaes sequer tem um
funcionrio com esse perfil. Em no havendo mo de obra especializada, a soluo alocar quem
se disponha (s vezes com parcos recursos e domnio da tecnologia em foco) para realizar o
mnimo 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 dirio. 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 no estar em produo porm acessvel, no caso de precisarmos "importar" alguns
itens para o banco de produo. Mecanismos de software podem ser criados para otimizao
peridica dos dados inteis. 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 distribuio de dados, mas eu a reputo como uma matria nova e
distinta, visto todos os dados distribudos estarem em franca produo, e serem vitais para o
funcionamento contnuo do sistema.
Pgina 19/26
31/12/2015

Segmento Servidor:
Listamos acima grande variedade de tipos de servidores, e uma prxima reviso no presente trabalho
certamente cuidaria de outros membros da famlia; para esta primeira verso porm, vamos nos limitar aos
servidores de dados convencionais, enfocando apenas os principais tpicos que fazem parte de um SGBD.
Hardware do Computador Servidor: Pouca coisa evolui to rapidamente quando o hardware hoje
em dia, e seria impossvel cobrir todas as novidades; vamos pois falar de algumas tecnologias:
1. Os discos rgidos alcanaram velocidades inacreditveis, se pensssemos em termos de cinco

anos atrs, alm de grandes capacidades (80 GigaBytes, em fevereiro de 2002) no mesmo espao
em que colocvamos uma leitora de diskettes convencionais de 3 1/2 polegadas. Alm do mais,
qualquer placa-me profissional vem com memria cache de 1Megabytes ou mais. Tais
caractersticas aliadas ao Ultra-DMA tem contribudo para o surgimento de uma gerao de
tecnologia de discos capaz de suplantar os "packs" do grande porte em velocidade de acesso. A
tecnologia SCSI permite tambm multi-session, o que facilita em muito o acesso de vrios usurios
ao mesmo disco, lendo e gravando simultaneamente. Porm, 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, tm feito uso desta
arquitetura. Num provedor por ns visitado, o contador de acessos mostrava mais de 1300 usurios
logados no mesmo banco, e o monitor de sistema indicava que mal estavam sendo usados 20% da
capacidade mxima do mesmo.
2. As placas-me tambm no ficaram atrs, seja por suportarem processadores cada vez mais
sofisticados, algumas delas com vrios processadores, como por virem com memria cache
escalonvel (vimos uma com 8 Megabytes de cache L2). A memria RAM mxima alocvel nestas
mother-boards de h muito superou a casa dos 1GigaBytes e percebendo essa tendncia, os
desenvolvedores de SGBDs investiram em bancos que trabalham quase o tempo todo com a
memria eletrnica (o banco Oracle, por excelncia), se permitindo fazer alteraes nos discos
rgidos apenas quando convm ao SGBD. A tecnologia RISC oferece tambm performances
inacreditveis, ainda que no permita o funcionamento das plataformas servidoras Windows, que
rodam exclusivamente nas mquinas CISC (comumente chamadas de mquinas Intel, ainda que a
Intel tenha fabricado processadores RISC tambm). A arquitetura RISC sob os sistemas
operacionais Unix permite ainda a replicao de discos - ou mirroring (espelhamento) executada
fisicamente e praticamente sem degradao de desempenho.
O que poderamos concluir que no existe um "Hardware Ideal" para nenhum projeto, como uma receita
pr-definida. O que necessrio fazermos um planejamento confivel de qual ser a demanda de
acessos a esses servidores, e com isso definirmos uma mquina (ou mais) de forma a sermos atendidos.
Recentemente, os provedores de acesso Internet comearam a mensurar seus custos de hospedagem
no mais apenas pelo volume de dados residente, mas tambm pelo trfego e nmero de usurios logados
simultaneamente no domnio. Veja por exemplo, as tabelas de preos da Telebraslia
(www.brturbo.com).
Como correo de problemas no hardware, podemos apontar:
a) Hardware com pouca memria, ou simplesmente com muita coisa carregada na memria, o que
comea a causar "travamentos" nos horrios de pico de acessos. Com alguns pacotes de software
estatsticos podemos facilmente acompanhar o comportamento do servidor.
b) Disco rgido muito cheio. Quando estoura a capacidade de memria RAM, os sistemas operacionais
realizam um processo chamado de disk-swapping, que consiste em enxergar parte do disco como
extenso da RAM. Ora, se o disco estiver trabalhando muito cheio, a rea para swapping se torna
restrita, e isso pode causar no s demoras homricas como at travamentos no sistema.
c) Em servidores NT, registry muito carregado ou simplesmente mal dimensionado. No caso, podemos
alocar mais espao para o registry, se tudo que est carregado nele necessrio, no Painel de
Controle/ Sistema/Avanado/Opes de Desempenho e/ou utilizarmos um Registry Cleaner, de forma
anloga que usaramos numa estao cliente.
d) Tambm em servidores NT adequado realizarmos a desfragmentao dos discos rgidos, 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:
Pgina 20/26
31/12/2015

1. As arquiteturas centralizadas e clusterizadas:
Arquitetura de Bases de Dados: Centralizados X Clusterizados (Agrupados).

VISO GERAL EXECUTIVA:
O Mercado de Bases de Dados paralelas de m qualidade, com propagandas competitivas, onde cada
vendedor tenta persuadir os clientes acerca dos benefcios de sua prpria arquitetura. O comprador precisa
fazer sua escolha da plataforma de software em regime de misso crtica, enquanto perdido numa pilha de
relatrios de benchmarking, contrastando revises de anlise e posicionamentos favorveis de usurios.
Este documento o resultado de uma avaliao tcnica 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). Tambm explanamos como
interpretar e utilizar resultados de avaliao de desempenho, seja dos vendedores de hardware, seja dos
de Bases de Dados, e como vrias caractersticas nas Bases de Dados podem ser relevantes, nas diversas
situaes do usurio real.
Este relatrio no abrange as bases de dados com tecnologia de disco nada-compartilhado em cluster. Os
Bancos centralizados constituem um passo, atravs dos clusters nada-compartilhados, mas na verdade no
passam de Bases de Dados Distribudas. Desta forma, uma Base de Dados nada-compartilhada
clusterizada, como a IBM DB2 7.2 uma Base de Dados simples, com um dicionrio de dados simples, e
no uma coleo de Bases de Dados acopladas independentemente. Clusters nada-compartilhados so
comparados com clusters em disco compartilhado, em outro boletim emitido pela Oracle: Comparaes
Tcnicas da Oracle Real Application Clusters contra o IBM DB2 UDB, tambm disponvel no endereo
http://www.oracle.com
Pgina 21/26
31/12/2015

INTRODUO:
O que uma base de dados centralizada ?
Uma base de dados centralizada a unificao lgica de bases de dados distintas rodando em servidores
independentes, sem compartilhamento de recursos (incluindo disco) e conectados por uma Rede.
O dado particionado horizontalmente atravs de cada servidor participante. Tanto para o DBA quanto
para o Desenvolvedor de Aplicao, h uma distino clara entre o que so dados "locais" e dados
"remotos" (princpio da distribuio de dados tradicional). As aplicaes vem uma consulta lgica simples
de dados mediante consultas UNION ALL e SQL distribudo - a Microsoft chama isto de Tecnologia de
Consultas Particionadas Distribudas (Distributed Partitioned Views - DPVs). O DPV construdo de forma
diferente para cada n, pois ele precisa considerar explicitamente quais lotes de dados so locais e quais
so remotos.
Figura 1 - Arquitetura de Bases de Dados Centralizadas.

Por exemplo, eis um resumo de como voc particionaria seus usurios atravs de mltiplos
servidores em tecnologia Microsoft SQL-Server (O cdigo foi obtido do endereo
http://msdn.microsoft.com/library/en-us/createdb/cm_8_des_06_17zr.asp )
1. Primeiro, crie parties independentes para cada n:
Pgina 22/26
31/12/2015
2. Em seguida, defina as informaes acerca da conectividade ("linked server definitios") e as opes de

otimizao para as queries de cada servidor participante.
3. Finalmente, crie uma DPV para cada n. Eis o cdigo para o servidor I
Observe-se como as instrues de SELECT, referenciando a consulta Customers, especificam uma

condio de busca sobre a coluna da partio (CustomerID), o otimizador de query usa as definies de
constries CHECK para determinar qual membro da tabela contm as linhas. Atravs de algumas
constries, 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 no possuem um dicionrio de dados global, e assim o otimizador precisa acessar todos os
ns para determinar o plano de execuo de uma query.
Portanto, uma Base de Dados Centralizada uma Base de Dados Distribuda, revestida pela tecnologia
DPV.
Os DPVs estendem as consultas UNION ALL por servidores distribudos, com base nas caractersticas de
uma chave de particionamento.
Pgina 23/26
31/12/2015

O que a Arquitetura de Bases de Dados com Disco Compartilhado em
Clusters ?
Um cluster (cacho, ramalhete, grupo) consiste de servidores (normalmente SMPs), uma
interconexo de cluster e um subsistema de disco compartilhado. As arquiteturas de Bases de
Dados em discos compartilhados rodam em um hardware tambm agrupado (clusterizado) o que
d a cada servidor participante igual acesso a todos os discos, por mais que os servidores no
compartilhem sua memria RAM. A maioria dos vendedores de hardware oferecem discos
compartilhados em clusters hoje em dia.
Figura 2 - Configurao 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 instncia de Base de Dados roda em qualquer n do cluster. As transaes sendo
executadas em uma instncia podem ler ou escrever em qualquer parte da Base de Dados, no
existe uma noo de dados "pertencentes" a um n. O desempenho do sistema baseado na
utilizao efetiva de uma interconexo rpida entre os servidores da Base de Dados, como a
Arquitetura de Interface Virtual - VIA (Virtual Interface Architeture), entre os ns 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 faa
necessrio o particionamento de dados ou aplicaes.
O Cache Fusion trabalha por:
Utilizao dos caches coletivos da Base de Dados, considerando cada n no sistema para
satisfazer as requisies de dados para a aplicao em qualquer n - "fundindo"
efetivamente os caches de todos os ns no cluster interno de um cache.
Removendo as operaes em disco (lentas) do caminho crtico para uma sincronizao de
dados entre os ns - se dois ns operam no mesmo bloco de dados, sincronizam as
informaes em seus caches e no atravs de gravao no disco.
Reduo drstica do nmero de mensagens requeridas, por causa da tecnologia de
sincronizao entre os ns.
Tirando proveito dos protocolos de interconexo de clusters, dotados de baixa latncia, tanto
para mensagens atravs da Base de Dados como para o trfego de dados entre os caches.
Pgina 24/26
31/12/2015

As aplicaes vem a mesma interface de programao tanto na verso Oracle SMP como no RAC, uma
vez que a tecnologia Cache Fusion torna a arquitetura de clusters transparente para a aplicao.
A Microsoft tambm abraou a tecnologia de clusterizao, embora com algumas diferenas (parte imposta
pelo Hardware CISC, parte pelas caractersticas da arquitetura NT). O SQL-Server 2000 suporta alguns
princpios interessantes de redundncia (ou seja, dotar uma Base de Dados de dispositivos que evitem a
sada do ar de uma aplicao, em caso de falha de um servidor, substituindo em tempo real os servios do
servidor com problemas pelo redirecionamento dos mesmos servios para um outro servidor.
Vamos enfatizar a clusterizao prova de falhas, a qual diferente da clusterizao de balanceamento de
carga. Em um cluster de servidores onde se implementou a tecnologia de balanceamento de cargas, as
requisies de processamento so distribudas atravs dos servidores. Os diferentes servidores
compartilham a carga do processamento, porm no compartilham recursos, como um array de discos ou
memria RAM.
Se um dos servidores acusa uma falha ou mesmo sai do ar, a carga de processamento pode ser
simplesmente redistribuda entre os ns "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 ns do cluster
requerido para implementar a redundncia em aplicaes estabelecidas tais quais as que fornecem
servios de mensagens e acesso s Base de Dados.
Na arquitetura de clusters prova de falhas, os recursos so compartilhados entre os servidores. Devido a
este compartilhamento de recursos, hoje em dia muito comum em arrays de disco, a maioria de solues
de clusterizao 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 partio de disco diferente em um array de discos. Nesta
arquitetura, apenas um servidor pode acessar um recurso ou partio particular de cada vez. No caso de
uma falha, outro servidor sobrevivente no cluster assume os recursos do servidor falhado e assim, todas as
requisies subsequentes dos clientes so redirecionadas para este servidor. A estrutura do Windows 2000
(servios de cluster) baseada neste modelo de Nada-Compartilhado. J no modelo de DiscoCompartilhado, muitos servidores em um cluster podem acessar simultaneamente um disco compartilhado.
A sincronizao lgica requerida para manter a integridade de dados neste modelo muito complexa, e
no utilizada nos servios 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 clusterizao, mas no modelo Nada-Compartilhado. Funcionam tambm
com arrays de discos, mas com tica bem mais simplificada se comparada arquitetura Unix-Oracle, a
qual emprega algoritmos sofisticados para sincronizao dos dados, obtendo assim performances bem
superiores, ainda que oferea pouca ou nenhuma vantagem em matria de integridade dos mesmos dados.
Os arrays de discos atingem desempenhos invejveis 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 situaes (o LINUX sempre o foi,
e ultimamente, o Solaris tem usado esta estratgia em diversos casos) demandam uma mo de obra
escassa no mercado, mais dispendiosa. As interfaces para desenvolvimento tambm continuam muito
pobres no ambiente UNIX, o que acarreta prazos bem mais dilatados, em qualquer processo de
desenvolvimento. A concluso provvel de todos quantos esto avaliando as duas vertentes que no
existe uma "plataforma ideal". Cada uma tem seus prs e contras, vantagens e desvantagens, dependendo
do projeto que se pretende desenvolver, o pblico-alvo de clientes, recursos financeiros, tamanho do banco
de dados e volume de acessos, trfego de dados, etc.
1. Mesmo sob o aspecto de que bastante subjetivo afirmar que um sistema est "rpido" ou "lento",
cabe a ns como empresa montarmos uma base de dados contendo informaes comparativas sem compararmos nosso servidor a algo que j exista, como afirmar se ele est adequado ou no?
Embora algumas medidas possam ser feitas simplesmente a nvel 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 anlise pura do servidor, ou seja,
no dependermos de outro segmento para nossas medies. A Oracle j fornece alguns medidores
estatsticos, na aquisio de seus SGBDs, mas eu indicaria fortemente alguns produtos de terceiros
para tal tarefa (in-off, os profissionais da Oracle tambm o fariam, mas intil pretendermos uma
declarao oficial no sentido). Recomendo pois (alm dos mencionados acima, para mquinas
clientes, os quais nos do ao menos a certeza de integridade da mquina) 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 avaliao de desempenho do banco. Eles nos do um espelho completo de
tudo que est acontecendo com o servidor, vale a pena dar uma olhada na verso trial (pode-se
Pgina 25/26
31/12/2015
2.
3.
4.
5.
fazer download no mesmo site). Alm da avaliao de desempenho, a famlia Spotlight ainda nos
ajuda a na sintonia da Base de Dados, realizando uma pr-sintonia e nos apontando que variveis
e/ou parmetros esto inadequados ao funcionamento do SGBD.
Estejamos atentos para o lanamento de service-packs dos ambientes operacionais. Embora
tenhamos que admitir que a maioria das correes de bugs se localiza no tratamento do ambiente
grfico (o que certamente faz com que o Unix seja mais veloz e menos sujeito aos travamentos
que as mquinas sob Windows), fato tambm que algumas correes e melhorias so feitas no
prprio Kernel do Windows e mesmo nas bibliotecas do DCOM.
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 mquinas Unix ! Em uma mquina com Windows NTServer, em um benchmark sumrio com queries de mdio porte, ele gastou em torno de 40 vezes
mais tempo (no estou falando de 40% mais, so 40 VEZES mais mesmo) que o mesmo banco,
com os mesmos ndices, mesmas chaves primrias e mesmas tabelas e relacionamentos
hospedada num servidor SQL-Server verso 7. O Oracle s um SGBD de alta performance em
ambiente UNIX, e incuo nos debatermos contra esse fato. Para maior compreenso destes
aspectos, sugiro uma leitura de matrias abordando o confronto CORBA X DCOM, o que
evitaremos fazer neste trabalho.
Para bases de dados onde nossas tabelas estejam atingindo a casa de 1 milho de registros, os
prprios engenheiros da Microsoft recomendam a migrao para Oracle (em ambiente Unix, bem
entendido).
Capriche na sintonia do seu servidor, especialmente em se tratando de um servidor Oracle ! Se
no souber faz-la, no saia experimentando mudar valores no Init.ORA, nem entre em Wizards de
sintonia, se no souber exatamente o que est fazendo! O risco consiste inclusive na situao de o
servidor no dar mais boot.
Procedures e Funes que rodam no Servidor de Dados:

1. Procedures armazenadas e triggers: Quando temos tabelas com muitos registros (a Oracle os
chama de linhas) recomendvel limitarmos o nmero de linhas que uma query armazenada
possa devolver. Quando ainda no tnhamos esse entendimento, passamos algumas vezes pelo
constrangimento de ver um sistema de contabilidade inteiro fora do ar porque algum usurio pedira
inadvertidamente todos os lanamentos iniciados por 1. A linguagem SQL possui clusulas para
coibir estas ocorrncias (a TOP e a MAXLINES por exemplo), e suas extenses (Transact-SQL e
PL/SQL, para o SQL-Server e Oracle, respectivamente) tambm nos permitem filtrar os resultados.
Sem tais cuidados, podemos cair na situao de cruzar os braos 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 condies regulares.
2. Consulte um DBA se estiver na dvida 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 produo. Interaja com o profissional responsvel pela Base
de Dados, e recorra ao mesmo em qualquer situao dbia.
3. Leia os manuais do fabricante para codificao de stored procedures e triggers. Sempre so
expostas ali tcnicas para melhoria de performance e evito de "gargalos" de processamento.
Pgina 26/26
31/12/2015

Manual de Performance

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual de Performance

Uploaded by

Copyright:

Available Formats

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Crescente quantidade de executivos de nvel mdio tomando decises importantes.

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Peculiaridades da Arquitetura Cliente - Servidor diferentes de outras formas de software distribudo:

Em suma, a arquitetura Cliente - Servidor uma infra-estrutura verstil, modular e baseada em

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

d) Servidor de Groupware: Este tipo de servidor usado para o rastreamento e acompanhamento de

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

g) Servidor de Impressoras: Este dispositivo to somente administra as solicitaes de uso de

Servidor de Respaldo (ou redirecionamento): inovador na arquitetura Cliente Servidor; administra a

Ao avaliarmos a performance de um ambiente Servidor, devemos levar em considerao os seguintes

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

O Hardware do Computador Cliente - Talvez a que oferece maiores dificuldades, no caso de se

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Software de Base do Computador Cliente - O primeiro problema o desconhecimento. Muitos usurios

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Software dos Aplicativos do Computador Cliente - Temos problemas estruturais envolvendo a mo de

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

1. Os discos rgidos alcanaram velocidades inacreditveis, se pensssemos em termos de cinco

Software de Base do Computador Servidor:

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

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

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Figura 1 - Arquitetura de Bases de Dados Centralizadas.

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

2. Em seguida, defina as informaes acerca da conectividade ("linked server definitios") e as opes de

Observe-se como as instrues de SELECT, referenciando a consulta Customers, especificam uma

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Figura 2 - Configurao de uma Base de Dados modelo Discos Compartilhados em Clusters.

Herbert Lopes da Silva (Consultor CTIS)

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

EMPRESA BRASILEIRA DE CORREIOS E TELGRAFOS

Procedures e Funes que rodam no Servidor de Dados:

Herbert Lopes da Silva (Consultor CTIS)