Relatorio de Projeto

DEPARTAMENTO DE INFORMÁTICA
Bloco C6 - Piso 3 - Campo Grande, 1749-016 Lisboa

Tel & Fax: +351 217500084
RELATÓRIO DE PROJECTO
sobre
Viabilidade RAC Oracle 10g + Linux / Benchmarking

Linux vs Windows 2003
realizado na
Trety, SA (Grupo Trèves)
por
Rui Miguel Silvestre Matos Nogueira

Typeset with LATEX.
Il me dit:
- Je suis content que tu aies trouvé ce qui manquait à ta machine. Tu vas pouvoir
rentrer chez toi...
- Comment sais-tu !
Je venais justement lui annoncer que, contre toute espérance, j’avais réussi mon travail!
Antoine de Saint-Exupéry, Le Petit Prince.

v
Agraı̈ments
Durant aquests mesos que he estat a l’empresa Trety he tingut el suport d’un equip.
Voldria expressar el meu agraı̈ment a tot el Departament d’Informàtica, especialment al
meu tutor Santi Solà que m’ha recolzat en tot moment i a l’Alberto Cárceles per haver-me
acollit i donat l’oportunitat de dur a terme aquest projecte.
Agradecimentos
Ao Professor João Cunha, a quem eu devo a sua orientação neste trabalho, o seu
cuidado apoio, disponibilidade e sobretudo pela sua paciência.
Ao Professor João Balsa, a quem eu agradeço toda a atenção e simpatia que sempre
encontrei na sua pessoa, assim como pela prontidão a que sempre acedeu, estivesse em
causa uma burocracia ou uma simples dúvida.
Quero agradecer ao Paulo Carvalho pelo seu tempo, ajuda, e principalmente pela
confiança que encontrei na sua amizade.
Ao Nuno Castro, por apesar de ser grande a distância, estar sempre tão perto.
À Cèlia e ao Josep por me fazerem sentir parte da famı́lia.
À minha famı́lia, eu devo o seu amor e suporte emocional, mas tenho a certeza que
encontrarei melhores formas para agradecer-lhes por isso. Uma palavra muito especial a
ti, Anna, a quem eu devo mais do que tempo.
vii
Resumo
O presente relatório faz uma descrição do trabalho efectuado no âmbito da disciplina de

Projecto do Curso de Especialização Profissional em Engenharia Informática (CEPEI).
O projecto, realizado na empresa Trety SA (Grupo Trèves), visa uma análise sobre a
viabilidade da solução de base de dados em cluster , o Oracle Database 10 g Real Application
Clusters.
Numa primeira fase foi determinado que sistema operativo seria utilizado para alojar
o cluster de base dados, através de um estudo de benchmarking. Os sistemas operativos
sobre os quais se debruçou o estudo foram as distribuições Red Hat Enterprise Linux
e SUSE Linux Enterprise Server , seleccionadas de entre um conjunto mais alargado de
soluções Linux, e o sistema operativo Windows 2003 Server .
Os dados analisados neste estudo foram criados por duas aplicações. Uma delas –
Bench– desenvolvida no decorrer deste projecto e a outra –Hammerora– de software aberto
e gratuita, que disponibiliza uma implementação do benchmark standard TPC-C.
Escolhido o sistema operativo em que iria ser hospedado o Oracle Database 10 g Real
Application Clusters, foi concebida a plataforma, analisados os requisitos e iniciada a im-
plementação do sistema, criando um cluster composto por dois nós. O cluster estabeleceu-
se num ambiente virtual, sobre VMware, uma solução que faculta uma camada de hard-
ware parametrizável, que possibilita a criação de um conjunto de máquinas virtuais, cujas
caracterı́sticas e dispositivos de suporte podem ser definidos “à medida”, possibilitando
adaptar a infra-estrutura às necessidades especı́ficas de diferentes cenários.
Criou-se uma base de dados, sobre a qual foi efectuado um conjunto de testes, de modo
a aferir sobre o correcto funcionamento do cluster .
Este relatório contém também a descrição de algumas tarefas adicionais, realizadas
durante o decorrer do projecto, como a avaliação do pacote de ferramentas OpenOffice
na compatibilidade com ficheiros MicrosoftOffice, assim como outras relacionadas com o
manuseamento de aplicações e servidores, no âmbito do sistema produtivo da empresa.
ix
Acrónimos
Listagem não exaustiva de acrónimos, siglas ou abreviaturas presentes neste relatório
ASM Automated Storage Management
BD Base de dados
DNS Domain Name Service
CD Compact Disc
CPU Central Processing Unit
CRS Cluster Ready Services
CVU Cluster Verification Utility
DBA Data Base Administrator
DVD Digital Versatile Disc
EVM Event Manager
GRUB GNU Grand Unified Bootloader
GNU GNU is Not Unix
ICA Independent Computing Architecture
JRE Java Runtime Environment
LAN Local Area Network
LILO Linux Loader
NAS Network Attached Storage.
NTP Network Time Protocol
OASIS Organization for the Advancement os Structured Information Standards
OCFS Oracle Cluster File System (OCFS2 refere-se à segunda versão deste sistema de
ficheiros)
OCR Oracle Cluster Registry
ODF Open Document Standard, forma reduzida para OASIS Open Document Format
for Office Applications
OUI Oracle Universal Installer
PDF Portable Document Format

x
RAC Real Application Clusters
RAID Redundant Array of Independent Disks
RAM Random Access Memory
RHEL Red Hat Enterprise Linux
SAN Storage Area Network
SCSI Small Computer System Interface
iSCSI Internet SCSI
SGA Shared Global Area
SGBD Sistema de Gestão de Base de Dados
SLES SUSE Linux Enterprise Edition
SO Sistema Operativo
SP Service Pack
SQI Simple Query Interface
TAF Transparent Application Failover
TNS Transparent Network Substrate
TCP Transmission Control Protocol
UDP User Datagram Protocol
VPN Virtual Private Network

Conteúdo
1 Introdução 1
1.1 Integração na empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Estrutura do relatório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Virtualização 4
2.1 Componentes do VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 VMwareTools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Criação de Máquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Resolução de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Sistemas Operativos 9
3.1 Selecção de candidatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Análise de algumas opções . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Partições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Sistema de Ficheiros . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Optimizações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Hugepages - Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Desactivar registos de acesso a leitura . . . . . . . . . . . . . . . . . 12
3.3.3 Recompilação do kernel . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Comparação de desempenhos 14
4.1 Sistema de Gestão de Base de Dados (SGBD) . . . . . . . . . . . . . . . . . 14
4.2 Aplicação Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Principais classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Testes de desempenho complementares . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 TPC-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Hammerora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.3 Automatic Workload Repository . . . . . . . . . . . . . . . . . . . . 18
xii CONTEÚDO
4.3.4 Test drive – Intel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.5 Orion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Cenários Testados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1 Em ambiente virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 Em ambiente nativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Requisitos tecnológicos para Real Application Clusters 27

5.1 Oracle Clusterware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1 Instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Armazenamento partilhado . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.1 Partições Raw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.2 Oracle Cluster File Sistem 2 . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.3 Network File System . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.4 Automatic Storage Management . . . . . . . . . . . . . . . . . . . . 33
5.2.5 Prós e contras dos diferentes métodos . . . . . . . . . . . . . . . . . 36
6 Real Application Clusters (RAC) 37

6.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1.1 Cache Fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.3 Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.4 Endereços IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.5 Sincronização do tempo . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Descrição de alguns componentes RAC . . . . . . . . . . . . . . . . . . . . . 45
6.3.1 Rede Privada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3.2 Rede Pública . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3.3 Endereço IP Virtual (VIP) . . . . . . . . . . . . . . . . . . . . . . . 45
6.4 Opções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4.1 Optimal Flexible Architecture (OFA) . . . . . . . . . . . . . . . . . 46
6.4.2 Módulo Hangcheck Timer . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4.3 Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4.4 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.4.5 Transparent Application Failover (TAF) . . . . . . . . . . . . . . . . 47
6.4.6 Agregação de placas de rede . . . . . . . . . . . . . . . . . . . . . . . 48
CONTEÚDO xiii
6.4.7 Orarun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.5 Scripts Desenvolvidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6.1 Cluster Verification Utility (CVU) . . . . . . . . . . . . . . . . . . . 51
6.6.2 Verificações de pós-instalação . . . . . . . . . . . . . . . . . . . . . . 52
6.6.3 Adição de um nó numa fase posterior . . . . . . . . . . . . . . . . . 54
6.7 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7 Protótipo 56
7.1 Infra-estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.1.1 Criação da máquina virtual . . . . . . . . . . . . . . . . . . . . . . . 57
7.2 Multiplos Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 Instalação SUSE Linux Enterprise Server 9 . . . . . . . . . . . . . . . . . . 59
7.4 Actualizar kernel e OCFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.5 Instalação das VMwareTools . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.6 Configuração de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.7 Acerto dos Relógios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.8 Criar directorias para software Oracle . . . . . . . . . . . . . . . . . . . . . 64
7.9 Instalação do CVU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.10 Configuração do Hangcheck-Timer . . . . . . . . . . . . . . . . . . . . . . . 65
7.11 Disponibilizar Memória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.12 Resolução de nomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.13 Orarun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.14 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.15 Máquinas seguintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.16 Equivalência de utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.17 Preparação das partições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.18 OCFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.19 Clusterware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.19.1 Verificar a instalação do Clusterware . . . . . . . . . . . . . . . . . . 74
7.20 Automatic Storage Management . . . . . . . . . . . . . . . . . . . . . . . . 75
7.20.1 Instalar o software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.20.2 Configurar o driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.20.3 Criar discos ASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.21 Instalação do software Oracle Database 10g . . . . . . . . . . . . . . . . . . 76
7.22 Configuração do Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.23 Criação da base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
xiv CONTEÚDO
8 Outras Tarefas 82
8.1 Servidores Blade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.2 Citrix Metaframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.3 Clonagem de servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.4 Open Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.4.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.4.2 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9 Conclusões finais 89
A Linux: “caderno de notas” 91

A.1 Comandos úteis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Índice 97
Bibliografia 98
Lista de Figuras
2.1 VMware - camada virtualização . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Esquema Máquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Bench - composição do sistema . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Bench - ambiente virtual - cenário B . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Bench - ambiente nativo - cenário C . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Bench - ambiente nativo - cenário D - configuração inicial . . . . . . . . . . 23
4.5 Bench - ambiente nativo - cenário D - várias configurações . . . . . . . . . . 24
5.1 Arquitectura tecnológica para Real Application Clusters . . . . . . . . . . . 27

5.2 Métodos de acesso ao armazenamento partilhado . . . . . . . . . . . . . . . 29
6.1 Arquitectura fı́sica Real Application Clusters . . . . . . . . . . . . . . . . . 38
7.1 Configuração dos discos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.2 Encadeamento das tarefas numa primeira fase da instalação RAC . . . . . . 59
8.1 Servidores Blade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.2 OpenOffice – Calc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.3 MicrosoftOffice 2007 versão beta – Excel . . . . . . . . . . . . . . . . . . . . 87
Lista de Tabelas
2.1 Host e guests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Sistemas de Ficheiros no sistema operativo Linux - análise comparativa . . 11
4.1 Resultados da execução dos testes de desempenho da aplicação Bench sobre

Windows e Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Resultados da execução do benchmark TPC-C sobre Windows e Linux
através do Hammerora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 Métodos alternativos de acesso ao armaz. partilhado: vantagens e desvan-

tagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1 Requisitos para RAC: Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 Requisitos de software para RAC . . . . . . . . . . . . . . . . . . . . . . . . 41
6.3 Análise: segmentação de rede . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4 Endereços IP: limites das subredes . . . . . . . . . . . . . . . . . . . . . . . 44
6.5 Interfaces utilizadas, com respectivas subredes e tipos de rede atribuı́dos . . 44
6.6 Endereços IP reservados para a implementação RAC . . . . . . . . . . . . . 44
7.1 Discos criados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2 Partições no disco local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.3 Identificadores SID utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.4 vipca - Configuração da rede virtual . . . . . . . . . . . . . . . . . . . . . . 74
7.5 Disk Group para ficheiros da BD: Escolha de discos membros . . . . . . . . 80
7.6 Disk Group para ficheiros da Flash Recovery Area: Escolha de discos membros 80
8.1 Programas Office utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Capı́tulo 1
Introdução
No âmbito da disciplina de Projecto do Curso de Especialização em Engenharia In-

formática (CEPEI) da Faculdade de Ciências da Universidade de Lisboa (FCUL), surge
este trabalho, desenvolvido na Trety, S.A. (Grupo Trèves) que decidiu propôr e acolher
esta iniciativa. Esta instituição, cujo ramo de actividade se situa no sector automóvel, tem
na produção e manutenção de sistemas informáticos uma importante actividade, quer na
administração de sistemas, na produção de software ou suporte aos utilizadores do grupo
em que se insere, dentro de uma considerável área geográfica (penı́nsula Ibérica, Marrocos,
Brasil, México, etc.).
A partir do interesse num novo produto da Oracle, o Oracle Database 10 g, com a sua
extensão Real Application Clusters (RAC), o presente projecto pretende ser um instru-
mento para avaliar a sua viabilidade, através de um estudo que contempla a concepção de
um sistema em cluster RAC, a análise dos requisitos necessários e a sua posterior imple-
mentação. Dadas as opções que esta plataforma apresenta, podendo ser instalada sobre
um sistema operativo Linux ou Windows, será efectuado um teste de benchmarking, que
colocará à prova o sistema operativo da Microsoft (Windows 2003 Server ) frente às alter-
nativas em código aberto Linux, a fim de avaliar qual apresenta o melhor comportamento
e assim decidir sobre que ambiente se realizará a implementação. Este estudo é feito com
vista numa possı́vel migração do sistema legado que actualmente vigora na organização,
alojado num ambiente integrado AS/400 da IBM.
1.1 Integração na empresa

O primeiro contacto com a empresa aquando o meu ingresso deu-se através de uma
recepção de “boas-vindas”, levada a cabo pelo departamento de Recursos Humanos. Foi-
me dado a conhecer o perfir geral da empresa.
Foram apresentados os traços gerais do grupo em que se insere, os moldes da or-
ganização, missão, principais clientes e productos, introdução a aspectos organizativos,
distribuição do grupo a nı́vel multi-nacional (mais detalhadamente na penı́nsula Ibérica),
assim como alguns aspectos práticos do dia-a-dia no ambiente de trabalho. Devido à natu-
reza especı́fica do projecto a desenvolver, foi considerada dispensável uma formação (que
normalmente é levada a cabo em novas incorporações) mais detalhada de cada um dos
departamentos que a compõem2 .
2
Unidade de Negócio, A.S.C.(Activité Textile et Aspect), A.T.A.(Activité de Sièges et Composantes),
H.A.P.P.(Habitacle Acoustique et Production de Porte)
2 Introdução
A nı́vel de Departamento de Informática, a minha recepção foi levada a cabo por Santi
Solà, Tutor e responsável pela supervisão deste projecto. Foi-me apresentada a equipa
do departamento, disponibilizado um posto de trabalho e dadas as primeiras linhas de
orientação incidentes no projecto a desenvolver.
Foi extremamente útil a interacção existente com a maioria dos colegas, pois daı́ pude
aprender com as suas sugestões e experiência, em diversas áreas. Áreas técnicas, pelo
conhecimento de úteis e poderosas aplicações, no aprofundamento de matérias ao nı́vel
de sistemas, das bases de dados, em Linux e tanto mais; mas também, e não menos
importantes, Humanas. Este ponto teve uma elevada importância para mim, dadas as
caracterı́sticas deste projecto, em que existia um alto grau de autonomia que lhe estava
associado.
1.2 Objectivos
Este trabalho tem como finalidade implementar um sistema de base de dados (SGBD)
Oracle Database 10 g utilizando a solução Real Application Clusters (RAC), que permite
a disposição de uma base de dados em múltiplas máquinas, funcionando em cluster , de
modo a promover as propriedades de disponibilidade e escalabilidade sobre as bases de
dados nele contidas.
Numa primeira fase, pretende-se definir que sistema operativo (SO) utilizar para su-
portar tal implementação. Para isso será feito um estudo de benchmarking que opõe
uma selecção de distribuições Linux ao Windows, com o Windows 2003 Server , o sistema
operativo maioritariamente utilizado nos servidores desta empresa.
Após a escolha do sistema operativo a adoptar, serão descartadas as outras alternati-
vas. Serão analisados os requisitos para o RAC e deverão ser feitas as opções necessárias
ao seu cumprimento, para traçar o conjunto de passos necessários à implementação do
cluster no sistema operativo seleccionado. Isto deverá ser feito em concordância com as
recomendações existentes, adequados à realidade da empresa e aos recursos de que seja
possı́vel dispôr.
Pretende-se que a plataforma criada com este trabalho crie uma base de conhecimento
a partir da qual se possam adoptar as orientações aqui tomadas e considerar esta hipótese
num potencial cenário de migração de um sistema existente, ou como possı́vel solução para
albergar um sistema a adoptar futuramente, que requeira garantias de alta disponibilidade
ou boas condições para uma fácil escalabilidade.
1.3 Estrutura do relatório
Este relatório regista ao longo dos seus capı́tulos os principais aspectos estudados
no desenvolvimento do Projecto em Engenharia Informática. Neste primeiro capı́tulo de
introdução é feita a apresentação da instituição de acolhimento – Trety, SA (Grupo Trèves)
– e é feita uma abordagem de como se deu, em moldes gerais, a integração na empresa.
São também apresentados os objectivos do projecto, na secção 1.2, e na presente secção é
explicada a organização do relatório.
No capı́tulo 2 explicam-se as caracterı́sticas da solução de virtualização de hardware
da VMware. A plataforma de VMware foi utilizada numa primeira fase para fazer o
estudo de benchmarking sobre o comportamento do SGBD Oracle Database 10 g sobre
1.3 Estrutura do relatório 3
diferentes sistemas operativos e através da qual foi também criada a infra-estrutura de

máquinas virtuais onde se veio a criar a plataforma RAC. São apresentadas as suas
componentes de interacção com o utilizador e dadas algumas ideias necessárias para um
correcto funcionamento deste software, como é a ferramenta VMwareTools. São referidos
alguns problemas encontrados com a utilização deste produto e suas respectivas soluções
assim como se referem algumas suas limitações.
No capı́tulo 3 são indicados alguns dos pontos em que se baseou o estudo sobre os
diversos sistemas operativos considerados quanto à selecção, instalação, configuração e re-
finamento. São vistos os aspectos contemplados antes e durante o estudo de benchmarking
realizado.
No capı́tulo 4 é retratado o ambiente criado para suportar o estudo sobre a comparação
de desempenhos na utilização do sistema de gestão de base de dados Oracle Database 10 g
com os diferentes sistemas operativos participantes. É apresentada uma aplicação (Bench),
que foi desenvolvida para dar suporte ao estudo de desempenhos, assim como algumas
aplicações que participaram também de um modo complementar como ferramentas de
benchmark, como o caso do Hammerora, que aplica o TPC-C, sobre o qual também é dada
uma ligeira explicação numa das secções. Sobre os testes são apresentados os resultados e
conclusão.
O capı́tulo 5 é dedicado aos requisitos tecnológicos para a a plataforma Real Applica-
tion Clusters. Deixa para trás as análises de desempenho sobre os sistemas operativos e
definitivamente considera-se a implementação em sistema Linux, adoptando a distribuição
SUSE Linux Enterprise Server 9 . É apresentada a camada que dá suporte à estrutura
em cluster com a apresentação do software Oracle Clusterware. Dá-se uma visão sobre
as diferentes soluções para o armazenamento partilhado, baseada nas diferentes soluções
tecnológicas sobre os distintos métodos de acesso à infra-estrutura de armazenamento,
como dispositivos Raw , Oracle Cluster File System 2 e Automatic Storage Management.
O capı́tulo seguinte, o sexto, apresenta o Real Application Clusters nos seus variados
pontos. Através de uma visão sobre a sua arquitectura, estudo dos requisitos, descrição dos
componentes. Aborda algumas opções tomadas e configurações que devem ser feitas, com
as respectivas justificações. É apresentada também uma ligeira descrição de alguns scripts
realizados para automatizar de alguma maneira o processo de instalação/configuração.
Trata também a utilização da ferramenta de diagnósticos da Oracle – CVU, e alguns testes
realizados para verificar do seu bom funcionamento, terminada a criação da plataforma.
São também referidas algumas limitações do RAC.
O capı́tulo 7 relata o desenvolvimento de um protótipo de implementação de uma
plataforma RAC, com a criação de um cluster de dois nós. É feita uma “visita guida”
através dos vários passos feitos em direcção a uma instalação bem sucedida, utilizando o
sistema operativo eleito e o Oracle Database 10 g Release 2 (10.2), em que o estado final
compreendeu uma base de dados funcional em dois nós.
No capı́tulo 8 abordam-se algumas conclusões sobre uma tarefa paralela, em que se
avaliava a utilização do OpenOffice com ficheiros MicrosoftOffice, com vista a uma possı́vel
adopção da solução em código aberto.
No capı́tulo 9 apresenta-se ainda algum trabalho realizado no âmbito do manuseamento
de equipamentos servidores e aplicações relacionadas com o ambiente produtivo da Trety.
É ainda apresentado em modo de caderno de apontamentos uma referência a alguns
dos comandos Linux utilizados nalgumas tarefas frequentes.
Capı́tulo 2
Virtualização
Neste projecto foi usada uma solução de virtua-

lização de hardware da VMware, o ESX Server 2.5 ,
que possibilita a criação de máquinas virtuais e faculta
sobre elas facilidades de acesso, gestão e monitorização.
Através da introdução de uma camada de virtua-
lização sobre o hardware, a máquina sobre a qual está
instalado este software é desdobrada, com os recursos
que lhe estão associados, por um conjunto de máquinas
virtuais, criadas e personalizadas conforme as necessi-
dades especı́ficas do utilizador.
Por este meio é possı́vel criar ambientes protegidos
com caracterı́sticas semelhantes a ambientes reais. Há
a possibilidade de moldar os recursos disponibilizados Figura 2.1: VMware - camada
às necessidades especı́ficas de cada cenário que se pre- virtualização
tenda implementar, permitindo que cenários distintos
possam ser postos em prática de uma forma acessı́vel,
quer a nı́vel económico, quer a nı́vel de esforço empreendido. Para além de fazer com
que os recursos criados sejam manuseados, fornece funcionalidades complementares que
dão suporte à sua utilização ou gestão, através das suas interfaces. É disponibilizada a
possibilidade de efectuar uma clonagem de uma dada máquina virtual, ou alterar a sua
parametrização, permitindo por exemplo a adição de um disco rı́gido.
Um sistema instalado debita ao longo do tempo diferentes nı́veis de “caudal” de pro-
cessamento. Imagine-se uma máquina cuja carga seja geralmente baixa, com picos de
maior execução. Utilizando as máquinas virtuais, existe a possibilidade de lhe atribuir
dinamicamente recursos quando deles necessita e libertá-los (de modo a disponibilizá-los
a outra máquina) quando já não façam falta. Torna-se assim mais eficaz a utilização dos
recursos de hardware.
O equipamento que suporta as máquinas virtuais é um IBM xSeries445 (cujas carac-
terı́sticas podemos ver na tabela 2.1), sobre o qual está instalado o VMware ESX Server
2.5. Seguindo a sua terminologia, referimo-nos ao sistema operativo que suporta a ca-
mada de virtualização como “host”, em oposição ao sistema operativo da máquina virtual
alojada, ao qual se denomina “guest”, de acordo com a relação que mantêm.
Muitas vezes a camada de virtualização assenta num sistema operativo que lhe é in-
dependente. Neste caso isso não acontece. A plataforma VMware lida directamente com
2.1 Componentes do VMware 5
o hardware e contém já a componente de sistema operativo integrada, que tem uma fisio-
nomia Linux, porém com algumas caracterı́sticas distintas.
Com esta arquitectura tenta aligeirar a camada de virtualização, encurtando a distância
entre as necessidades dos guests e os recursos facilitados pelo host.
2.1 Componentes do VMware

Consola Remota Como ferramenta de acesso, é disponibilizada uma consola de acesso
remoto. Permite o controlo, acesso e manuseamento de uma máquina virtual previ-
amente criada e lidar com ela como se de um computador real se tratasse.
Interface de Gestão Permite efectuar a gestão e monitorização das máquinas virtuais.
Aqui é feita a criação de máquinas virtuais, criação dos dispositivos que utilizam e a
associação entre ambos. São feitas outras configurações de carácter mais especı́fico.
Através desta interface podemos ter também acesso ao Gestor de Ficheiros.
Gestor de Ficheiros Disponibiliza uma interface gráfica que permite efectuar operações
sobre os ficheiros utilizados pela plataforma e que são mantidos a cargo do sistema.
Permite também visualizar um conjunto de informações relacionadas com a gestão
do armazenamento assim como manipular alguns destes recursos.
2.2 VMwareTools
Este é um pactote de aplicações que deverá ser instalado após o processo de instalação
do sistema operativo guest numa máquina virtual, qualquer que seja a versão utilizada.
Quando uma máquina virtual é criada é requerida a indicação do sistema operativo que irá
ser instalado. Mediante o caso, é disponibilizado o pacote VMwareTools adequado ao tipo
de sistema operativo utilizado. No caso particular do Linux, poderá ser necessária a com-
pilação deste pacote, dependendo da compatibilidade do pacote VMwareTools facultado
na versão do VMware presente com a versão especı́fica do kernel instalado.
Entre as funções deste pacote pode destacar-se a utilização de drivers apropriados para
uma melhor performance (driver SVGA, drivers de rede – vmxnet), suporte para partilha
de directorias ou facilidades de copiar/colar entre host e guest, etc.
Para efectuar a sua instalação, deve seleccionar-se a opção “Install VMwareTools” na
consola remota de acesso à máquina virtual em questão. É então montada na drive de
CD-ROM uma imagem com o pacote de instalação, e a partir daı́ efectuar o procedimento
de instalação recomendado (pode verificar-se um exemplo de instalação na secção 7.5,
presente na página 62).
2.3 Criação de Máquinas Virtuais

Inicialmente foram-me apresentadas algumas noções sobre como especificar uma má-
quina virtual pretendida e como concretizá-la. Posteriormente, com os conhecimentos
adquiridos e a frequente necessidade de efectuar operações de administração sobre elas,
foi-me atribuı́do um nı́vel de administração para o VMware, permitindo-me quer efec-
tuar operações de criação ou remoção de máquinas (com os seus respectivos dispositivos
associados), quer exercer as devidas alterações na sua configuração.
6 Virtualização
Foram criadas três máquinas virtuais com as seguintes caracterı́sticas:
Máquinas Virtuais criadas

IBM xSeries445
W2003 RHEL4 SLES9
S.O. VMWare ESX2.5 Win2003 RHEL4 SLES9
CPU Intel Xeon 2.7 GHz 4 1 1 1
RAM (GB) 12 2 2 2
Discos (GB) 2 x 146,8 30 30 30
Tabela 2.1: Mostra comparativa das caracterı́sticas básicas das máquinas “guest” e “host”
Figura 2.2: Esquema Máquinas Virtuais - visão geral
2.4 Resolução de Problemas
No decurso da instalação e configuração das máquinas virtuais foram encontrados

alguns obstáculos:
• Incompatibilidade do VMware com o Grub .

O Grub (GNU GRand Unified Bootloader) é um programa gestor de arranque, res-
ponsável pelo carregamento do kernel Linux, dando-lhe controlo do sistema. É utili-
zado por omissão em algumas distribuições Linux. Devido a esta incompatibilidade
foi utilizado um gestor de arranque alternativo – o LiLo (LInux LOader).
• Instalação obrigatória do Linux em modo de texto.

A Instalação do Linux não pode ser feita usando o modo gráfico pois daı́ resulta um
erro de instalação ou uma visualização deficiente dos ecrãs apresentados.
2.4 Resolução de Problemas 7
Isto é devido à necessidade de instalar as VMwareTools para o correcto funciona-

mento do modo gráfico e este passo somente pode ser feito após a instalação do
sistema operativo. Este facto cria um requisito adicional no processo de instalação
do sistema operativo neste ambiente, que é o de escolher atempadamente a opção de
efectuar esta instalação em modo de texto.
• Instalação das VMwareTools

Numa primeira fase apenas tinha atribuı́das permissões de acesso às máquinas virtu-
ais, não podendo efectuar operações como instalação das VMwareTools, necessárias
ao funcionamento regular do sistema num ambiente deste tipo.
• Funcionamento irregular dos relógios

No uso quotidiano das máquinas virtuais, notou-se que havia frequentemente um
desacerto dos relógios. Foi criada uma pequena aplicação em Java [Hora.class] para
monitorizar o relógio das várias máquinas virtuais e comparar a contabilização do
tempo que passava, que acabou por identificar que existia uma grave incoerência
entre elas, acontecendo que em algumas o “tempo” passava muito mais rápido.
Os relógios nas máquinas virtuais mostravam-se divergentes, o que representava um
comportamento anómalo. A instalação das vmware-tools com a opção de sincro-
nizaçao de relógios entre host e guest mostrou-se insuficiente na sua correcção.
Os relógios a funcionar nas máquinas virtuais, sobretudo nos sistemas Linux, de-
monstravam um avanço excessivamente rápido em relação ao tempo real. A razão
disto acontecer encontra-se devidamente documentada [45] e requer a adopção de al-
gumas medidas de configuração no sistema operativo guest no sentido de minimizar
este efeito.
É conveniente activar também o serviço de NTP para dar suporte às práticas adop-
tadas, com o intuito de fornecer um mecanismo adicional para o acerto do relógio.
Este serviço não foi posto em prática para o estudo de benchmark para não intro-
duzir efeitos de desvio sobre os registos de desempenho das máquinas e devido à
morosidade normalmente implicada na sua estabilização.
• Interferência mútua
O VMware faculta a possibilidade de definir um processador especı́fico para cada
máquina virtual. Porém, apesar desta escolha ser configurável, mostrou ter com-
portamentos pouco estanques durante da realização de execuções concorrentes. Isto
devido à partilha dos recursos existentes e consequente concorrência no seu acesso,
com processos de escalonamento que dificilmente facultam uma parcialidade total
perante as diferentes máquinas.
Outras máquinas, alheias ao contexto do teste de desempenho, impõem também
factores externos que tornam difı́cil limitar o subconjunto de factores que influenciam
os resultados obtidos.
• Permissões de administração insuficientes.

No VMware certas operações são vedadas a qualquer utilizador com um nı́vel de
permissões limitado ao acesso à consola remota. Ao passar a pertencer ao grupo de
administração do VMware esperava-se que o acesso a essas operações fosse disponibi-
lizado. Porém tal não acontecia. Também para a instalação das VMwareTools eram
necessárias permissões de root, facto não reportado na documentação existente.
8 Virtualização
Isto sucedia devido a uma gestão de permissões desapropriada. Os ficheiros eram

criados e mantidos sem facultar permissão de escrita ao nı́vel de grupo de adminis-
tração, o que não dava às contas com poder de administração a capacidade de actuar
sobre os ficheiros para exercer as operações pretendidas.
Nas máquinas criadas foram alteradas as permissões dos ficheiros associadas aos
recursos utilizados, de modo a restituir o estado apropriado.
2.5 Limitações
Foi verificada uma carência de instrumentos pormenorizados de monitorização do sis-

tema. Este produto não fornece instrumentos que possibilitem uma monitorização deta-
lhada sobre vários pontos importantes ao nı́vel dos recursos utilizados por cada máquina
virtual. A tı́tulo de exemplo, a monitorização do acesso ao disco ou da utilização de
CPU poderiam auxiliar na detecção de alguns problemas ou na detecção de casos com
comportamentos anómalos que podem representar situações de risco. Foram utilizados
programas alternativos, quer facultados pelo sistema operativo, quer externos. Porém,
devido à existência desta camada de virtualização, os resultados obtidos não alcançam um
grau satisfatório de credibilidade.
O acesso às máquinas virtuais através da consola remota notou-se lento e a janela de
apresentação limitava-se a uma fracção da zona útil de visualização. Fora do contexto do
registo de desempenhos foi configurado um acesso por Virtual Network Computing (VNC),
atingindo melhores resultados quer no conforto da visualização de ecrã completo, quer na
agilidade da captura de eventos tornando a interacção pessoa-máquina mais eficiente.
Apesar das boas capacidades que apresenta este produto, de uma maneira geral, no que
respeita à realização dos testes de desempenho à base de dados nos diferentes servidores
a interpretação dos seus resultados mostrou que esta opção não é a mais apropriada para
promover este tipo de tarefa, tão dependente de algumas caracterı́sticas como o isolamento
ou a equivalência no acesso aos recursos disponı́veis.
Capı́tulo 3
Sistemas Operativos
3.1 Selecção de candidatos
Inicialmente houve uma fase de angariação de opções para sistemas operativos que
fossem considerados válidos para participar no estudo de benchmarking a ser realizado em
oposição ao Windows 2003 Server .
Entre os candidatos podem destacar-se: Centos, Ubuntu, Red Hat Enterprise Linux ,
Suse Linux Enterprise Server e WhiteBox.
A selecção recaı́u sobre o Red Hat Enterprise Linux 4 e o SUSE Linux Enterprise
Server 9 , essencialmente por serem as soluções certificadas pela Oracle e por isso possuı́rem
melhores condições em termos de documentação e de “massa crı́tica”, assim como a sua
adopção fornece melhores garantias de suporte e segurança na continuidade das futuras
actualizações do produto.
3.2 Análise de algumas opções
3.2.1 Partições
O particionamento do sistema de ficheiros é uma prática que oferece diversas vantagens.

Por um lado representa um potencial aumento de eficiência pois agrupa conteúdos que
usualmente estão relacionados, o que representa uma probabilidade elevada que o seu
acesso seja geralmente próximo no tempo. Se se encontrarem em localizações próximas
no disco, reduz-se o tempo de deslocação das cabeças de leitura para aceder aos diferentes
sectores pretendidos, minorando a latência nos processo de acesso a disco.
Por outro lado o particionamento do sistema de ficheiros por sub-áreas de conteúdos
comuns promove uma protecção adicional à integridade do sistema.
Por exemplo, a directoria /var guarda os logs de erros. Se imaginarmos que um ser-
vidor importante desenvolve um erro crónico e frequente, as mensagens registadas podem
potencialmente encher a partição em que se encontram. Se esta directoria tiver uma
partição dedicada, as consequências poderão passar quase despercebidas, ao contrário do
que aconteceria se a directoria partilhasse uma mesma partição com outras directorias,
em que uma quebra no serviço fornecido pelo servidor seria inevitável.
10 Sistemas Operativos
Espaço Swap
Para cada processo que corre num computador é alocado um conjunto de blocos de
memória ou páginas. Se possı́vel, o sistema operativo tenta manter na RAM o conjunto
de páginas que são utilizadas, ou que se prevê que venham a sê-lo. Quando a utilização
de páginas excede a capacidade disponı́vel na memória RAM, o kernel tenta libertar a
memória esgotada, escrevendo páginas no disco. O espaço Swap é utilizado para este fim.
Efectivamente, ele aumenta a quantidade de memória disponı́vel pelo sistema. Porém,
se considerarmos que as operações de acesso a disco são cerca de cem vezes mais lentas
que as de leitura e escrita para RAM, este recurso deve ser considerado como memória de
emergência e não memória extra [46].
Em sistemas Linux é obrigatório definir espaço a ser utilizado para Swap. É um dos
passos a percorrer na instalação do sistema. Geralmente o espaço mı́nimo recomendado
para este efeito depende do tamanho da RAM utilizada, porém os valores apropriados
dependem também da utilização especı́fica que se pretenda dar ao sistema em mente.
Pode também ser definido espaço adicional numa fase posterior. Para isso podem ser
utilizados comandos para efectuar este acréscimo ou reconfiguração. Para definir uma
partição Swap, há que preparar o espaço onde ela será aplicada. Se pretendermos dedicar-
-lhe a partição referida por /dev/sda5 devemos primeiro preparar esta partição e depois
activá-la.
O espaço máximo utilizado por uma partição Swap depende da arquitectura. Para
uma arquitectura Intel i386, este limite é de 2GB. Existe, ainda assim, a possibilidade de
definir múltiplas partições para este efeito. A partir do kernel Linux 2.4, é permitido a
utilização de 32 áreas Swap, o que dá alguma margem de manobra. . .
Para uma utilização com bases de dados Oracle, os valores apontados como ideais
respeitam a tabela 6.1 constante na página 39. Dado que foram utilizados 2GB de memória
RAM em cada máquina virtual, como o valor recomedado para Swap pela Oracle para esta
quantidade de memória RAM é de 3GB, tiveram de ser criadas duas partições dedicadas
à utilização Swap em cada uma das máquinas, de modo a que o tamanho máximo para a
partição Swap não fosse excedido.
3.2.2 Sistema de Ficheiros
De um modo geral um sistema de ficheiros está presente e faz parte como subsistema de
qualquer sistema operativo. Funciona como interface entre os recursos de armazenamento
a que tem acesso e as camadas de nı́veis superiores. Trata de guardar os dados e organizá-
-los de maneira a que seja fácil a sua localização e acesso.
Pode lidar com diferentes tipos de recursos de armazenamento, sejam eles fı́sicos, como
um disco duro ou um CD, o que envolve conhecer a localização fı́sica dos ficheiros, ou
virtuais, e existir apenas como método de acesso em rede (por exemplo NFS), que faculta
um acesso em rede a conteúdos remotos.
Geralmente é através deste sistema que as operações de escrita ou leitura são efectua-
das. Em complemento a estas operações básicas, acumula um conjunto de outras operações
cujas caracterı́sticas e extensão depende de cada solução em particular. Algumas das fun-
cionalidades mais comuns são gerir o espaço livre, optimizar o manuseamento dos dados,
gerir as permissões de acesso aos ficheiros, registar meta-dados sobre a sua utlilização, etc.
3.3 Optimizações 11
O conjunto de serviços que cada sistema de ficheiros disponibiliza, assim como o tipo
de abstração que ele promove, depende de qual o seu propósito. Uma das “mais-valias”
que alguns dos sistemas de ficheiros oferecem é a capacidade de “journaling”.
Journaling é uma funcionalidade exercida através de um sistema de logs, em que du-
rante a execução regular do sistema é guardado um registo das operações efectuadas, e
que permite uma fácil recuperação (através da consulta aos registos efectuados), caso haja
uma interrupção abrupta do sistema, sem que tenha de ser feito um diagnóstico exaustivo
ao sistema de ficheiros.
Ext2 Ext3 ReiserFS3.6a

Tamanho máximo da partição 4TB 4TB 4TB
Tamanho máximo da ficheiros 2GB-2TB 2GB-2TB 4TB
Tamanho de bloco 1kB-4kB 1kB-4kB 4kB apenas
Capacidades de Journaling Não Sim Sim
Reinicialização após crash Lenta Rápida Muito rápida
Estado dos dados após crash Bom Muito bom Razoável
Suporte ACLb Sim Sim Não
Estabilidade Excelente Boa Boa
a
não suportado pela Oracle
b
sistema de protecção de recursos (gestão de permissões e direitos de acesso)
Tabela 3.1: Análise comparativa de alguns dos principais sistemas de ficheiros dedicados
a discos locais para Linux publicada em [47].
3.3 Optimizações
Foi explorada mais a vertente das optimizações no sistema operativo Linux por ser este
que apresentava inicialmente piores prestações nos testes de desempenho efectuados. No
entanto foram também exploradas algumas opções de modo encontrar uma configuração
optimizada para o sistema operativo Windows, com alguns efeitos práticos evidenciados.
3.3.1 Hugepages - Linux
Hugetlbpages é uma facilidade introduzida com o kernel Linux 2.6 que, em vez de usar
páginas de memória de 4kB, valor standard para arquitecturas x86 de 32-bit, faz com que
sejam utilizadas páginas até 4MB. Isto permite poupar um considerável “overhead” quer
em termos de processador, quer de memória, que de outra forma teria de ser empregue
gerindo uma quantidade significativamente maior de páginas de menor tamanho.
Pode ser especificado o tamanho de página a utilizar e por outro lado o número de
páginas que devem ser utilizadas (e reservadas para tal efeito).
Para configurar as Hugepages efectuar o seguinte procedimento:
1. Ver a configuração actual através do comando:

# cat /proc/meminfo |grep Huge
12 Sistemas Operativos
2. Definir o tamanho de página a ser usado (em kB), introduzindo na linha de comandos:
# echo 4096 > /proc/sys/vm/nr_hugepages
3. Editar o ficheiro de parametrização do gestor de arranque de sistema (\boot\lilo.conf

caso seja utilizado o Lilo , ou \boot\grub\menu.lst para o Grub), e adicionar na
linha da opção adequada “hugepages=50”. O valor de páginas adoptado deverá tra-
duzir o espaço que se pretenda utilizar (num páginas x tamanho). Numa instalação
Oracle, recomenda-se que cubra o espaço reservado para o SGA.
– Exemplo com Grub:
title Linux
kernel1 (hd0,1)/boot/vmlinux root=/dev/sda2
vga=0x311 selinux=0 hugepages=50 splash=silent
– Exemplo com Lilo:
image = /boot/vmlinuz
label = Linux
initrd = /boot/initrd
optional
root = /dev/sda4
append = "selinux=0 splash=silent clock=pmtmr hugepages=50"
4. Editar (ou criar caso não exista) o ficheiro /etc/sysctl.conf e colocar-lhe a seguinte
linha:
vm.disable_cap_mlock = 1
5. Para fazer com que o ficheiro editado seja levado em conta de cada vez que o sistema
reinicie, executar na linha de comandos: chkconfig boot.sysctl on
Após reiniciar o sistema pode verificar-se a utilização das Hugepages, com o comando
indicado anteriormente. É mostrada a informação do sistema respectiva à sua utilização.
HugePages_Total: 1024
HugePages_Free 940
Hugepagesize: 2048kB
Indicam o número de páginas total, disponı́veis e o tamanho de cada uma. A forma

mais fácil para verificar que esta funcionalidade está a ser utilizada é através desta in-
formação, avaliando que existe uma diferença entre os dois primeiros valores.
3.3.2 Desactivar registos de acesso a leitura
Os parâmetros noatime e nodiratime permitem desactivar a funcionalidade de actu-

alizar a estampilha temporal perante as operações de leitura efectuadas sobre os ficheiros
e directorias, respectivamente. Pode prescindir-se da utilização desta funcionalidade face
ao custo que representa em termos de performance de disco. Principalmente se esta é uma
propriedade importante no entender do administrador. O ambiente Windows faculta uma
possibilidade semelhante.
Para efectuar esta desactivação, ao montar um volume deve ser introduzida a opção
pretendida:
3.3 Optimizações 13
# mount -o noatime,nodiratime
Caso se pretenda que o volume seja optimizado automaticamente no processo de ar-

ranque, editar o ficheiro /etc/fstab e, ao editá-lo, introduzir a opção pretendida na linha
que corresponde ao volume onde se pretende a desactivação.
3.3.3 Recompilação do kernel
Quando o sistema operativo é instalado, é no seu núcleo, no kernel, que estão os

principais mecanismos que interagem numa primeira instância com o hardware. O kernel
permite estabelecer a ponte, criar uma primeira camada de abstracção, através da qual as
aplicações podem efectuar chamadas ao sistema, de modo a aceder aos recursos disponı́veis,
ou estabelecer a comunicação entre os diferentes processos.
O kernel pode classificar-se em diferentes tipos, dependendo da arquitectura que apre-
sente. Pode classificar-se como Microkernel, quando se trata de um kernel de pequena
dimensão que garante um conjunto mı́nimo de funcionalidades e é suportando por um
conjunto de camadas adicionais do sistema operativo que o complementam. Pode também
tratar-se de um kernel Monolı́tico, quando composto por um único bloco executável que
reúne todas as funcionalidades prestadas pelo sistema operativo.
Um kernel Monolı́tico, como é composto por um único executável, tem a vantagem de
que todas as estruturas em memória internas ao sistema operativo lhe estão disponı́veis,
evitando assim a passagem de dados através das diferentes camadas do sistema operativo,
o que comporta custos de performance. Porém, representa também a necessidade de re-
consruir todo o kernel quando se pretende acrescentar um driver para um novo dispositivo.
No Linux, é utilizado um modelo hı́brido, em que podem ser carregados módulos sobre
o kernel, que permitem carregar dinamicamente drivers de dispositivos ou camadas de sis-
tema operativo. Estes módulos apenas utilizam os recursos (como memória) quando estão
a ser utilizados. A sua configuração pode ser alterada através do processo de recompilação
do kernel. Durante este processo, são escolhidas as componentes que deverão integrar o
sistema operativo e é definido, para cada uma, se deve fazer parte integrante do kernel ou
se deverá ser carregada dinamicamente como módulo.
Capı́tulo 4
Comparação de desempenhos
O estudo de comparação de desempenhos efectuado entre as máquinas intervenien-

tes propõe-se averiguar qual o sistema operativo que apresenta melhor desempenho ao
funcionar com uma base de dados Oracle. Pretende acima de tudo aprofundar os conhe-
cimentos acerca do comportamento de um servidor Linux neste ambiente comparativo e
avaliar a hipótese da sua utilização efectiva como sistema operativo utilizado com o sis-
tema de gestão de base de dados da Oracle, dado que a utilização nesta empresa a nı́vel
de servidores com kernel Linux é extremamente reduzida.
Para fazer este estudo foi desenvolvida e utilizada uma aplicação em Java – Bench.
Foram também analisados alguns produtos especializados em testes de benchmarking a
bases de dados, como o Benchmark Factory 1 (um produto da Quest Software), e as soluções
de utilização livre SwingBench 2 e Hammerora 3 . Este último foi adoptado para dar suporte
ao estudo a ser realizado.
4.1 Sistema de Gestão de Base de Dados (SGBD)
Foi utilizado o sistema de gestão de bases de dados Oracle Database 10 g Release 2

(10.2), instalado na sua versão standard.
Numa primeira fase foi instalada a versão 10.1.0.2 e posteriormente foi utilizada a
versão mais actualizada, a 10.2.0.1. Esta versão foi utilizada para executar os testes
de desempenho e posteriormente também para criar o ambiente em cluster com os Real
Application Clusters.
Nas várias instalações foi utilizada uma configuração semelhante e tentou-se manter o
mesmo conjunto de serviços activos. Por exemplo o Enterprise Manager, uma plataforma
de gestão da Oracle, que nos sistemas operativos Linux não é colocada em actividade
após a instalação, foi lançada e através dela comparadas algumas parametrizações entre
os ambientes (utilização de memória, áreas System Global Area (SGA) e Process Global
Area (PGA), reservadas para utilização das instâncias Oracle, etc.).
1
http://www.quest.com/benchmark_factory
2
http://www.dominicgiles.com/swingbench.php
3
http://hammerora.sourceforge.net
4.2 Aplicação Bench 15
4.2 Aplicação Bench
Esta é uma aplicação em Java, criada para gerar um conjunto de pedidos a submeter
à base de dados, efectuando-lhe um teste de carga transaccional. Foi criada de forma
modular, de forma a permitir a escalabilidade da aplicação, e foram sendo acrescentadas
funcionalidades no sentido de colmatar as necessidades de cada ambiente especı́fico.
Inicialmente o desenvolvimento desta aplicação não estava planeado. A decisão da
sua utilização surgiu ao identificar o comportamento anormal dos relógios nas máquinas
virtuais (ver secção 2.4).
Figura 4.1: Bench - composição do sistema - comunicação e principais componentes
Foi então produzida esta aplicação de modo a tornear esse problema e dar resposta a
uma primeira necessidade - o registo credı́vel dos resultados. Através da inserção de um
coordenador externo, poder-se-ia isolar a execução do teste pretendido, que compreende
as operações de carga transaccional sobre a base de dados, realizadas localmente onde se
encontra alojada a BD, do controlo de desempenho, realizado numa máquina externa que
de um modo centralizado, a par de gerir quando deverá ser feito o arranque do teste em
cada servidor, trata também de efectuar a medição das durações de cada teste submetido,
eliminando os problemas relativos à sincronização de relógios. Assim, este coordenador
será responsável pelo controlo de execução e registo de desempenho.
Segue um modelo mestre-escravo, ou cap-i-cua4 para utilizar a designação em catalão,
com a classe Cap responsável pelo controlo do fio de execução dos testes e a classe Cua,
alojada em cada uma das máquinas virtuais, que recebe os pedidos para executar o teste
local.
Localmente cada instância Cua é responsável por atender aos pedidos que lhe chegam,
de acordo com um protocolo de comunicação. Prepara a base de dados e despoleta uma
nova ocorrência do teste preparado. Este teste por sua vez compreende um conjunto de
4
capicua, é uma aglutinação de palavras catalãs que significam cabeça(cap) e(i) cauda(cua).
16 Comparação de desempenhos
chamadas à base de dados através de um acesso concorrente. Pode ver-se o esquema de

comunicação na figura 4.1.
4.2.1 Principais classes
A aplicação Bench, está distribuı́da por duas componentes, o cliente (Cap) e o servidor
(Cua). O cliente, organizado num pacote de classes que corre numa máquina externa (que
funciona como coordenador), apresenta a interface de controlo com o utilizador, gere a
informação acumulada e estabelece as ligações com as múltiplas componentes servidor e
gere a informação adquirida. Cada componente servidor agrupa num ficheiro jar as classes
necessárias para preparar o teste de desempenho, executá-lo e notificar a sua conclusão ao
módulo cliente através da ligação TCP estabelecida.
BD Gere os dados relevantes de cada base de dados.
Cap Classe que contém o método main do programa cliente da aplicação de desempenho.
Comunica Trata das comunicações a realizar pela rede.
Concorrente Classe que contém o método main do programa que é lançado no servidor
onde está alojada a base de dados.
Contagem Contém os dados referentes a uma contagem.
Contagens Gere conjuntos de contagens referentes a um dado servidor.
Control Esta classe é responsável pela sincronização dos processos de inı́cio e fim dos
testes nos distintos servidores no funcionamento sı́ncrono ou assı́ncrono. Faz o con-
trolo das operações de teste, com a sinalização para arranque da fase de preparação
do teste e seu consequente lançamento.
Cua Gere as comunicações no lado servidor da aplicação.
Definicions Guarda as constantes utilizadas pelo programa (cliente/servidor)
Desempenho Tem funções que fazem a chamada a procedimentos pl/sql remotos utili-
zados para carregar a base de dados.
Estadistica Permite fazer operações estatı́sticas sobre as contagens adquiridas.
GestorSessoes Efectua operações de gestão relacionadas com as Sessões (sessão presente

e do histórico)
HistoricoSessoes Guarda as sessões executadas anteriormente, facultando operações de

manuseamento sobre elas.
Inout Efecua operações de E/S para o ecrã.
Ligacao Estabelece as ligações entre o cliente e servidor e gere a sua manutenção, assim
como lida com o protocolo de comunicação a usar com a parte servidor.
Menu Promove a interface com o utilizador através de uma sequência de menus.
Periodo Guarda informação sobre os perı́odos de tempo que se referem à duração dos
testes de desempenho.
4.3 Testes de desempenho complementares 17
Sessão Gere a informação respeitante a uma sessão, como o nome, a descrição os seus
conteúdos, a data da sua criação, as contagens, etc.
4.3 Testes de desempenho complementares
Para além da aplicação Bench, desenvolvida para realizar a comparação de desempe-

nhos do SGBD Oracle em diferentes sistemas, foram também encontradas outras soluções
de software que auxiliaram quer no desenvolvimento de benchmarks com medições sobre
o rendimento de operações sobre bases de dados, quer na medição de outras propriedades,
como a velocidade de operações E/S.
4.3.1 TPC-C
O TPC-C é um benchmark standard cuja especificação é disponibilizada gratuitamente

pelo Transaction Processing Performance Council (TPC), que é uma organização especi-
alizada em testes de benchmarking.
Este benchmark é um teste de carga “Online Transaction Processing” (OLTP). Mistura
transacções de leitura com outras que realizam actualizações intensivas, que simulam um
padrão de actividades tı́picas, encontradas em aplicações de ambiente OLTP. Funciona
executando um amplo teste aos componentes do sistema associados a ambientes deste
tipo.
Efectua a execução de múltiplos tipos de transacções que cobrem um vasto espectro de
complexidades. Realiza operações de disco de volume significativo e garante a integridade
transaccional (ACID5 ). Utiliza uma grande quantidade de tabelas de diferentes tamanhos,
atributos e relações. Permite a utilização de múltiplas sessões de terminal que acedem
concorrentemente à base de dados.
4.3.2 Hammerora
O Hammerora, disponibilizado no repositório da Sourceforge, é um software gratuito e

em código aberto que realiza testes de benchmarking sobre bases de dados Oracle baseados
em linguagem TCL. Permite também reproduzir de uma forma fidedigna conjuntos de
operações efectuados sobre a base de dados, o que permite realizar testes comparativos.
Para além de testes parametrizáveis, um dos testes de benchmarking que disponibiliza
é o TPC-C (secção 4.3.1).
Este benchmark foi utilizado adicionalmente à aplicação Bench (secção 4.2) desenvol-
vida para efectuar o registo de desempenhos. Deste modo podemos confirmar a validade
dos resultados com uma “segunda opinião” que possa corroborar as conclusões obtidas.
Para extrair os seus resultados foram criados relatórios AWR (Automatic Workload
Repository), uma ferramenta dedicada à produção de estatı́sticas da base de dados.
5
acrónimo para as propriedades Atomicidade, Consistência, Isolamento e Durabilidade
4.3.3 Automatic Workload Repository
O Automatic Workload Repository (AWR) é uma facilidade da Oracle que se encarrega

da recolha de uma extensa quantidade de informação da base de dados. Através do
tratamento dos dados recolhidos, tem a capacidade de efectuar estatı́sticas e resumir o
conhecimento adquirido, de modo a proceder à criação de relatórios que resumem grande
parte dessa informação, torna-os acessı́veis no seu repositório.
É uma ferramenta extremamente útil no suporte ao administrador de bases de dados.
Tem geralmente associados mecanismos automáticos para a realização de relatórios, utili-
zados tanto nos processos de optimização de comandos SQL, como na produção de alertas
previamente definidos, associados a um conjunto métricas.
A maneira mais fácil de aceder ao AWR é através da interface de administração do
Enterprise Manager. Esta funcionalidade foi utilizada por esse meio para registar o de-
sempenho dos sistemas avaliados, ao serem submetidos aos testes do benchmark TPC-C,
efectuados a partir do programa Hammerora.
4.3.4 Test drive – Intel
Foi avaliada a possibilidade de realizar o teste de desempenho preparado (Bench) sobre

o “Test Drive” da Intel. Este é um dispositivo de testes facultado pela Intel onde podem
ser submetidas aplicações de teste sobre um leque de aplicações disponibilizadas no lado
servidor, entre as quais bases de dados, sobre equipamentos Itanium com as alternativas
Windows e Linux disponı́veis.
No entanto, esta possibilidade não resultou interessante dada a natureza partilhada
dos recursos facultados. Apesar dos equipamentos disponibilizados pela Intel terem ca-
racterı́sticas semelhantes, sem controlo sobre o isolamento dos testes e sem garantias a
respeito da paridade ao nı́vel da resposta dada pelos recursos utilizados nos diferentes
ambientes, poderia acontecer que um dos testes fosse executado em exclusividade num dos
servidores e outro corresse em simultâneo com outros processos, o que tornaria incoerente
a interpretação dos resultados obtidos. Deste modo, o aproveitamento dos seus resultados
não teria efeitos práticos que contribuı́ssem positivamente para o estudo a ser efectuado.
4.3.5 Orion
O Orion é uma ferramenta que tenta prever a performance de uma base de dados
Oracle sem ter de instalar o software em questão ou criar uma base de dados. Foi criado
expressamente para simular cargas de E/S da BD usando nas operações realizadas uma
abordagem semelhante à efectuada pelas bases de dados Oracle.
Permite efectuar diferentes tipos de cargas de operações sobre os discos, podendo
inclusivamente efectuar simulações do efeito de striping produzido pelo Automatic Storage
Management (ASM), que será visto com algum detalhe na secção 5.2.4 (página 33).
Esta ferramenta foi utilizada para verificar o rendimento das operações de disco nos
sistemas operativos Windows e Linux perante uma instalação na mesma máquina, em
partições distintas.
4.4 Cenários Testados 19
4.4 Cenários Testados
O objectivo deste estudo não se baseou em descobrir qual o melhor sistema operativo,
pois esse tema apesar de muito debatido, dificilmente nos deixa com uma resposta objec-
tiva. Isto porque são muitos os factores de que depende este tipo de conclusões que uns e
outros sempre poderão alegar em defesa da sua escolha de preferência.
O seu foco incide sim em comparar os desempenhos que o sistema de gestão de bases
de dados, o Oracle Database 10 g revela sobre as diferentes soluções de sistema operativo
avaliadas.
4.4.1 Em ambiente virtual
Neste ambiente os servidores são máquinas virtuais. As máquinas foram criadas de-
finindo os seus recursos com caracterı́sticas semelhantes (quantidade de memória, disco,
velocidade de processamento) e o factor que as distingue, para além do nome que apresen-
tam perante a interface de gestão do VMware, é o sistema operativo que têm instalado.
Cenário A
No primeiro cenário o teste era lançado sobre os três

servidores ao mesmo tempo. Através da aplicação Bench,
os testes eram lançados sobre os três servidores de uma
forma sincronizada. Quando era finalizado o teste num
dos servidores, a base de dados era preparada para novo
teste e esperava pela ordem do coordenador para lançá-lo
de novo. Ao receber a informação por parte dos vários ser-
vidores acerca do final do teste presente, e posteriormente
de que a fase de preparação estava concluı́da, o coordenador emitia nova ordem para que
os testes fossem lançados, até perfazer o números de testes que havia sido inicialmente
definido pelo utilizador através da interface da aplicação.
Cenário B
No cenário anterior, as máquinas virtuais tinham sido especificadas com processadores

distintos (mas de caracterı́sticas idênticas). Numa fase em que se tentava interpretar os
dados obtidos no cenário anterior, verificou-se que alguns deles estavam atribuı́dos também
a outras.máquinas.
Para tentar promover uma situação de igualdade entre as máquinas utilizadas neste
estudo, foi feita uma re-atribuição dos processadores do host de modo a que todas fossem
tratadas pelo mesmo. A par disso, foi retirado o acesso das outras máquinas virtuais,
alheias ao contexto do teste de desempenho em questão, ao processador escolhido. Com
isto pretendia-se reduzir o impacto externo sobre os recursos associados às máquinas vir-
tuais utilizadas.
Para evitar factores espúrios neste ambiente de benchmarking, e uma atribuição de-
sigual de recursos às diferentes máquinas, por exemplo a nı́vel de escalonamento de pro-
cessador, foi decidido efectuar os testes de um modo sequencial e não simultâneo, e assim
tentar reduzir o acesso concorrente aos recursos partilhados.
Por parte da aplicação de benchmarking utilizada, a ordem de execução do teste era

dada a um servidor de cada vez. Ao ser definido, pelo utilizador, o numero de testes a
ser executado (por cada máquina), era criado um plano de execução que se encarregava
de ordenar os testes nas diferentes máquinas de uma forma aleatória, para assim ten-
tar distribuir o indesejável impacto de factores externos sobre os testes, de uma forma
equilibrada.
4.4.2 Em ambiente nativo
Em busca de resultados mais consistentes, procurou-se instalar os três servidores, com

os sistemas operativos em avaliação, fora do ambiente virtual anteriormente utilizado.
O cenário idealizado consistia em albergá-los em três máquinas distintas, de um mesmo
modelo, que tivessem as mesmas caracterı́sticas, em que os factores diferenciáveis se res-
tringissem ao software instalado e sua configuração.
Dada a indisponibilidade de tais recursos, foi usada uma mesma máquina para hospedar
os diferentes sistemas operativos. Neste ambiente foram apenas utilizadas duas das opções
anteriormente testadas, o Windows 2003 Server , que apresentava os melhores resultados
até à altura, e o SUSE Linux Enterprise Server 9 , que se revelou a distribuição Linux com
melhor resposta aos testes feitos anteriormente, assim como maior facilidade em termos
de instalação.
Cenário C
Neste cenário, a máquina albergou os sistemas operativos de forma simultânea. O

disco disponı́vel foi particionado de modo a possibilitar a permanência dos dois sistemas
operativos. Foi realizada a instalação do Windows 2003 Server e do SUSE Linux Enter-
prise Server 9 , pela ordem enunciada, para evitar um passo suplementar de restituição
do Master Boot Record. O acesso a cada um era feito através de um gestor de arranque
(Grub), que permitia proceder à sua escolha ao iniciar o sistema.
Cenário D
Com a indisponibilidade de duas máquinas com semelhantes caracterı́sticas para a

realização deste teste de desempenho, e de modo a ultrapassar as dificuldades encontradas
na análise dos resultados do cenário anterior, os ambientes em competição foram instalados
em fases distintas na mesma máquina, nas quais se procurou utilizar o mesmo espaço de
partições.
Foi formatada a máquina, instalado um dos sistemas (sistema operativo e SGBD Ora-
cle) e efectuados sobre ele os vários testes de desempenho. Após realizados os testes, foi
reproduzido o mesmo processo com outro sistema operativo.
Este cenário compreendeu a realização de testes sobre o sistema, em primeiro lugar com
as opções standard do sistema operativo (observadas imediatamente após a instalação).
Posteriormente foram também aplicadas algumas opções de optimização, cujas descrições
são apresentada na secção 3.3 (página 11). Sobre o sistema operativo Windows 2003
Server foram utilizadas as opções PAE, 3GB e também foi testado uma configuração que
conjugava estas duas opções. Sobre o SUSE Linux Enterprise Server 9 foi actualizado o
kernel para uma versão mais actual e (2.6.5-7.257), procedeu-se à sua recompilação, de
modo a criar um kernel monolı́tico, e foram utilizadas as Hugepages.
4.5 Resultados 21
Os testes de desempenho foram realizados não só pela aplicação Bench como também
pela aplicação Hammerora.
4.5 Resultados
Cenário A
Os resultados obtidos neste cenário manifestaram grandes oscilações no rendimento

das bases de dados, e não mostravam uma consistência nos seus dados. Eram obtidos
valores muito dispersos, dependendo da altura em que eram efectuados os testes, por
vezes atingindo picos de performance extremamente baixa em relação à média.
Na procura de possı́veis factores, foi analisada uma relação com todas as máquinas
presentes no servidor ESX Server 2.5 . Identificou-se que duas das máquinas utilizadas
partilhavam processador com diversas máquinas virtuais presentes no sistema de virtua-
lização, o que estaria muito provavelmente a influenciar o seu desempenho.
Cenário B
Os resultados obtidos mostraram uma clara vantagem no rendimento da base de dados

alojada em sistema operativo Windows 2003 Server .
SLES9
RHEL4
W2003
140
120
100
80
0 5 10 15 20
Figura 4.2: Bench - ambiente virtual - cenário B. Resultados registados pela aplicação
Bench. Os gráficos são respeitantes aos diferentes servidores, cujos sistemas operativos de
cada um são o Red Hat Enterprise Linux 4 (RHEL4), SUSE Linux Enterprise Server 9
(SLES9) e Windows 2003 Server (W2003).
Ao serem utilizadas opções de optimização a nı́vel de sistema operativo, não se notou

uma alteração considerável nos resultados obtidos. Este facto sugere alguma incapacidade,
por parte do host, em lidar efectivamente com algum tipo de configurações feitas a mais
baixo nı́vel por parte dos sistemas operativos guest. Esta resistência sobre os mecanismos
de optimização utilizados é imposta pela camada de virtualização que separa estes sistemas
operativos da camada fı́sica de hardware.
Cenário C
Os dados obtidos neste cenário mostraram-se extremamente desfavoráveis à solução

que tinha como sistema operativo o Windows 2003 Server , conforme se pode verificar na
figura 4.3.
SLES9
160
W2003
150
140
130
0 5 10 15 20
Figura 4.3: Bench - ambiente nativo - cenário C - Resultados relativos aos testes realizados
sobre sistema operativo SUSE Linux Enterprise Server 9 (SLES9) e Windows 2003 Server
(W2003).
Este cenário apresentava um ponto bastante importante por atingir no que toca à
equivalência de recursos entre os dois ambientes avaliados, sobretudo no tipo de teste que
estava a ser submetido às bases de dados, em que o acesso a disco representa um aspecto
extremamente importante, perante o tipo de operações submetidas. Com a utilização
de diferentes segmentos do disco por parte de cada um dos ambientes, era provável a
existência de diferenças na velocidade das operações de disco, o que tem um importante
impacto no desempenho, conforme sugeriram os resultados.
Estas expectativas foram confirmadas com a ajuda do Orion (ver secção 4.3.5, na
página 18). Confirmou-se o melhor rendimento das operações de disco no ambiente Linux,
cujas partiçoes, definidas posteriormente às do Windows, estavam localizadas em sectores
onde se atingem maiores velocidades que em sectores iniciais do disco.
Cenário D
Os primeiros resultados apresentados foram obtidos correndo os testes de desempenho

às base de dados em sistemas com a configuração inicial. Esta configuração reflete um
sistema com uma instalação base, em que quer o SGBD, quer o sistema operativo mantêm
as opções standard.
4.5 Resultados 23
Foram também aplicadas algumas optimizações sobre cada um dos ambientes analisa-
dos. No ambiente Windows as diferentes configurações avaliadas testaram a utilização da
opção PAE, 3GB e foi criada ainda outra configuração que conjugava estas duas opções.
No Linux, as configurações testadas adicionalmente compreenderam a utilização de um
kernel actualizado, a recompilação do kernel e a utilização das Hugepages.
Estas configurações foram testadas tanto pela aplicação Bench como pela Hammerora.
Resultados Bench
Os resultados comparativos relativos à configuração inicial podem ser consultados na

figura 4.4. Estes dados manifestam uma performance substancialmente uma melhor por
parte do Windows 2003 Server , em relação ao SUSE Linux Enterprise Server 9 .
125
SLES9
W2003
120
tempo (s)
115
110
0 5 10 15 20
Figura 4.4: Visão comparativa dos resultados da execução da aplicação Bench sobre os
sistemas operativos Windows 2003 Server (W2003) e SUSE Linux Enterprise Server 9
(SLES9), na sua configuração inicial.
Quanto às configurações que utilizaram opções de optimização, são apresentadas na

figura 4.5. Na tabela 4.1 é feito um resumo destes dados, com a média referente a cada
configuração efectuada nos ambientes Windows e Linux.
Resultados Hammerora
Ao realizar o benchmark Hammerora sobre os vários cenários testados, dado que esta
ferramenta se encarrega de realizar o teste mas não de avaliar os desempenhos, foi ne-
cessário procurar um meio de realizar essa medição, através de um mecanismo externo à
aplicação. Para esse efeito, foi utilizada a funcionalidade disponibilizada pela Oracle, o
AWR (ver secção 4.3.3, na página 18).
Os dados recolhidos estão resumidos na tabela 4.2
Os dados observados mostram prestações significativamente melhores sobre a base de
dados alojada em sistema operativo Linux.
130
config.inicial
pae
125 3gb
pae+3gb
120
tempo (s) 115
110
105
100
0 5 10 15 20
130
config. inicial
k. actualizado
125 k. monolitico
hugepages
120
115
tempo (s)
110
105
100
95
0 5 10 15 20
Figura 4.5: Resultados da execução da aplicação Bench sobre os sistemas operativos Win-
dows 2003 Server (W2003), em cima, e SUSE Linux Enterprise Server 9 (SLES9), em
baixo, com as diferentes configurações avaliadas.
Configuração t̄ (s)
Windows
Inicial 115,85
PAE 115,75
3GB 110,85
PAE + 3GB 100,85
Linux
Inicial 120,05
kernel actualizado 118,6
kernel Monolı́tico 103,7
Hugepages utilizadas 100,45
Tabela 4.1: Resultados da execução da aplicação Bench sobre Windows e Linux. Os

valores apresentados representam a duração, em média, de cada teste. São apresentados
os resultados das várias configurações avaliadas.
4.6 Conclusões 25
Configuração TPC-C (Tps)

Windows
Inicial 235,05
PAE 233,94
3GB 214,55
PAE + 3GB 288,42
Linux
Inicial 265,52
kernel actualizado 285,38
kernel Monolı́tico 290,36
Hugepages utilizadas 311,94
Tabela 4.2: Resultados da execução do benchmark TPC-C sobre Windows e Linux através
do Hammerora. Os valores apresentados referem-se a transacções por segundo. São apre-
sentados os resultados das várias configurações avaliadas.
4.6 Conclusões
São muitos os factores que influenciam um estudo de comparação de desempenhos

como o que foi desenvolvido. A principal dificuldade prende-se em limitar esse conjunto
de factores, de modo a conseguir exercer uma análise objectiva e controlada sobre os
cenários criados. Neste sentido, a nı́vel de base de dados, mantiveram-se as opções de
instalação e configuração com os valores facultados por omissão, promovendo uma condição
de igualdade sobre os diferentes ambientes.
O ambiente virtual foi abandonado, no contexto deste estudo. Um dos factores foi a
resistência oferecida pela camada responsável pela virtualização, interposta entre o hard-
ware e o sistema operativo, que funcionava como barreira ao manuseamento de estruturas
a mais baixo nı́vel, quando se pretendia aplicar algumas optimizações. Outro dos fac-
tores relacionou-se com as consequências da partilha de recursos existentes, refletidas no
efeito que umas máquinas exerciam sobre as outras. É certo que daqui deriva um impacto
considerável sobre o rendimento das máquinas. Ainda que esse impacto seja dificilmente
quantificável, não deverá ser negligenciado. Este tipo de comportamentos traduziu-se in-
compatı́vel com a natureza do estudo em causa, em que um dos principais objectivos é
controlar os factores que poderão provocar desvios indesejáveis sobre o rendimento do
sistema.
Pelas razões enunciadas anteriormente, foi o cenário D aquele que apresentou os re-
sultados mais consistentes. Através da sua observação podemos identificar que as duas
aplicações utilizadas revelaram duas tendências diferentes.
Pela aplicação Bench repara-se que o ambiente Linux apenas consegue um comporta-
mento mais competitivo quando aplicadas as opções de optimização. Sobre a configuração
inicial, o ambiente Windows mostra um melhor rendimento.
Ao considerarmos os resultados obtidos com o lançamento do benchmark TPC-C, efec-
tuado pela aplicação Hammerora, deparamo-nos com uma redundante vantagem para a
base de dados a correr no sistema operativo SUSE Linux Enterprise Server 9 , em que o
melhor comportamento, comparativamente ao ambiente Windows 2003 Server , é trans-
versal a todas as configurações avaliadas.
Como a aplicação Bench apresenta uma carga mais pesada a nı́vel de acesso a disco,
pode considerar-se que o subsistema de sistema de ficheiros no Linux seja menos eficiente
perante o tipo de operações predominante nesta aplicação. No entanto, com vista à ins-
talação do Oracle Database 10 g Real Application Clusters, e ao funcionamento de bases
de dados, esse facto teria pouca importância. As operações E/S nesse tipo de plataforma
são essencialmente realizadas sobre os ficheiros de dados e estes ficheiros encontram-se fora
do âmbito do sistema de ficheiros locais. Encontram-se num espaço de armazenamento
partilhado, mantido geralmente em equipamentos dedicados.
Com o estudo realizado, e analisados os resultados obtidos, decidiu-se adoptar o Linux,
nomeadamente a distribuição SUSE Linux Enterprise Server 9 , como sistema operativo
a instalar nos nós necessários à implementação da plataforma que sustentará o Oracle
Database 10 g, com a extensão Real Application Clusters. Sobre esta plataforma será
criada uma base de dados a funcionar em cluster . Neste ponto descartam-se os restantes
sistemas operativos avaliados.
Capı́tulo 5
Requisitos tecnológicos para

Real Application Clusters
Para efectuar a instalação do Oracle Database 10 g Release 2 (10.2) Real Application

Clusters é necessário criar previamente uma plataforma que lhe faculte a base tecnológica
de que depende o seu correcto funcionamento. O ambiente RAC assenta num funcio-
namento em cluster , onde vários computadores se encarregam de uma tarefa conjunta,
compartindo e colaborando entre si para correr uma base de dados comum.
Em primeiro lugar, é necessário criar uma
camada responsável por permitir e adminis-
trar o trabalho em grupo. Esta camada tem Rede publica
como responsabilidades registar a entrada ou
saı́da dos vários nós no cluster , exercer o con- No1
VIP
No2
VIP
trolo sobre os membros do cluster , efectuar

Instancia BD1 Instancia BD2
uma monitorização sobre o estado de cada
membro activo ou favorecer a tomada de de- Instancia ASM1 Instancia ASM2
cisões em grupo, promovendo canais de inter-
O. Clusterware O. Clusterware
ligação que permitam uma rápida troca de in-
Interligacao
formação entre eles. Sist. Operativo Sist. Operativo
cache-cache
Ao software que exerce estas responsabi- Armazenamento
lidades denomina-se clusterware. Para uti- partilhado
lização do RAC deve utilizar-se obrigatoria- ich.Controlo

mente o Oracle Clusterware. Este pode funci- Fich.de Dados
onar em modo exclusivo ou, caso existam ou-
tros productos dedicados a estas funções, inte-
ASM
{ Redo logs
ragir com eles de modo a estabelecer a ponte OCFS2 { OCR

Voting D.
entre estas soluções e o Oracle Real Applica-
tion Clusters.
Outro dos requisitos de que depende o fun-
cionamento RAC é dispôr de um espaço de
armazenamento partilhado, disposto numa ca- Figura 5.1: Arquitectura tecnológica para
mada independente, onde todos os nós possam Real Application Clusters
aceder em igualdade de circunstâncias. Aqui
serão mantidos os ficheiros de dados utiliza-
dos pela base de dados, assim como alguns ficheiros de que depende o Clusterware. Para
28 Requisitos tecnológicos para Real Application Clusters
cumprir este requisito podem ser tomadas diferentes opções, perante as diferentes soluções
tecnológicas disponı́veis. As principais são apresentadas mais adiante neste capı́tulo, na
secção 5.2.
5.1 Oracle Clusterware
Podemos considerar que estamos perante um “cluster ” quando temos múltiplos compu-
tadores ou servidores que aparentam ser apenas um servidor, perante os utilizadores finais
ou aplicações [48]. Vamos ainda considerar que falamos de duas ou mais máquinas com
partilha de disco rı́gido, que correm sobre o mesmo sistema operativo e estão interligados
através de uma rede comum.
O Oracle Clusterware, formalmente designado por Cluster Ready Services (CRS), é
uma solução integrada de gestão a nı́vel de cluster que permite ligar diversos servidores,
de modo que funcionam como um único sistema. Ajuda a agrupar um conjunto de trabalho
aplicacional que está sobre seu controlo [49].
É facultado por esta solução um conjunto de serviços de gestão do sistema e tem a
capacidade de exercer uma interacção com outros produtos de clusterware especializados,
caso sejam utilizados, de modo a coordenar informação a respeito dos membros do cluster.
O Oracle Cluster Registry (OCR) contém informação sobre a base de dados e sobre o
cluster , para os Cluster Ready Services a operar com Real Application Clusters (RAC).
Este ficheiro guarda a lista de nós na base de dados “clusterizada”, a aplicação CRS, perfis
de recursos utilizados e as autorizações para o Event Manager.
O OCR tem de ser alojado num espaço de armazenamento partilhado. Pode residir
num ficheiro contido num Cluster File System (sistema de ficheiros com funcionalidades
dedicadas ao ambiente em cluster ) ou num dispositivo Raw . A localização a utilizar para
o ficheiro OCR é especificada durante o processo de instalação do Oracle Clusterware.
Outro ficheiro do Oracle Clusterware a guardar no espaço partilhado é o Voting Disk,
que contém informação durante a operação, relativa aos membros activos no cluster a cada
momento.
5.1.1 Instalação
A sua directoria Home requere a existencia de 120MB, no mı́nimo, disponı́veis no

sistema de ficheiros em que está montada a directoria, para poder efectuar instalação
deste software. Onde for alojada a Home do Clusterware, o utilizador oracle deverá ter
previlégios de escrita.
São necessários 512MB de memória RAM disponı́vel para efectuar a sua instalação.
A criação da Home para o Clusterware é feita pelo OUI, e não deverá estar definida a
variável de ambiente TNS_ADMIN:
# unset TNS_ADMIN
Na preparação da instalação para o Oracle Clusterware, deverão estar definidas as
variáveis de ambiente respectivas à directoria base e à directoria home do Clusterware:
# ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
# ORACLE_HOME=/u01/crs/oracle/product/10/app; export ORACLE_HOME
5.2 Armazenamento partilhado 29
Caso se pretenda criar esta directoria, utilizar:

# mkdir -p /u01/crs/oracle/product/10/app
# chown -R root:oinstall /u01/crs
# chmod -R 775 /u01/crs/oracle
Depois da instalação, as permissões deverão ser alteradas de modo a que apenas a
conta do utilizador root possa efectuar operações de escrita na directoria Home do Oracle
Clusterware.
5.2 Armazenamento partilhado
Esta secção trata de um dos pontos chave dos quais depende a arquitectura dos Real
Application Clusters da Oracle, o acesso ao armazenamento partilhado em disco.
A arquitectura RAC é baseada no armazenamento partilhado. Os ficheiros da base
de dados, redo logs e ficheiros de controlo são mantidos num espaço a que todos os nós
pertencentes ao cluster acedem. Não só estes ficheiros são aqui mantidos, também alguns
componentes necessários ao Clusterware, o Oracle Cluster Registry (OCR) e o Voting
Disk, têm necessidade de estar alojados em ambiente partilhado, para que o sistema possa
funcionar.
Para além disso, com a nova versão Oracle Cluster File System 2 (OCFS2), é possı́vel
alojar também o software da base de dados. Esta é uma visão atı́pica do que costuma
acontecer num ambiente em cluster , onde não costuma haver partilha a este nı́vel.
A infraestrurura onde é feito o armazenamento pode ser de diferentes tipos. Pode
ser uma Storage Area Network (SAN), tı́pica em ambientes empresariais de larga escala,
Network Attached Storage (NAS), tipicamente disponibilizada através de servidores NFS,
ou dispositivos ligados directamente, que facultam a facilidade de partilha, normalmente
acedidos através de SCSI sobre cobre ou fibra óptica.
ASM
OCFS
BD
Oracle
Raw RAC
Clusterware
NFS
SCSI, discos c/
NAS SAN
partilha de bus
Figura 5.2: Relação das opções de armazenamento partilhado disponı́veis (em baixo), com
os métodos de acesso que se lhes podem aplicar (representados pelas caixas a picotado)
para possibilitar o alojamento da base de dados RAC e do Clusterware. As zonas fronteira
(tracejado forte) são as zonas de decisão que representam pontos onde deve ser escolhida
uma das opções. Existem casos de dependência estrita que estão representados pelas setas
a azul, em que para a adopção de uma opção há uma obrigatoriedade de satistfazer essa
dependência.
A par da infra-estrutura propriamente dita, há que definir os métodos de acesso aos
dispositivos de armazenamento partilhado. Na figura 5.2, podemos ver um esquema que
tenta resumir a relação entre as opções de infraestrutura a adoptar e os métodos de acesso
que podem ser utilizados. Ao criar uma plataforma RAC, tanto o Oracle Clusterware como
a base de dados necessitam dispôr do armazenamento partilhado para o seu funcionamento.
A base de dados pode utilizar qualquer uma das opções, devendo a sua escolha recair na
solução que lhe dê maiores vantagens de acordo com os recursos que existem à disposição.
Já o Clusterware não pode utilizar o ASM para colocar os seus ficheiros, pois sem existir
já activa uma camada de clusterware o ASM não pode operar. Isto sucede porque a
sua execução depende dos serviços prestados pelo Clusterware, da coordenação por ele
prestada às diferentes instâncias Oracle que no incumprimento deste requisito se vêm
incapazes de funcionar. Quanto ao NFS, necessita obrigatoriamente que a infraestrutura
utilizada seja o NAS, dado que se baseia num método de acesso a armazenamento remoto
por rede, necessita que a infra-estrutura utilizada faculte um acesso baseada numa ligação
IP, como é o caso NAS.
5.2.1 Partições Raw
Quando se fala em dispositivos Raw num contexto aplicado a dispositivos de armaze-

namento ou partições, está subjacente a ausência de um sistema de ficheiros nesse disco
ou partição. Na secção 3.2.2 são retratados os traços gerais de um sistema de ficheiros.
Ao contrário do que podemos dizer sobre o acesso ao armazenamento suportado por um
sistema desse tipo, a gestão do acesso feito aos dispositivos Raw é tratada directamente
pela aplicação que os utiliza, através de uma interface semelhante à utilizada para o ma-
nuseamento de ficheiros, através da qual são efectuadas sobre eles operações de leitura e
escrita.
Com a utilização de dispositivos Raw para a base de dados, cada Tablespace necessita
de uma partição e não é permitido guardar ficheiros regulares nestes recursos.
Foi testada a sua configuração para conter os ficheiros utilizados pelo Oracle Clus-
terware, OCR, Voting Disk e SPFILE (ficheiro que guarda a parametrização de uma
instância Oracle) a serem partilhados pelos nós. Nesta configuração os ficheiros utilizados
pela base de dados, também partilhados, ficaram alojados com a opção Automatic Storage
Management. Ao experimentar esta modalidade, foi verificado que o processo de confi-
guração é mais complexo que utilizando outras soluções como OCFS ou ASM. Por outro
lado mostrou-se pouco apelativo, quer pela necessidade de configuração de um dispositivo
Raw independente para cada ficheiro que se queira introduzir, quer pela pouca manea-
bilidade que este método oferece, ao ter de estabelecer a priori o tamanho da partição
exclusiva a cada ficheiro, com o risco de poder vir a ser considerado pouco numa fase
posterior, significando uma quebra no serviço, ou, pelo pólo oposto, estar a reservar um
espaço excessivamente grande, que estará a ser desaproveitado.
5.2.2 Oracle Cluster File Sistem 2
O Oracle Cluster File System (OCFS) é um sistema de ficheiros em cluster. Um sistema

de ficheiros em cluster permite que todos os nós de um cluster acedam concorrentemente
ao dispositivo através da interface de um sistema de ficheiros standard.
A primeira versão do OCFS foi lançada em Dezembro de 2002 para permitir aos utili-
zadores do Oracle Real Application Clusters (RAC) correr a base de dados em cluster sem
ter de configurar os dispositivos Raw. Essa versão foi desenhada para armazenar ficheiros
relacionados com a base de dados e não era permitido guardar ficheiros regulares. Esta
limitação foi levantada na versão seguinte.
A nova geração, o OCFS2, foi introduzida em Agosto de 2005 para as plataformas
Red Hat Enterprise Linux 4 e Suse Linux Enterprise Server 9. Com capacidades para
armazenar ficheiros regulares, é uma alternativa não só para guardar os ficheiros criados
pela base de dados como também os ficheiros binários e de configuração dos produtos
Oracle. Isto possibilita que tenhamos uma Home partilhada pelos diversos nós do cluster,
permitindo um ponto de gestão centralizado, que poderá facilitar algumas tarefas.
Os volumes utilizados com este tipo de partição com o objectivo de alojar especifica-
mente os componentes partilhados do cluster RAC como Voting Disk, Cluster Registry do
Oracle Clusterware, ou os ficheiros da base de dados como Data files, Redo logs, Archive
logs e Control logs devem ser montados com três opções fundamentais para o seu correcto
funcionamento:
datavolume Certifica que os processos Oracle abrem estes ficheiros com a flag o direct
nointr Comprova que as operações de escrita/leitura não são interrompidas por sinais
netdev Indica que este volume é dependente da ligação à rede, garantindo que a rede
seja ligada antes que entre em funcionamento e que, ao desligar, os serviços de
rede sejam desactivados apenas depois deste volume ser posto em inoperatividade
O2CB Cluster Service
O O2CB é um serviço que controla o funcionamento em cluster do Oracle Cluster File

System 2 . Para efectuar as diversas operações sobre o sistema de ficheiros é necessário
que este serviço esteja activo.
O O2CB é mais precisamente um grupo de serviços que são referidos também como
pilha do cluster OCFS2. Deste grupo fazem parte os serviços:
• Node Manager: Faz o seguimento dos membros do cluster declarados no ficheiro de

configuração.
• Heartbeat: Monitoriza e efectua notificações de entrada ou saı́da de actividade

quando um dos nós se junta ou abandona o cluster.
• TCP: Trata da comunicação entre os nós.
• DLM: Gestor de trincos distribuı́do, que mantém o controlo dos trincos existentes,
seus donos e seu estado actual
• CONFIGFS: Comunica a lista de nós no cluster ao módulo Node Manager carregado

e comunica os recursos utilizados à thread do heartbeat.
• DLMFS: Comunica operações de reserva ou libertação de trincos sobre os recursos

ao módulo DLM.
Heartbeat
O Heartbeat é um mecanismo que o OCFS usa para manter um controlo sobre o

funcionamento do cluster e ter uma ideia de quais os nós activos em qualquer altura.
Existe um processo de “pulsação” através de escritas em disco e outro através da rede,
através das ligações estabelecidas entre os membros do cluster.
Quando é criado o sistema de ficheiros, é reservado um conjunto contı́guo de sectores
alocado no ficheiro de sistema do Heartbeat. Cada nó registado no sistema de ficheiros
tem um identificador único que funciona como offset e estabelece em que sector deverá
efectuar o seu processo de escrita.
Com uma dada frequência, cada nó tem de marcar uma “pulsação” apontando uma
marca temporal no sector que lhe corresponde, no espaço reservado ao Heartbeat na
partição partilhada. Deste modo indica que se encontra em estado activo dentro do cluster.
A frequência com que este processo é efectuado está relacionada com o parâmetro
O2CB HEARTBEAT THRESHOLD. Este é usado para calcular o tempo de espera que
deve ser utilizado para considerar que um nó já não está activo. O cálculo baseia-se
na fórmula ((O2CB HEARTBEAT THRESHOLD - 1) * 2), que dá o perı́odo de espera
a considerar, em segundos. Quando este perı́odo se esgota, o nó é dado como inactivo
dentro do cluster e poderá ser configurado para proceder a um restauro de sistema.
Durante o processo de instalação do Oracle Clusterware, ao ser utilizado o OCFS2 para
conter os ficheiros de controlo, foi reportado um erro, quando solicitada a localização para
o ficheiro Oracle Cluster Registry (secção 5.1) que indicava que este sistema de ficheiros
não estava a ser correctamente partilhado por todos os nós. Este evento, causado por uma
quebra no Heartbeat, por ter definida uma frequência demasiado elevada, era interpretado
como uma falha de um dos membros do cluster.
O valor por omissão do parâmetro O2CB HEARTBEAT THRESHOLD adapta-se a
sistemas de armazenamento de alto rendimento (tipicamente configurados em Storage Area
Networks), que não é adequado, de uma maneira geral, a ambientes de teste, com nı́veis
de performance inferiores. Por esse motivo foi necessário relaxar esse parâmetro para um
valor menos exigente computacionalmente.
Opções
Com a possibilidade de usar ficheiros regulares, pode ser alojado na partição partilhada
em OCFS2 o software necessário à instalação dos produtos Oracle. Essa opção não foi
escolhida dado que como não está presente um mecanismo de mirroring/striping externo,
seria estabelecer um potencial ponto de estrangulamento, com os nós a concorrerem no
acesso, o que não é apropriado na utilização de um recurso de performance limitada como
o que foi utilizado.
Neste sistema de ficheiros foram apenas mantidos os ficheiros a ser partilhados para o
Clusterware. Também os ficheiros da base de dados poderiam ser aqui colocados, porém
para este fim foi usada a opção Automatic Storage Management (ASM) (apresentada na
secção 5.2.4), que permite algumas facilidades suplementares na gestão do armazenamento.
5.2.3 Network File System
Esta é também uma solução possı́vel para funcionar com os Oracle Real Application
Clusters, porém a Oracle apenas recomenda a sua utilização sob um conjunto limitado de
soluções fornecidos por parceiros certificados com polı́ticas de licenças de acesso restrito.
Para sua utilização é necessário que seja utilizado o protocolo TCP, que os blocos de
escrita/leitura usados sejam de 32kB e com servidores que permitam um acesso directo de
E/S.
Segundo a Oracle, é preferı́vel a utilização de outras alternativas, como OCFS ou
ASM, para disponibilizar o armazenamento partilhado para RAC. Por outro lado, a
indisponibilidade do software necessário devidamente licenciado traduzia o incumprimento
dos seus requisitos. Por estas razões este método não foi utilizado.
5.2.4 Automatic Storage Management
O Automatic Storage Management (ASM) é uma facilidade introduzida com o Oracle

Database 10 g, que contribui grandemente para minorar o esforço que um administrador
de bases de dados (DBA) necessita dispender com as tarefas de gestão de ficheiros e de
discos usados pela base de dados (BD). Isto porque o ASM se encarrega de administrar
os dispositivos de armazenamento que tem à sua disposição. Trata de criar ou eliminar
os ficheiros necessários à utilização da BD, gerindo o seu nome e localização, assim como
a forma em que são dispostos pelos discos que tem sob seu controlo. Efectua também
as operações necessárias para retirar o máximo rendimento e dar garantias de segurança
sobre os dados guardados, através de mecanismos de striping e mirroring, sem que para
isto seja necessária a intervenção do DBA. O ASM pode ser utilizado noutros procedi-
mentos administrativos, incluindo a criação e recuperação de cópias de segurança ou a
administração de discos.
Striping é um processo automático que trata de guardar a informação de uma forma

dispersa por múltiplos discos. Reparte o bloco de dados a armazenar em blocos
mais pequenos, que são disseminados simultaneamente nos discos onde se aplica.
Como as operações de escrita e leitura são executadas em paralelo, torna o seu
armazenamento ou extracção mais eficiente, conseguindo assim maiores velocidades
de transferência. Com o ASM, a informação é particionada em blocos de 1MB.
Mirroring é um processo que escreve os mesmos dados em múltiplos discos, replicando a

informação, de modo a aplicar redundância sobre os conteúdos armazenados. Deste
modo, caso os dados num dos discos sejam corrompidos ou um dos discos deixe de
funcionar, o acesso à informação continua a poder ser feito através dos dispositivos
restantes.
Instância ASM
O Automatic Storage Management (ASM) corre através de uma instância Oracle

própria. Durante o seu processo de arranque, os grupos de discos configurados e ficheiros
neles contidos são identificados. Os discos membros são montados e é criada uma tabela
de mapeamento entre os recursos e os seus conteúdos, que é passada à instância da base de
dados, de modo a que esta possa localizar e efectuar directamente as operações necessárias
sobre os ficheiros guardados. A partir daqui, a instância ASM passa envolver-se apenas
para criar ou eliminar um ficheiro, ou quando surjam alterações na configuração dos discos
(ao ser adicionado ou removido um disco).
Quando é adicionado ou removido um disco de um Disk Group é feito um balancea-

mento dos dados contidos e a instância da base de dados é informada das alterações na
configuração. Por isso, e de modo a que a base de dados possa aceder sempre aos ficheiros
guardados, é necessário que a instância ASM esteja a correr durante todo o perı́odo em
que a base de dados esteja em funcionamento, devendo apenas terminar após ser encerrada
a instância da base de dados [50].
Quando é utilizado o ASM, as duas instâncias, a do ASM e da base de dados, funcionam
concorrentemente, dada a dependência da segunda em relação à primeira, o que poderia
significar uma forte penalização do sistema pela carga computacional causada. Porém, de
uma forma geral, como a alocação de memória do ASM não excede os 64MB, o impacto
causado sobre a performance da instância da base de dados é mı́nimo.
Configuração do ASM
Com a utilização deste método de acesso ao armazenamento partilhado, a manipulação

dos discos é feita directamente pelo ASM. Ao utilizador cabe criar os grupos de discos
(Disk Groups), aos quais lhes associa os discos fı́sicos pretendidos, e definir qual deve
ser a utilização desse grupo. Ao Disk Group pode ser adicionado ou removido um disco
sem penalizar a disponibilidade da base de dados, desde que conserve ainda (nos discos
restantes) capacidade para satisfazer as necessidades requeridas.
Nas plataformas Linux, o ASM pode ser configurado usando duas diferentes alterna-
tivas. Uma é através de dispositivos Raw , em que são usadas as operações E/S standard
do Linux. É necessário criar um dispositivo Raw para cada uma das partições de disco
necessitadas pelo ASM [51]. Outra alternativa é utilizando o ASMlib, que não necessita
a configuração de dispositivos Raw , já que manuseia directamente as partições que tem
atribuı́das, ao nı́vel dos blocos de disco.
Opções de armazenamento
Quando é utilizada a opção Automatic Storage Management, esta ferramenta encarrega-

-se da gestão dos discos atribuı́dos e da utilização que é feita por esta O Automatic Storage
Management faz a gestão dos discos que tem
Disk Group (DG) - Indentifica o conjunto de discos a ser gerido como uma única uni-
dade lógica. Através deste conceito, o ASM elimina a complexidade associada à
gestão de uma enorme quantidade de dados e discos. Também simplifica os proces-
sos de aplicação de mirroring, adição de discos e sua remoção. O administrador da
base de dados fica com as suas tarefas significativamente simplificadas.
Dados com diferentes caracterı́sticas deverão ser guardados em grupos de discos
distintos. Para cada um desses grupos poderá ser definido um nı́vel particular de
redundância, definindo subgrupos de falha que estabeleçam uma configuração parti-
cular.
Exemplos de Disk Groups diferentes:
– DG para uso geral de uma base de dados.
– DG para recuperação, albergando a Flash Recovery Area.
– DG para histórico de dados.
Failure Group (FG) define um grupo de discos ou partições que partilham componen-
tes, de modo a que se um desses componentes falhar, os outros discos que dele
dependem também falham. Um exemplo de um grupo de falha pode ser um con-
junto de discos SCSI que partilham a mesma controladora SCSI. Num cenário de
falha dessa controladora, todo esse grupo de discos se torna indisponı́vel. Neste
exemplo, o conjunto de discos fazem parte do mesmo grupo de falha, devendo por
isso ser declarado como Failure Group. Como resultado desta declaração, a instância
ASM não irá utilizar discos dentro do mesmo grupo de falha para efectuar processos
de mirroring entre si. Pelo contrário, efectuará tal procedimento entre grupos de
falha distintos, para assim aumentar o nı́vel de protecção dos dados guardados.
Isto permite a perda ou falha de componentes sem que daı́ resulte uma perda dos dados
nele contidos.
Nı́veis de redundância:
• Externa - opção desabilitada

Quando este nı́vel é escolhido, a instância ASM não aplica qualquer mecanismo de
redundância sobre os dados guardados nos grupo de discos. Esta opção é empregue
geralmente quando existem mecanismos externos que oferecem esta propriedade ou
se os dados a ser armazenados não justificam tal medida.
• Normal - Necessário definir 2 FG

Este nı́vel é o utilizado por omissão numa instalação tı́pica. Aplica redundância
sobre os dados guardando-os em duplicado, através de mecanismos de mirroring.
Com esta opção são utilizados dois Failure Groups, que poderão ser configurados
pelo utilizador ou, caso não sejam declarados, são assumidos próprio pelo ASM.
Permite no máximo a perda de um dos grupos de falha.
• Elevada - Definir 3 FG
Com este nı́vel de redundância os dados são guardados em triplicado. Toda a in-
formação manuseada tem duas cópias redundantes e são utilizados três grupos de
falha. Com esta opção, é possı́vel a falha em dois dos grupos de falha que ainda
assim o terceiro é capaz de conter uma cópia completa dos dados contidos no Disk
Group.
Flash Recovery Area
A Flash Recovery Area é utilizada para recuperar dados que de outra maneira se
perderiam durante uma falha de sistema. É também utilizada pelo Enterprise Manager
caso esteja habilitada a opção de gestão local e cópias de segurança diárias, opções definidas
na página de “Opções de Configuração”, no processo de configuração da base de dados a
partir do Database Configuration Assistant.
Esta área é um espaço que pode ser localizado num sistema de ficheiros, numa directoria
gerida pelo software Oracle ou um Disk Group do ASM, que disponibiliza uma localização
centralizada em disco para guardar cópias de segurança e ficheiros de recuperação.
O Enterprise Manager pode usar este espaço para armazenar as suas cópias de segu-
rança e usa-o para proceder à recuperação de ficheiros. Os componentes de recuperação
da Oracle interagem com a Flash Recovery Area assegurando-se que a base de dados é
completamente recuperável usando os ficheiros aı́ contidos. Todos os ficheiros necessários

à recuperação da base de dados após a falha de um dos seus dispositivos fazem parte desta
área.
A Flash Recovery Area pode ser usada como um tipo de cache de disco para cópias de
segurança em tapes, abreviando os processos de recuperação e permitindo uma gestão de
cópias de segurança automatizada.
5.2.5 Prós e contras dos diferentes métodos
É apresentada, na tabela 5.1, uma sı́ntese dos principais pontos a favor e contra de
cada um dos métodos de acesso ao armazenamento partilhado, analisados anteriormente.
Ideal para quem tenha de tomar uma decisão em 5 minutos.
+/- Justificação
RAW
+ Não é necessário instalar clusterware da Oracle ou de outro
fornecedor, nem drivers adicionais
− Gestão penosa das partições necessárias
− Escalabilidade - complicadas operações de reparticiona-
mento ou adição de novas partições
NFS
+ Solução de baixo custo
+ Facilidade de utilização
− Apenas disponı́vel para SO’s de famı́lia Unix
− Não recomendado para grandes cargas transaccionais
OCFS2
+ Permite ficheiros regulares (pode alojar o software da BD
Oracle)
+ Aceita operações tı́picas fornecidas por um sistema de fichei-
ros regular
+ Fornece uma solução tanto para Linux como para Windows
− Não tão fácil de gerir como o ASM
ASM
+ Disponibiliza mecanismos de striping e mirroring
+ Grande facilidade de gestão, quer através de sintaxe Oracle,
quer através do Enterprise Manager
+ Óptima escalabilidade
− Difı́cil o manuseamento directo dos ficheiros contidos
− Não é possı́vel guardar os ficheiros do Oracle Clusterware
Tabela 5.1: Métodos alternativos de acesso ao armazenamento partilhado: algumas van-

tagens (+) e desvantagens (-).
Capı́tulo 6
Real Application Clusters (RAC)
O Real Application Clusters (RAC) pode considerar-se uma extensão ao servidor de

base de dados Oracle, que faculta um desdobramento da base de dados por diferentes
nós. Com uma arquitectura em grelha1 , fornece soluções em termos de tolerância a fal-
tas, disponibilidade e escalabilidade dos clusters em ambientes Linux, Unix ou Windows.
Substitui desde a versão Oracle9i o Oracle Parallel Server (OPS) e tem no Oracle Data-
base 10 g um novo nı́vel de portabilidade, em que as plataformas Oracle que o suportam
têm já à sua disposição uma camada de clusterware para interligação com o RAC.
Grande parte da informação pesquisada sobre este tema foi fornecida pela Oracle,
através da documentação técnica a que dá acesso através da sua página web, à qual
podemos aceder pelo endereço http://www.oracle.com.
6.1 Arquitectura
Uma base de dados Real Application Clusters é uma base de dados que funciona em
cluster , ou seja, é formada por um grupo de servidores independentes que cooperam
entre si, funcionando como um único sistema. Esta solução favorece o crescimento do
sistema através de um incremento modular, ao invés de promover pesados sistemas de
multiprocessadores simétricos (SMP). Ao haver uma falha do sistema, o funcionamento
em cluster assegura uma alta disponibilidade do serviço aos utilizadores, de modo a que
não se perca o acesso a dados crı́ticos.
Uma arquitectura RAC utiliza hardware redundante de modo a evitar os “pontos
únicos de falha”. Deste modo, quando sucede uma quebra imprevista no funcionamento
de um dos seus componentes, o que geralmente significaria uma quebra temporária do
serviço prestado, poderá ser suportado pelos componentes restantes que se mantenham
operacionais. O facto de haver uma multiplicidade de nós, interligações e discos no sistema
de armazenamento partilhado, permitem ao cluster garantir uma maior resistência aos
perı́odos de indisponibilidade.
Com a opção RAC, desacoplamos a instância Oracle (as estruturas e processos a correr
num servidor que permitem o acesso aos dados) da base de dados Oracle (as estructuras
fı́sicas residentes no espaço de armazenamento, referidas de uma maneira geral como fi-
cheiros de dados). Para isto contribui o facto destes ficheiros de dados serem alojados num
espaço comum de armazenamento, onde cada um dos nós tem o mesmo nı́vel de acesso.
1
ou grid (em inglês) - de onde vem o g de 10g.
38 Real Application Clusters (RAC)
Uma base de dados a funcionar em cluster , apesar de ser uma única BD, pode ser
acedida através de diversas instâncias. Cada instância corre num nó distinto do cluster .
Quando são requeridos recursos adicionais (como um novo servidor de base de dados ou
um par de discos), podem ser facilmente adicionados ao cluster , sem que seja necessário
suspender o serviço prestado pelos nós activos. A partir do momento em que uma nova
instância é iniciada, as aplicações que usam os serviços da base de dados podem imedia-
tamente dispôr do novo recurso, sem que para isso seja necessário introduzir alterações à
aplicação ou ao servidor de aplicações.
Figura 6.1: Arquitectura fı́sica Real Application Clusters
De acordo com o que se pode ver na figura 6.1, nesta arquitectura existe um elevado
grau de partilha em cada camada. Ao nı́vel do armazenamento partilhado, onde são
guardados os ficheiros de dados da BD, é mantido um acesso equidistante desde os vários
membros do cluster aos discos, que são alojados numa localização independente e cujos
métodos de acesso configurados permitem que os seus conteúdos sejam compartidos, de
modo concorrente, pelos vários nós. Ao nı́vel dos membros do cluster , onde são mantidas
as diferentes instâncias da BD, são partilhadas estruturas de memória, que através de
uma eficaz troca de mensagens de baixa latência, mantêm uma vista comum sobre o
estado actual da base de dados (através do mecanismo de Cache Fusion, apresentado na
secção 6.1.1). Ao nı́vel de rede, cada membro partilha duas sub-redes. Uma privada, onde
se estabelecem as interligações de alta velocidade que garantem a troca de mensagens
reservada ao funcionamento do cluster e outra pública, onde são estabelecidas as ligações
com as aplicações cliente ou por onde se estabelece a ligação com a consola de gestão
centralizada, capaz de administrar as inúmeras opções configuráveis deste software.
6.2 Requisitos 39
6.1.1 Cache Fusion
Um sistema Real Application Clusters equipado com uma tecnologia de interligação

de baixa latência e alta velocidade possibilita que o buffer da cache de cada nó se possa
fundir e formar virtualmente uma única “cache global”, de onde vem a denominação de
Cache Fusion.
Através desta arquitectura, este mecanismo cria uma cache partilhada e fornece uma
única imagem ou vista sobre a cache às aplicações.
De um ponto de vista funcional, uma instância num sistema RAC é equivalente a uma
única base de dados Oracle. Tem todos os mecanismos das bases de dados de instância
única, familiares aos administradores de bases de dados. A fusão de múltiplos buffers de
cache numa única cache global traduz-se num ponto a favor da escalabilidade, confiabili-
dade e disponibilidade.
Enquanto a Cache Fusion disponibiliza aos utilizadores Oracle uma cache expandida
da base de dados, para consultas e actualizações de operações de E/S, uma melhor perfor-
mance depende grandemente da eficiência do mecanismo de passagem de mensagens entre
os nós, que trata das transferências dos blocos de dados [52].
6.2 Requisitos
6.2.1 Hardware
Segundo é documentado pela Oracle [48], cada um dos elementos do cluster deve ter
disponı́vel:
• Pelo menos 1GB de memória RAM

– Para determinar o tamanho fı́sico da memória RAM:2
# grep MemTotal /proc/meminfo
• Espaço Swap
O espaço Swap é necessário para a utilização da memória virtual. Para isso deve
ser criada uma partição Swap dedicada (ou mais), processo configurável durante o
processo de instalação do sistema operativo, porém, caso seja necessário, pode ser
alocado mais espaço numa fase posterior. A quantidade de espaço em disco ocupada
para este efeito deve ser no mı́nimo igual à quantidade de memória RAM presente.
Consultar a tabela 6.1 para aplicar o tamanho apropriado.
RAM disponı́vel Espaço Swap necessário

Entre 1GB e 2GB 1,5 vezes o tamanho da RAM
Mais de 2GB Igual ao tamanho da RAM
Tabela 6.1: Esta tabela mostra a recomendação para o espaço Swap a utilizar.
– Para verificar a quantidade de espaço configurado como Swap: 2
2
A seguinte instrução deve ser executado na linha de comandos
# grep SwapTotal /proc/meminfo
• Pelo menos 400MB de espaço disponı́vel na directoria /tmp.

– Para determinar a quantidade de espaço em disco disponı́vel a esta directoria,
executar 2 :
# df -h /tmp
• Deve haver em disco espaço suficiente para o software Oracle, que pode alcançar os
4GB, dependendo do tipo de instalação e plataforma.
– Para verificar a quantidade de espaço existente nas diferentes partições disponı́veis,
introduzir:
# df -h
6.2.2 Software
A lista resumida do software necessário à instalação Oracle Real Application Clusters

em sistemas Linux x86 (32-bit) é mostrada na página 41 (ver tabela 6.2), com especial
foco na distribuição escolhida – SUSE Linux Enterprise Server 9 . Faz parte desta lista
o sistema operativo, onde são apresentadas as alternativas com certificação Oracle; a
versão do kernel, onde se indica qual a versão considerada como mı́nima (a utilização de
uma versão actualizada do kernel, caso exista, é recomendável); o conjunto de pacotes
de software (normalmente com extensão “.rpm”3 ), que podem ser escolhidos durante a
instalação do sistema operativo ou posteriormente incorporados através de um gestor de
pacotes.
Segundo a Oracle, não é dada assistência às instalações em ambiente Linux efectuadas
noutras distribuições que não as que constam na tabela apresentada.
Para determinar qual a distribuição e versão Linux actualmente instalada, executar na
linha de comandos:
# cat /etc/issue
Para verificar que versão do kernel está instalada com a presente distribuição Linux,
executar na linha de comandos:
# uname -r
No que diz respeito aos pacotes de software instalados, na comprovação que os requi-
sitos são cumpridos, pode ser executado um comando semelhante ao seguinte:
# rpm -q NOME_DO_PACOTE
ou
# rpm -qa | grep NOME_DO_PACOTE
Quanto ao Oracle Cluster File System 2 , a versão disponibilizada com o SUSE Linux
Enterprise Server 9 não tem, de uma maneira geral, um paralelismo no que respeita
ao seu número de versão com o OCFS2 presente no site oficial (http://oss.oracle.com/
projects/ocfs2/). Isto acontece devido à polı́tica de gestão de versões ser gerida por
3
...de Redhat Package Manager
6.2 Requisitos 41
Item Requisito
Sistema operativo x86 SUSE Linux Enterprise Server 9 (SP2 ou posterior)
Red Hat Enterprise Linux AS/ES 3 (Update 3 ou posterior)
Red Hat Enterprise Linux AS/ES 4 (Update 1 ou posterior)
Versão do Kernel O sistema deve correr no seguinte kernel (ou versão posterior)
SUSE Linux Enterprise Server 9 :
2.6.5-7.97
Red Hat Enterprise Linux 3 (Update 4):
2.4.21-27.EL
Red Hat Enterprise Linux 4 (Update 1):
2.6.9-11.EL
SLES9 (SP2) gcc-3.3

deve conter os seguintes gcc-c++-3.3.3-43
pacotes instalados glibc-2.3.3-98.28
libaio-0.3.98-18
libaio-devel-0.3.98-18
make-3.80
openmotif-libs-2.2.2-519.1
Oracle Real Application Para um sistema de ficheiros clusterizado, usar:

Clusters Oracle Cluster File System 2
OCFS2 é distribuı́do com SUSE Linux Enterprise Server 9 SP2
ou posterior.
Caso esteja instalado o SLES9, deve comprovar-se a instalação
deste Service Pack (ou um mais actual)
Instalação dos pacotes:
ocfs2-tools
ocfs2console
Tabela 6.2: Requisitos para sistemas Linux x86 (32-bit). Versão do kernel e pacotes a
instalar para a opção SUSE Linux Enterprise Server 9
entidades diferentes, com etapas de compilação não coincidentes no tempo. A origem do

seu código fonte é no entanto semelhante.
6.2.3 Rede
Cada elemento do cluster deve satisfazer os seguintes requisitos:
• Conter no mı́nimo dois adaptadores de rede: um para a interface com a “rede

pública” e outro para a interface com a “rede privada” (que são explicadas com
maior detalhe nas secções 6.3.2 e 6.3.1).
• Os nomes das interfaces associadas quer à rede privada, quer à rede pública, deverão
ser idênticos em todos os nós que façam parte do cluster. Se considerarmos que
estamos a produzir um cluster de dois nós, e associamos eth0 à interface de rede
pública e eth1 à interface de rede privada num dos nós, temos de manter essa mesma
atribuição no outro membro do cluster.
• Para uma maior confiabilidade, podem ser configurados adaptadores de rede redun-
dantes em cada nó do cluster quer para a rede pública, quer para a rede privada.
Para isto deve ser configurado um mecanismo de bonding (secção 6.4.6)
• A rede pública deve suportar TCP/IP
• Para a rede rede privada, a interligação deve suportar UDP, e usar adaptadores de
rede e comutadores de rede4 que suportem TCP/IP (Gigabit Ethernet ou superior
é recomendável)
UDP é o protocolo utilizado por omissão pelo Oracle Real Application Clusters e
TCP é o protocolo de interligação usado pelo Oracle Clusterware.
• Através da rede privada, os nós devem estar acessı́veis entre si. Não deve haver
qualquer nó que não tenha ligação com todos os outros. Para isto, a interface de
rede deve estar devidamente configurada, com os parâmetros apropriados (endereço
IP e máscara de rede válidos, ligações fı́sicas devidamente estabelecidas. . . ). Para
verificar o alcance a uma das interfaces presentes no cluster, pode ser utilizado o
comando ping . Utilizando a ferramenta Cluster Verification Utility (CVU), cujas
caracterı́sticas são apresentadas na secção 6.6.1, existe também uma funcionalidade
que permite aferir sobre a boa conectividade entre os nós, confirmando assim uma
correcta configuração ao nı́vel das interligações.
6.2.4 Endereços IP
Antes de começar o processo de instalação deve haver os seguintes endereços disponı́veis

para cada um dos elementos do cluster :
• Endereço IP com um nome de rede atribuı́do, que esteja registado no serviço de

nomes (DNS), para a rede pública.
Caso o serviço de nomes não esteja disponı́vel, o ficheiro /etc/hosts de cada máquina
do cluster deve ser editado, introduzindo uma linha com o par
4
switches
6.2 Requisitos 43
nome_de_rede endereço_ip
por cada um dos nós que compõem o cluster, incluindo o próprio onde está a ser
editado o ficheiro.
• Endereço IP Virtual (VIP), também com um nome de rede atribuı́do, registado

perante no serviço de DNS.
Caso o serviço de DNS não seja utilizado, proceder de igual modo para introduzir os
pares “Nome de rede VIP”/“Endereços VIP” no ficheiro /etc/hosts, tal como foi
explicado para o ponto anterior.
O endereço IP utilizado para a rede pública e o VIP devem fazer parte da mesma
subrede.
• Endereço IP privado com o respectivo nome de rede, atribuı́do a cada interface da

rede privada.
É recomendado pela Oracle que sejam utilizados para este fim endereços IP de âmbito
local (do género 192.168.*.* ou 10.*.*.*), pois deste modo é salvaguardado que estas
mensagens não serão alvo de processos de encaminhamento com redes exteriores.
Para estes endereços deve ser usado exclusivamente o ficheiro /etc/hosts para tra-
tar da resolução de nomes. Portanto, em todas as máquinas deve ser introduzido
no respectivo ficheiro, as diversas associações “Nome de rede”/“Endereco IP” res-
peitantes à globalidade dos membros da rede privada.
Nem os endreços IP especificados nem os nomes de rede a eles associados devem estar
sob utilização, de modo a não causar conflitos na rede e consequentemente um funciona-
mento defeituoso da plataforma criada.
Um exemplo de configuração da estrutura de rede pode ser visto na página 44, con-
sultando a tabela 6.6 que apresenta a configuração adoptada na criação do protótipo
desenvolvido no âmbito deste projecto.
Em conformidade com as considerações tecidas na secção 6.2.4, que estabelece a atri-
buição de endereços IP, foi requisitado um endereço de rede Classe C para albergar as
máquinas que farão parte do cluster. assim como as subredes necessárias à construção
uma plataforma de rede
Rede de Classe C que foi atribuı́da: 172.16.9.0
Com a necessidade de ter duas redes distintas, a pública (para as interfaces públicas e
virtuais) e a privada (para as interfaces privadas), torna-se imprescindı́vel segmentar esta
rede em subredes.
Do leque de endereços IP cedidos com a rede que foi atribuı́da, podemos dispôr dos
8 bits menos significativos, dos 32 que compõem um endereço IP, para gerir a necessária
segmentação. De modo a cumprir com os requisitos e guardar alguma margem de manobra,
para a possibilidade de ser necessária uma reserva extraordinária de endereços ou redes IP
numa fase posterior, foi analisado o espaço de endereços de modo a definir que segmentação
de rede efectuar. Foi criada uma tabela auxiliar para análise e decisão da configuração
da rede disponı́vel, com vista à sua segmentação. São mostradas as diferentes hipóteses
consideradas na tabela 6.3.
Octeto menos significativo Subredes Máquinas Máscara de Rede

1000.0000 2 126 255.255.255.128
1100.0000 4 62 255.255.255.192
1110.0000 8 30 255.255.255.224
1111.0000 16 14 255.255.255.240
1111.1000 32 6 255.255.255.248
1111.1100 64 2 255.255.255.252
Tabela 6.3: Hipóteses de configuração do octeto menos significativo do endereço IP para

especificar os bits utilizados na especificação das subredes. Para cada hipótese, a coluna
“Subredes” representa o número de subredes configuráveis para a segmentação em causa e
a coluna “Máquinas”, o número de máquinas possı́veis para cada uma dessas subredes. A
linha em destaque pelo tracejado representa a opção tomada.
# Subrede Primero IP Último IP Broadcast

1 172.16.9.0 172.16.9.1 172.16.9.14 172.16.9.15
2 172.16.9.16 172.16.9.17 172.16.9.30 172.16.9.31
Tabela 6.4: Endereços de subredes, com a indicação dos valores válidos como máximos e
mı́nimos para os endereços IP.
Subrede
Interface Rede
# Endereço
eth0 1 172.16.9.0 Pública (e Virtual)
eth1 2 172.16.9.16 Privada
Tabela 6.5: Relação entre cada interface, subrede definida e tipo de rede que a utiliza.
Nó Nome da Interface Tipo Endereço IP

rac1 rac1 Pública 172.16.9.1
rac1 rac1-vip Virtual 172.16.9.8
rac1 rac1-priv Privada 172.16.9.17
rac2 rac2 Pública 172.16.9.2
rac2 rac2-vip Virtual 172.16.9.9
rac2 rac2-priv Privada 172.16.9.18
Tabela 6.6: Endereços IP reservados para a implementação RAC

6.3 Descrição de alguns componentes RAC 45
6.2.5 Sincronização do tempo
Antes de efectuar a instalação, foi também verificado o acerto entre os relógios das
diferentes máquinas pois deste sincronismo depende o bom funcionamento do Oracle Real
Application Clusters. Nesse sentido, foi configurado o Network Time Protocol (NTP) nos
vários elementos do cluster. É importante verificar que todos os nós do cluster tenham
acesso a um mesmo servidor de tempo como referência.
6.3 Descrição de alguns componentes RAC
6.3.1 Rede Privada
É uma rede privada de alta velocidade, que permite a inter-comunicação entre todos
os elementos do cluster. Também conhecida como HSI (High-speed interconnect), é o
principal veı́culo para o eficaz funcionamento da tecnologia Oracle’s Cache Fusion que
combina a memória fı́sica (RAM), individual de cada máquina, numa cache única e global.
6.3.2 Rede Pública
Cada nó do cluster tem configurado um endereço IP com a interface de rede de acesso
público, contido numa rede comum, partilhada pelo conjunto de nós. Este endereço é
utilizado para a configuração da interface de rede utilizada pela base de dados para aceitar
as ligações com os clientes. Para além deste endereço deve estar atribuı́do um endereço IP
virtual (VIP) que lhe é associado automaticamente no processo de instalação dos Oracle
Real Application Clusters pelo OUI.
6.3.3 Endereço IP Virtual (VIP)
Para utilização dos Oracle Real Application Clusters é necessário haver um endereço
IP virtual (Virtual IP, ou VIP) atribuı́do a cada servidor que faça parte do cluster. Este
endereço deve estar disponı́vel e fazer parte da mesma subrede da interface de rede pública.
É o endereço que as aplicações ou utilizadores externos utilizam para se ligar à base
de dados RAC. Se um dos nós falhar, esse facto é identificado pelo cluster, que procede
a uma reatribuição desse endereço a um dos nós que tenham “sobrevivido”, dando assim
uma resposta imediata aos pedidos de ligação apesar da quebra existente.
Isto aumenta a disponibilidade para as aplicações, pois não têm de esperar as no-
tificações de rede sobre a quebra da ligação e buscar uma alternativa. Antes que isso
aconteça, o cluster trata de fazer o reencaminhamento do serviço indisponı́vel para outro
servidor enquanto o que registou a quebra não recuperar o seu estado operativo e voltar
a estar disponı́vel [53].
O VIP tem de ser definido mas inicialmente não tem qualquer adaptador de rede
atribuı́do. Somente numa fase posterior esta configuração é feita pelo OUI (Oracle Uni-
versal Installer ).
6.4 Opções
6.4.1 Optimal Flexible Architecture (OFA)
Para a decisão da estrutura de directorias e pontos de montagem a ser criados, foi

seguido o standard “Optimal Flexible Architecture” [54]. Este standard dá um conjunto
de directrizes vocacionado para a instalação e gestão de sistemas complexos de software e
dados em disco.
A sua prática pretende minimizar os pontos de estrangulamento nos dispositivos e a
baixa performance, assim como facilitar as tarefas administrativas, permitir a pacı́fica co-
existência de múltiplas bases de dados ou proporcionar as condições para que o crescimento
da base de dados se possa efectuar sem complicações.
Uma directoria “Home” indentifica onde é instalado todo o software relativo a um
dado produto.
A ORACLE BASE é directoria de alto nı́vel para produtos Oracle instalados pelo
mesmo utilizador. Normalmente deverão ter a forma / pm / h / u, onde pm é o ponto de
montagem escolhido, h o tipo de conteúdos que contém e u o utilizador responsável pela
instalação.
ORACLE BASE=/u01/app/oracle
ORACLE HOME=$ORACLE BASE/product/10.2.0/db 1
O Oracle Clusterware representa desde a nova versão Oracle (10.2.0.1) uma excepção
na estrutura padrão das directorias Home. Isto acontece porque devem ser mudadas as
permissões de todas as directorias ascendentes à home do Oracle Clusterware, de modo
a permitir acesso de escrita apenas ao utilizador root, e daı́ esta directoria não pode ser
subdirectoria da directoria base Oracle.
Dado que o Oracle Clusterware apenas pode ter uma única instalação no sistema, não
é necessária a introdução do contador.
6.4.2 Módulo Hangcheck Timer
Foi configurada a utilização deste módulo nos servidores do cluster da base de dados.
É um módulo do sistema operativo Linux que deve ser incorporado no kernel .
Monitoriza a disponibilidade e confiabilidade do servidor. Se por algum motivo uma
destas propriedades não é cumprida, como quando existe um bloqueio na resposta do
servidor este módulo trata de reiniciar a máquina automáticamente.
Utiliza dois parâmetros chave, um para o intervalo entre verificações do estado de saúde
do sistema – hangcheck-tick – e outro para a margem de espera – hangcheck-margin – que
define o perı́odo de tempo que deve ser tolerado a servidor até obter uma resposta activa.
6.4.3 Listener
É um processo que reside no servidor cuja responsabilidade é escutar por pedidos de

ligação emitidos pelos clientes e gerir o tráfego para o servidor. Podem ser configurados
diferentes Listeners.
6.4 Opções 47
Cada vez um cliente solicita uma sessão de rede com um servidor, um Listener recebe
o actual pedido. Caso a informação prestada pelo cliente coincida com a informação do
Listener, é concedida a ligação ao servidor.
6.4.4 Serviços
Os serviços são registados com o TNS Listener e estabelecem os pontos de acesso

através dos quais as aplicações cliente acedem à base de dados. Quando é adicionado um
serviço, podem ser definidas instâncias como preferidas.
Ao ser iniciado, a base de dados Oracle tenta arrancá-lo nestas instâncias. O número
de instâncias preferidas determina o número de instâncias onde a base de dados tenta
manter o serviço.
Outras instâncias podem ser identificadas como instâncias que estão disponı́veis em
apoio ao serviço, caso este não possa ser lançado nas instâncias preferidas por se encon-
trarem em baixo.
Os nomes de serviço com o prefixo SYS$ são reservados para uso dos processos internos
Oracle.
Configuração do serviço e preferências das instâncias
Cada instância deve ser declarada de um dos seguintes tipos:
• Preferida – O serviço corre de um modo geral nesta instância. O arranque do serviço

é tentado em primeiro lugar aqui e o serviço tenta manter-se activo em todas as
instâncias preferidas, enquanto estas se encontram activas.
• Disponı́vel – O serviço é arrancado nesta instância caso não seja possı́vel fazê-lo
numa preferida. O serviço pode correr na instância caso uma das preferidas falhe.
• Não usada – A base de dados nunca inicia o serviço nesta instância.
6.4.5 Transparent Application Failover (TAF)
Esta é uma tecnologia que permite restituir um serviço em caso de falha, dando suporte
aos Real Application Clusters para manter os serviços disponı́veis, ainda que ocorra uma
quebra num dos servidores. Quando isso acontece, o TAF tenta restabelecer a ligação
entre a aplicação e o serviço, mesmo que tenha de reencaminhar a aplicação para outra
instância. Este processo é feito sem que o utilizador final se aperceba.
Na configuração desta aplicação existem parâmetros que devem ser definidos. São
apresentados os dois principais.
Tipo:
• Session - apenas a ligação deve ser restabelecida. O trabalho já executado na

instância que sofre a falha não é passado à instância disponı́vel.
• Select - os cursores abertos na aplicação podem continuar a ser usados após a falha
desde a nova instância.
• None - não é implementada nenhuma funcionalidade de tolerância a falhas
Método:
• Basic - a ligação é estabelecida apenas na ocorrência de uma falha.
• Preconnect - as ligações são pré-estabelecidas. A ligação de suporte é estabelecida

ao mesmo tempo que a ligação principal.
6.4.6 Agregação de placas de rede
Quando se pretende fornecer um serviço onde a disponibilidade é uma propriedade es-

sencial, faz sentido criar um mecanismo que promova redundância sobre a rede utilizada,
também conhecido por bonding, evitando “pontos únicos de falha” e tolerando assim qual-
quer falha que possa suceder numa das interfaces.
Para isso é obrigatória a existência de uma placa de rede adicional (para além das duas
que são necessárias, dedicadas à rede pública e privada). Assim a interface suplementar
pode ser configurada em suporte a uma existente. Este mecanismo pode funcionar em
diferentes modos, sendo o de active-backup (1) o mais adequado para quando se pretende
garantir uma alta disponibilidade. Esta opção foi posta em prática para avaliar o seu
modo de configuração.
Foi criada uma interface agregada (bond0) para a interface de rede pública que será
a interface primária e cada uma das interfaces fı́sicas de rede agregada é definida como
slave. Pode ser configurado também o modo de funcionamento desta agregação.
Configuração
Para configurar esta funcionalidade deve ser efectuado o seguinte procedimento.

Parar o funcionamento de rede.
/etc/init.d/network stop
Se não estiverem configuradas as interfaces de rede, utilizar o programa YaST nesse

sentido e configurá-las para usar DHCP. Com isto são criados os ficheiros de configuração
(localizados em /etc/sysconfig/network/) das interfaces que se pretenda agrupar (neste
caso ifcfg-eth0 e ifcfg-eth2).
Editar cada um dos ficheiros de configuração efectuando as seguintes alterações: (ori-
gem à esquerda e ficheiro alterado à direita)
BOOTPROTO=’dhcp’ BOOTPROTO=’none’
MTU=’’ MTU=’’
REMOTE_IPADDR=’’ REMOTE_IPADDR=’’
STARTMODE=’onboot’ ⇒ STARTMODE=’onboot’
UNIQUE=’*deixar_como_está*’ UNIQUE=’*deixar_como_está*’
_nm_name=’*deixar_como_está*’ _nm_name=’*deixar_como_está*’
Posteriormente editar o ficheiro bond0 contido na mesma directoria de acordo com a
configuração pretendida:
6.5 Scripts Desenvolvidos 49
BOOTPROTO=static
BROADCAST=172.16.9.15
IPADDR=172.16.9.1
NETMASK=255.255.255.240
NETWORK=172.16.9.0
STARTMODE=onboot
BONDING_MASTER=’yes’
INTERFACE=’bond0’
BONDING_MODULE_OPTS=’miimon=100 mode=active-backup primary=eth0’
BONDING_SLAVE0=eth0
BONDING_SLAVE1=eth2
Deverá ser reiniciado o sistema para confirmar que a interface é iniciada no processo
de arranque. Para verificar o seu funcionamento efectuar a instrução indicada na linha de
comandos (como root) e confirmar a existencia da interface bond0 na lista de interfaces
apresentada.
# ifconfig
6.4.7 Orarun
Foi utilizado o pacote Orarun, que faz parte da distribuição da Novell. Este pacote
realiza um conjunto de tarefas que agilizam o processo de instalação de productos Oracle,
através da incorporação de um conjunto de scripts ao ser utilizados tornam
Altera os parâmetros do kernel e adaptá-los com valores indicados para uma instalação
Oracle.
Cria automaticamente os grupos necessários à instalação de produtos Oracle e o utili-
zador oracle do sistema operativo como membro destes grupos.
Estabelece para este utilizador as variáveis de ambiente necessárias para a instalação
dos diversos produtos.
Permite a disponibilização automática de alguns serviços comuns, como da base de
dados, ou o listener que fica à escuta de ligações por parte dos clientes.
• Numa instalação de Oracle Database 10 g “Standard Edition” com RAC podem

incluir-se até quatro nós uniprocessador ou dois nós de duplo processador. Caso
se pretenda acrescentar mais nós, deverá ser feito um upgrade para uma edição
“Enterprise” [55].
6.5 Scripts Desenvolvidos
Com a finalidade de reproduzir os passos feitos no desenvolvimento do protótipo que

cria um ambiente Real Application Clusters (apresentado à frente, na secção 7.2) e tornar
essa instalação mais célere, foi realizado um conjunto de scripts, utilizados com a shell
Bash. Estes scripts deverão ser executados seguindo um “fio-de-execução” proposto, cada
um pelo utilizador a que corresponde (root ou oracle).
• VARIAMB.sh
– Define as variáveis de ambiente utilizadas pelas diversas scripts desenvolvidas.
Neste ficheiro podem ser alterados os parâmetros a utilizar, como a directoria reflec-
tida na variável DESTI SEGURETAT, que deve ser usada para guardar os ficheiros
de sistema originais , a directoria onde se encontra o software a ser utilizado (FONT ),
a Home para o CVU (CV HOME ), a directoria onde devem ser colocados os ficheiros
de script a que serão executadas pelo utilizador oracle, etc.
• 000 fil de execucio.sh

– Este script, conforme o nome indica5 , é o fio de execução, encadeando os diferentes
ficheiros de modo a fazer de um modo sequencial as diferentes tarefas.
• 001 directoris.sh
– Cria as directorias necessárias ao software Oracle.
• 002 cvuhome.sh
–Instala o software CVU referente ao utilizador root. –
• 003 cvuoracle.sh
–Deve ser executado pelo utilizador oracle quando solicitado pelo script anterior.
• 004.sh
–Realiza a actualização do kernel e Oracle Cluster File System
• 005 hangcheck.sh
–Instala o módulo ao kernel com os parâmetros adequados.
• 006 hosts.sh
–Trata da resolução de nomes.
• 007 mem.sh
– Retira as limitações ao uso de memória por parte do utilizador oracle, conforme
visto na secção 7.11.
• 008 orarun.sh
–Modifica os ficheiros do pacote Orarun, de modo a adequar o ambiente criado
com as particularidades definidas, a nı́vel dos parâmetros ORACLE HOME, ORA-
CLE BASE e SID da instância de acordo com o servidor onde é executado. Executa
o script rcoracle que activa a utilização do Orarun.
• 009.sh
–Manipula os limites da shell para o utilizador oracle.
• 010.sh
–Cria as chaves SSH.
• 011
–Transfere as diversas chaves públicas para o ficheiro local de autorizações.
• 012 ocfs.sh
–Prepara a instalação do Oracle Cluster File System 2 .
5
em catalão. . .
6.6 Testes 51
• 015 asminstall.sh
–Instala o driver ASM.
• 016 asmconfigure.sh
–Configura o driver ASM.
• 018 preparaCRS.sh
–Prepara a instalação do Clusterware.
6.6 Testes
6.6.1 Cluster Verification Utility (CVU)
Esta é uma nova ferramenta disponibilizada a partir da última versão Oracle Data-
base 10 g Release 2 (10.2) desenvolvida para assistir na configuração e instalação quer
do Clusterware, quer do próprio RAC. Verifica as componentes essenciais, ao longo das
consecutivas etapas de instalação de todo o ambiente. A sua acção de diagnóstico sobre
o processo é extensa, abrangendo da configuração inicial do hardware, até à implantação
final do sistema no seu estado operacional.
Tem uma grande abrangência no diagnóstico de diferentes pontos do processo de ins-
talação do ambiente RAC. Através da linha de comandos, a instrução cluvfy pode funci-
onar através de dois modos de funcionamento essenciais:
• por fase: para os pontos crı́ticos da instalação são estabelecidos marcos, que identi-
ficam as suas fases fundamentais (como a instalação do Clusterware, por exemplo).
Esta ferramenta tem estabelecido um conjunto de critérios de entrada e de saı́da
para cada uma destas fases.
Quando a instalação atinge um dos marcos crı́ticos estipulados, pode ser executado o
teste respectivo. Então, com base nos critérios estabelecidos para a tarefa concreta a
executar, é avaliado o cumprimento dos seus requisitos (necessários para cumprir-la
com sucesso). Deste modo, em caso de esquecimento ou incorrecção no cumprimento
de algum dos passos necessários, pode evitar-se a sua propagação para etapas pos-
teriores, o que possivelmente teria consequências, quer na sua localização posterior,
quer nos impactos negativos que daı́ poderiam provir.
• por componente: em que as verificações efectuadas não estão associadas à fase de

instalação que se encontra a decorrer, senão ao correcto funcionamento de uma com-
ponente especı́fica, apontada pelo utilizador. São diversos os tipos de componentes
que podem ser avaliados segundo a intenção do utilizador. Podem variar desde uma
simples verificação sobre o espaço disponı́vel em disco, a análises complexas, como
verificar o estado da pilha Oracle Clusterware. Neste último caso, a execução com-
preende comprovar a integridade da pilha Oracle Clusterware, através da realização
de testes sobre os diversos sub-componentes que lhe estão associados. Este tipo de
verificação, que realiza um conjunto de sub-tarefas de verificação a mais baixo nı́vel,
é extremamente útil na depuração de potenciais problemas são normalmente difı́ceis
de identificar.
Comandos relacionados
Para diagnóstico dos vários items esta ferramenta pode ser usada com os seguintes
parâmetros:
LISTA DE NÓS: é uma lista separada por vı́rgulas com os nós sobre os quais incide o
teste. Por exemplo: rac1,rac2
Algumas das verificações executadas são aqui enunciadas:
• Hardware e configuração do sistema operativo:

# cluvfy stage -post hwos -n LISTA_DE_NÓS [-verbose]
• Conectividade entre os vários elementos do cluster através das interfaces de rede

(todas ou algumas em especı́fico):
# cluvfy comp nodecon -n LISTA_DE_NÓS [-verbose]
Descobre as interfaces disponı́veis nos vários nós, faz uma análise dos endereços IP
e subredes relacionados com cada interface, obtém a lista de interfaces compatı́veis
com o uso do VIP e a para as interligação privada, assim como também verifica a
boa conectividade entre todos os elementos através destas interfaces.
• Para verificar a ligação entre todos os nós através de uma interface em especı́fico,
usar a opção -i INTERFACE.
# cluvfy comp nodecon -n LISTA_DE_NÓS -i eth0 [-verbose]
• Uso do armazenamento partilhado

# cluvfy comp ssa -n LISTA_DE_NÓS -s /dev/sdb
• Este é um diagnóstico de fase que verifica os pré-requisitos relativos à instalação do

Clusterware.
# cluvfy stage -pre crsinst -n LISTA_DE_NÓS -verbose
• Fazer um diagnóstico do sistema para verificar o cumprimento dos pré-requisitos

para uma instalação do Clusterware ou da base de dados.
# cluvfy comp sys -n LISTA_DE_NÓS -p (crs|database) -osdba dba
-orainv oinstall -verbose
• Verificar se o sistema está preparado para instalar a Oracle Database 10 g com RAC
# cluvfy stage -pre dbinst -n LISTA_DE_NÓS
6.6.2 Verificações de pós-instalação
Foram efectuados alguns testes no sentido de verificar a correcta instalação do Real

Application Clusters. Existem algumas ferramentas que podem ser utilizadas para aferir
o bom estado de funcionamento do cluster. Através da linha de comandos, nomeadamente
através do comando srvctl podem ser feitas muitas delas (um conjunto de comandos
6.6 Testes 53
sobre este tema é apresentado no apêndice). Através do Sqlplus pode também ser avaliado
um vasto conjunto de parâmetros.
• Foi feita a verificação sobre o funcionamento RAC e sobre a tecnologia do Transparent

Application Failover (secção 6.4.5, na página 47).
1. Foi utilizado a seguinte sentença SQL para efectuar esta verificação:
COLUMN instance_name FORMAT a13

COLUMN host_name FORMAT a9
COLUMN failover_method FORMAT a15
COLUMN failed_over FORMAT a11
SELECT instance_name,
host_name,
NULL AS failover_type,
NULL AS failover_method,
NULL AS failed_over
FROM v$instance
UNION
SELECT
NULL,
NULL,
failover_type,
failover_method,
failed_over
FROM v$session
WHERE username = ’SYSTEM’;
2. Num cliente Oracle que tinha devidamente configurado o ficheiro tnsnames.ora,

estabeleceu-se, como utilizador System, uma ligação com o serviço da base de
dados RAC:
# sqlplusw system/manager@ortrety
3. Lançou-se a sentença SQL anteriormente apresentada e manteve-se a sessão

aberta no Sqlpus. Foi mostrada a seguinte informação:
INSTANCE_NAME HOST_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- --------- ------------- --------------- -----------
orcl1 rac1
SELECT BASIC NO
4. Num dos nós do cluster (podia ser qualquer deles) foi forçado o desligamento
da instância referida anteriormente (rac1) pelo utilizador oracle:
# su - oracle
#srvctl status database -d orcl
Instance orcl1 is running on node rac1
# srvctl stop instance -d orcl -i orcl1 -o abort
#srvctl status database -d orcl
Instance orcl1 is not running on node rac1
5. Nesta altura, a partir da consola que permaneceu aberta no cliente Oracle foi
executada de novo a sentença SQL, e o resultado foi então o seguinte:
INSTANCE_NAME HOST_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- --------- ------------- --------------- -----------
orcl2 rac2
SELECT BASIC YES
6. Desta maneira pôde verificar-se o comportamento perante uma falha, com a

transição do serviço da instância que falhou, e deixou de estar disponı́vel, para
a outra que se manteve operacional.
• Se o serviço que fornece acesso à base de dados foi devidamente instalado:

SQL> show parameter service
• Dá uma listagem de todas as instâncias de base de dados no cluster

SQL> SELECT inst_id,
instance_number inst_no,
instance_name inst_name,
parallel,
status,
database_status db_status,
active_state state,
host_name host
FROM gv$instance
ORDER BY inst_id;
6.6.3 Adição de um nó numa fase posterior
Após o processo de instalação inicial, em que é criado o cluster e posta a base de dados
num estado operacional, é possı́vel proceder à adição de nós adicionais, sem que para isto
seja necessário que os membros já existentes deixem de prestar o serviço sobre a base de
dados. Para isso é necessário criar no novo nó um sistema que seja compatı́vel com o
ambiente RAC, respeitando as suas limitações, sobre as quais são referidos alguns pontos
na secção seguinte (6.7).
É necessário que o novo membro tenha uma arquitectura semelhante aos já existentes,
assim como o mesmo sistema operativo. Após ter sido instalado o sistema operativo, é
necessário colocar a camada de rede num modo funcional, mantendo a estrutura de interfa-
ces utilizadas, e respectivos endereços, concordantes com o tipo de rede a que pertencem.
6.7 Limitações 55
Como exemplo, se nos outros nós a interface eth0 está atribuı́da à rede pública, esta
relação deve conservar-se na configuração do novo nó.
Deve ser configurada a equivalência de utilizador ao nı́vel do protocolo SSH, de modo
a permitir o estabelecimento de ligações seguras entre os nós, sem depender da entrada
em modo interactivo (para pedir a password ou confirmar o estabelecimento da ligação),
efectuando a troca de chaves públicas com os outros nós, tal como terá sido feito pelos
membros existentes anteriormente.
Deve ser seguido o processo de configuração do sistema para o ambiente RAC, ade-
quado aos novos nós, garantindo o acesso aos dispositivos que garantem o armazenamento
partilhado, conforme feito numa instalação de raı́z, até ao momento de instalação do
software Oracle.
Existem vários procedimentos para estender o ambiente RAC a novos nós e instâncias
e proceder à instalação do software Oracle, no qual se inserem o Oracle Clusterware e o
Oracle Database 10 g. Dos existentes, o método de clonagem Oracle é o preferı́vel. Este
método permite criar uma nova instalação, com todas as actualizações que já tiverem sido
aplicadas, através de um “único passo”, evitando ter de passar por todos os passos isolados
de instalação, configuração e aplicação de actualizações. Possibilita uma maior rapidez
neste processo e permite que um nó de origem, que faça já parte do cluster , com uma
instalação bem sucedida, funcione como fonte na disseminação da instalação por diversos
nós.
6.7 Limitações
Com o Oracle Database 10 g Release 2 (10.2), Oracle Clusterware e Oracle Real Appli-
cation Clusters são suportados até um máximo de 100 nós num cluster [53]. Apesar desta
imposição sobre o tamanho que pode atingir um cluster deste tipo ser bastante razoável,
um cenário de grandes dimensões não implica necessariamente uma melhor solução.
Segundo a opinião de alguns especialistas, o número “ideal” para popular um RAC
ronda os quatro nós.
Não tem de haver homogeneidade respeitante aos servidores que compõem o cluster
RAC, porém estes devem correr sobre o mesmo sistema operativo.
Tem de ser idêntica a versão Oracle que utilizam. Inclusivamente, quando co-existem
duas versões diferentes da base de dados no mesmo sistema, estas apenas podem funcionar
de modo independente e não poderão partilhar a mesma Home 6 .
A maior parte das actualizações, quer da base de dados, quer do sistema operativo,
representarão uma quebra no serviço disponibilizado pelo nó onde se procede a manu-
tenção. Dado que esta prática provavelmente terá de ser repetida pelos outros nós, poderá
representar uma morosidade considerável, sobretudo caso seja um cluster numeroso.
Todos os servidores devem suportar a mesma arquitectura, por exemplo serem todos
sistemas de 32-bit ou todos 64-bit.
6
variável que especifica a directoria onde é realizada a instalação do software dos produtos Oracle.
Capı́tulo 7
Protótipo
Com base no estudo efectuado sobre o produto Oracle Database 10 g Release 2 (10.2),
com a sua extensão Real Application Clusters, foi realizado um protótipo que pretendeu
criar na prática uma plataforma em cluster deste género. No decorrer deste capı́tulo são
apresentadas as principais opções tomadas na sua concretização, assim como os passos que
compuseram o seu desenvolvimento. Muitos dos termos, opções ou tarefas aqui tratados
são apresentados e justificados nos capı́tulos anteriores, cuja consulta se considera, deste
modo, bastante útil para melhor compreender este processo de implementação.
7.1 Infra-estrutura
A infra-estrutura preparada para albergar a plataforma Oracle Real Application Clus-

ters, apesar de numa fase inicial haver expectativas que pudesse ser concretizada com
hardware real, num ambiente nativo em servidores Blade PowerEdge 1855 da Dell, aca-
bou por não se concretizar desta forma.
Alternativamente, foi criada uma infra-estrutura virtual, com a solução de virtualização

utilizada na Trety , o ESX Server 2.5 da VMware, utilizada essencialmente para fins de
desenvolvimento e testes.
Salvo algumas especificidades na configuração, normalmente dependentes do sistema

operativo utilizado ou da natureza da estrutura fı́sica que se pretendia criar, com o ade-
quado seguimento da documentação fornecida pela VMware [56, 57, 58], os problemas
encontrados puderam ser circundados.
A camada de virtualização acabou por ser utilizada de forma transparente e o processo

de instalação do ambiente Oracle Real Application Clusters que aqui se propõe poderá fa-
cilmente ser extrapolada para uma plataforma fı́sica, seguindo as indicações aqui presentes,
com ligeiras alterações num ou noutro pormenor.
Para criar a infra-estrutura virtual adequada, foi utilizada a Interface de Gestão da

VMware. A partir desta interface gráfica foi realizado um conjunto de procedimentos que
criaram a estrutura que virtualiza a camada de hardware utilizada na implementação RAC
desenvolvida.
7.1 Infra-estrutura 57
7.1.1 Criação da máquina virtual
1. Escolheu-se a opção “Add Virtual Machine” para criar uma nova máquina virtual.
O painel onde são definidas as opções standard para a máquina em questão foi então
apresentado.
Sistema Sistema Operativo a ser instalado:

GNU/Linux
Nome O nome pelo qual é identificada a máquina dentro da Interface de Gestão.

Não tem relevância para sucesso da instalação, é meramente identificativo.
Neste ponto deve ser introduzido um nome coerente com a polı́tica de nomes
utilizada para este contexto.
RAC1
Localização Definiu-se onde deveria ser guardado o ficheiro que contém a parame-
trização da máquina virtual a ser criada.
/home/rnogueira/vmware/linux/rac1 maq.vmx
2. Processador e memória
Processador A licença aquirida para este software apenas permite a criação de

máquinas com um único processador, e por isto esta opção estava inibida
Memória A instalação da Oracle Database 10 g RAC requere um mı́nimo de 1GB
de memória RAM. As máquinas virtuais criadas foram definidas para utilizar
2GB (2048MB).
3. Opções de Disco
Para cada máquina foi criado um disco para conter os ficheiros locais necessários
(como o sistema operativo, software da base de dados e do Clusterware, etc.). So-
bre cada um destes discos foram criadas as partições necessárias à sua estrutura
básica local. Além destes, foram ainda criados discos responsáveis por garantir o
armazenamento partilhado, do qual depende a arquitectura RAC. Para este efeito
foi criado um disco para ser utilizado com sistema de ficheiros OCFS2 e outros três
para serem utilizados pelo ASM. Este espaço a ser compartido foi configurado para
ser “partilhado” através da controladora SCSI que lhes foi atribuı́da (que deverá ser
diferente da que controla o disco local).
# dispositivo tipo âmbito tamanho (GB)

1 /dev/sda Ext3 L 16
2 /dev/sdb OCFS2 P 1
3 /dev/sdc ASM P 6
4 /dev/sdd ASM P 6
5 /dev/sde ASM P 12
Tabela 7.1: Criação de discos. O âmbito de utilização para o disco respectivo, se Local ou
Partilhado, e o tamanho de cada um (em GigaBytes).
58 Protótipo
espaco /dev/sda
partilhado
/dev/sde
Local
/dev/sdd
/dev/sdc ASM
OCFS2
/dev/sda /dev/sdb
EXT3
Local
Figura 7.1: Configuração dos discos
4. Controladora SCSI virtual: BusLogic

Nos produtos VMware que foi possı́vel averiguar, são facultadas duas hipóteses de
escolha para este tipo de controladora. LSI Logic e BusLogic. Segundo um estudo
de benchmark consultado [59], promovido pela VMware, não existem diferenças con-
sideráveis a nı́vel de performance que justifiquem a adopção de uma em detrimento
da outra. Por isso, esta escolha foi baseada em critérios de confiabilidade e de com-
patibilidade.
Quanto ao primeiro critério, segundo a documentação consultada, em diversos siste-
mas Linux hóspedes foram observados problemas utilizando a controladora BusLogic
em máquinas virtuais VMware, de onde se conclui que deverá ser preferencialmente
utilizada a opção LSI Logic. Porém, a controladora BusLogic é a única alternativa
que oferece compatibilidade à combinação da utilização de servidores ESX Server
2.5 com a distribuição SUSE Linux Enterprise Server 9 . A controladora SCSI foi
portanto configurada como deste tipo.
7.2 Multiplos Nós
Para a instalação nos múltiplos nós do cluster pode ser usado um processo de clonagem.
Na figura 7.2 podem ver-se os passos que esta operação poderá englobar, facilitando o
processo global de instalação.
Existem alguns métodos para realizar este processo de clonagem. Podem ser utilizados
programas especı́ficos para este fim ou pode ser criado um ficheiro, compactando nele os
conteúdos do sistema de origem e utilizá-lo para transportá-los para o sistema de destino.
Neste caso foi utilizada uma terceira opção. O VMware fornece no seu componente Gestor
de Ficheiros a possibilidade de efectuar operações sobre os ficheiros contidos na máquina
host. No ambiente VMware, os discos das máquinas virtuais são alojados em ficheiros, cujo
nome é especificado na sua criação. Para clonar um destes discos basta apenas efectuar
uma cópia do ficheiro que lhe corresponde.
No entanto é necessário evitar possı́veis inconsistências que poderão resultar das clo-
nagens realizadas. Como precaução tomada nesse sentido, as interfaces de rede foram
7.3 Instalação SUSE Linux Enterprise Server 9 59
Criar
nova maquina
Instalar Sistema Operativo Realizar Actualizacoes Instalar VMwareTools
Preparar ambiente para "oracle" Configurar NTP Configurar rede
Instalar CVU Conf. Hangcheck Timer Conf. resolucao de nomes
todas? Criar pontos de montagem Ajustar Orarun Desbloquear Memoria
Estabelecer equivalencia de utilizadores
Figura 7.2: Encadeamento das várias tarefas numa primeira fase da instalação RAC.
Estas tarefas são feitas isoladamente em cada servidor, livres ainda das dependências de
grupo. Como este é um processo repetitivo entre os diferentes servidores, poderá ser usado
um processo de clonagem para aplicar a mesma configuração em múltiplos nós.
desabilitadas no momento prévio à criação dos clones. No seu restauro, antes de proce-
der à sua activação, as interfaces de rede foram devidamente configuradas, ajustando os
endereços de rede em conformidade com os valores definidos anteriormente (segundo a
tabela 6.6, presente na página 44).
7.3 Instalação SUSE Linux Enterprise Server 9
Para a instalação do sistema operativo foi utilizada a distribuição SUSE Linux Enter-
prise Server 9 (6 CDs) com o Service Pack 3 (3CDs).
1. Ligou-se a máquina e entrou-se no menu de configuração da BIOS (acedido pulsando

<F2> ). Nas opções de boot, definiu-se que o arranque se fizesse a partir da unidade
CDROM para poder lançar a instalação a partir do CD. Colocou-se o CD1 do SP3
na unidade de modo a lançar o processo de instalação a partir desta actualização e
confirmaram-se as alterações.
2. O sistema reiniciou e arrancou a partir o CD de instalação. Foi mostrado um ecrã de

60 Protótipo
entrada da SUSE com um um conjunto de opões principais e submenus disponı́veis

através de teclas de acesso directo. Dado que as VMwareTools ainda não tinham
sido instaladas, a utilização do modo gráfico não deveria ser utilizado. Por isso,
carregou-se em <F2> para definir o modo de resolução a utilizar no processo de
instalação, seleccionando “Text Mode”.
Opcionalmente definiu-se um modo “verbose” desde o submenu acessı́vel através da
tecla <F5> para que fosse mostrada informação adicional a respeito do processo de
instalação.
Para continuar, seleccionou-se “Installation” no menu principal.
Foi pedido que se inserisse o CD número 1. Foi então introduzido o primeiro CD de
instalação do SUSE Linux Enterprise Server 9 , e não o do Service Pack.
3. Foi aceite o acordo de licença respeitante a este produto. O programa de instalação

verificou o hardware presente e apresentou o menu do YaST2, o programa de confi-
guração do SLES9 , a solicitar a escolha do idioma a utilizar. Foi escolhida a opção
dada por omissão – Inglês. Foi então mostrado o menu principal do YaST, onde são
efectuadas as principais definições da instalação.
4. Escolheu-se o padrão de teclado a configurar – Espanhol.
5. Partições – O espaço disponı́vel no disco local (16GB) foi particionado da seguinte

forma utilizando a opção de particionamento personalizável:
# ponto de montagem tamanho utilização

1 /boot 100MB Gestor de arranque e kernel
2 swap 1GB Primeira partição de Swap
3 swap 2GB Segunda partição de Swap
4 /home 2GB Áreas de utilizadores
5 /u01 5GB Software Oracle
6 / 6GB Raı́z de sistema de ficheiros (SO)
Tabela 7.2: Criação das partições no disco local.
6. Software - Escolheu-se a selecção detalhada. Através do filtro de selecções elegeram-

se os seguintes grupos:
– Basis Runtime System
– YaST
– Graphical Base System
– Linux Tools
– Help & Support Documentation
– C/C++ Compiler and Tools
– KDE Desktop Environment
– Analysing Tools
Foram seleccionados também os seguintes pacotes:
– orarun (versão 1.8) que auxilia na configuração dos parâmetros de ambiente
adequados para a instalação de produtos Oracle.
7.4 Actualizar kernel e OCFS2 61
– ocfs2console – Ferramentas de suporte para utilização do Oracle Cluster File

System 2
– ocfs2-tools – Ferramentas do Oracle Cluster File System 2
– kernel-source – Para possı́veis alterações e recompilação do kernel.
7. Gestor de arranque: Seleccionou-se o Lilo. Apareceu um ecrã de alerta para a

possibilidade de perder algumas definições com esta acção. Das opções facultadas,
escolheu-se “converter a presente configuração”. A opção de espera do menu de
entrada do LiLo durante o processo de arranque pode ser desactivada caso não haja
um processo de escolha a ser efectuado, de modo a tornar o reinı́cio do sistema mais
rápido.
8. Definiu-se a zona horária e aceitaram-se as escolhas feitas.
9. Escolheu-se “skip” para as “definições de rede”, “teste de ligação à internet”, assim

como para a “definição de serviços”. O que fosse necessário configurar, sê-lo-ia
depois.
10. Método de Autenticação: Local.
11. Adicionou-se um utilizador local. Depois foram mostradas as “Release Notes”
12. Gráficos e som. Estes serviços não foram configurados. Caso se pretenda, estes
serviços podem ser configurados, porém isso deve ser feito depois da instalação das
VMwareTools.
7.4 Actualizar kernel e OCFS2
O sistema foi actualizado com o novo kernel Linux (2.6.5-7.257) e a utilização de uma
versão mais recente do OCFS2 (1.2.1-4.2), o que resolveu alguns problemas observados
com as versões anteriores. Uma das dificuldades com as versões anteriormente instaladas
era devida ao sistema de escalonamento E/S e, para circundá-la, podia ser definida uma
opção de boot elevator=deadline. Com estas actualizações esse procedimento já não é
necessário1 .
1. Com esta actualização tornou-se necessário reinstalar as VMwareTools. Começou-se

por remover a instalação antiga VMwareTools, através do comando:
# vmware-uninstall-tools.pl
2. Instalação dos pacotes rpm.

A partir da linha de comandos, na directoria onde estavam os pacotes de instalação2 ,
foi executado o comando rpm para instalar os pacotes necessários à actualização do
kernel. Também teve de ser instalado o pacote que disponibiliza o código fonte do
kernel, pois é requerido para a instalação das VMwareTools. Então foi restaurarada
a instalação do Lilo para que o processo de boot fosse feito correctamente após estas
alterações. Concluı́dos estes passos reiniciou-se a máquina.
1
este bug da antiga versão está documentado na página web http://oss.oracle.com/bugzilla/
show_bug.cgi?id=671
2
ficheiros com extensão rpm
62 Protótipo
# rpm -Fhv kernel-syms-2.6.5-7.257.i586.rpm \

kernel-default-2.6.5-7.257.i586.rpm
# rpm -Fhv kernel-source-2.6.5-7.257.i586.rpm
# lilo
# shutdown -r now
Para reinstalar as VMwareTools consultar a sub-secção respectiva (7.5).
3. Procedeu-se então à instalação do novo OCFS2 :

Neste caso foi feito um upgrade da versão 1.1.4-0.5 para a versão 1.2.1-4.2 .
# rpm -Uvh ocfs2console-1.2.1-4.2.i586.rpm \
ocfs2-tools-1.2.1-4.2.i586.rpm
7.5 Instalação das VMwareTools
1. Deverá ser utilizado preferencialmente o modo de texto. Para isso poderá ser usada
a combinação de teclas <Ctl> + <Alt> + <F1> para mudar para modo de texto
(ou introduzir o comando #telinit 3 num terminal virtual).
2. Efectuou-se login como utilizador root.
3. As VMwareTools podem ser disponibilizadas pelo sistema operativo host, seleccio-

nando a opção “Install VMwareTools” no menu superior da consola remota da
máquina virtual. Isto deverá ser efectuado com a máquina ligada e sistema ope-
rativo a correr. Ao ser seleccionada esta opção, foi disponibilizado no ponto de
montagem do CDROM (/media/cd) o software necessário.
4. Descomprimiu-se o ficheiro de instalação para a directoria /tmp

# cd /tmp
# tar xzvpf /media/cd/vmware-linux-tools.tar.gz
As opções utilizadas no comando tar são: x – refere a operação de extracção, z –

indica a manipulação de um arquivo compactado com GNUzip, v – para ser mostrada
informação detalhada dos ficheiros contidos, p – para conservar as permissões dos
ficheiros e f – para especificar o nome do ficheiro a ser descompactado.
5. Entrou-se na directoria criada e executou-se o ficheiro vmware-install.pl3 .

# cd /tmp/vmware-tools-distrib
# ./vmware-install.pl
6. Introduziu-se o seguinte conjunto de instruções para adicionar o driver vmxnet ao

kernel.
Alternativamente poderia ser lançado o script root/scripts/001_vmwareTools.sh
que lança esta mesma sequência de comandos.
3
este ficheiro é uma ligação simbólica para uma script Perl presente numa das subdirectorias.
7.6 Configuração de rede 63
# /etc/init.d/network stop
# rmmod pcnet32
# rmmod vmxnet
# depmod -a
# modprobe vmxnet
# /etc/init.d/network start
7.6 Configuração de rede
Este processo deverá ser reproduzido em todas as máquinas que fazem parte do cluster ,
caso a opção de clonagem não seja adoptada.
1. Utilizando o modo gráfico, efectuou-se login como root.
2. Acedeu-se ao programa de controlo do sistema, através de [Novell]4 ⇒[System]⇒[YaST]
3. Escolheu-se [Network Devices]⇒[Network Card]. Foram mostrados os diferentes

dispositivos de rede disponı́veis.
4. Seleccionou-se o primeiro e escolheu-se a opção “Configurar”.
5. A primeira coisa a fazer foi alterar o nome da configuração e utilizar o nome da

interface que deve ser configurada, neste caso eth0.
6. Definiu-se o endereço IP como estático, especificando-o. Foi utilizado o endereço

relativo à interface pública da máquina em questão (especificado na tabela 6.6 na
página 44). Definiu-se também a máscara de rede escolhida durante a fase de pla-
neamento para esta interface (255.255.255.240). Confirmaram-se as alterações.
7. Seleccionou-se o segundo dispositivo de rede de igual modo, usando eth1 para o

nome da configuração e os dados relativos à interface de rede privada.
8. Finalizou-se este processo de configuração.
7.7 Acerto dos Relógios
Para resolver o problema da velocidade excessiva do relógio no sistema (ver secção 2.4
na página 7), foi editado o ficheiro \etc\lilo.conf e junto com as opções do kernel,
introduziram-se as seguintes opções adicionais: acpi=off e clock=pmtmr
Exemplo:
image = /boot/vmlinuz
label = Linux
initrd = /boot/initrd
optional
root = /dev/sda4
append = "selinux=0 splash=silent acpi=off clock=pmtmr hugepages=146"
Adicionalmente, foi configurada a utilização do protocolo NTP.

64 Protótipo
1. Verificou-se que o servidor de tempo estava acessı́vel:

# ping SERVIDOR_DE_TEMPO
Caso não esteja, adicioná-lo na tabela de encaminhamento utilizando o comando

route ou o script correspondente.
Comprovar de novo.
2. Configurou-se o xntp para que o protocolo NTP fosse utilizado e pudesse corrigir al-
guns desacertos que pudessem existir. Para isso configurou-se o serviço de tempo no
YaST, em [Network Services]⇒ [NTP Client], especificando o servidor a utilizar. Nos
diferentes nós foi usado o mesmo conjunto de servidores como referência e foram hie-
rarquizados, usando a opção stratum no ficheiro de configuração (/etc/ntp.config).
Ao colocar a opção stratum n na secção de um determinado servidor de tempo no
ficheiro de configuração definimos o seu grau de preferência. Para “n” podem ser
estabelecidos números de ordem entre o 1 ao 15, sendo 1 o preferente e 15 o último
a ser utilizado.
3. Para verificação do estado do serviço de NTP, executou-se o seguinte comando, que
mostra qual o servidor de referência que está a ser utilizado:
# ntpq -p
7.8 Criar directorias para software Oracle

Foi criada a directoria estabelecida para ser a ORACLE BASE e as Home para a base
de dados e para o Clusterware.
7.9 Instalação do CVU

Este passo é necessário para a utilização das capacidades de diagnóstico fornecidas
por esta ferramenta no acessoramento da instalação Oracle Real Application Clusters (ver
secção 6.6.1 na página 51)
1. Foi criada uma directoria “Home” para alojar o software CVU onde o utilizador
oracle, responsável pela instalação Oracle Database 10 g, tivesse plenas permissões
de leitura e escrita. Nesta instalação foi definida a directoria cvu dentro da sua
directoria Home (\home\oracle\cvu).
# mkdir ∼oracle/cvu
# chown -R oracle:oinstall
# chmod -R 755 ∼oracle/cvu
2. Colocou-se o ficheiro de instalação do CVU – cvu_linux_x86.zip – nesta directoria.

3. Descomprimiu-se o ficheiro
# unzip cvu_linux_x86.zip
Opcionalmente poderá ser removido o ficheiro zip:

# rm cvu_linux_x86.zip
7.10 Configuração do Hangcheck-Timer 65
4. Criou-se uma directoria (∼oracle/cvu/tmp) onde seria colocado o output dos testes
executados por esta aplicação.
# mkdir ∼oracle/cvu/tmp
5. Definiram-se as variáveis de ambiente que indicavam qual a directoria dedicada ao

CVU, a sua directoria de output e a directoria onde se encontrava o software JRE1.45 ,
para que esta ferramenta pudesse funcionar correctamente.
Para descobrir a localização do JRE, executou-se:
# whereis java
De modo a que estas variáveis fiquem disponı́veis para futuras sessões pode editar-se
o ficheiro ∼oracle/.bashrc. Como este ficheiro não existia, foi necessário criá-lo, e
adicionaram-se as seguintes linhas:
CV_HOME=∼oracle/cvu
CV_JDKHOME=/usr/lib/java/jre
CV_DESTLOC=∼oracle/cvu/tmp
export CV_HOME CV_JDKHOME CV_DESTLOC
6. Para a utlização do CVU no SUSE Linux Enterprise Server 9 foi também necessário
fazer uma pequena alteração no ficheiro de configuração do CVU, localizado em
∼oracle/cvu/cv/admin/cvu_config, alterando o parâmetro ASSUME_DISTID do
valor Taroon para Pensacola de modo a permitir a adaptação da ferramenta ao
contexto desta distribuição. Desenvolveu-se um script (003_cvuoracle.sh) que faz
esta correcção automaticamente.
7.10 Configuração do Hangcheck-Timer
Este módulo, visto com melhor pormenor na secção 6.4.2, na página 46, deve ser
carregado no kernel com os parâmetros devidos. Para isso foram efectuados os seguintes
passos como root.
Introduziu-se dinamicamente o módulo no kernel Linux:
# modprobe hangcheck-timer hangcheck_tick=30 hangcheck_margin=180
Automatizou-se o seu carregamento para cada vez que o sistema fosse reiniciado:
# echo ’modprobe hangcheck-timer hangcheck_tick=30 hangcheck_margin=180’
>> /etc/init.d/boot.local
Confirmou-se que havia sido devidamente adicionado e que estava a funcionar com os
parâmetros correctos:
# grep Hangcheck /var/log/messages | tail -2
5
Java Runtime Environment, v1.4
66 Protótipo
7.11 Disponibilizar Memória

O sistema operativo Linux impõe limites na utilização de memória aos utilizadores re-
gulares. Para que a base de dados possa disponibilizar a quantidade de páginas de memória
conveniente para o seu óptimo desempenho, é necessário efectuar o seu desbloqueio. Este
procedimento é também necessário para utilizar as Hugepages.
Para proceder ao desbloqueio, executou-se:
# sysctl -w vm.disable_cap_mlock="1"
Para tornar esta alteração permanente e não apenas válida na presente sessão, executou-
se na linha de comandos:
# echo "vm.disable_cap_mlock = 1" >> /etc/sysctl
# chkconfig boot.sysctl on
7.12 Resolução de nomes

Para estabelecer localmente as relações Máquina – EndereçoIP, necessárias à resolução
de nomes local, foi editado o ficheiro /etc/hosts em cada um dos elementos do cluster,
conforme referido na secção 6.2.4, na página 42.
Exemplo:
172.168.9.1 rac1.localdomain rac1
172.168.9.17 rac1-priv.localdomain rac1-priv
172.168.9.8 rac1-vip.localdomain rac1-vip
172.168.9.2 rac2.localdomain rac2
172.168.9.18 rac2-priv.localdomain rac2-priv
172.168.9.9 rac2-vip.localdomain rac2-vip
7.13 Orarun
Foi necessário alterar os parâmetros em alguns dos scripts que fazem parte deste pacote
para adequar o ambiente criado com o cenário que se pretendia implementar.
• Alteraram-se as variáveis ORACLE HOME, ORACLE BASE e ORACLE SID no

ficheiro /etc/profile.d/oracle.sh, de acordo com os valores que tinham sido
definidos. Notar que quanto ao SID, cada um dos servidores deverá configurá-lo
como o nome global da base de dados (por exemplo orcl ) concatenado com um
identificador (que deverá ser um inteiro) da instância relativa ao nó do cluster em
causa. Assim, os diversos nós do cluster foram configurados conforme a relação entre
nó e respectivo SID que consta na tabela 7.3.
• No ficheiro /etc/sysconfig/oracle alterarou-se a variável ORACLE BASE e quadrando-
a com o valor adequado.
Ao editar este ficheiro, foi alterarada a atribuição feita ao parâmetro SHMMAX. Se-
gundo as recomendações da Oracle, deve ser-lhe atribuı́do um valor que seja metade
da memória RAM disponı́vel, com o este valor expresso em bytes.
7.14 Limites 67
Nó SID
rac1 orcl1
rac2 orcl2
Tabela 7.3: Identificadores SID utilizados nos nós do cluster.
• O ficheiro etc/init.d/oracle contém o motor de funcionamento deste pacote que

realiza as operações definidas no ficheiro da directoria profile.d .
Este pacote cria o utilizador oracle como membro dos grupos necessários para a
instalação dos productos Oracle, criando também os respectivos grupos. Inicialmente
esta conta tinha algumas capacidades desactivadas, como a de fazer login ou aceder à
linha de comandos. Foi necessário activá-las. Uma das formas utilizadas para fazê-lo foi
editando o ficheiro /etc/passwd atribuindo-lhe uma shell, alterando o valor /bin/false
para /bin/bash .
Feito isto, foi definida uma password para este utilizador através do comando:
# passwd oracle
7.14 Limites
Foram ainda alteradas algumas variáveis de ambiente (script 009) para permitir alargar
os limites ao utilizador oracle quanto ao número de descritores, assim como o número de
processos que se lhe permite ter abertos.
7.15 Máquinas seguintes

Neste ponto foram repetidos os passos vistos anteriormente nesta secção para configurar
as restantes máquinas do cluster. Considerêmo-lo um marco no processo de instalação.
Foi explorada a facilidade de clonagem, por um lado para optimizar o processo, por
outro para testar esta funcionalidade com um sistema Linux, o que ainda não havia sido
feito na Trety . Para isto foi realizado o seguinte:
1. retirados os discos partilhados da máquina virtual

2. confirmação que as interfaces de rede estavam inoperativas
3. desligada a máquina
4. cópia do disco virtual utilizado como disco “local”
5. criação de uma nova máquina virtual com caracterı́sticas idênticas, porém utilizando
o disco rı́gido virtual clonado e não originando um novo
6. atribuição dos discos partilhados a ambas as máquinas, configurados com a mesma
controladora SCSI, que tem o modo de partilha de bus activado, para que os discos
sejam de facto partilhados
Caso este procedimento seja utilizado, deverá ser reposta a funcionalidade de rede em
cada uma das máquinas.
68 Protótipo
7.16 Equivalência de utilizadores
É requisito para a instalação do RAC que haja uma equivalência do utilizador oracle,
assim como dos grupos a que pertence (em particular dba e oinstall), entre os vários nós
do cluster. Isto porque existem comandos, programas e ficheiros que são trocados entre
os vários servidores e esta prática facilita a gestão destas operações.
Nesse sentido foi configurada também uma equivalência a nı́vel de protocolo SSH, para
que as operações remotas fossem efectuadas de um modo seguro, por um lado, e autónomo,
por outro, já que através da equivalência que é estabelecida se evita a necessidade de
interacção com o utilizador para inserir a password quando se estabelece a ligação segura.
Em cada nó, na directoria Home da conta do utilizador oracle, foi criada a directoria
onde seriam guardados os ficheiros necessários à troca de mensagens SSH entre os membros
do cluster . Nesta localização criou-se um par de chaves (pública e privada) de cada tipo
(RSA e DSA). Isto porque a versão 1 do SSH utiliza chaves RSA e a versão 2 utiliza
chaves DSA. Cobrindo os dois tipos permite-se que o SSH possa utilizar qualquer uma das
versões.
Como utilizador oracle, foi executado:
# mkdir ∼/.ssh
# chmod 755 ∼/.ssh
# /usr/bin/ssh-keygen -t rsa
# /usr/bin/ssh-keygen -t dsa
Na criação das chaves pode ser opcionalmente definida uma frase de passe para garantir
uma protecção adicional. Nesta configuração foi deixada em branco. Porém, caso seja
preenchida, deverá ser definida com o mesmo valor em ambos os nós e lançado o programa
ssh-agent em todas as máquinas do cluster .
O conteúdo dos ficheiros relativos às chaves públicas de cada nó, id_rsa.pub e também
id_dsa.pub, deve ser copiado para o ficheiro ∼oracle/.ssh/authorized_keys, quer da
própria máquina, quer de todas as outras que fazem parte do cluster . Neste caso, entre
máquinas distintas, o comando ssh especificado faz a cópia dos conteúdos da máquina
remota para a máquina local. Estes comandos devem ser repetidos nos vários membros
do cluster .
# cat ∼/.ssh/id_rsa.pub >> ∼/.ssh/authorized_keys

# cat ∼/.ssh/id_dsa.pub >> ∼/.ssh/authorized_keys
# ssh oracle@rac2 cat ∼/.ssh/id_rsa.pub >> ∼/.ssh/authorized_keys
# chmod 644 ∼/.ssh/authorized_keys
Foi então testada a conectividade entre todos os nós, estabelecendo a partir de cada um
ligações SSH tanto para o próprio, como para os restantes nós. Quando se estabelecia a
primeira ligação entre cada par, era apresentado um pedido de confirmação sobre a ligação
em causa, que não se voltava a repetir em posteriores ligações. Como este pedido deve ser
evitado durante o funcionamento do RAC, devem ser testadas e estabelecidas, nesta fase,
todas as ligações possı́veis entre os nós.
7.17 Preparação das partições 69
7.17 Preparação das partições
De forma a utilizar o espaço partilhado de armazenamento, foram criadas as partições

necessárias à sua utilização.
Executou-se para cada disco, a partir de uma única máquina:
# fsdisk /dev/sdb
# fsdisk /dev/sdc
# fsdisk /dev/sdd
# fsdisk /dev/sde
Foi criada uma única partição em cada disco. Ao correr o fsdisk, utilizou-se a opção
n para criar uma nova partição. Indicou-se que seria primária (p) e que seria a primeira
partição primária de quatro possı́veis (1). Escolhendo a opção p era mostrada a tabela de
partições, pronta a ser criada. Quando se confirmou a validação, por parte do utilizador,
da configuração preparada, através da opção w foi feita a escrita da nova tabela de partições
no disco apontado. Ao ser finalizada a escrita, o programa saiu automaticamente para a
linha de comandos.
Para que nos outros elementos do cluster as alterações realizadas fossem reconhecidas
pelo kernel, foi executado como root, em cada um deles, o comando:
# partprobe
7.18 OCFS2
Seguidamente são enunciados os passos que foram percorridos para configurar o sistema
de ficheiros Oracle Cluster File System 2 .
1. Para criar o ficheiro de configuração do Oracle Cluster File System 2 , que é alojado
em /etc/ocfs2/cluster.conf, foi executado como root:
# ocfs2console
Foi mostrada a consola de configuração do OCFS2. Nesta aplicação foi seleccionado

no menu superior a opção [Cluster]⇒[Configure Nodes]. Então foi apresentada uma
janela onde foram adicionados os diferentes elementos do cluster que deveriam parti-
lhar este sistema de ficheiros. Para adicioná-los, clicou-se em “Add”, adicionando na
janela emergente os dados relativos ao primeiro nó – o seu nome e endereço IP (rela-
tivos à rede pública), deixando o porto que aparecia por omissão (7777) inalterado.
Este procedimento de adição foi repetido para os nós seguintes.
2. O ficheiro criado deverá constar em todos os servidores. Para isso poderá ser feita
uma cópia fiel do ficheiro criado no ponto anterior, colocando-a na localização res-
pectiva nos diferentes nós ou pode ser usada a consola utilizada no ponto anterior.
Foi utilizado este último método, que é provavelmente o mais ágil. Para isso fechou-
se a janela em que é feita a configuração dos nós. Seleccionou-se então, na janela
inicial da consola, [Cluster]⇒[Propagate Configuration]. O ficheiro de configuração
criado foi disseminado pelos restantes servidores.
70 Protótipo
Como esta propagação utiliza SSH, teve de ser introduzida a password de root,
quando requerido, para permitir que a operação fosse efectuada nos diversos servi-
dores.
3. Para ver o estado da pilha de serviços do cluster OCFS2:

# /etc/init.d/o2cb status
4. Para que a pilha fosse carregada a cada reinı́cio, inseriu-se o seguinte comando em
todos os nós, como root:
# /etc/init.d/o2cb enable
A sua activação no reinı́cio do sistema foi verificada no conjunto de membros intro-

duzindo:
# chkconfig --list 02cb
Espera-se que o serviço se encontre com o estado “on” para os nı́veis 3 e 5, que
representam o respectivo runlevel 6 .
5. Criou-se o ponto de montagem para este sistema de ficheiros nos vários nós:
# mkdir /u02
6. Apenas a partir de um nó, foi criado o sistema de ficheiros, introduzindo como root:
# mkfs.ocfs2 -b 4K -C 32K -N 4 -L /u02 /dev/sdb1
Este comando cria o sistema de ficheiros OCFS2 na partição /dev/sdb1 com a

etiqueta /u02 (-L) através da qual pode ser identificado, com um tamanho de bloco
de 4kB (-b) e de cluster de 32kB-C com 4 slots disponı́veis (-N).
7. Procedeu-se então à montagem do sitema de ficheiros recém criado no ponto de

montagem que lhe é dedicado, em todos os elementos do cluster . Isto foi feito na
linha de comandos:
# mount -t ocfs2 -o datavolume,nointr,_netdev -L /u02 /u02
Pode ver-se que foi utilizada a etiqueta que associámos ao sistema de ficheiros quando
o criámos, para facilitar a sua identificação.
Utilizou-se também a opção de montagem datavolume. É uma opção essencial para
os volumes que contenham os ficheiros Voting Disk, Cluster Registry, os ficheiros de
dados da BD, Redo logs, logs de arquivo e ficheiros de controlo, de modo a assegurar
que os processos Oracle abram estes ficheiros com a flag o_direct [60]. Esta flag
tenta minimizar os efeitos da cache de E/S nos ficheiros acedidos. Geralmente este
procedimento traduz-se num decréscimo da performance mas é útil em situações em
que as aplicações têm os seus próprios mecanismos de cache ou necessitam ter um
acesso directo aos dados contidos nos dispositivos, como é o caso.
Para verificar se a montagem foi feita devidamente:
# mount
6
runlevel é uma configuração do software do sistema que apenas permite existir um grupo pré-
seleccionado de processos em execução
7.19 Clusterware 71
Detectar os volumes OCFS2 no sistema:

# mounted.ocfs2 -d
Fazer diagnóstico dos volumes OCFS2 no sistema:

# fsck.ocfs2 -n /u02
8. De modo a que a montagem deste sistema de ficheiros fosse restituı́da automati-

camente aquando do reinı́cio do sistema, em todos os nós foi editado o ficheiro
/etc/fstab, introduzindo a linha:
LABEL=/u02 /u02 ocfs2 _netdev,datavolume,nointr 0 0
netdev – representa que depende da ligação de rede, devendo por isso, durante o
processo de arranque do sistema, ser activada depois do serviço de rede e antes dele,
quando o sistema é desligado.
datavolume – activa flag o direct.
nointr – assegura que as operações de escrita e leitura não são interrompidas por
sinais.
9. Criou-se uma directoria no sistema de ficheiros OCFS2, usada para guardar os fi-
cheiros partilhados do Clusterware. Como root executou-se na linha de comandos:
# mkdir -p /u02/oracrs
# chown oracle:oinstall /u02/oracrs
# chmod 775 /u02/oracrs
Criou-se outra directoria para conter os ficheiros da base de dados (onde seria mon-
tado posteriormente o ASM).
# mkdir -p /u02/oradata
# chown oracle:oinstall /u02/oradata
# chmod 775 /u02/oradata
7.19 Clusterware
Caso sejam utilizadas aplicações que utilizem o acesso remoto para executar aplicações
gráficas, de maneira a permitir esse tipo de acesso, deve ser desactivado o controlo de
acesso ao servidor X pelo root (executando xhost +) ou especificando o endereço IP da
máquina de onde provém o pedido (executando xhost + IPMÁQUINA).
# su a
# DISPLAY=:0.0; export DISPLAY; xhost +
a
introduzir a password de root e após realizar os comandos preten-
didos como super-utilizador, introduzir exit na respectiva consola para
voltar ao modo normal.
Foi assegurado que algumas variáveis de ambiente não estivessem definidas (ver secção 5.1.1
na página 28).
# unset ORACLE_HOME
# unset TNS_ADMIN
72 Protótipo
Confirmou-se que as variáveis de ambiente ORACLE SID eram distintas em cada um

dos nós do cluster .
# echo $ORACLE_SID
Criou-se uma directoria para o software necessário e colocou-se aı́ o ficheiro zip de
instalação do Clusterware. Descomprimiu-se o ficheiro zip.
# unzip 10201_clusterware_linux32.zip
Na directoria do onde se encontrava o software, executou-se o programa de instalação.

# ./runInstaller
1. Directoria do inventário de instalações: /u01/app/oracle/oraInventory

Grupo do sistema operativo7 : oinstall
2. Nome da instalação: OraCrs10g home

Caminho: /u01/crs/oracle/product/10/app
3. Seguidamente foram feitos alguns diagnósticos que comprovam o cumprimento dos
pre-requisitos especı́ficos do software que estava a ser instalado. Caso houvesse algum
que não fosse cumprido, deveria ser abortada a instalação e efectuar os procedimentos
necessários para que fosse satisfeito. Com o resultado de sucesso em todos os items,
continuou-se para o passo seguinte (Next).
4. Especificação da configuração do cluster .

Definir um nome para o cluster : crs
Adicionaram-se todos os nós pertencentes ao cluster e definiram-se os nomes utili-
zados para as interfaces de rede pública, privada e virtual de cada nó. Os nomes
utilizados foram os indicados na tabela 6.6, apresentada na página 44.
5. Especificação do uso de interfaces de rede.

Para as interfaces disponı́veis (eth0 e eth1), indicou-se a subrede e o tipo de in-
terface, de acordo com o estabelecido na tabela 6.5, apresentada na página 44, na
secção onde são vistos os Endereços IP a utilizar pelos Real Application Clusters.
6. Especificar a localização do ficheiro OCR.

Há que escolher o nı́vel de redundância a utilizar (Normal ou Externa): Foi esco-
lhida Redundância Externa por este se tratar de um ambiente de prova, porém
é recomendado que seja utilizado o nı́vel de Redundância Normal num ambiente
de produção, o que gera (por parte do software) um mirror deste ficheiro que será
utilizado em caso de dano ou indisponibilidade do primeiro.
Localização para o OCR: /u02/oracrs/ocr.crs
Notar que ao ser seleccionado o nı́vel de redundância normal, a localização do mirror
tem de ser também inserida. Neste caso preencher o campo que indica a sua loca-
lização no armazenamento partilhado, como por exemplo: /u02/oracrs/ocr mirror.crs.
Preferencialmente deverá ser utilizado um volume diferente para aumentar a segu-
rança dos dados.
7
deve ser especificado o grupo que tem privilégios de escrita sobre o inventário de instalações para
produtos Oracle.
7.19 Clusterware 73
7. Actuar de igual modo como no ponto anterior, agora relativamente ao Voting Disk.
Localização para o Voting Disk: /u02/oracrs/vot.crs
8. A instalação é efectuada primeiro localmente, depois nos membros remotos do clus-

ter . Quando o processo terminou foi apresentada uma janela solicitando a execução
de uns scripts complementares a executar pelo root.
Abriu-se uma nova consola em cada uma das máquinas como root. Executou-se
primeiro na máquina de onde se estava a proceder à instalação, depois nas seguintes
(que neste caso era apenas uma):
/u01/app/oracle/oraInventory/orainstRoot.sh
9. Usando as mesmas consolas, também como super-utilizador, pela mesma ordem,

editou-se o ficheiro /u01/crs/oracle/product/10/app/install/rootconfig em
cada máquina.
Na linha 356, alterou-se a entrada
CLSCFG_MISCNT="-misscount 60"
para
CLSCFG_MISCNT="-misscount 360"
Após ser editado o ficheiro, executou-se o segundo script conforme era solicitado na
janela que especificava os scripts a executar, procedendo da mesma forma que para
o anterior.
/u01/crs/oracle/product/10/app/root.sh
10. Verificar as mensagens reportadas pelo script executado.

Devido à utilização de uma subrede de âmbito local (172.16.*.*)8 , onde os pacotes
inseridos na rede não são alvo dos processos de encaminhamento, o processo de
atribuição do endereço VIP falhou, por considerar encontrar-se configurado numa
rede que não é pública.
Neste caso, a execução do último script apresentava o seguinte erro:
The given interface(s), "eth0" is not public.

Public interfaces should be used to configure virtual IPs.
Caso isto suceda é necessário correr manualmente o assistente de configuração do

endereço virtual (vipca) a partir do último nó onde foi executado o script (que deverá
ser o rac2), e lançá-lo como root. Confirmou-se previamente que era possı́vel correr
aplicações gráficas utilizando o servidor X local.
/u01/crs/oracle/product/10/app/bin/vipca
(a) Ao entrar na aplicação clicou-se em “Next”

(b) Escolheu-se a interface de rede pública: eth0
(c) Especificou-se o VIP para os nós do cluster . Editaram-se os campos que definem
a configuração de cada um dos nós:
8
o que acontece também se forem utilizadas as subredes 10.*.*.* ou 192.168.*.*
74 Protótipo
rac1
Nome do nó rac1
Nome da interface VIP rac1-vip
Endereço VIP: 172.16.9.8
Máscara de rede 255.255.255.240
rac2
Nome do nó rac2
Nome da interface VIP rac2-vip
Endereço VIP: 172.16.9.9
Máscara de rede 255.255.255.240
Tabela 7.4: vipca - Configuração da rede virtual.
(d) Foi então apresentado o sumário da configuração a realizar, que deveria ser
confirmada. Finalizou-se, de modo a que fosse aplicada.
(e) Quando o processo terminou, foram mostrados os resultados na janela do as-
sistente de configuração. Poude então ser terminada a aplicação escolhendo
“Exit”.
11. Finalizou-se então a aplicação OUI, confirmando a completa execução dos scripts
solicitados por parte do utilizador root.
7.19.1 Verificar a instalação do Clusterware
Verificaram-se os nós registados no Clusterware:

# $CRS_HOME/bin/olsnodes -n
Verificaram-se os scripts de iniciação automática do Clusterware:

# ls -l /etc/init.d/init.*
Avaliou-se a integridade do Oracle Cluster Registry:

# ocrcheck
Iniciaram-se as aplicações ao nı́vel do nó num elemento do cluster em particular (uma

lista mais detalhada da utilização do comando srvctl pode ser consultada em [61, apêndice
B]).
# srvctl nodeapps -n rac1
Mostrar o estado dos serviços nos diferentes elementos do cluster :

# $CRS_HOME/bin/crs_stat -t
Parar os serviços geridos pelo Clusterware:

# $CRS_HOME/bin/crs_stop -all
Iniciar os serviços geridos pelo Clusterware.

7.20 Automatic Storage Management 75
# $CRS_HOME/bin/crs_start -all
Depois da instalação, foram alteradas as permissões de modo a dar permissão de escrita

na directoria Home do Clusterware apenas ao utilizador root.
# chown root /u01/crs
# chmod o-w /u01/crs
7.20 Automatic Storage Management

Para a instalação do ASM são necessários três pacotes, o driver para o kernel especı́fico
em que irá funcionar, a biblioteca e as ferramentas de suporte.
Este software foi descarregado na página da Oracle em http://www.oracle.com/technology/
software/tech/linux/asmlib/sles9.html .
7.20.1 Instalar o software
Deve instalar-se o software, o que foi feito através da conta do utilizador root, na
directoria onde se encontravam os pacotes rpm, através do comando:
# rpm -Uvh oracleasm-2.6.5-7.257-default-2.0.2-1.i586.rpm \
oracleasmlib-2.0.2-1.i386.rpm oracleasm-support-2.0.2-1.i386.rpm
7.20.2 Configurar o driver
Antes de a utilizar, esta ferramenta teve de ser configurada em todos os nós (pelo
root).
# /etc/init.d/oracleasm configure
Default user to own the driver interface []: oracle

Default group to own the driver interface []: dba
Start Oracle ASM library driver on boot (y/n) [n]: y
Fix permissions of Oracle ASM disks on boot (y/n) [y]: y
7.20.3 Criar discos ASM
Para utilizar os discos dedicados à utilização ASM foi necessário prepará-los como tal,
usando as partições criadas na secção 7.17 (página 69).
Esta operação foi realizada apenas num dos membros do cluster através da conta de
super-utilizador. No comando a empregado é especificado o nome a atribuir ao novo disco
(NOMEDISCO), onde devem ser usadas apenas letras maiúsculas, números e undersco-
res( ), tendo necessariamente de começar por uma letra. A PARTIÇÃO que deverá ser
utilizada é especificada pela identificação que tem perante o sistema operativo. O comando
tem o formato ‘oracleasm createdisk NOMEDISCO PARTIÇ~ AO’.
# /etc/init.d/oracleasm createdisk VOL1 /dev/sdc1
# /etc/init.d/oracleasm createdisk VOL2 /dev/sdd1
# /etc/init.d/oracleasm createdisk VOL3 /dev/sde1
76 Protótipo
De modo a verificar que os discos foram marcados convenientemente foi introduzido

na linha de comandos:
# /etc/init.d/oracleasm listdisks
Caso se pretenda alterar a disposição dos dispositivos marcados ou proceder à remoção

de um dado VOLUME de uma instalação anterior pode ser executado:
# /etc/init.d/oracleasm delete disks VOLUME
Nos outros pontos do cluster , foi validada a configuração efectuada através do co-
mando:
# /etc/init.d/oracleasm scandisks
Pode também ser questionado se uma determinada partição está a ser utilizada pelo
ASM através do comando:
# /etc/init.d/oracleasm querydisk /dev/sda3
7.21 Instalação do software Oracle Database 10g
Este processo efectuou-se a partir de um único servidor do cluster . Neste caso fez-se
desde o rac1.
Desactivou-se o controlo de acesso sobre o modo gráfico, pelo método já referido em
pontos anteriores (secção 7.19), de modo a que a aplicação pudesse ser executada.
Confirmou-se que em cada nó o SID definido era distinto e que o Clusterware nos
vários nós se encontrava activo. Usando a conta de utilizador oracle, desactivaram-se
as variáveis de ambiente ORACLE HOME e TNS ADMIN. Lançou-se o OUI em modo
gráfico para realizar a instalação do software.
# /u01/app/oracle/orainstall/database/runInstaller
1. Escolher um dos tipos de instalação: Enterprise Edition
2. Especificar detalhes da Home:

Nome: OraDb10g home1
Caminho:/u01/app/oracle/product/10.2.0/db 1
3. Especificar modo de instalação de hardware do cluster

Seleccionou-se a instalação em cluster e aplicou-se a instalação a todos os nós,
escolhendo-os a todos na janela de selecção.
4. Diagnóstico de pré-requisitos. Este processo é feito para todos os items excepto os

relativos à configuração de rede. Quanto a este ponto, a verificação é da responsabili-
dade do utilizador, como foi realizado, validando a caixa verificação correspondente.
Caso algum dos diagnósticos falhe, a sua causa deverá ser revista pelo utilizador de
modo a que os pré-requisitos sejam satisfeitos. Neste caso, repetir os diagnósticos
(escolhendo “Retry”).
7.22 Configuração do Listener 77
5. Na escolha da opção de configuração, seleccionou-se “Install database Software

only”
6. Foi apresentado o sumário da instalação que seria aplicada. Clicou-se em “Next”

para prosseguir com a instalação.
7. A instalação efectuou-se primeiro localmente e depois nos nós remotos relativamente

ao assistente de instalação.
Quando o processo se concluı́u, foi solicitado ao utilizador que executasse em cada nó
um script, através do “super-utilizador”, primeiro na máquina onde corre o assistente
de instalação e posteriormante nas máquinas seguintes. Esta execução não deve
ser simultânea. O script a lançar (./root.sh) encontrava-se disponibilizado na
directoria seleccionada para Home do software da base de dados.
# /u01/app/oracle/product/10.2.0/db_1/root.sh
8. Após ter sido efectuado em todos os nós do cluster , a sua execução teve de ser
indicada no assistente de instalação e então finalizou-se.
7.22 Configuração do Listener
Para proceder a esta configuração é necessário ter acesso ao modo gráfico. Fez-se o
login como oracle. Através do modo gráfico, arrancou-se num dos nós o assistente de
configuração Oracle Net:
# netca &
1. Seleccionar como tipo de configuração Oracle Net Services: Cluster configuration.
2. Seleccionar todos os nós do cluster , neste caso rac1 e rac2.
3. Escolher Listener configuration.
4. Add para adicionar um listener.
5. Escolher um nome para o listener. Pode ser utilizado o valor LISTENER, que é
apresentado por omissão.
6. Indicou-se o TCP como único protocolo utilizado.
7. Utilizou-se o porto 1521.
8. Indicou-se que não deve ser criado um Listener adicional e no final da configuração
clicou-se em “Next”.
Um erro reportado ao colocar o Listener em estado online num dos nós, representa
muito provavelmente um problema na configuração, possivelmente relacionado com
o VIP. Certificar que as interfaces de rede têm a configuração adequada. Caso seja
utilizado uma gateway, verificar que está acessı́vel (através do comando ping), pois
tal inacessibilidade pode traduzir-se num funcionamento irregular da rede virtual,
fundamental para o sucesso desta fase.
78 Protótipo
9. Ao tornar ao menu de entrada, seleccionou-se uma nova operação de configuração,

desta vez Naming Methods configuration
10. Indicou-se a utilização do método de resolução de nomes local, através da escolha

Local Naming
11. Depois de esperar pelo final do processo de configuração pôde-se sair da aplicação.
Pode-se verificar o sucesso desta configuração através de uma das seguintes instruções:
# ps -ef | grep -v grep | grep lsnr
# $CRS_HOME/bin/crs_stat -t
# netstat -anp | grep 1521
Pelo primeiro comando vemos se o processo está a correr, pelo segundo o estado do
serviço no registo, segundo os registos do Clusterware, e pelo terceiro vemos que o porto
especificado se encontra a ser utilizado pelo Listener.
7.23 Criação da base de dados
Este processo foi efectuado apenas num dos nós, utilizando a conta de utilizador oracle
e através do modo gráfico, de acordo com o procedimento efectuado em pontos anteriores.
# dbca &
1. Ao entrar na aplicação foi mostrada uma janela de boas-vindas ao assistente de

configuração de bases de dados para Oracle Real Application Clusters. Seleccionou-
se o tipo de base de dados que se pretendia criar: Oracle Real Application
Clusters database.
2. Operação que se pretende efectuar: Create a Database
3. Selecção dos nós. Foram seleccionados todos os nós disponı́veis (rac1 e rac2).
4. Escolheu-se o formato de base de dados a criar: Custom Database
5. Identificação da base de dados.

Nome global da Base de Dados: orcl.localdomain
Prefixo SID: orcl
6. Opções de gestão.
Foram utilizados os valores apresentados por omissão. A base de dados é configurada
com o Enterprise Manager. Poderá opcionalmente ser definido um endereço de email
para onde deverão ser enviadas as notificações respeitantes à gestão da base de dados
assim como poderá ser activado o serviço de cópias de segurança diárias, porém estas
facilidades não foram activadas.
7. Credenciais da Base de Dados.

Foram definidas as passwords a ser utilizadas na nova base de dados, que não devem
começar por dı́gitos.
7.23 Criação da base de dados 79
Pode ser definida apenas uma para todas as contas de administração (opção utilizada,
adequada num âmbito de provas porém veemente desaconselhada para um ambiente
de produção).
Caso seja escolhida a opção que permite a distinção de passwords, deverão ser espe-
cificados os pares – password e confirmação – para os utilizadores SYS, SYSTEM ,
DBSNMP e SYSMAN.
8. Opções de Armazenamento.
A opção utilizada foi Automatic Storage Management (ASM).
9. Criar instância ASM.

Dado que a instância ASM não foi previamente criada, nos passos seguintes foram
introduzidas as opções de configuração para este método de acesso ao armazenamento
partilhado.
Introduziu-se a password referente ao utilizador SYS para a instância ASM.
Especificou-se a localização para o ficheiro que guarda os parâmetros de servidor SP-
FILE. Escolheu-se um local partilhado de modo a que os vários servidores pudessem
compartir a parametrização.
Neste sentido, foi utilizado o espaço partilhado do sistema de ficheiros OCFS2.
Especificou-se como localização /u02/oradata/orcl/dbs/spfile+ASM.ora. Clicou-
-se em “Next”.
Confirmou-se a criação da instância ASM clicando em “OK”.
10. Foi apresentado um ecrão onde seria feita a gestão dos grupos de discos (Disk Group).
Procedeu-se à criação de um novo Disk Group (secção 5.2.4, página 34), clicando em
“Create New”.
(a) Criou-se o Disk Group para utilização geral da base de dados.

Foi definido o nome a ser utilizado pelo grupo:
Nome do Disk Group: ORCL GRUP1
Escolheu-se qual o nı́vel de redundância a aplicar. Foi escolhido o nı́vel ex-
terno, para aligeirar a carga exercida sobre os discos usados, dado o ambiente
particular onde foi implementado o sistema, cuja utilização não era exclusiva à
plataforma criada e existiam outras aplicações que deles necessitavam.
Redundância: External
Num caso tı́pico, deverá ser escolhido o nı́vel normal, ou de redundância elevada.
Nesse caso é disponibilizada a opção de especificar grupos de falha. Devem
ser definidos pelo menos dois grupos de falha distintos (por exemplo FAILU-
REGROUP 1 e FAILUREGROUP 2) no âmbito do Disk Group utilizado. A
instância ASM fará a gestão da utilização de discos de maneira a que cada um
dos grupos de falha ofereça um mecanismo de mirroring ao outro.
A distribuição dos discos pelos grupos de falha deverá ser feita agrupando dis-
cos que dependam de dispositivos comuns (como controladoras SCSI ou fontes
de alimentação) ou estabelecendo grupos que partilhem a mesma localização.
Deste modo, se falhar um dos grupos de falha, existe uma menor probabilidade
que o outro padeça do mesmo mal. Ao utilizarem dispositivos diferentes, os
factores que poderão causar uma quebra são independentes entre os diferentes
80 Protótipo
grupos, o que permite que perante uma incidência sobre um dos grupos possa
ser mantida uma resposta activa do serviço por parte do outro.
Foram apresentados como candidatos ao Disk Group presente os discos ASM
anteriormente criados na secção 7.20.3 (página 75).
Seleccionaram-se os discos membros: ORCL:VOL1 e ORCL:VOL2 (Deixou-
se o volume ORCL:VOL3 por seleccionar)
Selecção Disk Path Header Status ASM Name Size(MB)

? ORCL:VOL1 Provisioned 6142
ORCL:VOL3 Provisioned 12284
Tabela 7.5: Disk Group para armazenamento da BD: Escolha de discos membros.
Clicou-se em “OK” para proceder à criação.

Ao voltar ao menu de gestão dos grupos de discos, escolheu-se de novo “Create
New” para criar um novo, desta vez para uso especı́fico da Flash Recovery Area.
(b) Criar “Disk Group” .
Nome do Disk Group: FLASH RCVR AREA GRUP
Redundância: External
Seleccionar discos membros: ORCL:VOL3
Selecção Disk Path Header Status ASM Name Size(MB)

ORCL:VOL1 Member VOL1 6142
ORCL:VOL2 Member VOL2 6142
Tabela 7.6: Disk Group para Flash Recovery Area: Escolha de discos membros.
Clicou-se em “OK” para proceder sua à criação.
Na janela de gestão dos grupos de discos, escolheu-se apenas o grupo para utilização
geral da BD (ORCL GRUP1) e clicou-se em “Next” para adoptá-lo como grupo
que contém a base de dados.
11. Especificou-se a localização dos ficheiros a ser criados para a BD.

Foi utilizada a opção “Oracle-Managed Files”
Área de BD: Utilizou-se o Disk Group criado no ponto 10a (+ORCL GRUP1).
12. Configuração de recuperação.

Activou-se a caixa de selecção que permitia a especificação da Flash Recovery Area.
No campo disponı́vel para a introdução do endereço, utilizou-se o botão de na-
vegação e seleccionou-se o Disk Group dedicado a este efeito, criado anteriormente
no ponto 10b (+FLASH RCVR AREA GRUP).
Feita a selecção, o campo que define o tamanho do volume foi automaticamente
preenchido.
7.23 Criação da base de dados 81
13. Conteúdo da base de dados.

Neste sector, são definidas as funcionalidades que a presente base de dados engloba
e respectivas tablespaces. Algumas das opções encontravam-se desabilitadas, dado
que o software especı́fico de que necessitam não foi instalado (requer a instalação
do software contido no Oracle Companion CD). Foi utilizada a selecção apresentada
por omissão.
14. Serviços da base de dados.

À base de dados presente foi adicionado um novo serviço, através do qual as aplicações
cliente podem aceder à base de dados.
Seleccionou-se a base de dados a ser criada (orcl.localdomain) e clicou-se em “Add”.
Introduziu-se o nome pelo qual deveria ser identificado o serviço: ortrety
No painel de detalhes, indicaram-se as duas instâncias do cluster (rac1 e rac2) como
preferidas e escolheu-se para polı́tica TAF (Transparent Application Failover) o nı́vel
básico.
Seguiu-se para o passo seguinte.
15. Parâmetros de inicialização.

Neste passo podem ser alterados os parâmetros de inicialização da base de dados.
Dividem-se em diferentes painéis – Memória (alocação de memória, SGA, PGA),
Dimensionamento (tamanho dos blocos utilizados e número máximo de processos
que se podem ligar simultaneamente à BD), Conjuntos de caracteres (definições
regionais), Modo de ligação (servidor dedicado ou partilhado).
Atenção que alguns destes parâmetros não podem ser alterados posteriormente.
Foram usados os valores apresentados por omissão.
16. Armazenamento da base de dados.

Foram mostrados parâmetros deste âmbito (Controlfile, Tablespaces, ficheiros de
dados e grupos de Redo log). Os valores foram mantidos inalterados.
17. Opções de criação.

É possı́vel criar um molde a partir da configuração escolhida assim como a criação
de scripts para geração automática da base de dados.
A única opção escolhida foi a de criação da base de dados.
18. Antes de criar a instância da base de dados, foi apresentado o respectivo sumário.
Após a sua verificação, foi confirmada a criação.
No final, foi apresentada uma janela reportando a conclusão da criação, a partir da
qual poderia ser completado o processo de gestão das contas de utilizador de maneira
a desbloquear algumas delas e, se pretendido, alterar as respectivas passwords.
Ao sair da aplicação a instância foi iniciada juntamente com os respectivos serviços.
Capı́tulo 8
Outras Tarefas
Durante o perı́odo em que o projecto ia sendo desenvolvido, houve também uma co-
laboração activa com a secção de Infra-estruturas do departamento de informática em
algumas tarefas. Apesar de não estarem relacionadas com o projecto de um modo di-
recto, pela sua natureza, permitiram o contacto fı́sico com as plataformas sobre as quais
se debruçava o estudo levado a cabo.
Por outro lado, com a formação apreendida neste âmbito, caso se tivessem concretizado
as expectativas de se ter seguido com a implementação Oracle Real Application Clusters em
ambiente nativo, pela aprendizagem e familiarização em termos de conceitos, componentes
e equipamentos que daı́ resultou, alguns dos passos já estariam dados, pois segundo a
previsão inicial seria utilizado equipamento semelhante.
8.1 Servidores Blade
Houve um contacto com servidores Blade da Dell (PowerEdge 1855), executando a sua
instalação desde uma fase “bare-metal” com a montagem fı́sica no rack de servidores, até
ao estado de produção.
Figura 8.1: Rack de servidores Blade. Em destaque pode ver-se um dos servidores Blade
(limitado a laranja)
8.2 Citrix Metaframe 83
Nestes servidores foi realizada a instalação de sistemas operativos Microsoft Windows

2003 Server de 32 e 64 bit, a partir da consola de administração. Houve ainda a utilização
do software Open Management Server Assistent da Dell para o particionamento dos discos,
configuração das máquinas em RAID1, configuração de rede e definição de outras opções
de instalação.
8.2 Citrix Metaframe
A plataforma Citrix MetaFrame, também conhecida como Citrix Presentation Server,

é uma solução que funciona como servidor de aplicações. O seu funcionamento baseia-se
numa separação entre o nı́vel da aplicação por um lado e a interface com o utilizador, por
outro.
O nı́vel aplicacional é realizado por um grupo de servidores dedicados, responsáveis
por executar as aplicações acedidas pelos clientes. Este conjunto de servidores é mantido
na “quinta Citrix”1 (denominação que é dada ao conjunto de servidores que se encontram
em estado operacional e que participam na disponibilização do serviço) e são geridos de
uma forma centralizada.
No lado oposto funciona o cliente Citrix-ICA2 , aplicação que é mantida nos termi-
nais clientes, disponı́vel para diferentes tipos de sistemas operativos, entre eles Microsoft
Windows ou Linux, que executa as aplicações disponibilizadas em modo de “terminal”
e pode aceder-lhes através de uma LAN ou sobre Internet através de ligação VPN. Nos
terminais, são apresentadas as aplicações através de um acesso seguro e após um processo
de autenticação.
Houve uma formação em alguns dos processos de gestão na plataforma Citrix Meta-
Frame que visou a adição de servidores na “quinta” Citrix, adição/remoção de aplicações a
serem disponibilizadas, alteração do modo de aceitação do fornecimento de serviço em ser-
vidores especı́ficos e a aprendizagem de métodos para sua colocação e retirada de produção.
8.3 Clonagem de servidores
Foi realizada a clonagem de servidores de Domı́nio e servidores Citrix através da uti-

lização da ferramenta Ghost. Esta ferramenta tem um funcionamento cliente/servidor.
Permite capturar uma imagem de uma dada máquina de origem, onde deverá ser lançado
o programa cliente e seleccionadas as opções locais de modo preparar o processo.
No servidor, é lançado o programa no modo que lhe corresponde (modo servidor), são
definidas as opções gerais e são tomadas as acções essenciais de gestão do processo como
iniciar a extracção ou a recuperação dos dados.
Criada a imagem pode então ser extrapolada para a máquina destino, que deve ter em
execução o programa cliente. Neste caso o fluxo é no sentido servidor/cliente.
Este método fornece uma forma eficaz de colocar em funcionamento novos servidores,
eliminar potenciais desvios ou enganos a respeito da configuração correcta, assim como
permite dispôr de um sistema eficiente de restauração em caso de desastre.
1
tradução literal de “Citrix farm”.
2
ICA – Independent Computing Architecture, protocolo proprietário da Citrix Systems que se baseia
numa especificação para comunicação de dados entre servidor de aplicações e cliente.
84 Outras Tarefas
Nas máquinas onde foi aplicada esta prática o processo era composto por três fases:
• Preparação do servidor a ser clonado
• Clonagem
• Reposição do servidor a um estado operativo.
Após o processo era verificado o sucesso da acção realizada.
8.4 Open Office
Dada a proximidade do projecto com o tema da utilização de software aberto e o

interesse da organização neste âmbito, foi-me pedido que me dedicasse também na tarefa
de avaliar a compatibilidade das ferramentas OpenOffice com arquivos MicrosoftOffice e
na medida do possı́vel comparar as soluções através do uso quotidiano do seu conjunto de
aplicações, considerando uma hipótese de migração.
Esta tarefa deveria assumir uma percentagem reduzida do tempo útil empreendido.
Os produtos avaliados foram o OpenOffice versão 2.0.2 e o MicrosoftOffice 2003. Foi
também feita uma “visita” à versão Beta do novo MicrosoftOffice 2007 cuja saı́da está
prevista para Outono deste ano.
No decorrer desta avaliação, foram analisados diversos ficheiros e sempre que possı́vel
eram utilizadas as duas soluções sobre o mesmo ficheiro, de modo a verificar possı́veis
incompatibilidades na importação do documento. Os documentos averiguados foram ex-
clusivamente do formato MicrosoftOffice dado que a alternativa da Microsoft não oferece
neste momento qualquer compatibilidade com o formato standard Open Document For-
mat 3 (ODF), utilizado pelo OpenOffice.
As aplicações Office utilizadas durante este perı́odo com os diversos ficheiros cons-
tam na tabela 8.1, agrupadas por tipo de aplicação. De cada alternativa Office fazem
parte outras aplicações, mas este grupo reúne apenas o núcleo de aplicações de uso mais
generalizado, cujas funções são comparáveis e onde a compatibilidade pode ser avaliada.
Tipo de programa OpenOffice MicrosoftOffice

Processador de texto Write odt Word doc
Folha de cálculo Calc ods Excel xls
Apresentação Impress odp PowerPoint ppt
Base de dados Base odb Access mdb
Tabela 8.1: Programas utilizados em cada uma das soluções Office, segundo o seu tipo. É
também referida a extensão dos ficheiros no formato tı́pico utilizado por cada um.
3
formato standard com especificação pública e aberta, desenvolvido pela OASIS (um consórcio de orga-
nizações internacional com fins não lucrativos), que pretende ser uma alternativa aos formatos proprietários
para documentos “Office”.
8.4 Open Office 85
8.4.1 Resultados
Write
Esta solução pareceu bastante consistente a nı́vel da importação de documentos doc.

Raramente a importação era mal sucedida, porém tal sucedia esporadicamente, sobretudo
se eram utilizadas tabelas ou templates mais complexos.
Permite a geração de um ficheiro em formato PDF 4 directamente a partir do docu-
mento editado, enquanto que o Word depende da utilização de programas externos para
permitir esta facilidade.
Tem também uma funcionalidade que torna a comparação de ficheiros uma tarefa
extremamente fácil, ideal sobretudo para fazer uma análise comparativa sobre diferentes
versões do mesmo documento, possibilitando ver a sobreposição das versões e adoptar ou
descartar cada uma das diferenças.
Quanto à velocidade no arranque da aplicação, apesar da avaliação que foi feita não
se debruçar sobre este ponto, notou-se uma grande diferença. No Write este processo era
significativamante mais lento que no Word. Para atenuar este “handicap” foram alteradas
as opções de utilização de memória do OpenOffice (Tools⇒Options⇒Memory). Os valores
apresentados por omissão na secção Graphics Cache de memória a utilizar pelo OpenOffice
e de memória por objecto foram alterados para 64MB e 4MB respectivamente. Desta
alteração resultou uma melhoria considerável.
Calc
Esta solução tem as funcionalidades da tı́pica folha de cálculo. O tamanho da folha

no Calc e no Excel é igual.
Foi observado o comportamento do OpenOffice no acesso a uma base de dados externa
de produção através desta aplicação. O resultado pode considerar-se positivo, se bem que
se mostrou menos capaz que o seu opositor em pesquisas mais densas à base de dados (em
tabelas com várias dezenas de colunas).
Tem uma funcionalidade incorporada que permite uma visibilidade global sobre as
tabelas constantes nas bases de dados com uma fácil interacção com a folha de cálculo
(ver figura 8.2), algo que não é possibilitado com a utilização da alternativa, o Excel.
Na realização de consultas à base de dados externa, a ferramenta MicrosoftQuery
apresenta um maior poder face às capacidades demonstradas nesta aplicação, porém as
diferenças não são significativas.
A importação de ficheiros requer muitas vezes algum manuseamento posterior de modo
a adaptar-se às diferenças que os dois programas apresentam.
Por exemplo na importação de ficheiros que utilizam tabelas dinâmicas (ou pivot ta-
bles) por vezes perde-se a estrutura dos dados, o que requere o trabalho adicional ao
utilizador de recompôr correctamente a origem dos dados a resumir.
O OpenOffice permite a possibilidade de colocar um filtro sobre a importação de da-
dos da origem para a tabela dinâmica, o que a torna mais ágil. Porém apresenta também
algum défice no que se refere aos filtros quanto a algumas opções (nomeadamente, as pos-
sibilidades apresentadas quando é feita a escolha do filtro não são dinâmicas, aparecendo
opções seleccionáveis que não são aplicáveis ao contexto presente).
4
Portable Document Format – formato standard de documentos, da Adobe Systems.
86 Outras Tarefas
Figura 8.2: OpenOffice – Calc – Acesso à base de dados DB2 de produção no AS/400. Na
parte superior é mostrado o conteúdo da base de dados, através das tabelas disponı́veis (no
lado esquerdo) e o conteúdo da tabela seleccionada (à direita). Em baixo está a folha de
cálculo, onde podem ser estabelecidas ligações com a base de dados.
Impress
A importação deste tipo de ficheiros foi geralmente feita de modo simples porém, de
igual modo, algumas alterações no formato exibido ou a exclusão de algum tipo de objectos
sucede nalgumas ocasiões.
De salientar a enorme quantidade de formatos para que podem ser exportados os
documentos utilizados por esta aplicação, que para além de PDF, permite a exportação
para o formato Flash, além de muitos outros.
A gravação em formato ppt desde esta aplicação, apesar de possı́vel, geralmente não
é feita correctamente já que nos testes feitos guardando o documento com este tipo, a
abertura do documento pelo PowerPoint não era bem sucedida, sendo o erro justificado
pelo não reconhecimento do formato.
Base
Esta aplicação, incuı́da muito recentemente no pacote do OpenOfice (desde a versão

2.0), revelou encontrar-se ainda num estado algo imaturo, indicando algumas dificuldades
no que respeita a uma importação pacı́fica de bases de dados em formato mdb, do Access.
Ainda os ficheiros deste tipo não possam ser abertos directamente pelo Base, a sua
importação pode ser feita através do mecanismo de acesso a uma base de dados externa.
8.4 Open Office 87
Nos casos testados ao efectuar esta ligação, a importação no seu essencial resultou no que
se refere às tabelas e dados nelas contidos, assim como a maioria de consultas criadas, por
vezes de modo incompleto, exigindo ao utilizador um esforço complementar e um nı́vel de
experiência avançado com a ferramenta para estabelecer manualmente algumas ligações
quebradas do esquema inicial.
Quanto aos formulários, os que provêm do Access não são suportados pelo Base.
Também em formato nativo se apresentaram menos completos já que, por exemplo, apenas
podem organizar-se num único nı́vel, não podendo criar-se sub-formulários de uma forma
hierarquizada.
Microsoft Office 2007 - versão Beta 2
Pela visita que foi feita à versão beta do MicrosoftOffice 2007 (figura 8.3), também
a sua adopção exigirá uma forte adaptação por parte do utilizador de versões anteriores,
dadas as sua diferenças com a actual versão, quer pela localização espacial das ferramentas
quer pela adopção de um novo modelo de funcionamento, muito mais gráfico.
Figura 8.3: MicrosoftOffice 2007 versão beta – Excel.
8.4.2 Conclusões
A solução livre avaliada demostrou poder ser uma alternativa viável ao MicrosoftOffice
pela boa resposta nas funcionalidades que disponibiliza a um nı́vel de utilização simples
ou médio. Os principais pontos negativos encontrados concentram-se a um nı́vel de uti-
lização avançada e sobretudo com a frequente incapacidade na importação amena dos
88 Outras Tarefas
documentos das aplicações Microsoft, sobretudo quando são utilizados estruturas (como
tabelas, macros ou gráficos) mais complexas, reflexo de uma dificuldade em lidar com a
impermeabilidade do formato fechado que estas utilizam.
Sem dúvida que o preço é uma importante motivação para considerar a adopção de
uma solução open-source. Se reflectirmos sobre os principais entraves para uma migração
destre género, seguramente que um excessivo esforço a nı́vel da familiarização com uma
nova interface, causando uma quebra nos hábitos de funcionamento do “utilizador tipo”
ao efectuar as operações quotidianas e, por outro lado, uma resposta ineficaz ao nı́vel da
funcionalidade por parte do novo produto, se traduzirá num custo demasiado elevado nessa
adopção que não justificará a mudança. Neste caso não parecem ser estes os factores que
bloqueiam a transição, pois o frontend das aplicações no OpenOffice e nas aplicações Mi-
crosoftOffice é muito semelhante. No seu essencial, também as funcionalidades fornecidas
apresentam uma grande proximidade, apesar de uma maior consistência demonstrada na
solução da Microsoft, em que foram testemunhados menos bloqueios súbitos nas aplicações.
Considerando o cenário de uma implantação OpenOffice, um dos critérios essenciais
reside na boa capacidade de intercâmbio de documentos com o exterior, com parceiros
que potencialmente utilizam de forma massificada os formatos fechados MicrosoftOffice.
Até agora este critério não se encontra satisfeito dado ter sido precisamente no ponto da
importação e exportação destes formatos onde foram identificadas maiores dificuldades.
No entanto a Microsoft, que se encontrava até há pouco tempo estanque a qualquer
iniciativa no sentido de uma abertura ao formato standard, alterou de alguma maneira a
sua posição perante os pedidos de interoperabilidade por parte de algumas organizações
governamentais. Algumas delas com medidas efectivamente tomadas na transição para o
OpenOffice como software de produtividade adoptado (em França, Dinamarca, Espanha
ou ultimamente pelo governo do estado de Massachusetts). Em resposta a estes factos, a
Microsoft anunciou recentemente estar a colaborar num novo projecto de open source, alo-
jado na SourceForge (http://sourceforge.net/projects/odf-converter), que se encontra
a trabalhar no desenvolvimento de um tradutor que visa possibilitar a leitura e escrita
em formato ODF dos documentos editados no MicrosoftOffice 2007, através de um add-in
instalável gratuitamente.
Talvez esta medida proporcione a ponte entre as duas plataformas de modo a que a
escolha de uma solução de produtividade deste tipo por parte dos utilizadores se possa
basear em factores de qualidade e não num jogo de dependências.
Capı́tulo 9
Conclusões finais
A plataforma de virtualização, bastante utilizada durante o desenvolvimento deste

projecto, que de solução provisória passou a solução definitiva como infra-estrutura que
suporta a implementação, foi causa de alguns dos desvios no processo de desenvolvimento
do projecto. Numa primeira fase, de selecção do sistema operativo a utilizar para a pos-
terior criação do cluster de base de dados, mostrou-se inadequada. O ambiente requerido
para efectuar uma comparação de desempenhos é muito exigente, caso se pretenda que os
resultados sejam credı́veis. Nesse ponto a solução da VMware não apresentou as carac-
terı́sticas ideais para o seu cumprimento.
Com a adopção de uma alternativa em ambiente nativo a resposta foi bastante diferente
que no ambiente virtual. Os resultados foram bem mais equilibrados entre as soluções
Windows e Linux.
Entre sistemas Linux, a distribuição que apresentou sempre melhores resultados foi o
SUSE Linux Enterprise Server 9 .
Ao analisar os resultados das comparações de desempenhos obtidos entre a aplicação
desenvolvida Bench e a aplicação adoptada para efectuar o benchmark TPC-C, o Hamme-
rora, pode reparar-se que nos da segunda aplicação os resultados são muitos mais favoráveis
à solução Linux que da primeira. Possivelmente isto dever-se-á ao facto de nesta aplicação
ser efectuada uma carga significativamente mais pesada a nı́vel de acesso a disco relativa-
mente à aplicação Hammerora. Caso haja um desiquilı́brio entre o subsistema de sistemas
de ficheiros que penalize a solução Linux com operações de leitura/escrita mais lentas que
no Windos, em ambiente RAC esse factor em grande parte deverá anular-se. Isto porque
num funcionamento com bases de dados, o acesso aos ficheiros de dados representa uma
grande fatia no que toca ao acesso a disco e na plataforma proposta, os mecanismos encar-
regues desta tarefa estão a cargo do software do SGBD. Ao tratar-se de uma plataforma
RAC, o sistema de ficheiros local não trataria deste tipo de operações.
Quanto ao desenvolvimento do protótipo, a implementação pretendida foi realizada
com sucesso. Pôde verificar-se que o funcionamento sobre uma base de dados com extensão
Real Application Clusters é realizado de um modo transparente, comprovando-se a boa
interoperabilidade desta solução com as aplicações desenvolvidas para bases de dados
alojadas numa única instância.
No entanto, ao nı́vel das aplicações cliente, existe ainda um espaço para a adaptação,
se pretenderem tirar todo o rendimento dos mecanismos de tolerância a falha promovidos
nesta geração da Oracle.
90 Conclusões finais
A introdução de discos no cluster revelou-se fácil, com a sua introdução no DiskGroup,

mas lenta, dado o ambiente de natureza virtual e a utilização de um mesmo disco do
sistema host que alberga o ambiente virtual em que foi desenvolvido.
Apêndice A
Linux: “caderno de notas”
A.1 Comandos úteis
Para quaisquer dúvidas ou informação detalhada sobre os comandos, utilizar as páginas

de manual acessı́veis pelo comando man ou outra documentação adequada. Este capı́tulo
não pretende ser mais que um resumido caderno de notas!
Ajuda
# man Comando
Mostra a página de manual sobre um determinado Comando
# whatis Comando
Mostra quais as várias páginas de manual disponı́veis para Comando
# whereis Comando
Especifica qual a localização de um determinado Comando
# apropos Palavra
Indica que páginas do manual (man) fazem referência a uma dada Palavra
Informação de sistema
# uname -r
Diz qual é a versão do kernel usada
# cat /proc/version
Mostra versão do kernel presente
# rpm -qf /boot/vmlinuz

Diz qual é o pacote do kernel instalado
# grep "model name" /proc/cpuinfo

92 Linux: “caderno de notas”
Mostra qual o modelo de CPU utilizado pela máquina
# cat /etc/issue
Mostra qual a distribuição Linux instalada
# lsmod
# cat /proc/modules
Informa sobre os módulos carregados no kernel
#modprobe -l
Lista os módulos presentes
Pesquisas
# find / -name ’Fitxer.txt’

Procura pelo ficheiro ’Fitxer.txt’, a partir da raı́z
# egrep -Rin --color vmxnet ./* 2>/dev/null | grep ’May 20’

Filtro que procura pelo texto padrão pretendido nos ficheiros especificados
Permissões
# chmod 777 Fitxer.txt

Altera o modo de permissões do ficheiro Fitxer.txt
# chmod g+w Fitxer.txt

Forma alternativa para alteração de permissões
# chown root[:Grupo] Fitxer.txt

Altera o detentor do ficheiro, estabelecendo opcionalmente o Grupo a que pertence
# chgrp Grupo Fitxer.txt

Muda o grupo do ficheiro para Grupo
# umask 022
Estabelece 755 como nı́vel de permissões por omissão.
Definido realizando operação Xor entre o valor que é inserido, ’022’, e a máscara ’777’
# passwd Utilizador
Procede à alteração da password do Utilizador referido
A.1 Comandos úteis 93
Rede
# ping Endereço_Destino
Verifica a ligação com o destinatário através do envio de pacotes ICMP
# ifconfig
Mostra informação acerca das interfaces de rede, assim como permite configurá-las
# netstat
Dá a lista de ligações estabelecidas
# route
Informação diversa sobre encaminhamento
# cat /proc/net/dev
# mii-tool
Dão informação relativa aos dispositivos de rede no sistema
Recursos
# cat /proc/cpuinfo
Apresenta informação sobre o processador
# top
Mostra um quadro com informação sobre o processamento actual
# free
Informa sobre a utilização de memória actual
# cat /proc/meminfo
Apresenta informação relacionada com memória
# grep MemTotal /proc/meminfo

Mostra apenas informação relativa à memória fı́sica
# grep SwapTotal /proc/meminfo

Mostra apenas informação relativa à memória Swap
# iostat
Ferramenta de monitorização sobre dispositivos de armazenamento
# df -h
Indica qual a utilização feita das partições de disco
# lspci -vv
Lista as placas PCI presentes na máquina
Base de dados Oracle RAC
# export ORACLE_SID=orcl1
# srvctl start nodeapps -n rac1
# srvctl start asm -n rac1
# srvctl start instance -d orcl -i orcl1
# emctl start dbconsole
Iniciar ambiente RAC
# export ORACLE_SID=orcl1
# emctl stop dbconsole
# srvctl stop instance -d orcl -i orcl1
# srvctl stop asm -n rac1
# srvctl stop nodeapps -n rac1
Encerrar ambiente RAC
# emctl status dbconsole

Verifica estado da interface de gestão Enterprise Manager
# lsnctl start|stop|status
Inicia, termina ou verifica o estado do Listener
# srvctl status nodeapps -n rac1

Mostra o estado das aplicações num nó em particular
# srvctl status asm -n rac1

Apresenta o estado de uma instância ASM
Verificações sobre a base de dados RAC
# srvctl status database -d orcl

Apresenta o estado de todas as instâncias e serviços
# srvctl status database -d orcl -i rac1

Dá o estado de uma instância especı́fica
# srvctl status service -d orcl -s ortrety

Dá o estado de um serviço especificado no âmbito da base de dados
# srvctl status nodeapps -n rac1

Mostra o estado das aplicações num nó em particular
# srvctl status asm -n rac1

Apresenta o estado de uma instância ASM
# srvctl config database

Mostra todas as bases de dados configuradas
# srvctl config database -d orcl

A.1 Comandos úteis 95
Apresenta a configuração da base de dados RAC
# srvctl config service -d orcl

Mostra todos os serviços para a base de dados especificada
# srvctl config nodeapps -n rac1 -a -g -s -l

Mostra a configuração para as aplicações num nó (VIP, GSD, OSN, Listener)
# srvctl config asm -n rac1

Mostra a configuração relativa à instancia ASM
Vários
# file *
Informa de que tipo são os ficheiros
# crontab -e (editar)
# crontab -r (retirar)
Permite calendarizar o lançamento de programas com uma frequência configurável.
Configuração guardada em /var/spool/cron/tabs/Utilizador
# shutdown -h now
Ordena o encerramento imediato do sistema
# pwd
Indica qual a directoria actual
# vi /etc/sysctl.conf
# vi /etc/rc.local
Definir serviços lançados no arranque do sistema
# cat /var/log/messages
# cat /var/log/dmesg
Mostra mensagens lançadas pelo kernel
# strace -p Pid
Monitoriza as chamadas de sistema feitas por um determinado processo
# cat /proc/interrupts
Contador de interrupções do sistema operativo (entrada 0 refere-se ao relógio)
# ulimit -a
Limites de ambiente impostos ao utilizador actual
# telinit 3
Provoca a mudança para o runlevel 3
# ssh -X user@hostname
Cria um túnel seguro com possibilidade de forwarding para aplicações gráficas
# ln -s Fitxer.txt Ligacao.lnk
Cria uma ligação simbólica Ligacao.lnk para Fitxer.txt
# xhost +[<Endereço_Remoto>]
# xhost -[<Endereço_Remoto>]
Habilita/desabilita o controlo de acesso para servidor X.
Pode-se habilitar/desabilitar apenas um endereço especı́fico
# Comando --display=122.133.132.123:0.0
# export DISPLAY=123.123.123.123:0.0; Comando;
Executa um dado Comando e apresenta-o remotamente (no servidor X indicado)
# tar -czvf Guardar.tgz Directoria

Salvaguarda a Directoria no ficheiro comprimido Guardar.tgz
# ps -ef
Mostra todos os processos que se encontram a correr na máquina
# w
# who
Apresenta os utilizadores que têm sessões abertas e que programas estão a correr
# chkconfig ntpd on
Verifica para que runlevels o serviço ”ntpd”está activo
# pgrep ntpd
Indica os identificadores dos processos que correm o ntpd
# service ntpd start|stop|restart

Inicia, trermina ou reinicia o serviço enunciado (ntpd, neste exemplo)
# chkconfig -l
Lista que scripts estão activados para iniciar nos diferentes runlevels
# mkswap -f /dev/hda5
Prepara a partição para ser usada como Swap
# swapon /dev/hda5
Activa a partição referida como espaço Swap
# sysctl -p
Define todas as variáveis de sysctl.conf em proc/
# mount /dev/sda1 /mnt/Directoria

Monta o dispositivo indicado na Directoria
# mount -a
Monta todos os dispositivos constantes no ficheiro /etc/fstab
# chroot Directoria
Altera a directoria tida como raı́z. Útil no restauro do Lilo
Índice
agregação placas de rede, 48 Base, 86

armazenamento, 29 Calc, 85
comparação, 36 conclusões, 87
ASM, 33 Impress, 86
AWR, 18 Write, 85
Orarun, 49
Blade, 82 Orion, 18
Cache Fusion, 39 RAC, 37
Citrix, 83 arquitectura, 37
clonagem componentes, 45
servidores, 83 limitações, 55
cluster, 28 opções, 46
Clusterware, 28 requisitos, 39
instalação, 28 endereços IP, 42
CRS, 28 hardware, 39
CVU, 51 rede, 42
comandos, 52 software, 40
tempo, 45
Disk Group
testes, 51
criar, 79, 80
Raw, 30
Failure Group rede
definir, 79 pública, 45
privada, 45
Grub, 6 virtual, 45
requisitos tecnológicos, 27
Hammerora, 17 runlevel, 70
Hangcheck Timer, 46
Heartbeat, 32 scripts, 49
Sistema de ficheiros, 10
journaling, 11
TAF, 47
Lilo, 6 configuração, 81
Listener, 46 TPC-C, 17
NFS, 32 VIP, 45
VMware, 4
O2CB, 31
tools, 7
OCFS2, 30
opções, 32
OCR, 28
OFA, 46
OpenOffice, 84
Bibliografia
[1] L. Lamport, LATEX: A Document Preparation System. Addison-Wesley, 1986.
[2] M. Jakubowska-Sobczak, RAC 10g on Linux. CERN.

http://openlab-mu-internal.web.cern.ch/openlab-mu-internal/Documents/3_
Presentations/Slides/2005/05-10_MJS_summerStudentLecture3.pdf.
[3] A. Singh, Oracle 10g R2 (10.2.0.1) on Suse Linux Enterprise Server 9 (How to
Install). Novell, Julho, 2005.
http://ftp.novell.com/partners/oracle/docs/10gR2_sles9_install.pdf.
[4] S. Daniel, NAS vs. SAN for Database Applications Using NAS Protocols with
Databases. Network Appliance, Fevereiro, 2003.
http://www.netapp.com/library/tr/3227.pdf.
[5] A. Firebaugh, A. Robinson and T. Patel, Oracle10g real application clusters release
1: Installation with a filer in a suse linux enterprise server 8/9 (sles 8, sles 9)
environment, tech. rep., Network Appliance, Julho, 2005.
http://www.netapp.com/library/tr/3413.pdf.
[6] K. McGowan and R. Knapp, Oracle Real Application Clusters Best Practices On
Linux. Oracle Corporation.
http://web51-01.oracle.com/owparis_2003/50136_McGowan.doc.
[7] J. Dyke, “A rough guide to rac.” Versão Web, 2005. http:

//julian.dyke.users.btopenworld.com/com/Presentations/ARoughGuideToRAC.ppt,
OPTannote = .
[8] VMware, Systems Compatibility Guide for ESX Server 2.x, Maio, 2006.
http://www.vmware.com/pdf/esx_system_guide.pdf.
[9] VMware, Using ESX Server and VirtualCenter to Reduce Oracle Real Application
Clusters Deployment Costs And Cycle Times, 2004.
http://www.vmware.com/pdf/esx_vc_oracle.pdf.
[10] B. Mackin, ISCSI Delivers Storage Over Ethernet.

http://www.adaptec.com/pdfs/iscsi_storageoverethernet.pdf.
[11] B. Martelli and G. Peco, LCG 3D and Oracle Cluster, Março, 2006.
http://agenda.pi.infn.it/askArchive.php?base=agenda&categ=a06133&id=
a06133s4t26/transparencies.
[12] R. Kulkarni and P. Schay, Linux Filesystem Performance Comparison for OLTP
with Ext2, Ext3, Raw, and OCFS on Direct-Attached Disks using Oracle 9i Release
BIBLIOGRAFIA 99
2. Oracle Corporation, Janeiro, 2004. http://www.oracle.com/technology/tech/

linux/pdf/Linux-FS-Performance-Comparison.pdf.
[13] A. Hangai, Project MegaGrid: Infrastructure Design. Oracle Corporation, Setembro,

2005. http://www.oracle.com/technologies/grid/docs/twp_megagrid_
infrastructure_design.pdf.
[14] Oracle Corporation, Oracle Cluster File System (OCFS2) Users Guide. http:
//oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_users_guide.pdf.
[15] Oracle Corporation, OCFS2 - Frequently Asked Questions.

http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_faq.html.
[16] M. Fasheh, Oracle’s Cluster File System on Linux. Oracle Corporation.

http://www.lugod.org/presentations/ocfs/ocfs_talk_distrib.pdf.
[17] M. E. Matsunaga, Oracle Cluster FileSystem for Linux (Users Guide). Oracle
Corporation, Agosto, 2003.
http://oss.oracle.com/projects/ocfs/dist/documentation/OCFS_Users_Guide.doc.
[18] S. Poon and G. Verstraeten, Oracle 10g R2 RAC Implementation on xSeries. IBM
Corporation, Janeiro, 2006. http://www-03.ibm.com/solutions/businesssolutions/
oracle/doc/content/bin/Oracle_10g_R2_RAC_xSeries-Jan2006.pdf.
[19] V. Ravipati and A. Zavery, Oracle Application Server 10g : The Best Application
Server for the Oracle Database. Oracle Corporation, Dezembro, 2004.
http://www.oracle.com/technology/products/ias/pdf/oracleas10g_best_appserver_
for_oracledatabase_wp.pdf.
[20] R. Rossebo, Best Practices for 10g RAC. Oracle Corporation, Dezembro, 2005.
http://www.oracleracsig.org/pls/htmldb/Z?p_url=RAC_SIG.download_my_file?p_
file=1000480&p_cat=1000480&p_company=550311706566234.
[21] Z. Afrookhteh, Technical Comparison of Oracle Real Application Clusters 10g vs.
IBM DB2 UDB v8.2. Oracle Corporation, Agosto, 2005.
http://www.oracle.com/technology/products/database/clustering/pdf/twp_rac_
10g_vs_db2_v8.2%5B1%5D.pdf.
[22] Oracle Corporation, Your Desktop Data Center: Oracle Database 10g on SuSE
Linux on VMware Evaluation, Fevereiro, 2005. http:
//www.oracle.com/technology/tech/linux/vmware/readme_desktop_suse_v14.pdf.
[23] M. Newman, C.-M. Wiberg and B. Braswell, Server Consolidation with VMware
ESX Server. IBM Corporation, Janeiro, 2005.
http://www.redbooks.ibm.com/redpapers/pdfs/redp3939.pdf.
[24] J. Loaiza, Optimal Storage Configuration Made Easy. Oracle Corporation.

http://www.oracle.com/technology/deploy/availability/pdf/oow2000_same.pdf.
[25] D. Austin, M. Bauer, A. Gusev, K. Broeg and R. Jayaraman, Providing High

Availability for SAP Resources. Oracle Corporation, Abril, 2006. http:
//www.oracle.com/technology/tech/linux/pdf/sap-availability-on-rac-twp.pdf.
[26] S. Surender, 11i and RAC on Linux - 101. Verities Solutions.

http://www.ncoaug.org/presentations/2004-Mar/sara.ppt.
100 BIBLIOGRAFIA
[27] J. Tate, R. Kanth and A. Telles, Introduction to Storage Area Networks. IBM
Corporation, Abril, 2005.
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245470.pdf.
[28] K. Arrell, L. Dupin, D. Dutcavich, T. Elliott, B. Frank, C. Little, B. Robinson and

T. Russell, Experiences with Oracle 10g Database for Linux on zSeries. IBM
Corporation, Agosto, 2005.
http://www.redbooks.ibm.com/redbooks/pdfs/sg246482.pdf.
[29] N. Harris, F. Armingaud, M. Belardi, C. Hunt, M. Lima, W. M. Jr., J. R. Ruibal

and J. Taylor, Linux Handbook A Guide to IBM Linux Solutions and Resources.
IBM Corporation, Abril, 2004.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247000.pdf.
[30] K. Weidner, SLES Security Guide. Novell, Dezembro, 2003.

http://www.novell.com/linux/security/eal3/SLES8_EAL3_SecurityGuide.pdf.
[31] S. T. Council, Shared Storage Model A framework for describing storage

architectures. Storage Networking Industry Association, Abril, 2003. http://www.
snia.org/tech_activities/shared_storage_model/SNIA-SSM-text-2003-04-13.pdf.
[32] D. Patel, Storage File Mapping in Databases. Veritas Architect Network, Abril,
2003. http://sysdoc.doors.ch/VERITAS/2867.pdf.
[33] Hewlett-Packard Company, Using ServiceGuard Extension for Real Application
Cluster (RAC), Junho, 2003. http://docs.hp.com/en/T1859-90006/T1859-90006.pdf.
[34] S. Behlert, F. Bodammer, S. Dirsch, O. Donjak, R. Drahtmüller, T. Duwe,
T. Dubiel, T. Fehr, S. Fent, W. Fink, K. Garloff, C. Groß, J. Gleißner,
A. Grünbacher, F. Hassels, A. Jaeger, K. Kämpf, H. Mantel, L. Marowsky-Bree,
J. Meixner, L. Müller, M. Nagorni, A. Nashif, S. Olschner, P. Pöml, T. Renninger,
H. Rommel, M. Schäfer, N. Schüler, K. Singvogel, H. Vogelsang, K. G.Wagner,
R. Walter and C. Zoz, Suse Linux Enterprise Server - Installation And
Administration. Suse Linux Ag., 9 ed., 2004. http://www-uxsup.csx.cam.ac.uk/pub/
doc/suse/sles9/SUSE-LINUX-Enterprise-Server-9-Adminguide.pdf.
[35] D. G. Pfeifer, Optimizing Kernel 2.6 and SLES9 for the best possible performance.
Novell. http://www.novell.com/brainshare/europe/05_presentations/tut303.pdf.
[36] G. Smith, Oracle RAC 10g Overview - An Oracle White Paper. Oracle Corporation,
Novembro, 2003.
http://www.oracle.com/technology/tech/windows/wp/Oracle_DB_10g_RAC_WP.pdf.
[37] Z. Mahmood, U. D. Shet and B. Sajnani, Migrating an Oracle10g RAC Database

from Oracle Cluster File System to Oracle Automatic Storage Management on
Dell/EMC Storage Arrays. Dell Power Solutions, Agosto, 2005.
http://www.dell.com/downloads/global/power/ps3q05-20050193-Mahmood-SOE.pdf.
[38] Red Hat, Inc., Red Hat Enterprise Linux 4: Introduction to System Administration,
2005. http:
//www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/pdf/rhel-isa-en.pdf.
[39] D. Colello, Oracle Database 10g Release 2 Architecture on Windows. Oracle

Corporation, Novembro, 2005. http://www.oracle.com/technology/tech/windows/
rdbms/Oracle_10gR2_Windows_DB_Architecture_TWP.pdf.
BIBLIOGRAFIA 101
[40] VMware, Inc., Accelerate Software Development Testing and Deployment with the
VMware Virtualization Platform, 2005. http://www.vmware.com/pdf/dev_test.pdf.
[41] VMware, ESX Server 2 - Best Practices, 2003.
http://www.vmware.com/pdf/esx2_best_practices.pdf.
[42] VMware, Inc., VMware ESX Server 2 - ESX Server Performance and Resource
Management for CPU-Intensive Workloads, 2005.
http://www.vmware.com/pdf/ESX2_CPU_Performance.pdf.
[43] VMware, Inc., ESX Server 2 - NIC TEAMING IEEE 802.3ad, 2003.
http://www.vmware.com/pdf/esx2_NIC_Teaming.pdf.
[44] VMware, Inc., VMware ESX Server 2 - NUMA Support, 2005.

http://www.vmware.com/pdf/esx2_NUMA.pdf.
[45] VMware, Inc., VMware - Timekeeping in VMware Virtual Machines, 2005.

http://www.vmware.com/pdf/vmware_timekeeping.pdf.
[46] A. Lissot, Linux Partition HOWTO, Dezembro, 2005.

http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/pdf/Partition.pdf.
[47] S. Calish, Guide to linux filesystem mastery, tech. rep., Oracle, Novembro, 2004.
http://www.oracle.com/technology/pub/articles/calish_filesys.html.
[48] D. Austin, M. Bauer, K. Flood, E. Murphy, L. Vadassery and D. Williams, Oracle

Clusterware and Oracle Real Application Clusters Installation Guide. Oracle, 6,
7 ed., Maio, 2006.
http://download-east.oracle.com/docs/cd/B19306_01/install.102/b14203.pd%f.
[49] M. Ault, D. Liu and M. Tumma, Oracle Database 10g New Features. Novembro,
2003. http://www.remote.dba.cc/10g_409.html.
[50] L. Morris-Murphy, Storage on Automatic. http://www.oracle.com/technology/
oramag/webcolumns/2003/techarticles/murphy_asm.html.
[51] L. Morris-Murphy, Storage on automatic, tech. rep., Oracle, 2003. http://www.

oracle.com/technology/oramag/webcolumns/2003/techarticles/murphy_asm.html.
[52] M. Ault and M. Tumma, Oracle 10g Grid & Real Application Clusters. Rampant
Techpress, Maio, 2004.
[53] B. Lundhild, Oracle Real Application Clusters 10g – An Oracle White Paper. Oracle
Corporation, Maio, 2005. http://www.oracle.com/technology/products/database/
clustering/pdf/twp_rac10gr2.pdf.
[54] A. Das, S. Sharma and L. Vadassery, Oracle Database Installation Guide 10g
Release 2 (10.2) for Linux x86. Oracle, 2005.
http://download-east.oracle.com/docs/cd/B19306_01/install.102/b15660.pdf.
[55] C. McGregor, Oracle Database 2 Day DBA 10g Release 2 (10.2). Oracle, Dezembro,
2005.
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14196.pdf.
[56] VMware, Inc, ESX Server 2.5 Administration Guide, Março, 2005.
http://www.vmware.com/pdf/esx25_admin.pdf.
102 BIBLIOGRAFIA
[57] VMware, Inc, ESX Server 2.5 Installation Guide, Março, 2005.
http://www.vmware.com/pdf/esx25_install.pdf.
[58] VMware, Inc, ESX Server 2.5 Release Notes, Abril, 2006.
http://www.vmware.com/support/esx25/doc/releasenotes_esx253.html.
[59] VMware, Inc, Storage Subsystem Performance in VMware ESX Server: BusLogic
Versus LSI Logic, Abril, 2006.
http://www.vmware.com/pdf/ESX2_Storage_Performance.pdf.
[60] J. Hunter, Build your own oracle rac 10g cluster on linux and firewire, tech. rep.,
Oracle, Março, 2005.
http://www.oracle.com/technology/pub/articles/hunter_rac.html.
[61] D. Austin, M. Bauer and D. Williams, Oracle Clusterware and Oracle Real
Application Clusters Administration and Deployment Guide. Oracle, Janeiro, 2006.
http://download-east.oracle.com/docs/cd/B19306_01/rac.102/b14197.pdf.
[62] VMware, Inc., ESX Server 2 - Security White Paper, 2004.

http://www.vmware.com/pdf/esx2_security.pdf.
[63] VMware, Inc., ESX Server 2 - Systems Management, 2004.

http://www.vmware.com/pdf/ESX2SysMgt.pdf.
[64] Blade Infrastructure Solution Center, VMware ESX 2.1 NIC Bonding and VLANs
On BladeCenter HS20, Março, 2004.
http://www.vmware.com/pdf/esx21_IBM_NIC_VLAN.pdf.
[65] VMware, Inc., VMware ESX Server Using Raw Device Mapping, 2005.
http://www.vmware.com/pdf/esx/esx25_rawdevicemapping.pdf.
[66] VMware, Inc., Systems Compatibility Guide for ESX Server 2.x, Mayo, 2006.
http://www.repton.co.uk/library/Storage/esx_systems_guide.pdf.
[67] VMware, Inc., VMware Server 802.1Q-VLAN Solutions, 2004.

http://www.vmware.com/pdf/esx3_vlan_wp.pdf.
[68] S. K. Lee and M. Susairaj, Optimizing Linux I/O. Oracle Corporation.

http://download-uk.oracle.com/oowsf2005/939.pdf.
[69] R. Schrag, Configuring Oracle on Linux For Peak Performance. Database

Specialists, Inc., Agosto, 1999.
http://www.dbspecialists.com/presentations/LinuxWorldTutorialHK.doc.
[70] Red Hat, Inc., Red Hat Enterprise Linux Performance Tuning Guide, 2004.
http://people.redhat.com/mbehm/RHEL_Tuning_Guide.pdf.
[71] J. N. Patel, Oracle9iR2 on Linux: Performance, Reliability and Manageability

Enhancements on Red Hat Linux Advanced Server 2.1. Oracle Corporation, Junho,
2002. http://www.redhat.com/whitepapers/rhel/OracleonLinux.pdf.
[72] VMware, Inc., VMware ESX Server 2 - Architecture and Performance Implications,
2005. http://www.vmware.com/pdf/esx2_performance_implications.pdf.
BIBLIOGRAFIA 103
[73] Oracle Corporation, Quick Installation Guide - 10g Release 1 (10.1.0.3) for Linux
x86, Outubro, 2004.
http://ftp.portera.com/Linux/SLES9-x64-ORA10/10gR1_sles9_install.pdf.
[74] K. Mensah, Whats New for Java DB, JDBC, and Database Web Services in Oracle
Database 10g. Oracle Corporation, Maio, 2005.
http://www.oracle.com/technology/tech/java/sqlj_jdbc/pdf/twp_appdev_jav%a_
whats_new_4_java_jdbc_web_services.pdf.
[75] J. E. Koerv, Deploying Oracle 10g on Red Hat Enterprise Linux v.3. Red Hat, Inc.,
Abril, 2004. http://www.redhat.com/f/pdf/rhel/WHP0007USOracle10g.pdf.
[76] V. K. Murthy, Oracle Enterprise Manager - Installation and Basic Configuration

10g Release 2 (10.2) for Linux x86. Oracle Corporation, Outubro, 2005.
http://huihoo.com/oracle/docs/B14099_19/manage.1012/b16228.pdf.
[77] Novell, Guest OS Issues - SLES, Setembro, 2005.

http://www.novell.com/coolsolutions/feature/15955.html.
[78] K. Weidner, Common Criteria EAL4+ Evaluated Configuration Guide for SUSE
LINUX Enterprise Server on IBM Hardware. Atsec, Janeiro, 2005.
http://www.uniforum.chi.il.us/slides/HardeningLinux/
IBM-SLES-EAL4-Configuration-Guide.pdf.
[79] Novell, What’s New in Suse Linux Enterprise Server 9, Julho, 2004.
http://www.novell.com/products/linuxenterpriseserver/sles9_whatsnew.pdf.
[80] L. Mearelli, Installazione di Oracle 10g su Ubuntu Linux.

http://www.spazidigitali.com/media/Oracle_su_ubuntu.pdf.
[81] P. Huey, Oracle Database Installation Guide 10g Release 1 (10.1.0.2.0) for
Windows. Oracle Corporation, Setembro, 2004.
http://download-uk.oracle.com/docs/pdf/B10130_02.pdf.
[82] Oracle Corporation, Oracle Database Quick Installation Guide 10g Release 1
(10.1.0.2.0)) for Windows, Março, 2004.
http://download-uk.oracle.com/docs/pdf/B13669_01.pdf.
[83] Red Hat, Inc., Red Hat Enterprise Linux 4 Introduction to System Administration,
2005. http:
//www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/pdf/rhel-isa-en.pdf.
[84] P. Rad, R. Rajagopalan, T. Michael and J. Kozak, Best Practices for Oracle
Database 10g - Automatic Storage Management on Dell/EMC Storage. Dell, Inc.,
Outubro, 2004.
http://www.dell.com/downloads/global/power/ps4q04-20040150-Rad.pdf.
[85] Z. Mahmood, A. Fernandez, B. Scalzo and M. Vallath, Testing Oracle 10g RAC
Scalability on Dell PowerEdge Servers and Dell/EMC Storage. Dell, Inc., Fevereiro,
2006. http://www.dell.com/downloads/global/power/ps1q06-20050300-Quest.pdf.
[86] S. T. Council, Shared Storage Model - A framework for describing storage

architectures. Storage Networking Industry Association, Abril, 2003.
http://www.hpl.hp.com/research/papers/Shared_Storage_Model.pdf.
104 BIBLIOGRAFIA
[87] P. Newlan, Using Oracle Clusterware to Protect 3rd Party Applications. Oracle
Corporation, Maio, 2005. http://www.oracle.com/technology/products/database/
clustering/pdf/twp_oracleclusterware3rdparty%5B1%5D.pdf.
[88] Oracle Corporation, Oracle Cluster File System (OCFS2) User’s Guide. http:
//oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_users_guide.pdf.
[89] Red Hat, Inc., Red Hat Enterprise Linux - Performance Tuning Guide, 2004.
http://people.redhat.com/mbehm/RHEL_Tuning_Guide.pdf.
[90] Oracle Corporation, Orion: Oracle I/O Numbers Calibration Tool. http:
//oraclelon1.oracle.com/otn/utilities_drivers/orion/Orion_Users_Guide.pdf.

Relatorio de Projeto

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Relatorio de Projeto

Enviado por

Direitos autorais:

Formatos disponíveis

DEPARTAMENTO DE INFORMÁTICA

Bloco C6 - Piso 3 - Campo Grande, 1749-016 Lisboa

Viabilidade RAC Oracle 10g + Linux / Benchmarking

Trety, SA (Grupo Trèves)

Rui Miguel Silvestre Matos Nogueira

Antoine de Saint-Exupéry, Le Petit Prince.

O presente relatório faz uma descrição do trabalho efectuado no âmbito da disciplina de

Listagem não exaustiva de acrónimos, siglas ou abreviaturas presentes neste relatório

ASM Automated Storage Management

DNS Domain Name Service

CPU Central Processing Unit

CRS Cluster Ready Services

CVU Cluster Verification Utility

DBA Data Base Administrator

DVD Digital Versatile Disc

EVM Event Manager

GRUB GNU Grand Unified Bootloader

GNU GNU is Not Unix

ICA Independent Computing Architecture

JRE Java Runtime Environment

LAN Local Area Network

LILO Linux Loader

NAS Network Attached Storage.

NTP Network Time Protocol

OASIS Organization for the Advancement os Structured Information Standards

OCR Oracle Cluster Registry

OUI Oracle Universal Installer

PDF Portable Document Format

RAC Real Application Clusters

RAID Redundant Array of Independent Disks

RAM Random Access Memory

RHEL Red Hat Enterprise Linux

SAN Storage Area Network

SCSI Small Computer System Interface

iSCSI Internet SCSI

SGA Shared Global Area

SGBD Sistema de Gestão de Base de Dados

SLES SUSE Linux Enterprise Edition

SQI Simple Query Interface

TAF Transparent Application Failover

TNS Transparent Network Substrate

TCP Transmission Control Protocol

UDP User Datagram Protocol

VPN Virtual Private Network

4.3.4 Test drive – Intel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Requisitos tecnológicos para Real Application Clusters 27

6 Real Application Clusters (RAC) 37

A Linux: “caderno de notas” 91

2.1 VMware - camada virtualização . . . . . . . . . . . . . . . . . . . . . . . . . 4

4.1 Bench - composição do sistema . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1 Arquitectura tecnológica para Real Application Clusters . . . . . . . . . . . 27

6.1 Arquitectura fı́sica Real Application Clusters . . . . . . . . . . . . . . . . . 38

7.1 Configuração dos discos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.1 Servidores Blade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

2.1 Host e guests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Sistemas de Ficheiros no sistema operativo Linux - análise comparativa . . 11

4.1 Resultados da execução dos testes de desempenho da aplicação Bench sobre

5.1 Métodos alternativos de acesso ao armaz. partilhado: vantagens e desvan-

6.1 Requisitos para RAC: Swap . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.1 Discos criados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.1 Programas Office utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

No âmbito da disciplina de Projecto do Curso de Especialização em Engenharia In-

1.1 Integração na empresa