New to databases? New to Oracle? Find out
how databases and Oracle fit into the modern
IT infrastructure in Chapter 1
A solid foundation is the best way to start any
project. Chapter 2 helps you understand the
architecture behind the Oracle software,
which goes a long way toward helping you be
a successful
Chapter 3 shows you how an Oracle database
fits in a typical IT application environment.
You also find out about the requirements you
need to meet before installing Oracle
database.
Chapter 1
Discovering Databases and Oracle 12c
In This Chapter
▶ Defining databases
▶ Getting to know Oracle databases
▶ Identifying when using Oracle 12c is
appropriate
▶ Understanding database administration
Welcome to the exciting world of databases,
specifically Oracle 12c. Oracle is a recognized
hardware and software giant on par with
Microsoft in terms of size and influence.
Oracle Corporation made its reputation and
initial wealth with database technology and is
still a recognized leader in databases. Many
information technology (IT) professionals
would agree Oracle databases provide the
most advanced and capable means of storing,
accessing, and managing data in the world
today. As you read this book, you find out why
many professionals hold that belief.
In this chapter, we explain what databases
are, how they work, and why they’re a core
component of any computer system. Next, we
introduce Oracle databases and guide you on
Novo em bases de dados? Novo para a Oracle?
Descubra como bancos de dados e Oracle se
encaixa na moderna infra-estrutura de TI no
Capítulo 1.
Uma base sólida é a melhor maneira de iniciar
qualquer projeto. O Capítulo 2 ajuda você a
entender a arquitetura por trás do software
Oracle, o que é um longo caminho para ajudá-
lo a ser um sucesso
O Capítulo 3 mostra como um banco de dados
Oracle se encaixa em um ambiente típico de
aplicativos de TI. Você também conhece os
requisitos que você precisa conhecer antes de
instalar o banco de dados Oracle.
Capítulo 1
Descobrindo bancos de dados e Oracle 12c
Neste capítulo
▶ Definição de bancos de dados
▶ Conhecendo os bancos de dados Oracle
▶ Identificar quando usar o Oracle 12c é
apropriado
▶ Compreendendo a administração de banco
de dados
Bem-vindo ao mundo emocionante dos bancos
de dados, especificamente Oracle 12c. A Oracle
é um gigante de hardware e software
reconhecido a par com a Microsoft em termos
de tamanho e influência. A Oracle Corporation
fez sua reputação e riqueza inicial com
tecnologia de banco de dados e ainda é um
líder reconhecido em bancos de dados. Muitos
profissionais de tecnologia da informação (TI)
concordariam que os bancos de dados Oracle
fornecem os meios mais avançados e capazes
de armazenar, acessar e gerenciar dados no
mundo de hoje. Ao ler este livro, você descobre
por que muitos profissionais mantêm essa
crença.
Neste capítulo, explicamos o que são os bancos
de dados, como eles funcionam e por que eles
são um componente central de qualquer
sistema computacional.. Em seguida,
when to use Oracle 12c. Finally, we examine
database administration and what a database
administrator’s (DBA) role entails.
Discovering Databases
Since the earliest days of information
technology (that’s data processing for you old-
timers), data has been at the heart of
everything computers do.
Users input data; and programs process,
analyze, and perform calculations on the data.
Then data output occurs. Notice a common
theme? verything
relates to data! As technology increasingly
becomes a part of daily life, you can expect
almost every aspect of your life to have a data
element associated with it.
Data comes from different sources in various
formats. Every year, new types of data are
created as technology evolves. Consider this
partial list of data sources:
✓ Order information from your favorite online
shopping application
✓ Trouble ticket information entered into a
computer by a person in a call center
✓ Financial data including calculations for
interest, taxes, and investments generated by
banks and investment companies
✓ Multidimensional scans captured by
complex medical imaging equipment
✓ Inventory data captured by tracking
products by their RFID tags and point of sale
information
✓ Images, videos, and audio files uploaded to
social media and video sharing websites
The amount of data in the world is growing at
an explosive rate. Consider the number of
online sales transactions every day in addition
to the Twitter tweets and Facebook posts from
smartphones. Additionally, almost every retail
apresentamos bancos de dados Oracle e
orientamos você quando usar o Oracle 12c.
Finalmente, examinamos a administração do
banco de dados e o papel do administrador de
banco de dados (DBA).
Descobrindo bancos de dados
Desde os primeiros dias de tecnologia da
informação (que é o processamento de dados
para você veterano), os dados tem sido o
coração de tudo o que os computadores fazem.
Usuários entram com dados; e os programas
processam, analisam e executam cálculos nos
dados. Em seguida, ocorre a saída de dados.
Observe um tema comum? muita coisa
relaciona-se aos dados! À medida que a
tecnologia se torna cada vez mais parte da vida
diária, você pode esperar que quase todos os
aspectos da sua vida tenham um elemento de
dados associado.
Os dados provêm de diferentes fontes em
vários formatos. Todos os anos, novos tipos de
dados são criados à medida que a tecnologia
evolui. Considere esta lista parcial de fontes de
dados:
✓ Solicite informações do seu aplicativo de
compras on-line favorito
✓ Informações de ingresso de problemas
inseridas em um computador por uma pessoa
em uma Central de Atendimento
✓ Dados financeiros, incluindo cálculos de
juros, impostos e investimentos gerado por
bancos e empresas de investimento
✓ Varreduras multidimensionais capturadas
por equipamentos complexos de imagem
médica
✓ Dados de inventário capturados pelos
produtos de rastreamento pelas suas etiquetas
RFID e informações de ponto de venda
✓ Imagens, vídeos e arquivos de áudio
carregados em sites de mídia social e
compartilhamento de vídeos
A quantidade de dados no mundo está
crescendo a uma taxa explosiva. Considere o
número de transações de vendas on-line todos
os dias, além dos tweets do Twitter e postagens
do Facebook a partir de smartphones. Além
sale is tied to an automated sales tracking and
inventory control system. Almost anything you
do that involves interaction, communication,
or commerce generates data.
The size and number of data elements created
are also increasing as technology evolves.
Pictures, sound files, and videos take far more
space on computer disk storage than simple
text data (letters and numbers). Scientific and
medical devices, such as satellite images and
MRI scans, are common examples of how large
data is generated rapidly and are part of
peoples’ lives.
Defining a database
All this data needs to reside somewhere;
specifically, within a database. Databases are
complex software programs that catalog and
provide access to data. Although the data is
usually stored on a disk storage system, the
database software manages how that data is
stored and managed.
Businesses use databases to store their data
because the size and complexity of their data
often exceed what can be stored on a
spreadsheet. Most business and scientific
activities, and many social activities involving
technology will require the creation, access,
updating, or deleting of data at some level. It
is database software that allows these
activities occur in a fast, efficient manner.
Databases provide these primary functions:
✓ Storage: Data must be kept within a
computer system, usually disk storage, so that
the data is available when needed. Disk
storage technologies can vary, but they must
be fast and large and are often expensive and
complex.
✓ Organization: Data must be stored in a
logical manner on disk so it can be found
quickly and efficiently. Compare an organized
disso, quase todas as vendas a varejo estão
ligadas a um sistema automatizado de
rastreamento de vendas e controle de estoque.
Quase tudo o que você faz, envolve interação,
comunicação ou comércio, gera dados.
O tamanho e o número de elementos de dados
criados também estão aumentando à medida
que a tecnologia evolui. Imagens, arquivos de
som e vídeos levam muito mais espaço no
armazenamento de disco do computador do
que dados de texto simples (letras e números).
Dispositivos científicos e médicos, como
imagens de satélite e exames de ressonância
magnética, são exemplos comuns de como
grandes dados são gerados rapidamente e
fazem parte da vida das pessoas.
Definindo um banco de dados
Todos esses dados precisam residir em algum
lugar; especificamente, dentro de um banco de
dados. Os bancos de dados são programas de
software complexos que catalogam e fornecem
acesso a dados. Embora os dados sejam
geralmente armazenados em um sistema de
armazenamento em disco, o software de banco
de dados gerencia como esses dados são
armazenados e gerenciados.
As empresas usam bancos de dados para
armazenar seus dados porque o tamanho e a
complexidade de seus dados geralmente
excedem o que pode ser armazenado em uma
planilha. A maioria das atividades comerciais e
científicas e muitas atividades sociais
envolvendo tecnologia exigirão a criação,
acesso, atualização ou exclusão de dados em
algum nível. É um software de banco de dados
que permite que essas atividades ocorram de
forma rápida e eficiente.
Os bancos de dados fornecem essas funções
principais:
✓ Armazenamento: os dados devem ser
mantidos dentro de um sistema de
computador, geralmente armazenamento em
disco, para que os dados estejam disponíveis
quando necessário. As tecnologias de
armazenamento em disco podem variar, mas
devem ser rápidas e grandes e muitas vezes são
caras e complexas.
✓ Organização: os dados devem ser
desk and file cabinet with a child’s messy
bedroom; where would you prefer to work?
✓ Access: Finding the requested data in a fast
and efficient manner and returning that data
to the requestor is a key function of
databases.
✓ Security: A database determines who can
access the data and what they can do with
that data. Security must be established and
enforced.
✓ Adding, updating, and deleting: After data is
added to the database, it can be modified and
deleted. The database software manages the
complex rules for how data is manipulated.
✓ Safekeeping: Databases keep data safe and
available when failures occur such as a disk
drive crashing. Backup and recovery are the
processes used by databases to ensure data is
not permanently lost if there is a failure.
Here’s the general process:
1. You open the database and enter your data.
2. The database determines how best to store
and catalog that data in a secure manner on
the computer system’s disk storage.
3. When you (or a computer application) want
to access, update, or delete that data, the
database checks your security permissions and
then implements your request in the fastest
manner based on the rules that have been
defined.
Databases can look more like full operating
systems (OSs) than simple applications you start
armazenados de maneira lógica no disco para
que possam ser encontrados de forma rápida e
eficiente. Compare uma mesa organizada e um
arquivo com um quarto desordenado de
criança; Onde você prefere trabalhar?
✓ Acesso: Encontrar os dados solicitados de
forma rápida e eficiente e retornar esses dados
ao solicitante é uma função-chave dos bancos
de dados.
✓ Segurança: um banco de dados determina
quem pode acessar os dados e o que eles
podem fazer com esses dados. A segurança
deve ser estabelecida e aplicada.
✓ Adicionando, atualizando e excluindo:
Depois que os dados são adicionados ao banco
de dados, ele pode ser modificado e excluído. O
software de banco de dados gerencia as regras
complexas sobre como os dados são
manipulados.
✓ Proteção: os bancos de dados mantêm os
dados seguros e disponíveis quando ocorrem
falhas, como uma falha no disco rígido. O
backup e a recuperação são os processos
usados pelos bancos de dados para garantir
que os dados não sejam permanentemente
perdidos se houver uma falha.
Aqui está o processo geral:
1. Você abre o banco de dados e insire seus
dados.
2. O banco de dados determina a melhor forma
de armazenar e catalogar esses dados de forma
segura no armazenamento em disco do sistema
de computador.
3. Quando você (ou um aplicativo de
computador) deseja acessar, atualizar ou
excluir esses dados, o banco de dados verifica
suas permissões de segurança e, em seguida,
implementa seu pedido da maneira mais rápida
com base nas regras que foram definidas.
Os bancos de dados podem parecer mais
sistemas operacionais (OS) completos do
and stop. Advanced databases (such as Oracle)
have users, detailed security privileges, network
configuration settings, performance tuning for
memory, CPU, and disk options, and robust
backup and disaster recovery (DR) options.
Examining how databases work
Databases have evolved over the years but have
stabilized into the relational model. A relational
database management system (RDBMS) stores
data in logical structures called tables. A table is
a logical container of similar data. A table
definition is the set of rules or characteristics for
each row of data stored in table. When data is
loaded into a database, it is loaded as rows
within one or more tables based on the
characteristics of the data.
Each row of unique data exists only once in a
table. For example, there will only be one row of
data for each individual customer in a table.
Each row is identified by its primary key, which
is a unique identifier for that specific row.This
uniqueness is a fundamental component of the
relational aspect of databases.In Figure 1-1, each
customer exists as a single row in the
CUSTOMER table as identified by its unique
primary key (CUST_ID) and is defined by
columns specific to that table.
Tables are joined together by connecting the
primary key of one table to a related table
where it is defined as a foreign key. You
implement relationships between tables by
joining a row of one table to one or more rows
in another table. (Remember: This is a relational
database).
The CUSTOMER table contains a single row for
each customer, and each customer has a unique
primary key identifier. The ORDER table stores
all the orders for the company and each order is
identified by its primary key ORDER_ID. A
customer may have zero (new customer), one,
que aplicativos simples que você inicia e
pára. Os bancos de dados avançados (como
o Oracle) têm usuários, privilégios de
segurança detalhados, configurações de
rede, ajuste de desempenho para memória,
CPU e opções de disco, e opções robustas de
backup e recuperação de desastres (DR).
Examinando como os bancos
de dados funcionam
As bases de dados evoluíram ao longo dos
anos, mas se estabilizaram no modelo
relacional. Um sistema de gerenciamento de
banco de dados relacional (RDBMS) armazena
dados em estruturas lógicas chamadas
tabelas. Uma tabela é um recipiente lógico de
dados semelhantes. Uma definição de tabela
é o conjunto de regras ou características para
cada linha de dados armazenada na tabela.
Quando os dados são carregados em um
banco de dados, ele é carregado como linhas
dentro de uma ou mais tabelas com base nas
características dos dados.
Cada linha de dados únicos existe apenas
uma vez em uma tabela. Por exemplo, haverá
apenas uma linha de dados para cada cliente
individual em uma tabela. Cada linha é
identificada por sua chave primária, que é um
identificador exclusivo para essa linha
específica. Essa singularidade é um
componente fundamental do aspecto
relacional dos bancos de dados. Na Figura 1-
1, cada cliente existe como uma única linha
na tabela CLIENTE como identificado por sua
chave primária única (CUST_ID) e é definido
por colunas específico para essa tabela.
As tabelas são unidas juntas conectando a
chave primária de uma tabela a uma tabela
relacionada onde ela é definida como uma
chave estrangeira. Você implementa
relacionamentos entre tabelas juntando uma
linha de uma tabela a uma ou mais linhas em
outra tabela. (Lembre-se: Este é um banco de
dados relacional).
A tabela CLIENTE contém uma única linha
para cada cliente, e cada cliente possui um
identificador de chave primária exclusivo. A
tabela ORDER armazena todos os pedidos
para a empresa e cada ordem é identificada
pela sua chave primária ORDER_ID. Um
or many (repeat customer) orders, and each
order must have a customer. (You can’t have an
order without a customer.) Each row in the
ORDER table is tied to the CUSTOMER table by
the CUST_ID column which acts as the foreign
key joining the ORDER and CUSTOMER table.
Databases have hundreds or even thousands of
tables, keys, and relationships, and tables can
have millions of rows of data consuming
gigabytes or even terabytes of disk storage. To
speed access when searching for a specific row
of data, an index is created on one or more
columns in a table. indexes work similarly to the
indexes in a book. On a daily basis, it is common
for thousands of rows of data to be inserted,
updated, or deleted within the database.The
RDBMS software, managed by the database
administrator (DBA), supports the overall
management, functioning, and performance of
the database. We talk about DBAs in the
upcoming “Keeping a Database Safe and Sound”
section.
Structured Query Language (SQL) is the language
used to query (SELECT), create (INSERT), modify
(UPDATE), and remove (DELETE) data in a
database. SQL is the core language that DBAs
and database application developers work in;
you need a working knowledge of SQL to
effectively manage a database. SQL is further
defined as data manipulation language (DML)
for querying, creating, modifying, and removing
data and data definition language (DDL) for
changing database and table structure. Oracle
offers a programming extension of SQL called
PL/SQL used to implement application logic
within an Oracle database.
Oracle gained a big advantage early in the
database market by successfully implementing
row locking inside tables. That is, when one or
more people update the same row in a database
at the same time, the RDBMS software ensures
that everyone’s changes are made without
cliente pode ter pedidos de zero (novo
cliente), um ou muitos (clientes com
repetição) e cada pedido deve ter um cliente.
(Você não pode ter um pedido sem um
cliente.) Cada linha na tabela ORDER está
vinculada à tabela CLIENTE pela coluna
CUST_ID que atua como a chave estrangeira
que une a tabela ORDER e CLIENTE.
Os bancos de dados têm centenas ou mesmo
milhares de tabelas, chaves e
relacionamentos, e as tabelas podem ter
milhões de linhas de dados que consomem
gigabytes ou mesmo terabytes de
armazenamento em disco. Para acelerar o
acesso ao procurar uma linha específica de
dados, um índice é criado em uma ou mais
colunas em uma tabela. Os índices funcionam
de forma semelhante aos índices de um livro.
Diariamente, é comum que milhares de linhas
de dados sejam inseridas, atualizadas ou
excluídas no banco de dados. O software
RDBMS, gerenciado pelo administrador de
banco de dados (DBA), suporta o
gerenciamento completo, o funcionamento e
o desempenho da base de dados. Falamos
sobre DBAs na próxima seção 'Mantendo um
banco de dados seguro e Sadio.
Structured Query Language (SQL) é o idioma
usado para consulta (SELECIONAR), criar
(INSERT), modificar (UPDATE) e remover
(DELETE) dados em um banco de dados. O
SQL é o idioma principal em que os DBA e os
desenvolvedores de aplicativos de banco de
dados trabalham; você precisa de um
conhecimento prático do SQL para gerenciar
efetivamente um banco de dados. O SQL
também é definido como linguagem de
manipulação de dados (DML) para consulta,
criação, modificação e remoção de dados e
linguagem de definição de dados (DDL) para
alterar a estrutura do banco de dados e da
tabela. A Oracle oferece uma extensão de
programação de SQL chamada PL / SQL usada
para implementar a lógica do aplicativo
dentro de um banco de dados Oracle.
A Oracle ganhou uma grande vantagem no
início do mercado de banco de dados
implementando com sucesso o bloqueio de
linhas dentro de tabelas. Ou seja, quando
uma ou mais pessoas atualizam a mesma
linha em um banco de dados ao mesmo
conflicts and the data is visible with read
consistency throughout the life of the
transaction. Not all database vendors handled
this issue cleanly
Finding the right database for the Encontrando o banco de dados
job certo para o trabalho
The traditional saying, “If all you have is a
hammer, everything looks like a nail,” is
appropriate to the selection of IT toolsets.
Whether people are storing
the addresses, phone numbers, and e-mails for a
family reunion or they’re maintaining an online
shopping application, they need a data store.
The size, complexity, and scope of that data
store determines whether a database is even
necessary and, if so, what characteristics (and
vendor) of the database are appropriate.
The data requirements for people and
businesses vary greatly in size, complexity, and
importance. Different technologies exist based
on these factors to meet users’ data needs.
✓ Small, individual, or limited-use data stores,
such as address information, are best served by
a Microsoft Excel spreadsheet or a Microsoft
Access database because both are inexpensive
and easy to use.
✓ Small or medium size data stores, such as
those found at small or medium sized
businesses, could make good use of Microsoft
SQL Server, Oracle MySQL, or Oracle Enterprise
or Standard Edition. These implementations are
commonly small, less complex databases where
keeping costs low is an important factor.
✓ Medium to large data stores, such as those
found at medium and large businesses, are
commonly the realm of Microsoft SQL Server,
IBM DB2, and Oracle Enterprise Edition. This
medium to large database market is what many
people think of as a typical database
environment.
tempo, o software RDBMS garante que as
mudanças de todos sejam feitas sem conflitos
e os dados são visíveis com consistência de
leitura ao longo da vida da transação. Nem
todos os fornecedores de banco de dados
trataram este problema de forma limpa
O ditado tradicional, 'Se tudo o que você tem
é um martelo, tudo parece um prego', é
apropriado para a seleção de ferramentas de
TI. Se as pessoas estão armazenando
os endereços, números de telefone e e-mails
para uma reunião de família ou eles estão
mantendo uma aplicação de compras on-line,
eles precisam de um armazenamento de
dados. O tamanho, a complexidade e o
escopo desse armazenamento de dados
determinam se um banco de dados é mesmo
necessário e, em caso afirmativo, quais
características (e fornecedor) do banco de
dados são apropriadas.
Os requisitos de dados para pessoas e
empresas variam muito em tamanho,
complexidade e importância. Existem
diferentes tecnologias com base nesses
fatores para atender às necessidades de
dados dos usuários.
✓ Os Armazenamentos de dados de uso
pequeno, individual ou de uso limitado, como
informações de endereço, são melhor
atendidas por uma planilha do Microsoft
Excel ou por uma base de dados do Microsoft
Access porque ambas são de baixo custo e
fáceis de usar.
✓ Os Armazenamentos de dados de tamanho
pequeno ou médio, como as encontradas em
pequenas ou médias empresas, podem fazer
bom uso do Microsoft SQL Server, Oracle
MySQL ou Oracle Enterprise ou Standard
Edition. Essas implementações são
comumente bancos de dados pequenos e
menos complexos, onde manter os custos
baixos é um fator importante.
✓ Os Armazenamentos de dados de médio a
grande, como as encontradas em empresas
de médio e grande porte, são comumente o
domínio do Microsoft SQL Server, IBM DB2 e
✓ Large and extremely large data stores, such as
those found at large and multinational
businesses, are commonly served by Oracle
Enterprise Edition and IBM DB2. The large and
complex database environments are special
creatures and require very specialized software
and hardware.
Review your current computer system
environment and projected future needs to
make the best decision for your mission.
Vendors might try to upsell you on their product,
so do your homework before making a decision.
However, understand that as your data
requirements change, your database
environment might require change. We often
see systems that started as small, departmental
desktop applications grow until the old software
is no longer functional. The result is an upgrade
to a larger-scaled database system, and that
system is often Oracle.
Choosing Oracle
Many seasoned IT people agree that Oracle
makes the most advanced and reliable
databases in the world. Your authors happen to
agree with that opinion, too. Oracle offers
several databases targeted for different uses and
audiences at varying price points, including
Oracle Enterprise Edition, Oracle Standard
Edition, Oracle Berkley DB, Oracle NoSQL, and
MySQL. (This book focuses on Oracle Enterprise
Edition, Release 12c, although what you learn
will be relevant to previous versions of Oracle.)
Additionally, Oracle offers a programming
extension of SQL called PL/SQL, which is used to
implement application logic within an Oracle
database.
Oracle as a database
Oracle databases are extremely advanced and
Oracle Enterprise Edition. Este mercado de
banco de dados médio a grande é o que
muitas pessoas pensam como um ambiente
de banco de dados típico.
✓ Os Armazenamentos de dados grandes e
extremamente grandes, como as encontradas
em grande e as empresas multinacionais, são
comumente atendidas pela Oracle Enterprise
Edition e pela IBM DB2. Os ambientes de
banco de dados grandes e complexos são
criaturas especiais e requerem software e
hardware muito especializados.
Reveja o seu atual ambiente de sistema
computacional e as futuras necessidades
projetadas para tomar a melhor decisão para
sua missão. Os vendedores podem tentar
valorizar o seu produto, então faça sua lição
de casa antes de tomar uma decisão. No
entanto, entenda que conforme seus
requisitos de dados mudam, seu ambiente de
banco de dados pode exigir mudanças.
Muitas vezes, vemos sistemas que
começaram quando pequenos aplicativos de
desktop departamentais crescem até que o
software antigo não seja mais funcional. O
resultado é uma atualização para um sistema
de banco de dados de escala maior, e esse
sistema geralmente é Oracle.
Escolhendo o Oracle
Muitas pessoas de TI experientes concordam
que a Oracle é a base de dados mais
avançada e confiável do mundo. Seus autores
também concordam com essa opinião. A
Oracle oferece vários bancos de dados
segmentados para diferentes usos e públicos
em diferentes preços, incluindo Oracle
Enterprise Edition, Oracle Standard Edition,
Oracle Berkley DB, Oracle NoSQL e MySQL.
(Este livro se concentra na Oracle Enterprise
Edition, Versão 12c, embora o que você
aprenda será relevante para versões
anteriores da Oracle). Além disso, a Oracle
oferece uma extensão de programação do
SQL chamada PL / SQL, que é usada para
implementar a lógica do aplicativo em um
Oracle base de dados.
Oracle como banco de dados
Os bancos de dados Oracle são componentes
sophisticated software components that are
state of the art for RDBMS. Many features and
options are available, and we guide you through
the features you need for most
implementations. The highly advanced features,
such as Real application Clusters (RAC), remote
data replication, and engineered solutions such
as Exadata, are for customers who require the
cutting edge of technology for specialized
implementations. Visit www.oracle.com for
more details on these advanced technologies.
The sophistication and technological
advancement that make Oracle databases so
great can also make them very complex. Skilled
DBAs devote their entire careers to learning the
finer points of Oracle databases — it’s a
neverending (but often rewarding) process.
Fortunately, Oracle understands that not
everyone wants to commit themselves to
learning the complexities of Oracle databases.
Therefore, Oracle provides a robust, web-based
administration tool, Enterprise Manager, where
you manage and monitor your databases and
the environment supporting them. Leveraging
Enterprise Manager to make your job easier is a
theme you can find throughout this book.
What is the “c” in Oracle 12c?
Following on the success of the previous Oracle
database, release 11g (g is for grid), the most
recent Oracle database release is 12c; the c
stands for cloud computing, but what is that?
Oracle just does databases,
right?
Wrong! At one point in time, if any Oracle
product came into an IT shop, it got passed
straight to the DBAs for implementation because
it had to be database related. Those times are
long gone, and understanding the history of
Oracle is important so you’re not confused by
the myriad of Oracle products.
de software extremamente avançados e
sofisticados que são o estado da arte para o
RDBMS. Muitos recursos e opções estão
disponíveis, e nós o orientamos através dos
recursos que você precisa para a maioria das
implementações. Os recursos altamente
avançados, como Real Clusters de aplicativos
(RAC), replicação de dados remotos e
soluções de engenharia, como o Exadata, são
para clientes que exigem a vanguarda da
tecnologia para implementações
especializadas. Visite www.oracle.com para
obter mais detalhes sobre essas tecnologias
avançadas.
A sofisticação e o avanço tecnológico que
tornam os bancos de dados Oracle tão bons
também podem torná-los muito complexos.
DBAs qualificados dedicam suas carreiras
inteiras a aprender os pontos mais finos dos
bancos de dados Oracle - é um processo
interminável (mas muitas vezes gratificante).
Felizmente, a Oracle entende que nem todos
querem comprometer-se a aprender as
complexidades dos bancos de dados Oracle.
Portanto, a Oracle fornece uma ferramenta
de administração robusta, baseada na web,
Enterprise Manager, onde você gerencia e
monitoriza seus bancos de dados e o
ambiente que os suporta. Alavancar o
Enterprise Manager para tornar seu trabalho
mais fácil é um tema que você pode
encontrar ao longo deste livro.
O que é o 'c' no Oracle 12c?
Seguindo o sucesso do banco de dados Oracle
anterior, a versão 11g (g é para grade), a
versão mais recente do banco de dados
Oracle é 12c; O c significa computação em
nuvem, mas o que é isso?
Oracle apenas faz bases de
dados, certo?
Errado! Em um momento, se algum produto
Oracle entrou em uma loja de TI, ele passou
diretamente para os DBAs para
implementação, porque ele tinha que ser
relacionado ao banco de dados. Esses tempos
são longos e a compreensão do histórico da
Oracle é importante para que você não esteja
confundido com a miríade de produtos

Oracle Corporation started as a database
software company but, through remarkable
success and a series of acquisitions of other
companies, now has a bunch of products. The
acquisition of Sun Microsystems yielded SPARC
UNIX server hardware, the Solaris operating
system, storage systems, and the Java
programming language. The purchase of BEA
Systems provided the well-respected WebLogic
Java application server. Other purchases, such as
PeopleSoft and Siebel, provided Oracle with new
applications software.
Today, Oracle products include (but are not
limited to) databases, operating systems (Linux
and Solaris), database and web application
server hardware, disk and tape storage devices,
web and application server software, Business
Intelligence (BI) software, Java programming
language and supporting software, and multiple
business applications. As you design your next
computer system, you likely will have the option
to have most, if not all, the components
supplied by Oracle. You can consider the pros
and cons of that (end-to-end support versus
vendor commitment, for example), based on
your mission requirements.
Cloud computing is an architecture where
services (such as databases, applications,
development environments, or even server
infrastructure) are available over the network to
the consumer (user). The cloud service provider
supplies the product and bills the consumer
based on usage. For example, say you wanted to
use a type of computer server but you didn’t
want the overhead of buying and maintaining
physical computer hardware and software. A
cloud provider could sell you access to that
computer server hosted in their cloud. You
would pay the cloud service provider a fee based
on your usage and the provider would give you
access to the servers in their cloud. You get the
benefits of having access to the cloud based
server without the hassle and costs of buying
and maintaining your own servers.
Oracle.
A Oracle Corporation começou como uma
empresa de software de banco de dados,
mas, através de um sucesso notável e uma
série de aquisições de outras empresas, agora
tem um monte de produtos. A aquisição da
Sun Microsystems gerou o hardware do
servidor SPARC UNIX, o sistema operacional
Solaris, sistemas de armazenamento e a
linguagem de programação Java. A compra da
BEA Systems proporcionou o bem respeitado
servidor de aplicativos Java WebLogic. Outras
compras, como PeopleSoft e Siebel, forneceu
ao Oracle um novo software de aplicativos.
Hoje, os produtos Oracle incluem (mas não
estão limitados a) bancos de dados, sistemas
operacionais (Linux e Solaris), banco de dados
e hardware do servidor de aplicativos da
Web, dispositivos de armazenamento de
disco e fita, software de servidor web e de
aplicativos, software de Business Intelligence
(BI), programação Java linguagem e software
de suporte e múltiplas aplicações comerciais.
À medida que você projeta seu próximo
sistema de computador, você provavelmente
terá a opção de ter a maioria, se não todos,
dos componentes fornecidos pela Oracle.
Você pode considerar os prós e os contras
desse (suporte de ponta a ponta versus
compromisso do fornecedor, por exemplo),
com base em seus requisitos de missão.
Cloud computing é uma arquitetura onde
serviços (como bancos de dados, aplicativos,
ambientes de desenvolvimento ou até
mesmo infraestrutura de servidor) estão
disponíveis na rede para o consumidor
(usuário). O provedor de serviços da nuvem
fornece o produto e conta o consumidor com
base no uso. Por exemplo, digamos que você
queria usar um tipo de servidor de
computador, mas você não queria a
sobrecarga de comprar e manter hardware e
software de hardware físico. Um provedor de
nuvem poderia vender seu acesso ao servidor
de computador hospedado em sua nuvem.
Você pagaria ao provedor de serviço da
nuvem uma taxa com base em seu uso e o
provedor lhe daria acesso aos servidores em
sua nuvem. Você obtém os benefícios de ter
acesso ao servidor baseado na nuvem sem o
incômodo e os custos de comprar e manter

Cloud architecture allows consumers to choose
only the services they need and pay for only
what they use. Benefits to the consumer include
lower cost, not having to provide their own IT
service, and generally faster delivery of services
than if they built the computing environment
themselves.
Oracle 12c is engineered to run on the cloud and
be accessible as a service. Through virtualization
and multi-tenant architecture, each database
application can appear to have its own private
database but, in reality, the system is a shared
database environment. The use of shared
resources and virtualization is a method used by
companies and database providers to reduce
costs. However, there is no requirement that
Oracle 12c must run in the cloud; you may run
Oracle 12c just like you run other versions of
Oracle without the cloud.
Keeping a Database Safe and
Sound
The person who installs and configures a
database, manages user access and accounts,
ensures space for database objects, and (we
hope) makes backups, among many other
responsibilities, is the database administrator,
or DBA.
Medium to large IT shops have one or more
DBAs, sometimes even a large team of DBAs.
Smaller IT shops may have a person working as a
DBA parttime but doing system administration
or application development as well. Regardless
of whether you’re a full-time or part-time DBA,
you need to understand the responsibilities and
common tasks involved with the care and
feeding of a database.
Try not to confuse the DBA with the application
developer. The process of defining tables,
columns, relationships, and rules is application
seus próprios servidores.
A arquitetura em nuvem permite aos
consumidores escolher apenas os serviços de
que precisam e pagar apenas o que eles
usam. Os benefícios para o consumidor
incluem custos mais baixos, não têm que
fornecer seu próprio serviço de TI e
geralmente uma entrega mais rápida de
serviços do que se eles construíssem o
próprio ambiente de computação.
O Oracle 12c é projetado para ser executado
na nuvem e ser acessível como um serviço.
Através da virtualização e arquitetura multi-
tenant, cada aplicativo de banco de dados
pode parecer ter seu próprio banco de dados
privado, mas, na realidade, o sistema é um
ambiente de banco de dados compartilhado.
O uso de recursos compartilhados e
virtualização é um método usado por
empresas e provedores de banco de dados
para reduzir custos. No entanto, não há
nenhum requisito de que o Oracle 12c deve
ser executado na nuvem; você pode executar
o Oracle 12c, assim como você executa outras
versões do Oracle sem a nuvem.
Manter um banco de dados
seguro e sadio
A pessoa que instala e configura um banco de
dados, gerencia o acesso e as contas do
usuário, garante espaço para objetos de
banco de dados e (esperamos) faz backups,
entre muitas outras responsabilidades, é o
administrador do banco de dados ou DBA.
As lojas de TI de médio a grande possuem um
ou mais DBAs, às vezes até uma grande
equipe de DBAs. Pequenas lojas de TI podem
ter uma pessoa trabalhando como DBA a
tempo parcial, mas também fazendo
administração de sistema ou
desenvolvimento de aplicativos.
Independentemente de você ser um DBA em
tempo integral ou a tempo parcial, você
precisa entender as responsabilidades e
tarefas comuns envolvidas com o cuidado e a
alimentação
de um banco de dados.
Tente não confundir o DBA com o
desenvolvedor do aplicativo. O processo de
definição de tabelas, colunas,
design, data modeling, and ultimately
application development. The DBA is
peripherally involved with these tasks, but
they’re typically the application developers’
responsibilities.
DBA responsibilities
A DBA has multiple responsibilities around
which individual tasks are created to support.
Work comes in the form of technical, non-
technical, database-centric, and business-centric
tasks, but they generally relate to a set of core
areas. As a DBA, you have to
✓ Protect the data. You are the gatekeeper and
protector of the data you are entrusted to
defend. Data must be protected from theft,
damage, and destruction. Protecting the data
encompasses both security and backup and
recovery. This responsibility commonly comes in
the form of establishing, testing, and monitoring
backups and implementing security policies and
technologies.
✓ Provide access to the data. You must ensure
that the data is available to those users and
programs which are authorized to access it.
Speedy, quick access is necessary because if a
query takes too long to execute and the user
gives up, it might as well never finish. Data must
be accessible as well; if the database is
shutdown or otherwise unavailable, it does the
users no good. Providing access to the data
involves performance tuning and High
Availability (HA).
✓ Maintain the software. You are responsible
for ensuring the general maintenance and
housekeeping of the database is kept up to date.
Databases must be monitored for errors,
ensuring there is enough space to grow as new
data is loaded, and monitor processing jobs for
success. Furthermore, there is always a new
version of software to upgrade to or apply a
patch (often after hours). These are generally
mundane items 16 Part I: Getting Started with
Oracle 12c and much of it can be automated via
scripts or Enterprise Manager, but they still are
relacionamentos e regras é design de
aplicativos, modelagem de dados e,
finalmente, desenvolvimento de aplicativos.
O DBA é envolvido perifericamente com essas
tarefas, mas geralmente são as
responsabilidades dos desenvolvedores de
aplicativos.
Responsabilidades do DBA
Um DBA tem múltiplas responsabilidades em
torno das quais tarefas individuais são criadas
para suportar. O trabalho vem sob a forma de
tarefas técnicas, não técnicas, baseadas em
banco de dados e centradas no negócio, mas
geralmente se relacionam com um conjunto
de áreas principais. Como um DBA, você tem
que
✓ Proteja os dados. Você é o porteiro e
protetor dos dados que você está confiado
para defender. Os dados devem ser
protegidos contra roubo, dano e destruição.
Proteger os dados engloba segurança e
backup e recuperação. Esta responsabilidade
geralmente vem na forma de estabelecer,
testar e monitorar backups e implementar
políticas e tecnologias de segurança.
✓ Fornecer acesso aos dados. Você deve
garantir que os dados estejam disponíveis
para aqueles usuários e programas que estão
autorizados a acessá-lo. O acesso rápido e
rápido é necessário porque, se uma consulta
demorar muito para ser executada e o
usuário desistir, talvez nunca termine. Os
dados também devem estar acessíveis; Se o
banco de dados estiver desligado ou não
estiver disponível, os usuários não são bons.
Fornecer acesso aos dados envolve
desempenho tuning e alta disponibilidade
(HA).
✓ Mantenha o software. Você é responsável
por garantir que a manutenção geral e o
arrumação do banco de dados sejam
atualizados.
Os bancos de dados devem ser monitorados
quanto a erros, garantindo que haja espaço
suficiente para crescer à medida que novos
dados sejam carregados e monitorize o
processamento de tarefas para o sucesso.
Além disso, sempre há uma nova versão do
your responsibility.
✓ Support the business. Databases do not exist
in isolation. They are part of an overall business
objective, and that business objective is usually
evolving. New application code is being
generated requiring developer assistance, audits
of your processes are being conducted, and
users always have miscellaneous issues. The
most common example is applying a new
application release to the database or
implementing new technology to enable a new
business capability. These efforts periodically
correspond to database maintenance, but they
are in support of moving the business objectives
forward, and the wise DBA supports these
efforts.
Common tasks
Life as a DBA varies based on the nature of the
business and the IT environment. Here’s how
the core responsibilities can manifest
themselves within a common task:
✓ Protect the data by
• Reviewing output logs and messages to ensure
the previous night’s backups ran successfully.
• Responding to questions about user access and
database auditing procedures. (This task also
falls under support the business.)
• Researching and applying Critical Patch Update
(CPU) patches to ensure security and
vulnerability fixes are made. (This task also falls
under maintain the software.)
✓ Provide access to the data by checking
Enterprise Manager and your cell phone texts
for alerts showing down databases or listeners,
which would impact user access to the
databases.
software para atualizar ou aplicar um patch
(muitas vezes após horas). Estes são
geralmente itens mundanos 16 Parte I:
Introdução ao Oracle 12c e muito pode ser
automatizado através de scripts ou Enterprise
Manager, mas eles ainda são sua
responsabilidade.
✓ Apoie o negócio. Os bancos de dados não
existem isoladamente. Eles são parte de um
objetivo geral de negócios, e esse objetivo
comercial é geralmente evoluindo. O novo
código de aplicação está sendo gerado,
exigindo ajuda do desenvolvedor, as
auditorias de seus processos estão sendo
conduzidas e os usuários sempre têm
problemas diversos. O exemplo mais comum
é aplicar uma nova versão do aplicativo ao
banco de dados ou implementar nova
tecnologia para permitir uma nova
capacidade de negócios. Esses esforços
correspondem periodicamente à manutenção
de banco de dados, mas eles são de suporte
para mover os objetivos de negócios para a
frente, e o sábio DBA apoia esses esforços.
Tarefas comuns
A vida como DBA varia com base na natureza
do negócio e no ambiente de TI. Veja como as
principais responsabilidades podem se
manifestar em uma tarefa comum:
✓ Proteja os dados por
• Revisão de logs e mensagens de saída para
garantir que os backups da noite anterior
tenham sido executados com sucesso.
• Respondendo a perguntas sobre acesso de
usuários e procedimentos de auditoria de
banco de dados. (Esta tarefa também se
enquadra no suporte do negócio.)
• Pesquisando e aplicando correções de
Atualização de Patch Crítico (CPU) para
garantir que as correções de segurança e
vulnerabilidade sejam feitas. (Esta tarefa
também fica sob manter o software.)
✓ Fornecer acesso aos dados, verificando o
Enterprise Manager e os textos do seu
telefone celular para alertas que aparecem
✓ Maintain the software by using Enterprise
Manager and log files to search for database
alerts, errors, and space usage threshold
concerns.
✓ Support the business by
• Reviewing output logs and messages to ensure
the previous night’s application batch jobs and
processes completed.
• Checking e-mail and responding to any
application or user issues
• Applying application updates to development,
test, and production databases to provide
additional functionality and bug fixes for users.
Database administration is a respected
profession in the IT field. Many people make a
comfortable living as an Oracle DBA. Some
would say Oracle wouldn’t be where it is today if
not for the legions of dedicated Oracle
professionals worldwide.
Understanding Oracle Database
Architecture
In This Chapter
▶ Structuring memory
▶ Checking the physical structures
▶ Applying the irreducible logic of the logical
structures
Understanding the Oracle architecture is
paramount to managing a database.
If you have a sound knowledge of the way
Oracle works, it can help all sorts of things:
✓ Troubleshooting
✓ Recovery
abaixo dos bancos de dados ou ouvintes, o
que afetaria o acesso do usuário aos bancos
de dados.
✓ Mantenha o software usando o Enterprise
Manager e arquivos de log para procurar
alertas de base de dados, erros e
preocupações de limiar de uso do espaço.
✓ Apoie o negócio por
• Revisando logs e mensagens de saída para
garantir que os trabalhos e processos em lote
de aplicativos da noite anterior sejam
concluídos.
• Verificar e-mail e responder a qualquer
problema de aplicativo ou usuário
• Aplicação de atualizações de aplicativos
para bancos de dados de desenvolvimento,
teste e produção para fornecer
funcionalidades adicionais e correções de
bugs para usuários.
A administração de banco de dados é uma
profissão respeitada no campo de TI. Muitas
pessoas fazem uma vida confortável como
um Oracle DBA. Alguns diriam que a Oracle
não estaria onde está hoje, senão para as
legiões de profissionais dedicados da Oracle
em todo o mundo.
Compreendendo a arquitetura
de banco de dados Oracle
Neste capítulo
▶ Estruturação da memória
▶ Verificando as estruturas físicas
▶ Aplicação da lógica irredutível das
estruturas lógicas
Compreender a arquitetura Oracle é
fundamental para gerenciar um banco de
dados.
Se você tem um conhecimento sólido sobre o
funcionamento da Oracle, pode ajudar todo
tipo de coisas:
✓ Solução de problemas
✓ Tuning
✓ Sizing
✓ Scaling
As they say, that list can go on and on. That’s
why a solid knowledge of the inner workings of
Oracle is so important.
In this chapter, we break down each process,
file, and logical structure. Despite the dozens of
different modules in the database, you should
come away with a good understanding of what
they are, why they’re there, and how they work
together. This chapter is more conceptual than it
is hands-on, but it gives you a solid base for
moving forward as you begin working with
Oracle
Defining Databases and Instances
In Oracle speak, an instance is the combination
of memory and processes that are part of a
running installation. The database is the physical
component or the files. You might hear people
use the term database instance to refer to the
entire running database. However, it’s
important to understand the distinction
between the two.
Here are some rules to consider:
✓ An instance can exist without a database. Yes,
it’s true. You can start an Oracle instance and
not have it access any database files. Why would
you do this?
• This is how you create a database. There’s no
chicken-or-egg debate here. You first must start
an Oracle instance; you create the database
from within the instance.
• An Oracle feature called Automatic Storage
Management uses an instance but isn’t
associated with a database.
✓ A database can exist without an instance but
✓ Recuperação
✓ Tuning
✓ Dimensionamento
✓ Escalação
Como eles dizem, essa lista pode continuar e
continuar. É por isso que um conhecimento
sólido do funcionamento interno da Oracle é
tão importante.
Neste capítulo, dividimos cada processo,
arquivo e estrutura lógica. Apesar das
dezenas de módulos diferentes no banco de
dados, você deve ter uma boa compreensão
do que eles são, por que eles estão lá e como
eles trabalham juntos. Este capítulo é mais
conceitual do que é prático, mas dá-lhe uma
base sólida para avançar à medida que você
começa a trabalhar com o Oracle
Definindo bancos de dados e
instâncias
Na Oracle, uma instância é a combinação de
memória e processos que fazem parte de
uma instalação em execução. O banco de
dados é o componente físico ou os arquivos.
Você pode ouvir pessoas usar a instância do
banco de dados do termo para se referir a
toda a base de dados em execução. No
entanto, é importante compreender a
distinção entre os dois.
Aqui estão algumas regras a considerar:
✓ Uma instância pode existir sem um banco
de dados. Sim, é verdade. Você pode iniciar
uma instância Oracle e não ter acesso a
nenhum arquivo de banco de dados. Por que
você faria isso?
• É assim que você cria um banco de dados.
Não há debate de frango ou ovo aqui. Você
deve primeiro iniciar uma instância Oracle;
Você cria o banco de dados dentro da
instância.
• Um recurso Oracle chamado
Gerenciamento de armazenamento
automático usa uma instância, mas não está
would be useless. It’s just a bunch of magnetic
blips on the hard drive.
✓ An instance can access only one database.
When you start your instance, the next step is to
mount that instance to a database. An instance
can mount only one database at a time.
✓ You can set up multiple instances to access
the same set of files or one database. Clustering
is the basis for the Oracle Real Application
Clusters feature. Many instances on several
servers accessing one central database allows
for scalability and high availability.
Deconstructing the Oracle
Architecture
You can break down the Oracle architecture into
the following three main parts:
✓ Memory: The memory components of Oracle
(or any software, for that matter) are what
inhabit the RAM on the computer. These
structures exist only when the software is
running. For example, they instantiate when you
start an instance. Some of the structures are
required for a running database; others are
optional. You can also modify some to change
the behavior of the database, whereas others
are static.
✓ Processes: Again, Oracle processes exist only
when the instance is running. The running
instance has some core mandatory processes,
whereas others are optional, depending on what
features are enabled. These processes typically
show up on the OS process listing.
✓ Files and structures: Files associated with the
database exist all the time as long as a database
is created. If you install only the Oracle software,
no database files exist. The files show up as soon
as you create a database. As with memory and
process, some files are required, whereas others
associado a um banco de dados.
✓ Um banco de dados pode existir sem uma
instância, mas seria inútil. É apenas um
monte de blips magnéticos no disco rígido.
✓ Uma instância pode acessar apenas um
banco de dados. Quando você inicia sua
instância, o próximo passo é montar essa
instância em um banco de dados. Uma
instância pode montar apenas um banco de
dados por vez.
✓ Você pode configurar várias instâncias para
acessar o mesmo conjunto de arquivos ou um
banco de dados. Clustering é a base do
recurso Oracle Real Application Clusters.
Muitas instâncias em vários servidores
acessando um banco de dados central
permitem escalabilidade e alta
disponibilidade.
Desconstruindo a Arquitetura
Oracle
Você pode dividir a arquitetura do Oracle nas
três partes principais a seguir:
✓ Memória: os componentes de memória da
Oracle (ou qualquer software, para esse
assunto) são o que habitam a RAM no
computador. Essas estruturas existem
somente quando o software está sendo
executado. Por exemplo, eles instanciam
quando você inicia uma instância. Algumas
das estruturas são necessárias para um banco
de dados em execução; outros são opcionais.
Você também pode modificar alguns para
alterar o comportamento do banco de dados,
enquanto outros são estáticos.
✓ Processos: Novamente, os processos
Oracle existem somente quando a instância
está sendo executada. A instância em
execução possui alguns processos
obrigatórios do núcleo, enquanto outros são
opcionais, dependendo do recurso habilitado.
Esses processos normalmente aparecem na
listagem do processo OS.
✓ Arquivos e estruturas: os arquivos
associados ao banco de dados existem todo o
are optional. Files contain your actual database
objects: the things you create as well as the
objects required to run the database. The logical
structures are such things as tables, indexes, and
programs.
Maybe you could say that the Oracle
architecture has two-and-a-half parts. Because
files contain the structures, we lump those two
together.
The following sections get into more detail
about each of these main components.
Walking Down Oracle Memory
Structures
Oracle has many different memory structures for
the various parts of the software’s operation.
Knowing these things can greatly improve how
well your database runs:
✓ What each structure does
✓ How to manage it
In most cases, more memory can improve your
database’s performance. However, sometimes
it’s best to use the memory you have to
maximize performance.
For example, are you one of those power users
who likes to have ten programs open at once,
constantly switching between applications on
your desktop? You probably know what we’re
talking about. The more programs you run, the
more memory your computer requires. In fact,
you may have found that upgrading your
machine to more memory seems to make
everything run better. On the other hand, if you
are really a computer nerd, you might go into
the OS and stop processes that you aren’t using
tempo, desde que seja criado um banco de
dados. Se você instalar apenas o software
Oracle, não existem arquivos de banco de
dados. Os arquivos aparecem assim que você
criar um banco de dados. Tal como acontece
com a memória e o processo, alguns arquivos
são necessários, enquanto outros são
opcionais. Os arquivos contêm seus objetos
de banco de dados reais: as coisas que você
cria, bem como os objetos necessários para
executar o banco de dados. As estruturas
lógicas são coisas como tabelas, índices e
programas.
Talvez você possa dizer que a arquitetura
Oracle tem duas partes e meia. Como os
arquivos contêm as estruturas, agrupamos
esses dois.
As seções a seguir contêm mais detalhes
sobre cada um desses componentes
principais.
Caminhando para baixo
Estruturas de memória Oracle
A Oracle possui muitas estruturas de
memória diferentes para as várias partes da
operação do software.
Conhecer essas coisas pode melhorar
consideravelmente a eficácia do seu banco de
dados:
✓ O que cada estrutura faz
✓ Como gerenciá-lo
Na maioria dos casos, mais memória pode
melhorar o desempenho do seu banco de
dados. No entanto, às vezes é melhor usar a
memória que você precisa para maximizar o
desempenho.
Por exemplo, você é um desses usuários
avançados que gostam de ter dez programas
abertos de uma vez, alternando
constantemente entre aplicativos em sua
área de trabalho? Você provavelmente sabe
do que estamos falando. Quanto mais
programas você executar, mais memória seu
computador requer. Na verdade, você pode
to make better use of the memory you have.
Oracle works in much the same way.
Trotting around the System
Global Area
The System Global Area (SGA) is a group of
shared memory structures. It contains things like
data and SQL. It is shared between Oracle
background processes and server processes.
The SGA is made up of several parts called the
SGA components:
✓ Shared pool
✓ Database buffer cache
✓ Redo log buffer
✓ Large pool
✓ Java pool
✓ Streams pool
The memory areas are changed with
initialization parameters.
✓ You can modify each parameter individually
for optimum tuning (only for the experts).
✓ You can tell Oracle how much memory you
want the SGA to use (for everyone else).
Say you want Oracle to use 1GB of memory. The
database actually takes that 1GB, analyzes how
everything is running, and tunes each
component for optimal sizing. It even tells you
when it craves more.
Shared pool
achar que atualizar sua máquina para mais
memória parece fazer com que tudo funcione
melhor. Por outro lado, se você é realmente
um nerd do computador, você pode entrar no
sistema operacional e parar os processos que
você não está usando para usar melhor a
memória que você possui. O Oracle funciona
da mesma maneira.
Trotando em torno da Área
Global do Sistema
A Área Global do Sistema (SGA) é um grupo
de estruturas de memória compartilhada. Ele
contém coisas como dados e SQL. É
compartilhado entre os processos de fundo
Oracle e os processos do servidor.
O SGA é composto por várias peças chamadas
componentes SGA:
✓ pool compartilhado
✓ Cache de buffer de banco de dados
✓ Refazer o buffer de registro
✓ Grande piscina
✓ pool de Java
✓ pool de fluxos
As áreas de memória são alteradas com os
parâmetros de inicialização.
✓ Você pode modificar cada parâmetro
individualmente para o melhor ajuste (apenas
para os especialistas).
✓ Você pode dizer a Oracle quanto memória
você deseja que o SGA use (para todos os
outros).
Digamos que você deseja que a Oracle use
1GB de memória. O banco de dados
realmente toma esse 1GB, analisa como tudo
está sendo executado e sintoniza cada
componente para dimensionamento ótimo.
Até lhe diz quando anseia mais.
Shared pool
Certain objects and devices in the database are
used frequently. Therefore, it makes sense to
have them ready each time you want to do an
operation.
Furthermore, data in the shared pool is never
written to disk.
The shared pool itself is made up of four main
areas:
✓ Library cache
✓ Dictionary cache
✓ Server Result cache
✓ Reserved Pool
A cache is a temporary area in memory created
for a quick fetch of information that might
otherwise take longer to retrieve. For example,
the caches mentioned in the preceding list
contain precomputed information. Instead of a
user having to compute values every time, the
user can access the information in a cache
The library cache
The library cache is just like what it’s called: a
library. More specifically, it is a library of ready-
to-go SQL statements.
Each time you execute a SQL statement, a lot
happens in the background. This background
activity is called parsing. Parsing can be quite
expensive in terms of processing power.
During parsing, some of these things happen:
✓ The statement syntax is checked to make sure
you typed everything correctly.
✓ The objects you’re referring to are checked.
For example, if you’re trying to access a table
called EMPLOYEE, Oracle makes sure it exists in
the database.
✓ Oracle makes sure that you have permission
Certos objetos e dispositivos no banco de
dados são usados com freqüência. Por isso,
faz sentido prepará-los sempre que quiser
fazer uma operação.
Além disso, os dados no pool compartilhado
nunca são gravados no disco.
O pool compartilhado é composto por quatro
áreas principais:
✓ Library cache
✓ Dictionary cache
✓ Server Result cache
✓ Reserved Pool
Um cache é uma área temporária na
memória criada para uma rápida busca de
informações que, de outra forma, poderiam
levar mais tempo para recuperar. Por
exemplo, os caches mencionados na lista
anterior contêm informações pré-
computadas. Em vez de um usuário ter que
calcular valores de cada vez, o usuário pode
acessar as informações em um cache
The library cache
O cache da biblioteca é exatamente como o
chamado: uma biblioteca. Mais
especificamente, é uma biblioteca de
instruções SQL prontas a serem executadas.
Cada vez que você executa uma instrução
SQL, muito acontece em segundo plano. Esta
atividade em segundo plano é chamada de
análise. Parsing pode ser bastante caro em
termos de poder de processamento.
Durante a análise, algumas dessas coisas
acontecem:
✓ A sintaxe da instrução é verificada para
garantir que você digitou tudo corretamente.
✓ Os objetos aos quais você está se referindo
são verificados. Por exemplo, se você estiver
tentando acessar uma tabela chamada
to do what you’re trying to do.
✓ The code is converted into a database-ready
format. The format is called byte-code or p-
code.
✓ Oracle determines the optimum path or plan.
This is by far the most expensive part.
Every time you execute a statement, the
information is stored in the library cache. That
way, the next time you execute the statement
not much has to occur (such as checking
permissions).
The dictionary cache
The dictionary cache is also frequently used for
parsing when you execute SQL. You can think of
it as a collection of information about you and
the database’s objects. It can check background-
type information.
The dictionary cache is also governed by the
rules of the Least Recently Used (LRU) algorithm:
If it’s not the right size, information can be
evicted. Not having enough room for the
dictionary cache can impact disk usage. Because
the definitions of objects and permission-based
information are stored in database files, Oracle
has to read disks to reload that information into
the dictionary cache. This is more time-
consuming than getting it from the memory
cache. Imagine a system with thousands of users
constantly executing SQL . . . an improperly sized
dictionary cache can really hamper performance.
Like the library cache, you can’t control the size
of the dictionary cache directly. As the overall
shared pool changes in size, so does the
dictionary cache.
The server result cache
EMPREGADO, a Oracle assegura que ela
exista no banco de dados.
✓ A Oracle garante que você tenha
permissão para fazer o que você está
tentando fazer.
✓ O código é convertido em um formato
pronto para banco de dados. O formato é
chamado byte-code ou p-code.
✓ A Oracle determina o caminho ou o plano
ideal. Esta é, de longe, a parte mais cara.
Toda vez que você executa um comando, as
informações são armazenadas no cache da
biblioteca. Dessa forma, na próxima vez que
você executar a instrução, não há muito que
ocorrer (como verificar permissões).
The dictionary cache
O cache do dicionário também é usado com
frequência para analisar quando você executa
o SQL. Você pode pensar nisso como uma
coleção de informações sobre você e os
objetos do banco de dados. Pode verificar
informações de tipo de plano de fundo.
O cache do dicionário também é regido pelas
regras do algoritmo Menos Recentemente
Usado (LRU): se não for o tamanho certo, a
informação pode ser despejada. Não ter
espaço suficiente para o cache do dicionário
pode afetar o uso do disco. Como as
definições de objetos e informações baseadas
em permissão são armazenadas em arquivos
de banco de dados, a Oracle deve ler discos
para recarregar essas informações no cache
do dicionário. Isso é mais demorado do que
obtê-lo do cache de memória. Imagine um
sistema com milhares de usuários
constantemente executando o SQL. . . um
cache de dicionário de tamanho incorreto
pode realmente dificultar o desempenho.
Como o cache da biblioteca, você não pode
controlar o tamanho do cache do dicionário
diretamente. Como o pool compartilhado
geral muda de tamanho, o mesmo ocorre
com o cache do dicionário.
The server result cache
The server result cache has two parts:
✓ SQL result cache: This cache lets Oracle see
that the requested data — requested by a
recently executed SQL statement — might be
stored in memory. This situation lets Oracle skip
the execution part of the, er, execution, for lack
of a better term, and go directly to the result set
if it exists.
What if your data changes? Well, we didn’t say
this is the end-all-performance-woes feature.
The SQL result cache works best on relatively
static data (like the description of an item on an
e-commerce site).
Should you worry about the result cache
returning incorrect data? Not at all. Oracle
automatically invalidates data stored in the
result cache if any of the underlying components
are modified.
✓ : The PL/SQL function result cache stores the
results of a computation. For example, say you
have a function that calculates the value of the
dollar based on the exchange rate of the Euro.
You might not want to store that actual value
since it changes constantly. Instead, you have a
function that calls on a daily or hourly rate to
determine the value of the dollar. In a financial
application, this call could happen thousands of
times an hour. Therefore, instead of the function
executing, it goes directly to the PL/SQL result
cache to get the data between the rate updates.
If the rate does change, Oracle reexecutes the
function and updates the result cache.
The reserved pool
When Oracle needs to allocate a large chunk
(over 5 KB) of contiguous memory in the shared
pool, it allocates the memory in the reserved
O cache do resultado do servidor tem duas
partes:
✓ cache de resultados SQL: este cache
permite que a Oracle veja que os dados
solicitados - solicitados por uma declaração
SQL executada recentemente - podem estar
armazenados na memória. Essa situação
permite que a Oracle ignore a parte de
execução da execução, por falta de um termo
melhor, e vá diretamente ao conjunto de
resultados, se existir.
E se seus dados mudarem? Bem, não
dissemos que este é o recurso final-tudo-
desempenho-woes. O cache de resultados
SQL funciona melhor em dados relativamente
estáticos (como a descrição de um item em
um site de comércio eletrônico).
Você deve se preocupar com o cache do
resultado retornando dados incorretos? De
modo nenhum. O Oracle invalida
automaticamente os dados armazenados no
cache de resultados se qualquer um dos
componentes subjacentes for modificado.
✓ cache do resultado da função PL / SQL: o
cache do resultado da função PL / SQL
armazena os resultados de uma computação.
Por exemplo, digamos que você possui uma
função que calcula o valor do dólar com base
na taxa de câmbio do euro. Você pode não
querer armazenar esse valor real, uma vez
que muda constantemente. Em vez disso,
você tem uma função que exige uma taxa
diária ou horária para determinar o valor do
dólar. Em uma aplicação financeira, esta
chamada pode acontecer milhares de vezes
por hora. Portanto, em vez da função que
executa, ele vai diretamente ao cache de
resultados PL / SQL para obter os dados entre
as atualizações de taxa. Se a taxa mudar, o
Oracle recorre a função e atualiza o cache do
resultado.
The reserved pool
Quando a Oracle precisa alocar um pedaço
grande (mais de 5 KB) de memória contígua
no pool compartilhado, ele aloca a memória
pool. Dedicating the reserved pool to handle
large memory allocations improves performance
and reduces memory fragementation.
Least Recently Used algorithm
If the library cache is short on space, objects are
thrown out. Statements that are used the most
stay in the library cache the longest. The more
often they’re used, the less chance they have of
being evicted if the library cache is short on
space.
The library cache eviction process is based on
what is called the Least Recently Used (LRU)
algorithm. If your desk is cluttered, what do you
put away first? The stuff you use the least.
You can’t change the size of the library cache
yourself. The shared pool’s overall size
determines that. If you think too many
statements are being evicted, you can boost the
overall shared pool size if you’re tuning it
yourself. If you’re letting Oracle do the tuning, it
grabs free memory from elsewhere.
Heap area
There aren’t a lot of interesting things to say
about the heap area within the context of this
book. Basically, the heap area is a bunch of
smaller memory components in the shared pool.
Oracle determines their sizes and tunes them
accordingly.
Only the nerdiest of Oracle DBAs search the dark
nether-regions of the Internet for heap area
information. It’s not readily available from
Oracle in the documentation, and the
information you do find may or may not be
accurate.
If all I have done was make you more curious,
look at the dynamic performance view in the
database called V$SGASTAT to get a list of all the
other heap area memory component names;
no pool reservado. Dedicar o pool reservado
para lidar com grandes alocações de memória
melhora o desempenho e reduz a
fragmentação da memória.
Least Recently Used algorithm
Se a Library Cache é curta em espaço, os
objetos são descartados. As Instruções que
são mais utilizadas permanecem na Library
Cache por mais tempo. Quanto mais vezes
eles são usados, menor será a chance de
serem despejadas se a Library Cache é
pequena.
O processo de despejo do cache da biblioteca
é baseado no chamado algoritmo Least
recently Used (LRU). Se a sua mesa estiver
bagunçada, o que você coloca em primeiro
lugar? O que você usou por último.
Você não pode alterar o tamanho do cache
da biblioteca. O tamanho geral do pool
compartilhado determina isso. Se você acha
que muitas declarações estão sendo
despejadas, você pode aumentar o tamanho
geral da Shared Pool se você estiver
ajustando você mesmo. Se você estiver
deixado o Oracle fazer o ajuste, ele pega
memória livre de outro lugar.
Heap area
Não há muitas coisas interessantes para dizer
sobre a área do heap no contexto deste livro.
Basicamente, a área do heap é um monte de
componentes de memória menores no pool
compartilhado. A Oracle determina seus
tamanhos e os ajusta de acordo.
Somente o nerdiest dos DBAs Oracle
procuram as regiões inferiores escuras da
Internet para obter informações sobre a área
do heap. Não está prontamente disponível da
Oracle na documentação, e as informações
que você encontra podem ou não ser
precisas.
Se tudo o que fiz foi torná-lo mais curioso,
veja a visão de desempenho dinâmico no
banco de dados chamado V $ SGASTAT para
obter uma lista de todos os outros nomes de
componentes de memória de área de heap;
Database buffer cache
The database buffer cache is typically the largest
portion of the SGA. It has data that comes from
the files on disk. Because accessing data from
disk is slower than from memory, the database
buffer cache’s sole purpose is to cache the data
in memory for quicker access.
The database buffer cache can contain data from
all types of objects:
✓ Tables
✓ Indexes
✓ Materialized views
✓ System data
In the phrase database buffer cache, the term
buffer refers to database blocks.
A database block is the minimum amount of
storage that Oracle reads or writes. All storage
segments that contain data are made up of
blocks. When you request data from disk, at
minimum Oracle reads one block. Even if you
request only one row, many rows in the same
table are likely to be retrieved.
The same goes if you request one column in one
row. Oracle reads the entire block, which most
likely has many rows, and all columns for that
row.
It’s feasible to think that if your departments
table has only ten rows, the entire thing can be
read into memory even if you’re requesting the
name of only one department
Buffer cache state
The buffer cache controls what blocks get to stay
depending on available space and the block
state (similar to how the shared pool decides
Database buffer cache
O cache do buffer do banco de dados
normalmente é a maior parte do SGA. Tem
dados provenientes dos arquivos no disco.
Como o acesso aos dados do disco é mais
lento do que a partir da memória, o único
objetivo do cache do buffer do banco de
dados é armazenar em cache os dados na
memória para acesso mais rápido.
O cache do buffer do banco de dados pode
conter dados de todos os tipos de objetos:
✓ Tabelas
✓ Índices
✓ visualizações materializadas
✓ Dados do sistema
Na frase cache de buffer de banco de dados,
o termo buffer refere-se a blocos de banco de
dados.
Um bloco de banco de dados é a quantidade
mínima de armazenamento que o Oracle lê
ou escreve. Todos os segmentos de
armazenamento que contêm dados são
constituídos por blocos. Quando você solicita
dados do disco, no mínimo o Oracle lê um
bloco. Mesmo que você solicite apenas uma
linha, muitas linhas na mesma tabela
provavelmente serão recuperadas.
O mesmo acontece se você solicitar uma
coluna de uma linha. Oracle lê o bloco inteiro,
que provavelmente tem muitas linhas e todas
as colunas para essa linha.
É viável pensar que, se sua tabela de
departamentos tiver apenas dez linhas, tudo
pode ser lido na memória mesmo se você
estiver solicitando o nome de um único
departamento
Buffer cache state
O cache do buffer armazena quais blocos
ficam dependendo do espaço disponível e do
estado do bloco (semelhante ao modo como
what SQL gets to stay). The buffer cache uses its
own version of the LRU algorithm.
A block in the buffer cache can be in one of three
states:
✓ Free: Not currently being used for anything
✓ Pinned: Currently being accessed
✓ Dirty: Block has been modified but not yet
written to disk
Free blocks
Ideally, free blocks are available whenever you
need them. However, that probably isn’t the
case unless your database is so small that the
whole thing can fit in memory.
The LRU algorithm works a little differently in
the buffer cache than it does in the shared pool.
It scores each block and then times how long it
has been since it was accessed. For example, a
block gets a point each time it’s touched. The
higher the points, the less likely the block will be
flushed from memory.However, it must be
accessed frequently or the score decreases. A
block has to work hard to stay in memory if the
competition for memory resources is high.
Giving each block a score and time prevents this
type of situation from arising: A block is
accessed heavily at the end of the month for
reports. Its score is higher than any other block
in the system. That block is never accessed
again. It sits there wasting memory until the
database is restarted or another block finally
scores enough points to beat it out. The time
component ages it out very quickly after you no
longer access it.
Pinned blocks
A block currently being accessed is a pinned
block. The block is locked (or pinned) into the
buffer cache so it cannot be aged out of the
buffer cache while the Oracle process (often
o pool compartilhado decide o que o SQL
pode permanecer). O cache do buffer usa sua
própria versão do algoritmo LRU.
Um bloco no cache do buffer pode estar em
um dos três estados:
✓ Livre: Não está sendo usado para nada
✓ Incluído: atualmente acessado
✓ Sujo: o bloco foi modificado, mas ainda
não foi gravado no disco
Free blocks
Idealmente,Free blocks estão disponíveis
sempre que você precisar deles. No entanto,
isso provavelmente não é o caso, a menos
que seu banco de dados seja tão pequeno
que tudo possa caber em memória.
O algoritmo LRU funciona um pouco
diferente no cache do buffer do que no pool
compartilhado. Ele classifica cada bloco e, em
seguida, vezes quanto tempo existe desde
que foi acessado. Por exemplo, um bloco
recebe um ponto cada vez que é tocado.
Quanto maior os pontos, menos provável
será que o bloco seja eliminado da memória.
No entanto, deve ser acessado com
frequência ou a pontuação diminui. Um bloco
tem que trabalhar duro para manter a
memória se a competição por recursos de
memória for alta.
Dar a cada bloco uma pontuação e tempo
evita que esse tipo de situação surja: um
bloco é acessado pesadamente no final do
mês para relatórios. Sua pontuação é maior
do que qualquer outro bloco no sistema. Esse
bloco nunca mais será acessado. Senta-se
desperdiçando memória até que o banco de
dados seja reiniciado ou outro bloco
finalmente pontue pontos suficientes para
vencê-lo. O componente de tempo envelhece
muito rapidamente depois de você não mais
acessá-lo.
Pinned blocks
Um bloco atualmente acessado é um bloco
fixo. O bloco está bloqueado (ou fixado) no
buffer buffer para que ele não possa ser
envelhecido fora do buffer buffer enquanto o
representing a user) is accessing it.
Dirty blocks
A modified block is a dirty block. To make sure
your changes are kept across database
shutdowns, these dirty blocks must be written
from the buffer cache to disk. The database
names dirty blocks in a dirty list or write queue.
You might think that every time a block is
modified, it should be written to disk to
minimize lost data. This isn’t the case — not
even when there’s a commit (when you save
your changes permanently)! Several structures
help prevent lost data.
Furthermore, Oracle has a gambling problem.
System performance would crawl if you wrote
blocks to disk for every modification. To combat
this,
Oracle plays the odds that the database is
unlikely to fail and writes blocks to disk only in
larger groups. Don’t worry; it’s not even a risk
against lost data. Oracle is getting performance
out of the database right now at the possible
expense of a recovery taking longer later.
Because failures on properly managed systems
rarely occur, it’s a cheap way to gain some
performance.
However, it’s not as if Oracle leaves dirty blocks
all over without cleaning up after itself.
Block write triggers
What triggers a block write and therefore a dirty
block?
✓ The database is issued a shutdown command.
✓ A full or partial checkpoint occurs — that’s
when the system periodically dumps all the dirty
buffers to disk.
processo Oracle (geralmente representando
um usuário) está acessando.
Dirty blocks
Um bloco modificado é um bloco sujo. Para
certificar-se de que suas alterações são
mantidas em paradas de banco de dados,
esses blocos sujos devem ser escritos do
Buffer Cacher para o disco. O banco de dados
nomeia blocos sujos em uma lista suja ou fila
de gravação.
Você pode pensar que sempre que um bloco
é modificado, ele deve ser gravado no disco
para minimizar os dados perdidos. Este não é
o caso - nem mesmo quando há uma
confirmação (quando você salva suas
alterações permanentemente)! Várias
estruturas ajudam a evitar dados perdidos.
Além disso, a Oracle tem um risco de
empreender um problema. O desempenho
do sistema se arrastaria se você escrevesse
blocos no disco para cada modificação. Para
combater isso,
A Oracle joga as probabilidades de que o
banco de dados é improvável de falhar e
grava blocos de disco apenas em grupos
maiores. Não se preocupe; nem sequer é um
risco contra perda de dados. A Oracle está
obtendo o desempenho fora do banco de
dados agora, com a possível despesa de uma
recuperação, demorando mais tempo. Como
as falhas em sistemas corretamente
gerenciados raramente ocorrem, é uma
maneira barata de obter algum desempenho.
No entanto, não é como se a Oracle deixasse
blocos sujos por toda parte sem limpar
depois de si.
Block write triggers
O que desencadeia um bloco de escrita e,
portanto, um bloco sujo?
✓ O banco de dados é emitido um comando
de desligamento.
✓ Ocorre um checkpoint total ou parcial - é
quando o sistema despeja periodicamente

✓ A recovery time threshold, set by you, is met;
the total number of dirty blocks causes an
unacceptable recovery time.
✓ A free block is needed and none are found
after a given amount of searching.
✓ Certain data definition language (DDL)
commands. (DDL commands are
SQL statements that define objects in a
database. You find out more about DDL in
Chapter 6.)
✓ Every three seconds.
✓ Other reasons. The algorithm is complex, and
we can’t be certain with all the changes that
occur with each software release.
The fact is the database stays pretty busy writing
blocks in an environment where there are a lot
changes.
Redo log buffer
The redo log buffer is another memory
component that protects you from yourself, bad
luck, and Mother Nature. This buffer records
every SQL statement that changes data. The
statement itself and any information required to
reconstruct it is called a redo entry. Redo entries
hang out here temporarily before being
recorded on disk. This buffer protects against
the loss of dirty blocks.
Dirty blocks aren’t written to disk constantly.
Imagine that you have a buffer cache of 1,000
blocks, and 100 of them are dirty. Then imagine
a power supply goes belly up in your server, and
the whole system comes crashing down without
any dirty buffers being written. That data is all
lost, right? Not so fast. . . .
The redo log buffer is flushed when these things
occur:
todos os buffers sujos no disco.
✓ Um limite de tempo de recuperação,
definido por você, é cumprido; o número
total de blocos sujos causa um tempo de
recuperação inaceitável.
✓ É necessário um bloco free e nenhum é
encontrado após uma determinada
quantidade de busca.
✓ Certos comandos de linguagem de
definição de dados (DDL). (Comandos DDL
são Instruções SQL que definem objetos em
um banco de dados. Você descobre mais
sobre DDL no Capítulo 6.)
✓ A cada três segundos.
✓ Outros motivos. O algoritmo é complexo e
não podemos ter certeza de todas as
mudanças que ocorrem com cada versão de
software.
O fato é que o banco de dados permanece
bastante ocupado escrevendo blocos em um
ambiente onde há muitas mudanças.
Redo log buffer
O Redo log buffer é outro componente de
memória que o protege de você, má sorte e
Mãe Natureza. Este buffer registra cada
declaração SQL que muda dados. A
declaração em si e qualquer informação
necessária para reconstruí-la é chamada de
entrada redo. Entradas de Redo param aqui
temporariamente antes de serem gravado no
disco. Este buffer protege contra a perda de
blocos sujos.
Os blocos sujos não são escritos no disco
constantemente.
Imagine que você tenha um buffer buffer de
1.000 blocos, e 100 deles estão sujos. Então,
imagine que uma fonte de energia vá para o
seu servidor, e todo o sistema vem se
derrubando sem que sejam armazenados
buffers sujos. Esses dados estão todos
perdidos, certo? Não tão rápido. . . .
✓ Every time there’s a commit to data in the
database
✓ Every three seconds
✓ When the redo buffer is 1/3 full
✓ Just before each dirty block is written to disk
Why does Oracle bother maintaining this whole
redo buffer thingy when instead, it could just
write the dirty buffers to disk for every commit?
It seems redundant.
✓ The file that records this information is
sequential. Oracle always writes to the end of
the file. It doesn’t have to look up where to put
the data. It just records the redo entry. A block
exists somewhere in a file. Oracle has to find out
where, go to that spot, and record it. Redo
buffer writes are very quick in terms of I/O.
✓ One small SQL statement could modify
thousands or more database blocks. It’s much
quicker to record that statement than wait for
the I/O of thousands of blocks. The redo entry
takes a split second to write, which reduces the
window of opportunity for failure. It also returns
your commit only if the write is successful. You
know right away that your changes are safe. In
the event of failure, the redo entry might have
to be re-executed during recovery, but at least it
isn’t lost.
Large pool
We’re not referring to the size of your
neighbor’s swimming pool. Not everyone uses
the optional large pool component. The large
pool relieves the shared pool of sometimes-
transient memory requirements.
These features use the large pool:
O buffer de registro redo é liberado quando
essas coisas ocorrem:
✓ Sempre que houver um commit de dados
no banco de dados
✓ A cada três segundos
✓ Quando o buffer redo está 1/3 cheio
✓ Antes de cada bloco sujo ser gravado no
disco
Por que a Oracle incomoda manter essa coisa
de refino total quando, em vez disso, poderia
apenas escrever os buffers sujos no disco
para cada commit? Parece redundante.
✓ O arquivo que registra esta informação é
seqüencial. O Oracle sempre escreve até o
final do arquivo. Não é necessário procurar
onde colocar os dados. Apenas registra a
entrada de refazer. Um bloco existe em
algum lugar em um arquivo. A Oracle tem
que descobrir onde, ir para esse ponto e
gravá-lo. As gravações do buffer Redo são
muito rápidas em termos de E / S.
✓ Uma pequena instrução SQL pode
modificar milhares ou mais blocos de banco
de dados. É muito mais rápido registrar essa
afirmação do que esperar pela E / S de
milhares de blocos. A entrada de refazer leva
uma fração de segundo a escrever, o que
reduz a janela de oportunidade por falha. Ele
também retorna seu commit somente se a
gravação for bem-sucedida. Você sabe
imediatamente que suas mudanças são
seguras. Em caso de falha, a entrada de reto
pode ter que ser re-executada durante a
recuperação, mas pelo menos não é perdida.
Large pool
Não nos referimos ao tamanho da piscina do
seu vizinho. Nem todos usam o componente
de pool grande opcional. A grande piscina
alivia o compartilhamento de requisitos de
memória às vezes transientes.
Esses recursos usam o grande pool:
✓ Oracle Recovery Manager
✓ Oracle Shared Server
✓ Parallel processing
✓ I/O-related server processes
Because many of these activities aren’t constant
and allocate memory only when they’re running,
it’s more efficient to let them execute in their
own space.
Without a large pool configured, these processes
steal memory from the shared pool’s SQL area.
That can result in poor SQL processing and
constant resizing of the SQL area of the shared
pool. Note: The large pool has no LRU. Once it
fills up (if you size it too small) the processes
revert to their old behavior of stealing memory
from the shared pool.
Java pool
The Java pool isn’t a swimming pool filled with
coffee (Okay, we’re cutting off the pool
references.) The Java pool is an optional
memory component.
Starting in Oracle 8i, the database ships with its
own Java Virtual Machine (JVM), which can
execute Java code out of the SGA. In our
experience, this configuration is relatively rare.
In fact, we see this where Oracle-specific tools
are installed.
However, don’t let that discourage you from
developing your own Java-based Oracle
applications. The fact is, even though Oracle has
its own Java container, many other worthwhile
competing alternatives are out there.
Streams pool
The streams pool is used only if you’re using
Oracle Streams functionality. Oracle Streams is
an optional data replication technology where
✓ Oracle Recovery Manager
✓ Oracle Shared Server
✓ Processamento paralelo
✓ Processos de servidor relacionados à E / S
Como muitas dessas atividades não são
constantes e alocam memória somente
quando estão sendo executadas, é mais
eficiente deixá-las executar em seu próprio
espaço.
Sem um grande pool configurado, esses
processos roubam a memória da área SQL do
pool compartilhado. Isso pode resultar em
um processamento SQL incorreto e um
redimensionamento constante da área SQL
do pool compartilhado. Nota: O grande grupo
não tem LRU. Uma vez que ele se enche (se o
tamanho for muito pequeno), os processos
retornam ao seu antigo comportamento de
roubar memória do pool compartilhado.
Java pool
O pool de Java não é uma piscina cheia de
café (Ok, estamos cortando as referências do
pool.) O pool de Java é um componente de
memória opcional.
Começando no Oracle 8i, o banco de dados é
fornecido com sua própria Java Virtual
Machine (JVM), que pode executar o código
Java fora do SGA. Na nossa experiência, esta
configuração é relativamente rara. Na
verdade, vemos isso onde as ferramentas
específicas do Oracle estão instaladas.
No entanto, não permita que isso o
desencoraje de desenvolver seus próprios
aplicativos Oracle baseados em Java. O fato é
que, mesmo que a Oracle tenha seu próprio
recipiente Java, muitas outras alternativas
concorrentes valiosas estão lá fora.
Streams pool
O pool de fluxos é usado somente se você
estiver usando a funcionalidade Oracle
Streams. O Oracle Streams é uma tecnologia
you replicate (reproduce) the same transactions,
data changes, or events from one database to
another (sometimes remote) database. You
would do this if you wanted the same data to
exist in two different databases. The streams
pool stores buffered queue messages and
provides the memory used to capture and apply
processes. By default, the value of this pool is
zero and increases dynamically if Oracle Streams
is in use.
Program Global Area
The Program Global Area (PGA) contains
information used for private or session-related
information that individual users need.
Again, PGA used to be allocated out of the
shared pool. In Oracle 9i, a memory structure
called the instance PGA held all private
information as needed. This alleviated the need
for the shared pool to constantly resize its SQL
area to meet the needs of individual sessions.
Because the amount of users constantly varies,
as do their private memory needs, the instance
PGA was designed for this type of memory
usage.
The PGA contains the following:
✓ Session memory
• Login information
• Information such as settings specific to a
session (for example, what format to use when
dates are displayed)
✓ Private SQL area
• Variables that might be assigned values during
SQL execution
• Work areas for processing specific internal SQL
actions: sorting, hash-joins, bitmap operations
• Cursors
opcional de replicação de dados onde você
replica (reproduz) as mesmas transações,
mudanças de dados ou eventos de um banco
de dados para outro (às vezes remoto). Você
faria isso se você quisesse que os mesmos
dados existissem em dois bancos de dados
diferentes. O pool de fluxos armazena
mensagens de fila armazenadas em buffer e
fornece a memória usada para capturar e
aplicar processos. Por padrão, o valor desse
pool é zero e aumenta dinamicamente se o
Oracle Streams estiver em uso.
Program Global Area
A Área Global do Programa (PGA) contém
informações usadas para informações
privadas ou relacionadas à sessão que os
usuários individuais precisam.
Novamente, a PGA costumava ser alocada
fora do pool compartilhado. No Oracle 9i,
uma estrutura de memória chamada PGA de
instância possuía todas as informações
privadas conforme necessário. Isso aliviou a
necessidade de o pool compartilhado
redimensionar constantemente sua área de
SQL para atender às necessidades de sessões
individuais. Como a quantidade de usuários
varia constantemente, assim como suas
necessidades de memória privada, a instância
PGA foi projetada para esse tipo de uso de
memória.
O PGA contém o seguinte:
✓ Memória de sessão
• Informações de login
• Informações como configurações
específicas de uma sessão (por exemplo, qual
formato usar quando datas são exibidas)
✓ Área de SQL Privada
• Variáveis que podem ser atribuídas valores
durante a execução do SQL
• Áreas de trabalho para processar ações
internas específicas de SQL: classificação,
hash-junções, operações de bitmap

Managing Memory
You have basically three ways to manage the
memory in your instance:
✓ Automatically by letting Oracle do all the
work
✓ Manually by tuning individual parameters for
the different memory areas
✓ Combination of automatic and manual by
using your knowledge of how things operate,
employing Oracle’s advice infrastructure, and
letting Oracle take over some areas
First, a quick note on Oracle automation.
Through the last several releases of Oracle, the
database has become more automated in areas
that were previously manual and even tedious
at times. This isn’t to say that soon it will take no
special skill to manage an Oracle database.
Exactly the opposite: When more mundane
operations are automated, it frees you up as the
DBA to focus on the more advanced features.
We’ve had great success implementing
automated features for clients. It frees up our
resources to focus on things such as high
availability and security, areas that require near
full-time attention. Thank goodness we don’t
have to spend hours watching what SQL
statements are aging out of the shared pool
prematurely, resulting in performance problems.
We recommend that you manage memory
automatically in Oracle 12c. For that reason, we
cover only automatic management in this
chapter.
Managing memory automatically
• Cursores
Managing Memory
Você basicamente tem três maneiras de
gerenciar a memória em sua instância:
✓ Automaticamente deixando a Oracle fazer
todo o trabalho
✓ Manualmente ajustando parâmetros
individuais para as diferentes áreas de
memória
✓ Combinação de automotivo e manual
usando seu conhecimento de como as coisas
funcionam, empregando a infraestrutura de
conselhos da Oracle e deixando a Oracle
assumir algumas áreas
Primeiro, uma nota rápida sobre a automação
Oracle. Através dos últimos vários
lançamentos da Oracle, o banco de dados
tornou-se mais automatizado em áreas que
eram anteriormente manuais e até tediosas
às vezes. Isso não quer dizer que, em breve,
não terá nenhuma habilidade especial para
gerenciar um banco de dados Oracle.
Exatamente o oposto: quando as operações
mais mundanas são automatizadas, elas
liberam você como o DBA para se concentrar
nos recursos mais avançados.
Tivemos um grande sucesso implementando
recursos automatizados para clientes. Isso
liberta nossos recursos para se concentrar em
coisas como alta disponibilidade e segurança,
áreas que exigem atenção quase a tempo
inteiro. Graças a Deus, não precisamos passar
horas assistindo o que as declarações de SQL
estão envelhecendo fora do pool
compartilhado prematuramente, resultando
em problemas de desempenho.
Recomendamos que você gerencie a
memória automaticamente no Oracle 12c.
Por esse motivo, cobrimos apenas o
gerenciamento automático neste capítulo.
Managing memory
automatically
When you create your database, you can set one
new parameter that takes nearly all memory
tuning out of your hands: MEMORY_TARGET. By
setting this parameter, all the memory areas
discussed earlier in this chapter are
automatically sized and managed. After you type
show parameter memory_target in SQL*Plus
(the SQL command-line interface available in
Oracle), you see this output on the screen:
NAME TYPE VALUE
------------------------------------ -----------
------------------------------
memory_target big integer 756M
Automatic memory management lets you take
hold of the amount of memory on the system
and then decide how much you want to use for
the database.
It’s never obvious what value you should choose
as a starting point. Answer these questions to
help set the value:
✓ How much memory is available?
✓ How many databases will ultimately be on the
machine?
✓ How many users will be on the machine? (If
many, we allocate 4MB per user for process
overhead.)
✓ What other applications are running on the
machine?
Before the users get on the machine, consider
taking no more than 40 percent of the memory
for Oracle databases. Use this formula:
(GB of memory × .40) / Number of Eventual
Databases = GB for MEMORY_TARGET per
database
For example, if your machine had 8GB of
memory and will ultimately house two
databases similar in nature and only 100 users
each, we would have this equation: (8 × .40) / 2
= 1.6GB for MEMORY_TARGET per database.
Quando você cria seu banco de dados, você
pode definir um novo parâmetro que leva
quase todas as configurações de memória de
suas mãos: MEMORY_TARGET. Ao definir
este parâmetro, todas as áreas de memória
discutidas anteriormente neste capítulo são
automaticamente dimensionadas e
gerenciadas. Depois de digitar show
parameter memory_target no SQL * Plus (a
interface de linha de comando SQL disponível
no Oracle), você vê esta saída na tela:
VALOR DE NOME TIPO
------------------------------------ ----------- ---
---------------------------
memory_target inteiro inteiro 756M
O gerenciamento automático de memória
permite que você segure a quantidade de
memória no sistema e depois decida quanto
você deseja usar para o banco de dados.
Nunca é óbvio qual o valor que você deve
escolher como ponto de partida. Responda
estas perguntas para ajudar a definir o valor:
✓ Quanta memória está disponível?
✓ Quantas bases de dados estarão na
máquina?
✓ Quantos usuários estarão na máquina? (Se
muitos, alocamos 4MB por usuário para
despesas gerais de processo).
✓ Que outros aplicativos estão executando
na máquina?
Antes que os usuários entrem na máquina,
considere levar mais de 40% da memória
para bancos de dados Oracle. Use esta
fórmula:
(GB de memória × .40) / Número de Eventual
Databases = GB para MEMORY_TARGET por
base de dados
Por exemplo, se sua máquina possuísse 8GB
de memória e, em última análise, abrirá dois

To help determine whether you have enough
memory, Oracle gives you some pointers if you
know where to look. It’s called the Memory
Target Advisor. Find it from the command line in
the form of the view
V$MEMORY_TARGET_ADVICE. As seen in Figure
2-1, find it in the Database Control home page
by clicking Advisor Central➪Memory
Advisors➪Advice. 30
Whatever you choose for the MEMORY_TARGET
setting isn’t all the memory Oracle uses. That’s
why you should have an idea of how many
sessions there will be before you make the final
determination.
For instance, this parameter covers only
memory used by the SGA and PGA.
Every single session that connects to the
database requires memory associated with its
OS or server process. This memory requirement
adds up. One
of our clients has nearly 3,000 simultaneous
connections eating up about 16GB of memory
outside the SGA and PGA. The client’s machine
has 64GB of memory, and the MEMORY_TARGET
is set at 16GB.
Following the Oracle Processes
When you start and initiate connections to the
Oracle instance, many processes are involved,
including
✓ The component of the Oracle instance that
uses the Oracle programs
✓ Code to gain access to your data
There are no processes when the Oracle instance
is shut down. Some of the processes are
mandatory, and others are optional depending
bancos de dados de natureza similar e apenas
100 usuários cada, teríamos esta equação: (8
× .40) / 2 = 1.6GB para MEMORY_TARGET por
banco de dados.
Para ajudar a determinar se você tem
memória suficiente, a Oracle fornece alguns
ponteiros se você souber onde procurar. É
chamado de 'Memory Target Advisor'.
Localize-o a partir da linha de comando na
forma da exibição V $
MEMORY_TARGET_ADVICE. Conforme visto
na Figura 2-1, encontre-o na página inicial do
Banco de Dados de Banco de Dados clicando
em Advisor Central➪Memory
Advisors➪Advice. 30
O que você escolher para a configuração
MEMORY_TARGET não é toda a memória que
a Oracle usa. É por isso que você deve ter
uma idéia de quantas sessões haverá antes
de fazer a determinação final.
Por exemplo, esse parâmetro cobre apenas a
memória usada pelo SGA e PGA.
Cada sessão única que se conecta ao banco
de dados requer memória associada ao seu
sistema operacional ou processo do servidor.
Este requisito de memória se acrescenta. 1
dos nossos clientes tem quase 3.000
conexões simultâneas consumindo cerca de
16GB de memória fora do SGA e PGA. A
máquina do cliente possui 64 GB de memória
e o MEMORY_TARGET está configurado em
16 GB.
Following the Oracle Processes
Quando você inicia e inicia conexões com a
instância Oracle, muitos processos estão
envolvidos, incluindo
✓ O componente da instância Oracle que usa
os programas Oracle
✓ Código para obter acesso aos seus dados
Não há processos quando a instância Oracle
está desligada. Alguns dos processos são
obrigatórios e outros são opcionais
on the features you’ve enabled. It can also
depend on your OS.
Three types of processes are part of the
instance:
✓ Background processes are involved in running
the Oracle software itself.
✓ Server processes negotiate the actions of the
users.
✓ User processes commonly work outside the
database server itself to run the application that
accesses the database.
Background processes
In Oracle 12c, you can have over 200 background
processes. We say “over 200” because it varies
by operating system. If this sounds like a lot,
don’t be scared. Many are multiples of the same
process (for parallelism and taking advantage of
systems with multiple CPUs). Table 2-1 shows
the most common background processes.
By default, no processes have more than one
instance of their type started. More advanced
tuning features involve parallelism. To see a
complete list of all the background processes on
your OS, query V$BGPROCESS.
Other background processes exist, as you can
tell by the “over 200” number we stated at the
beginning of this section. However, those
described in Table 2-1 are the most common,
and you will find them on almost all Oracle
installations. When you engage some of Oracle’s
more advanced functionality, you’ll see other
processes.
It’s very easy to see these background processes
if you have an Oracle installation available on
Linux or UNIX. In Figure 2-2, the ps –ef|grep ora_
portion lists the background processes. This
situation works very well because all
background processes begin with ora_.
dependendo dos recursos que você ativou.
Também pode depender do seu sistema
operacional.
Três tipos de processos fazem parte da
instância:
✓ Os processos em segundo plano estão
envolvidos na execução do próprio software
Oracle.
✓ Os processos do servidor negociam as
ações dos usuários.
✓ Os processos do usuário geralmente
funcionam fora do próprio servidor de banco
de dados para executar o aplicativo que
acessa o banco de dados.
Background processes
No Oracle 12c, você pode ter mais de 200
processos em segundo plano. Nós dizemos
'mais de 200' porque ele varia de acordo com
o sistema operacional. Se isso soar muito, não
tenha medo. Muitos são múltiplos do mesmo
processo (para paralelismo e aproveitando
sistemas com várias CPUs). A Tabela 2-1
mostra os processos de fundo mais comuns.
Por padrão, nenhum processo tem mais de
uma instância do tipo iniciada. As
características de afinação mais avançadas
envolvem paralelismo. Para ver uma lista
completa de todos os processos em segundo
plano do sistema operacional, consulte V $
BGPROCESS.
Existem outros processos em segundo plano,
como você pode dizer pelo número 'mais de
200' que declaramos no início desta seção.
No entanto, os descritos na Tabela 2-1 são os
mais comuns, e você os encontrará em quase
todas as instalações Oracle. Quando você
envolve algumas das funcionalidades mais
avançadas da Oracle,Você verá outros
processos.
É muito fácil ver esses processos em segundo
plano se você tiver uma instalação Oracle
disponível em Linux ou UNIX. Na Figura 2-2, a
porção ps -ef | grep ora_ lista os processos

Table 2-1 Common Background Processes
PMON The process monitor manages the
system’s server processes. It cleans up failed
processes by releasing resources and rolling back
uncommitted data.
SMON The system monitor is primarily
responsible for instance recovery. If the
database crashes and redo information must be
read and applied, the SMON takes care of it. It
also cleans and releases temporary space.
DBWn The database writer’s sole job is taking
dirty blocks from the dirty list and writing them
to disk. There can be up to 20 of them, hence the
n. It starts as DBW0 and continues with DBW1,
DBW2, and so on. After DBW9, it continues with
DBWa through DBWj. An average system won’t
see more than a few of these.
LGWR The log writer process flushes the redo log
buffer. It writes the redo entries to disk and
signals a completion.
CKPT The checkpoint process is responsible for
initiating check points. A check point is when the
system periodically dumps all the dirty buffers to
disk. Most commonly, this occurs when the
database receives a shutdown command. It also
updates the data file headers and the control
files with the check point information so the
SMON know where to start recovery in the
event of a system crash.
ARCn Up to 30 archiver processes (0–9, a–t) are
responsible for copying filled redo logs to the
archived redo storage area. If your database
isn’t running in archive mode, this process shuts
down.
CJQ0 The job queue coordinator checks for
scheduled tasks within the database. These jobs
can be set up by the user or can be internal jobs
for maintenance. When it finds a job that must
be run it spawns the following goodie.
J000 A job queue process slave actually runs the
em segundo plano. Esta situação funciona
muito bem porque todos os processos em
segundo plano começam com ora_.
Tabela 2-1 Processos de fundo comuns
PMON O monitor de processo gerencia os
processos do servidor do sistema. Ele limpa
os processos falhados, liberando recursos e
rolando dados não confirmados.
SMON O monitor do sistema é o principal
responsável pela recuperação da instância. Se
o banco de dados falhar e refazer
informações devem ser lidos e aplicados, o
SMON cuida disso. Ele também limpa e libera
espaço temporário.
DBWn O único trabalho do escritor de banco
de dados é tirar blocos sujos da lista suja e
gravá-los no disco. Pode haver até 20 deles,
daí o n. Ele começa como DBW0 e continua
com DBW1, DBW2 e assim por diante. Após o
DBW9, continua com o DBWa através do
DBWj. Um sistema médio não verá mais do
que alguns desses.
LGWR O processo do registro de registro
acalma o buffer de log de retomada. Ele grava
as entradas de refazer no disco e sinaliza uma
conclusão.
CKPT O processo de ponto de verificação é
responsável por iniciar pontos de verificação.
Um ponto de verificação é quando o sistema
despeja periodicamente todos os buffers
sujos no disco. Mais comumente, isso ocorre
quando o banco de dados recebe um
comando de desligamento. Ele também
atualiza os cabeçalhos dos arquivos de dados
e os arquivos de controle com as informações
do ponto de verificação para que o SMON
saiba por onde iniciar a recuperação em caso
de falha do sistema.
ARCn Até 30 processos de arquivamento (0-9,
a-t) são responsáveis por copiar logs redo
cheios na área de armazenamento redo
arquivado. Se o seu banco de dados não
estiver sendo executado no modo de arquivo,
esse processo será encerrado.
job. There can be up to 1,000 of them (000–999).
DIA0 The diagnosability process resolves
deadlock situations and investigates hanging
issues.
VKTM The virtual keeper of time sounds like a
fantasy game character but simply provides a
time reference within the database.
LREG The listener registration process, which
registers database instance and dispatcher
information with the Oracle listener process.
This allows incoming user connections to get
from the listener to the database.
MMON The manageablity monitor process
supports the Automatic
Workload Repository (AWR) by capturing
statistics, monitoring threasholds, and taking
snapshots. This is related to performance tuning
and troubleshooting.
MMNL The manageability monitor lite’s job is to
write Active Session History (ASH) statistics from
ASH buffer in the SGA to disk. This is related to
performance tuning and troubleshooting.
User and server processes
Because user and server processes are
intertwined, we discuss the two together.
However, they are distinct and separate
processes. As a matter of fact, they typically run
on separate machines. A very simple example:
When you start SQL*Plus on a Windows client,
CJQ0 O coordenador da fila de trabalho
verifica tarefas agendadas no banco de
dados. Esses trabalhos podem ser
configurados pelo usuário ou podem ser
tarefas internas para manutenção. Quando
ele encontra um trabalho que deve ser
executado, ele engendra o seguinte goodie.
J000 Um escravo de processo de fila de
trabalho executa o trabalho. Pode haver até
1.000 deles (000-999).
DIA0 O processo de diagnóstica resolve
situações de impasse e investiga problemas
suspensos.
VKTM O guardião virtual do tempo soa como
um personagem de jogo de fantasia, mas
simplesmente fornece uma referência de
tempo no banco de dados.
LREG O processo de registro do ouvinte, que
registra a instância do banco de dados e as
informações do expedidor com o processo
ouvinte Oracle. Isso permite que as conexões
de usuário recebidas passem do ouvinte para
o banco de dados.
MMON O processo do monitor de
gerenciamento suporta o Automático
Workload Repository (AWR), capturando
estatísticas, monitorando threasholds e
tirando instantâneos. Isso está relacionado ao
ajuste de desempenho e solução de
problemas.
MMNL O trabalho do gerenciável monitor lite
é escrever estatísticas do Histórico de Sessões
Ativas (ASH) a partir do buffer ASH no SGA
para o disco. Isso está relacionado ao ajuste
de desempenho e solução de problemas.
User and server processes
Como os processos do usuário e do servidor
estão entrelaçados, discutimos os dois juntos.
No entanto, eles são processos distintos e
separados. Na verdade, eles geralmente
correm em máquinas separadas. Um exemplo
muito simples:
you get a user process called sqlplus.exe. The
user process represents a user’s session in the
database.
When a connection is made to the database on a
Linux machine, you get a connection to a process
named something like oracle<database_name>
or
ora_S000_<database_name>.
The server process serves and exists on the
database server. It does anything the user
requests of it. It is responsible for reading blocks
into the buffer cache. It changes the blocks if
requested. It can create objects.
Server processes can be one of two types:
✓ Dedicated
✓ Shared
The type depends on how your application
operates and how much memory you have.
You’re first presented with the choice of
dedicated or shared when you create your
database with Oracle’s Database Configuration
Assistant (DBCA). However, you can change it
one way or the other later on.
Dedicated server architecture
Each user process gets its own server process.
This is the most common Oracle configuration. It
allows a server process to wait on you. If the
resources can support dedicated connections,
this method also is the most responsive.
However, it can also use the most memory. Even
if you’re not doing anything, that server process
is waiting for you.
Not that it’s a bad thing. Imagine, though, 5,000
users on the system sitting idle most of the time.
If your applications can’t use connection pools
(similar to shared server processes), your
database probably won’t survive and perform
Quando você inicia o SQL * Plus em um
cliente do Windows, você obtém um
processo do usuário chamado sqlplus.exe. O
processo do usuário representa a sessão de
um usuário no banco de dados.
Quando uma conexão é feita no banco de
dados em uma máquina Linux, você obtém
uma conexão com um processo denominado
como oracle <database_name> ou
ora_S000_ <database_name>.
O processo do servidor serve e existe no
servidor do banco de dados. Faz qualquer
coisa que o usuário solicite. É responsável por
ler blocos no cache do buffer. Ele muda os
blocos, se solicitado. Pode criar objetos.
Os processos do servidor podem ser um dos
dois tipos:
✓ Dedicado
✓ Partilhado
O tipo depende do funcionamento do seu
aplicativo e da quantidade de memória que
você possui. Você é apresentado pela
primeira vez com a opção de dedicado ou
compartilhado quando cria seu banco de
dados com o Assistente de Configuração de
Banco de Dados Oracle (DBCA). No entanto,
você pode mudar de um jeito ou outro mais
tarde.
Dedicated server architecture
Cada processo de usuário obtém seu próprio
processo de servidor. Esta é a configuração
Oracle mais comum. Ele permite que um
processo do servidor aguarde você. Se os
recursos podem suportar conexões
dedicadas, esse método também é o mais
responsivo. No entanto, ele também pode
usar a maioria das memórias. Mesmo que
você não esteja fazendo nada, esse processo
do servidor está esperando por você.
Não é que seja ruim. Imagine, no entanto,
5.000 usuários no sistema sentado ocioso na
maioria das vezes. Se seus aplicativos não
adequately for more than a day
Shared server architecture
Just as the name implies, the server processes
are shared. Now, instead of a server process
waiting on you hand and foot, you have only one
when you need it.
Think of a server process as a timeshare for
Oracle. It’s more cost-effective (in terms of
memory), and you almost always have one
available when you need it (provided the
infrastructure is properly configured).
On a system with 5,000 mostly idle users, you
might be able to support them with only 50
server processes. You must do these things for
this to work properly:
✓ Make sure the number of concurrent
database requests never exceeds the number of
shared servers configured.
✓ Make sure users don’t hold on to the
processes for long periods. This works best in a
fast transaction-based environment like an e-
commerce site.
✓ Have a few extra CPU cycles available. All the
interprocess communication seems to have
small CPU cost associated with it over dedicated
server processes.
The fact is shared server configurations are less
common in today’s environment where memory
is cheap. Most applications these days get
around the problems associated with too many
dedicated servers by using advanced connection
pooling on the application server level.
You should know about some other limitations:
DBA connections must have a dedicated server.
Therefore, a shared server environment is
actually a hybrid. Shared servers can coexist
with a dedicated server.
Many different types of files are required (and
podem usar pools de conexão (semelhantes
aos processos do servidor compartilhado),
seu banco de dados provavelmente não
sobreviverá e executará adequadamente por
mais de um dia
Shared server architecture
Assim como o nome indica, os processos do
servidor são compartilhados. Agora, em vez
de um processo de servidor esperando por
você mão e pé, você tem apenas um quando
você precisar.
Pense em um processo de servidor como um
timeshare para Oracle. É mais econômico (em
termos de memória), e você quase sempre
possui um disponível quando você precisar
(desde que a infra-estrutura esteja
configurada corretamente).
Em um sistema com 5.000 usuários na maior
parte ociosos, você pode suportá-los com
apenas 50 processos de servidor. Você deve
fazer essas coisas para que isso funcione
corretamente:
✓ Certifique-se de que o número de
solicitações de banco de dados concorrentes
nunca exceda o número de servidores
compartilhados configurados.
✓ Certifique-se de que os usuários não se
apeguem aos processos por longos períodos.
Isso funciona melhor em um ambiente rápido
baseado em transações, como um site de
comércio eletrônico.
✓ Tenha alguns ciclos adicionais de CPU
disponíveis. Toda a comunicação de
interprocesso parece ter um pequeno custo
de CPU associado a isso em processos de
servidor dedicados.
O fato é que as configurações do servidor
compartilhado são menos comuns no
ambiente atual onde a memória é barata. A
maioria dos aplicativos atualmente contorna
os problemas associados a muitos servidores
dedicados usando o pool de conexão
avançado no nível do servidor da aplicação.
optional) to run an Oracle database:
✓ Data files
✓ Control files
✓ Redo log files
✓ Archive log files
✓ Server and initialization parameter files
Knowing what each of these files does greatly
increases your database management success.
Getting Physical with Files
Many types of files are created with your
database. Some of these files are for storing raw
data. Some are used for recovery. Some are
used for housekeeping or maintenance of the
database itself. In the next few sections, we take
a look at the various file types and what they’re
responsible for storing.
Data files: Where the data meets
the disk
Data files are the largest file types in an Oracle
database. They store all the actual data you put
into your database as well as the data Oracle
requires to manage the database. Data files are
a physical structure: They exist whether the
database is open or closed.
Data files are also binary in nature. You can’t
read them yourself without starting an instance
and executing queries. The data is stored in an
organized format broken up into Oracle blocks.
Você deve saber sobre algumas outras
limitações: as conexões DBA devem ter um
servidor dedicado. Portanto, um ambiente de
servidor compartilhado é realmente um
híbrido. Servidores compartilhados podem
coexistir com um servidor dedicado.
Muitos tipos diferentes de arquivos são
necessários (e opcional) para executar um
banco de dados Oracle:
✓ Arquivos de dados
✓ Arquivos de controle
✓ Refazer arquivos de log
✓ Arquivar arquivos de log
✓ Servidor e arquivos de parâmetros de
inicialização
Sabendo o que cada um desses arquivos
aumenta consideravelmente seu sucesso em
gerenciamento de banco de dados.
Getting Physical with Files
Muitos tipos de arquivos são criados com seu
banco de dados. Alguns desses arquivos são
para armazenar dados brutos. Alguns são
usados para recuperação. Alguns são usados
para limpeza ou manutenção do próprio
banco de dados. Nas próximas seções,
examinamos os vários tipos de arquivos e o
que eles são responsáveis pelo
armazenamento.
Data files: Where the data
meets the disk
Os arquivos de dados são os maiores tipos de
arquivos em um banco de dados Oracle. Eles
armazenam todos os dados reais que você
colocou em seu banco de dados, bem como
os dados que a Oracle precisa para gerenciar
o banco de dados. Os arquivos de dados são
uma estrutura física: eles existem se o banco
de dados está aberto ou fechado.
Os arquivos de dados também são de
natureza binária. Você não pode lê-lo sozinho
sem iniciar uma instância e executar
Whenever a server process reads from a data
file, it does so by reading at the very least one
complete block. It puts that block into the buffer
cache so that data can be accessed, modified,
and so on.
It’s also worth noting that the data file is
physically created using OS blocks.
OS blocks are different from Oracle blocks. OS
blocks are physical, and their size is determined
when you initially format the hard drive.
You should know the size of your OS block.
Make sure that it’s equal to, or evenly divisible
into, your Oracle block.
Most of the time Oracle data files have an
extension of .DBF (short for database file). But
the fact of the matter is that file extensions in
Oracle don’t matter. You could name it .XYZ, and
it would function just fine.
We feel it is best practice to stick with .DBF
because that extension is used in 95 percent of
databases.In every data file, the very first block
stores the block header. To be specific,
depending on your Oracle block size, the data
file header block may be several blocks. By
default, the header block is 64k. Therefore, if
your Oracle
block size is 4k, then 16 header blocks are at the
beginning of the file. These header blocks are for
managing the data file’s internal workings. They
contain
✓ Backup and recovery information
✓ Free space information
✓ File status details
Lastly, a tempfile is a special type of database
file. Physically, it’s just like a regular data file,
but it holds only temporary information. For
example, a tempfile is used if you perform sorts
on disk or if you’re using temporary tables. The
space is then freed to the file either immediately
after your operation is done or as soon as you
log out of the system.
consultas. Os dados são armazenados em um
formato organizado dividido em blocos
Oracle.
Sempre que um processo do servidor lê a
partir de um arquivo de dados, ele faz isso
lendo pelo menos um bloco completo. Ele
coloca esse bloco no buffer buffer para que
os dados possam ser acessados, modificados
e assim por diante.
Também vale a pena notar que o arquivo de
dados é fisicamente criado usando blocos de
sistema operacional.
Os blocos do sistema operacional são
diferentes dos blocos Oracle. Os blocos do
sistema operacional são físicos, e seu
tamanho é determinado quando você
inicializa o disco rígido.
Você deve saber o tamanho do seu bloco de
sistema operacional. Certifique-se de que é
igual ou facilmente divisível no seu bloco
Oracle.
Na maioria das vezes, os arquivos de dados
Oracle possuem uma extensão de .DBF
(abreviação de arquivo de banco de dados).
Mas o fato é que as extensões de arquivos na
Oracle não são importantes. Você poderia
nomeá-lo .XYZ, e funcionaria bem.
Nós sentimos que é melhor prática ficar
com .DBF porque essa extensão é usada em
95 por cento dos bancos de dados. Em cada
arquivo de dados, o primeiro bloco armazena
o cabeçalho do bloco. Para ser específico,
Dependendo do seu tamanho de bloco
Oracle, o bloco de cabeçalho do arquivo de
dados pode ser vários blocos. Por padrão, o
bloco de cabeçalho é 64k. Portanto, se o seu
Oracle
O tamanho do bloco é 4k, então 16 blocos de
cabeçalho estão no início do arquivo. Esses
blocos de cabeçalho são para gerenciar o
funcionamento interno do arquivo de dados.
Eles contém
✓ Informações de backup e recuperação
Figure 2-3 shows that by executing a simple
query against V$TEMPFILE and V$DATAFILE you
can see a listing of the data files in your
database.
Control files
The control file is a very important file in the
database — so important that you have several
copies of it. These copies are placed so that
losing a disk on your system doesn’t result in
losing all of your control files.
Typically, control files are named with the
extension .CTL or .CON. Any extension will work,
but if you want to follow best practice, those
two are the most popular.
Control files contain the following information:
✓ Names and locations of your data files and
redo log files
✓ Recovery information
✓ Backup information
✓ Checkpoint information
✓ Archiving information
✓ Database name
✓ Log history
✓ Current logging information
✓ Informações de espaço livre
✓ Detalhes do status do arquivo
Por fim, um tempfile é um tipo especial de
arquivo de banco de dados. Fisicamente, é
como um arquivo de dados regular, mas
possui apenas informações temporárias. Por
exemplo, um tempfile é usado se você
executar tipos no disco ou se estiver usando
tabelas temporárias. O espaço é então
liberado no arquivo imediatamente após a
sua operação estar concluída ou assim que
você desconectar o sistema.
A Figura 2-3 mostra que, executando uma
consulta simples contra V $ TEMPFILE e V $
DATAFILE, você pode ver uma listagem dos
arquivos de dados em seu banco de dados.
Control files
O arquivo de controle é um arquivo muito
importante no banco de dados - tão
importante que você tenha várias cópias
dele. Essas cópias são colocadas para que
perder um disco no seu sistema não resulte
em perder todos os seus arquivos de
controle.
Normalmente, os arquivos de controle são
nomeados com a extensão .CTL ou .CON.
Qualquer extensão funcionará, mas se você
quiser seguir as melhores práticas, esses dois
são os mais populares.
Os arquivos de controle contêm as seguintes
informações:
✓ Nomes e locais de seus arquivos de dados
e refazer arquivos de log
✓ Informação de recuperação
✓ Informações de backup
✓ Informações do ponto de verificação
✓ Arquivamento de informações
✓ Nome do banco de dados
Control files contain a host of other internal
information as well. Typically,
control files are some of the smaller files in the
database. It’s difficult to tell you how big they
are because it varies depending on the
following:
✓ How many files your database has
✓ How much backup information you’re storing
in them
✓ What OS you’re using 38 Part I: Getting
Started with Oracle 12c
As mentioned earlier, it’s important that you
have several copies of your control files. If you
were to lose all of your control files in an
unfortunate failure, it is a real pain to fix.
Redo log files
Redo log files store the information from the log
buffer. They’re written to by the Log Writer
(LGWR). Again, you can’t read these binary files
without the help of the database software.
Typically, redo log files are named with the
extension .LOG or .RDO. It can be anything you
want, but best practice indicates one of those
two extensions.
Also, redo log files are organized into groups and
members. Every database must have at least
two redo log groups.
Redo log files contain all the information
necessary to recover lost data in your database.
Every SQL statement that you issue changing
data can be
✓ Histórico de logs
✓ Informação de registro atual
Os arquivos de controle também possuem
uma série de outras informações internas.
Tipicamente,
arquivos de controle são alguns dos arquivos
menores no banco de dados. É difícil dizer-lhe
o quão grande eles são porque varia de
acordo com o seguinte:
✓ Quantos arquivos seu banco de dados
tem?
✓ Quanta informação de backup você está
armazenando neles
✓ O sistema operacional que você está
usando 38 Parte I: Primeiros passos com o
Oracle 12c
Como mencionado anteriormente, é
importante que você tenha várias cópias de
seus arquivos de controle. Se você perdesse
todos os seus arquivos de controle em uma
falha infeliz, é uma verdadeira dificuldade
para consertar.
Redo log files
Redo log files armazena as informações do
buffer de log. Eles são escritos pelo Log
Writer (LGWR). Mais uma vez, você não pode
ler esses arquivos binários sem a ajuda do
software de banco de dados.
Normalmente, os arquivos de reto de log são
nomeados com a extensão .LOG ou .RDO.
Pode ser tudo o que quiser, mas as melhores
práticas indicam uma dessas duas extensões.
Além disso, refazer arquivos de log estão
organizados em grupos e membros. Todo
banco de dados deve ter pelo menos dois
grupos de log redo.
Redo log contém todas as informações
necessárias para recuperar dados perdidos
reconstructed by the information saved in these
files.
Redo log files don’t record select statements. If
you forget what you selected, you’re just going
to have to remember that on your own!
The optimal size for your redo log files depends
on how many changes you make to your
database. The size is chosen by you when you
set up the database and can be adjusted later.
When the LGWR is writing to a redo log file, it
does so sequentially. It starts at the beginning of
the file and once it is filled up, it moves on to the
next one. This is where the concept of groups
comes in.
Oracle fills each group and moves to the next.
Once it has filled all the groups, it goes back to
the first. You could say they are written to in a
circular fashion.
If you have three groups, it would go something
like 1,2,3,1,2,3, . . . and so on.
Each time a group fills and the writing switches,
it’s called a log switch operation.
These things happen during a log switch
operation:
✓ The LGWR finishes writing to the current
group.
✓ The LGWR starts writing to the next group.
✓ A database check point occurs.
✓ The DBWR writes dirty blocks out of the
buffer cascade.
How fast each group fills up is how you
determine its size. By looking at all the things
that occur when a log switch happens, you might
agree that it is a fairly involved operation. For
this reason, you don’t want frequent log
switches.
The general rule is that you don’t want to switch
log files more often than every 15–30 minutes. If
you find that happening, consider increasing the
size of each group.
em seu banco de dados. Toda declaração SQL
que você emite a alteração de dados pode ser
reconstruído pelas informações guardadas
nestes arquivos.
Redirecionar arquivos de log não gravar
instruções selecionadas. Se você esquecer o
que você selecionou, você só vai ter que se
lembrar disso sozinho!
O tamanho ideal para seus arquivos de log de
redo depende de quantas mudanças você faz
no seu banco de dados. O tamanho é
escolhido por você quando você configura o
banco de dados e pode ser ajustado
posteriormente. Quando o LGWR está
escrevendo para um arquivo de log de
refazer, ele faz isso de forma sequencial.
Começa no início do arquivo e, uma vez que é
preenchido, ele passa para o próximo. É aqui
que entra o conceito de grupos.
O Oracle enche cada grupo e passa para o
próximo. Uma vez preenchido todos os
grupos, ele volta ao primeiro. Você poderia
dizer que eles estão escritos de forma
circular.
Se você tiver três grupos, seria algo como
1,2,3,1,2,3,. . . e assim por diante.
Cada vez que um grupo preenche e a escrita
muda, é chamada de operação de troca de
log.
Essas coisas acontecem durante uma
operação de troca de log:
✓ O LGWR termina a gravação para o grupo
atual.
✓ O LGWR começa a escrever para o próximo
grupo.
✓ Ocorre um ponto de verificação do banco
de dados.
✓ O DBWR escreve blocos sujos da cascata
do buffer.
Quão rápido cada grupo preenche é como
você determina seu tamanho. Ao olhar para

Because these redo log files may be involved in
recovery operations, don’t lose them. Similar to
control files, redo log files should be configured
with mirrored copies of one another. And, as
with control files, each member should be on a
separate disk device. That way, if a disk fails and
the database goes down, you still have recovery
information available. You should not lose any
data.
Each copy within a group is called a member. A
common configuration might be three groups
with two members apiece, for a total of six redo
log files. The group members are written to
simultaneously by the log writer.
✓ How many groups are appropriate? The most
common configuration we come across is three.
You want enough that the first group in the list
can be copied off and saved before the LGWR
comes back around to use it. If it hasn’t been
copied off, the LGWR has to wait until that
operation is complete. This can severely impact
your system. Thankfully, we rarely see this
happen.
✓ How many members are appropriate? It
depends on how paranoid you are. Two
members on two disks seems to be pretty
common. However, it isn’t uncommon to see
three members on three disks. More than that
and you’re just plain crazy. Well, not really. It’s
just that the more members
you have, the more work the LGWR has to do. It
can impact system performance while at the
same time offering very little return. We
commonly get this question: “If my disks are
mirrored at the hardware level, do I need more
than one member on each group? After all, if a
disk fails, I have another one right there to pick
up the slack.”
Unfortunately, you get different answers
depending on who you ask. Ask us, and we’ll
recommend at least two members for each
group:
✓ Oracle still recommends two members for
each group as a best practice.
todas as coisas que ocorrem quando ocorre
uma mudança de log, você pode concordar
que é uma operação bastante envolvida. Por
esse motivo, você não quer trocas de log
freqüentes.
A regra geral é que você não deseja alternar
arquivos de log com mais freqüência do que
15-30 minutos. Se você achar isso
acontecendo, considere aumentar o tamanho
de cada grupo.
Como esses arquivos de log de refazer podem
estar envolvidos em operações de
recuperação, não as perca. Semelhante aos
arquivos de controle, refazer arquivos de log
devem ser configurados com cópias
espelhadas entre si. E, como nos arquivos de
controle, cada membro deve estar em um
dispositivo de disco separado. Dessa forma,
se um disco falhar e o banco de dados desce,
você ainda possui informações de
recuperação disponíveis. Você não deve
perder nenhum dado.
Cada cópia dentro de um grupo é chamada
de membro. Uma configuração comum pode
ser três grupos com dois membros cada, para
um total de seis arquivos de log redo. Os
membros do grupo são escritos
simultaneamente pelo escritor do registro.
✓ Quantos grupos são apropriados? A
configuração mais comum que encontramos
é de três. Você quer o suficiente para que o
primeiro grupo da lista possa ser copiado e
salvo antes que o LGWR volte para usá-lo. Se
não foi copiado, o LGWR deve esperar até
que a operação esteja completa. Isso pode
afetar severamente seu sistema. Felizmente,
raramente vemos isso acontecer.
✓ Quantos membros são apropriados?
Depende de quão paranóico você é. Dois
membros em dois discos parecem ser
bastante comuns. No entanto, não é
incomum ver três membros em três discos.
Mais do que isso e você é simplesmente
louco. Bem, na verdade não. É só que os
membros mais

✓ Depending on how your hardware is set up,
you may have the same disk controller writing to
your disk mirrors. What if that controller writes
corrupt gibberish? Now both your copies are
corrupted. Separating your members across two
different disks with different controllers is the
safest bet.
Moving to the archives
Archive log files are simply copies of redo log
files. They’re no different from redo log files
except that they get a new name when they’re
created.
Most archive log files have the extension
.ARC, .ARCH, or .LOG. We try to use .ARC as that
seems most common.
Not all databases have archive log files. It
depends on whether you turn on archiving. By
turning on archiving, you can recover from
nearly any type of
failure providing two things:
✓ You have a full backup.
✓ You haven’t lost all copies of the redo or
archive logs.
There is a small amount of overhead with
você tem, quanto mais trabalho o LGWR tem
que fazer. Pode afetar o desempenho do
sistema e, ao mesmo tempo, oferecer muito
pouco retorno. Geralmente, obtemos esta
pergunta: 'Se meus discos estiverem
espelhados no nível de hardware, preciso de
mais de um membro em cada grupo? Afinal,
se um disco falhar, eu tenho outro aqui para
pegar a folga '.
Infelizmente, você obtém respostas
diferentes, dependendo de quem você
pergunta. Pergunte-nos e recomendamos
pelo menos dois membros para cada grupo:
✓ A Oracle ainda recomenda dois membros
para cada grupo como uma prática
recomendada.
✓ Dependendo de como seu hardware está
configurado, você pode ter o mesmo
controlador de disco que escreve nos seus
espelhos de disco. E se esse controlador
escrever gibberish corrupto? Agora, ambas as
cópias estão corrompidas. Separar seus
membros em dois discos diferentes com
diferentes controladores é a aposta mais
segura.
Moving to the archives
Os arquivos de log de arquivo são
simplesmente cópias de arquivos de log de
reimpressão. Eles não são diferentes dos
arquivos de log de refazer, exceto que eles
obtêm um novo nome quando eles são
criados.
A maioria dos arquivos de log de arquivo tem
a extensão .ARC, .ARCH ou .LOG. Tentamos
usar o .ARC como parece mais comum.
Nem todos os bancos de dados possuem
arquivos de log de arquivamento. Depende se
você ativar o arquivamento. Ao ativar o
arquivamento, você pode recuperar de quase
qualquer tipo de
Falha no fornecimento de duas coisas:
✓ Você tem um backup completo.
✓ Você não perdeu todas as cópias dos logs
database archiving:
✓ I/O cost: The ARCn process has to copy each
redo log group as it fills up.
✓ CPU cost: It takes extra processing to copy the
redo logs via the ARCn process.
✓ Storage cost: You have to keep all the archive
logs created between each backup.
Relatively speaking, each of these costs is small
in terms of the return you get: recovering your
database without so much as losing the dot over
an i.
We typically recommend that, across the board,
all production databases archive their redo logs.
Sometimes, archiving isn’t needed, such as in a
test database used for testing code. You can
easily just copy your production database to
revive a broken test. We’re not recommending
not archiving on test databases. Sometimes the
test database is important enough to archive.
We’re just saying that sometimes you can get by
without incurring the extra overhead.
You should keep archive log files for recovery
between each backup. Say you’re doing a
backup every Sunday. Now say that your
database loses files due to a disk failure on
Wednesday. The recovery process would be
restoring the lost files from the last backup and
then telling Oracle to apply the archive log files
from Sunday all the way up to the failure on
Wednesday. It’s called rolling forward, and we
talk about it in Chapter 8.
Like control files and redo log files, it’s best
practice to have more than one copy of each of
your archive log files. They should go to two
different destinations on different devices, just
like the others. You can’t skip over a lost archive
log.
redo ou archive.
Há uma pequena quantidade de despesas
gerais com arquivamento de banco de dados:
✓ Custo de I / O: o processo ARCn tem que
copiar cada grupo de registro de
reabastecimento conforme ele se enche.
✓ Custo da CPU: é necessário um
processamento extra para copiar os logs de
refazer através do processo ARCn.
✓ Custo de armazenamento: você deve
manter todos os registros de arquivo criados
entre cada backup.
Relativamente falando, cada um desses
custos é pequeno em termos do retorno que
você obtém: recuperando seu banco de
dados sem perder o ponto sobre um i.
Normalmente recomendamos que, em geral,
todos os bancos de dados de produção
arquivem seus logs redo.
Às vezes, o arquivamento não é necessário,
como em um banco de dados de teste usado
para testar o código. Você pode facilmente
copiar seu banco de dados de produção para
revivir um teste quebrado. Não
recomendamos não arquivar em bancos de
dados de teste. Às vezes, o banco de dados
de teste é suficientemente importante para
arquivar. Estamos apenas dizendo que às
vezes você pode passar sem incorrer nos
custos extras.
Você deve manter arquivos de registro de
arquivos para recuperação entre cada
backup. Diga que você está fazendo um
backup todos os domingos. Agora, diga que
seu banco de dados perde arquivos devido a
uma falha no disco na quarta-feira. O
processo de recuperação seria restaurar os
arquivos perdidos do último backup e, em
seguida, informar a Oracle para aplicar os
arquivos de registro de arquivos do domingo
até a falha na quarta-feira. É chamado de
avançar, e falamos sobre isso no Capítulo 8.

Server and initialization
parameter files
Server and initialization parameter files are the
smallest files on your system:
✓ PFILE, or parameter file, is a text version that
you can read and edit with a normal text editor.
✓ SPFILE, or server parameter file, is a binary
copy that you create for the database to use
after you make changes.
Typically, these files end with an .ORA
extension. Personally, we have never seen
anything but that. It’s best practice for you to
continue the tradition.
PFILEs and SPFILEs have information about how
your running database is configured. This is
where you configure the following settings:
✓ Memory size
✓ Database and instance name
✓ Archiving parameters
✓ Processes
✓ Over 1,900 other parameters
Wait, what was that? Over 1900 parameters to
configure and tweak? Don’t be frightened. The
fact is 99 percent of your database configuration
is done with about 30 of the main parameters.
The rest of the parameters are for uncommon
configurations that require more expert
adjustment. As a matter of fact, of those 1,900,
over 1,600 are hidden. Sorry if we scared you a
little there. We just want you to have the whole
picture.
Whenever you start your database, the very first
Como arquivos de controle e refazer arquivos
de log, é melhor prática ter mais de uma
cópia de cada um de seus arquivos de
registro de arquivo. Eles devem ir para dois
destinos diferentes em dispositivos
diferentes, assim como os outros. Você não
pode ignorar um registro de arquivo perdido.
Server and initialization
parameter files
Os arquivos de parâmetros de servidor e
inicialização são os arquivos mais pequenos
do seu sistema:
✓ PFILE, ou arquivo de parâmetro, é uma
versão de texto que você pode ler e editar
com um editor de texto normal.
✓ SPFILE, ou arquivo de parâmetro do
servidor, é uma cópia binária que você criou
para o banco de dados usar depois de fazer
alterações.
Normalmente, esses arquivos terminam com
uma extensão .ORA. Pessoalmente, nunca
vimos nada além disso. É a melhor prática
para você continuar a tradição.
PFILEs e SPFILEs têm informações sobre como
seu banco de dados em execução está
configurado. Aqui é onde você configura as
seguintes configurações:
✓ Tamanho da memória
✓ Nome do banco de dados e da instância
✓ Parâmetros de arquivamento
✓ Processos
✓ Mais de 1.900 outros parâmetros
Espere, o que foi isso? Mais de 1900
parâmetros para configurar e ajustar? Não
fique assustado. O fato é que 99 por cento da
sua configuração de banco de dados é feita
com cerca de 30 dos principais parâmetros. O
resto dos parâmetros são para configurações
incomuns que exigem mais ajuste
especializado. Na verdade, dos 1.900, mais de
file read is the parameter file. It sets up all your
memory and process settings and tells the
instance where the control files are located. It
also has information about your archiving status.
In Chapter 4, we cover how the PFILEs and
SPFILEs are located under the directory where
you installed the database software. This
directory is called the ORACLE_HOME:
✓ Linux/UNIX: $ORACLE_HOME/dbs
✓ Windows: %ORACLE_HOME%\database
It should have a specific naming structure. For
example, if your database name is dev12c, the
files would be named as follows:
✓ The PFILE would be called initdev12c.ora.
✓ The SPFILE would be called spfiledev12c.ora.
42 Part I: Getting Started with Oracle 12c
By naming them this way and putting them in
the appropriate directory, Oracle automatically
finds them when you start the database. Else,
you have to tell Oracle where they are every
time you start the database; that just isn’t
convenient.
We recommend you keep the PFILE and SPFILE
in the default locations with the default naming
convention for ease of administration.
Applying Some Logical Structures Applying Some Logical
Structures
After you know the physical structures, you can
break them into more logical structures. All the
logical structures that we talk about are in the
data files.
1.600 estão escondidos. Desculpe se tivemos
medo de você um pouco. Nós só queremos
que você tenha toda a imagem.
Sempre que você inicia seu banco de dados, o
primeiro arquivo lido é o arquivo de
parâmetros. Ele configura todas as
configurações de memória e processo e
informa a instância onde os arquivos de
controle estão localizados. Ele também possui
informações sobre seu status de
arquivamento.
No Capítulo 4, cobrimos como os PFILEs e
SPFILE estão localizados no diretório onde
você instalou o software do banco de dados.
Este diretório é chamado de ORACLE_HOME:
✓ Linux / UNIX: $ ORACLE_HOME / dbs
✓ Windows:% ORACLE_HOME% \\ database
Deve ter uma estrutura de nomeação
específica. Por exemplo, se o nome do banco
de dados for dev12c, os arquivos serão
nomeados da seguinte maneira:
✓ O PFILE seria chamado initdev12c.ora.
✓ O SPFILE seria chamado spfiledev12c.ora.
42 Parte I: Introdução ao Oracle 12c
Ao nomeá-los desta forma e colocá-los no
diretório apropriado, o Oracle os encontra
automaticamente quando você inicia o banco
de dados. De qualquer forma, você deve dizer
à Oracle onde estão todas as vezes que você
inicia o banco de dados; isso simplesmente
não é conveniente.
Recomendamos que você mantenha o PFILE e
SPFILE nas localizações padrão com a
convenção de nomenclatura padrão para
facilidade de administração.
Depois de conhecer as estruturas físicas, você
pode dividi-las em estruturas mais lógicas.
Todas as estruturas lógicas sobre as quais
falamos estão nos arquivos de dados.
Logical structures allow you to organize your
data into manageable and, well, logical, pieces.
Without logical breakdown of the raw, physical
storage, your database would
✓ Be difficult to manage
✓ Be poorly tuned
✓ Make it hard to find data
✓ Require the highly trained and special skill set
of a madman
Figure 2-4 shows the relationship of logical to
physical objects. The arrow points in the
direction of a one-to-many relationship.
Tablespaces
Tablespaces are the first level of logical
organization of your physical storage.
Every 12c database should have the following
tablespaces:
✓ SYSTEM: Stores the core database objects
that are used for running the
database itself.
✓ SYSAUX: For objects that are auxiliary and not
specifically tied to the core features of the
database.
✓ UNDO: Stores the rollback or undo segments
used for transaction recovery.
✓ TEMP: For temporary storage.
Each tablespace is responsible for organizing one
or more data files.
Typically, each tablespace might start attached
to one data file, but as the database grows and
your files become large, you may decide to add
storage
in the form of multiple data files.
So what’s the next step to getting your database
up and running? You create some areas to store
As estruturas lógicas permitem que você
organize seus dados em peças gerenciáveis e,
bem, lógicas. Sem quebra lógica do
armazenamento físico bruto, seu banco de
dados
✓ Seja difícil de gerenciar
✓ Seja mal ajustado
✓ Facilite a busca de dados
✓ Exigir o conjunto de habilidades altamente
treinadas e especiais de um louco
A Figura 2-4 mostra a relação de objetos
físicos e lógicos. A flecha aponta na direção
de um relacionamento de um para muitos.
Tablespaces
Tablespaces são o primeiro nível de
organização lógica do seu armazenamento
físico.
Todo banco de dados 12c deve ter os
seguintes espaços de tabela:
✓ SISTEMA: Armazena os objetos principais
do banco de dados que são usados para
executar o
próprio banco de dados.
✓ SYSAUX: para objetos que são auxiliares e
não especificamente ligados aos recursos
principais do banco de dados.
✓ UNDO: Armazena os segmentos de
reversão ou desdobramento usados para
recuperação de transações.
✓ TEMP: para armazenamento temporário.
Cada espaço de tabela é responsável pela
organização de um ou mais arquivos de
dados.
Normalmente, cada espaço de tabela pode
começar anexado a um arquivo de dados,
mas à medida que o banco de dados cresce e
seus arquivos se tornam grandes, você pode
your data. Say your database is going to have
sales, human resources, accounting data, and
historical data. You might have the following
tablespaces:
✓ SALES_DATA
✓ SALES_INDEX
✓ HR_DATA
✓ HR_INDEX
✓ ACCOUNTING_DATA
✓ ACCOUNTING_INDEX
✓ HISTORY_DATA
✓ HISTORY_INDEX
Separating tables and indexes both logically and
physically is common in a database.
✓ Because tablespaces must have at least one
data file associated with them, you can create
them so data files are physically on separate
devices and therefore improve performance.
✓ You can harden our databases against
complete failure. Tablespaces can be backed up
and recovered from one another independently.
Say you lose a data file in the SALES index
tablespace. You can take only the SALES_INDEX
tablespace offline to recover it while human
resources,
accounting, and anyone accessing historical data
is none the wiser.
We discuss actual tablespace creation in Chapter
7.
Keep in mind that when deciding on the logical
organization, it pays to sit down and map out all
the different activities your database will
support. If possible, create tablespaces for every
major application and its associated indexes.
If your database has especially large subsets of
data, sometimes it pays to separate that data
decidir adicionar o armazenamento
sob a forma de vários arquivos de dados.
Então, qual é o próximo passo para colocar
seu banco de dados em funcionamento?
Você cria algumas áreas para armazenar seus
dados. Diga que seu banco de dados terá
vendas, recursos humanos, dados contábeis e
dados históricos. Você pode ter os seguintes
espaços de tabela:
✓ SALES_DATA
✓ SALES_INDEX
✓ HR_DATA
✓ HR_INDEX
✓ ACCOUNTING_DATA
✓ ACCOUNTING_INDEX
✓ HISTÓRIA_DATA
✓ HISTÓRIA_INDEX
Separar tabelas e índices tanto logicamente
quanto fisicamente é comum em um banco
de dados.
✓ Como os espaços de tabela devem ter pelo
menos um arquivo de dados associado a eles,
você pode criá-los para que os arquivos de
dados sejam fisicamente em dispositivos
separados e, portanto, melhorem o
desempenho.
✓ Você pode endurecer nossos bancos de
dados contra falhas completas. Os
Tablespaces podem ser copiados e
recuperados um do outro
independentemente. Digamos que você
perca um arquivo de dados no espaço de
tabela do índice SALES. Você pode levar
apenas o espaço de tabelas SALES_INDEX
offline para recuperá-lo enquanto recursos
humanos,
contabilidade e qualquer pessoa acessando
dados históricos não é a mais sábia.
from your regular data as well. For example, say
you’re storing lots of still pictures. Those
pictures probably never change. If you have a
tablespace dedicated to them, you can make it
read only. The tablespace is taken out of the
checkpointing process. You can also back it up
once, and then do it again only after it changes.
That reduces the storage required for backups,
plus it speeds up your backup process.
Segments
Segments are the next logical storage structure
after tablespaces. Segments are objects in the
database that require physical storage and
include the following:
✓ Tables
✓ Indexes
✓ Materialized views
✓ Partitions
These object examples are not segments and
don’t store actual data:
✓ Views
✓ Procedures
✓ Synonyms
✓ Sequences
The latter list of objects don’t live in a tablespace
Discutimos a criação real de tablespace no
Capítulo 7.
Tenha em mente que, ao decidir sobre a
organização lógica, vale a pena sentar-se e
mapear todas as atividades diferentes que
seu banco de dados irá suportar. Se possível,
crie espaços de tabela para cada aplicação
principal e seus índices associados.
Se o seu banco de dados tem subconjuntos
de dados especialmente grandes, às vezes
vale a pena separar esses dados de seus
dados regulares também. Por exemplo, diga
que você está armazenando muitas imagens
estáticas. Essas fotos provavelmente nunca
mudam. Se você tem um tablespace dedicado
a eles, você pode fazê-lo somente ler. O
espaço de tabela é retirado do processo de
verificação. Você também pode fazer o
backup uma vez, e depois fazê-lo novamente
somente depois que ele muda. Isso reduz o
armazenamento necessário para backups,
além disso, acelera seu processo de backup.
Segments
Segmentos são a próxima estrutura de
armazenamento lógica após espaços de
tabela. Os segmentos são objetos no banco
de dados que requerem armazenamento
físico e incluem o seguinte:
✓ Tabelas
✓ Índices
✓ visualizações materializadas
✓ Partições
Esses exemplos de objetos não são
segmentos e não armazenam dados reais:
✓ Vistas
✓ Procedimentos
✓ Sinônimos
✓ Seqüências
with segments. They’re pieces of code that live
in the SYSTEM tablespace.
Whenever you create a segment, specify what
tablespace you want it to be part of. This helps
with performance.
For example, you probably want the table
EMPLOYEES stored in the HR_DATA tablespace.
In addition, if you have an index on the
LAST_NAME column of the EMPLOYEES table,
you want to make sure it is created in the
HR_INDEXES tablespace. That way, when people
are searching for and retrieving employee
information, they’re not trying to read the index
off the same data file that the table data is
stored in.
Extents
Extents are like the growth rings of a tree.
Whenever a segment grows, it gains a new
extent. When you first create a table to store
items, it gets its first extent. As you insert data
into that table, that extent fills up. When the
extent fills up, it grabs another extent from the
tablespace.
When you first create a tablespace, it’s all free
space. When you start creating objects, that free
space gets assigned to segments in the form of
extents. Your average tablespace is made up of
used extents and free space.
When all the free space is filled, that data file is
out of space. That’s when your DBA skills come
in and you decide how to make more free space
available
for the segments to continue extending.
Extents aren’t necessarily contiguous. For
example, when you create an items table and
insert the first 1,000 items, it may grow and
extend several times. Now your segment might
be made up of five extents. However, you also
create a new table. As each table is created in a
new tablespace, it starts at the beginning of the
data file. After you create your second table,
your first table may need to extend again. Its
next extent comes after the second extent. In
A última lista de objetos não vive em um
tablespace com segmentos. Eles são pedaços
de código que vivem no tablespace SYSTEM.
Sempre que você criar um segmento,
especifique o espaço de tabela que deseja
que ele faça parte. Isso ajuda com o
desempenho.
Por exemplo, você provavelmente quer a
tabela EMPREGADOS armazenada no espaço
de tabela HR_DATA. Além disso, se você tiver
um índice na coluna LAST_NAME da tabela
EMPREGADOS, você deseja garantir que ele
seja criado no espaço de tabela HR_INDEXES.
Dessa forma, quando as pessoas estão
procurando e recuperando a informação dos
funcionários, eles não estão tentando ler o
índice do mesmo arquivo de dados no qual os
dados do quadro estão armazenados.
Extents
Extentes são como os anéis de crescimento
de uma árvore. Sempre que um segmento
cresce, ele ganha uma nova extensão.
Quando você cria uma tabela pela primeira
vez para armazenar itens, ele obtém sua
primeira extensão. À medida que você insere
dados nessa tabela, essa extensão é
preenchida. Quando a extensão se enche, ele
agarra outra extensão do tablespace.
Quando você cria um espaço de tabela pela
primeira vez, é todo o espaço livre. Quando
você começa a criar objetos, esse espaço livre
é atribuído a segmentos sob a forma de
extensões. Seu espaço de tabela médio é
composto de extensões usadas e espaço livre.
Quando todo o espaço livre é preenchido,
esse arquivo de dados está fora do espaço. É
aí que as suas habilidades DBA entram e você
decide como disponibilizar mais espaço
disponível
para que os segmentos continuem se
estendendo.
As extensões não são necessariamente
contíguas. Por exemplo, quando você cria
uma tabela de itens e insira os primeiros
1.000 itens, ele pode crescer e se estender
várias vezes. Agora seu segmento pode ser
the end, all objects that share a tablespace will
have their extents intermingled.
This isn’t a bad thing. In years past, before
Oracle had better algorithms for storage, DBAs
spent a lot of their time and efforts trying to
coalesce these extents. It was called
fragmentation. It’s a thing of the past but we
still see people getting all up in arms about it.
Don’t get sucked in! Just let it be. Oracle 12c is
fully capable of managing such situations.
I also want to mention situations where you
have multiple data files in a tablespace. If a
tablespace has more than one data file, the
tablespace automatically creates extents in a
round-robin fashion across all the data files.
This is another Oracle performance feature.
Say you have one large table that supports most
of your application. It lives in a tablespace made
of four data files. As the table extends, Oracle
allocates the extents across each data file like
this:
1,2,3,4,1,2,3,4,1,2,3,4 . . . and so on
This way, Oracle can take advantage of the data
spread across many physical devices when users
access data. It reduces contention on segments
that have a lot of activity.
Oracle blocks
We’ve mentioned Oracle blocks at least twice
before. We had to mention them when talking
about the buffer cache and data files. Here in
this section we can fill in a little more
information.
composto por cinco graus. No entanto, você
também cria uma nova tabela. Como cada
tabela é criada em um novo espaço de
tabelas, ele começa no início do arquivo de
dados. Depois de criar sua segunda tabela,
sua primeira tabela pode precisar se estender
novamente. A próxima extensão vem após a
segunda extensão. No final, todos os objetos
que compartilham um tablespace terão suas
proporções entremeadas.
Isso não é ruim. Nos anos passados, antes de
a Oracle ter melhores algoritmos de
armazenamento, os DBAs gastaram muito
tempo e esforços tentando unir essas
extensões. Foi chamado de fragmentação. É
uma coisa do passado, mas ainda vemos as
pessoas se agarrando sobre isso. Não seja
sugado! Apenas deixe ser. O Oracle 12c é
totalmente capaz de gerenciar tais situações.
Eu também quero mencionar situações em
que você possui vários arquivos de dados em
um tablespace. Se um tablespace tiver mais
de um arquivo de dados, o tablespace cria
automaticamente extensões de forma
redonda em todos os arquivos de dados.
Este é outro recurso de desempenho da
Oracle.
Digamos que você tenha uma tabela grande
que suporte a maioria de sua aplicação. Vive
em um tablespace composto por quatro
arquivos de dados. À medida que a tabela se
estende, o Oracle aloca as extensões em cada
arquivo de dados como este:
1,2,3,4,1,2,3,4,1,2,3,4. . . e assim por diante
Desta forma, a Oracle pode aproveitar os
dados espalhados por vários dispositivos
físicos quando os usuários acessam os dados.
Reduz a contenção em segmentos que têm
muita atividade.
Oracle blocks
Já mencionamos blocos Oracle pelo menos
duas vezes antes. Tivemos que mencioná-los
quando falamos sobre o cache do buffer e os
arquivos de dados. Aqui, nesta seção,
podemos preencher um pouco mais de
informações.
An Oracle block is the minimum unit that Oracle
will read or write at any given time.
Oracle usually reads and writes more than one
block at once, but that’s up to Oracle these days.
You used to have more direct control of how
Oracle managed
its reads and writes of blocks, but now
functionality is automatically tuned. You can
tune it manually to a certain extent, but most
installations are best left to Oracle.
Regardless, blocks are the final logical unit of
storage. Data from your tables and indexes are
stored in blocks. The following things happen
when you insert a new row into a table:
✓ Oracle finds the segment.
✓ Oracle asks that segment if there’s any room.
✓ The segment returns a block that’s not full.
✓ The row or index entry is added to that block.
If no blocks are free for inserts, the segment
grabs another free extent from the tablespace.
By the way, all this is done by the server process
to which you’re attached.
Oracle blocks also have a physical counterpart
just like the data files do.
Oracle blocks are made up of OS blocks. It is the
formatted size of the minimum unit of storage
on the device.
Oracle blocks should be evenly divisible by your
OS block size. Oracle blocks should never be
smaller than your OS block size. We discuss
Oracle block sizing more in Chapter 4.
Um bloco Oracle é a unidade mínima que a
Oracle lê ou escreve a qualquer momento.
O Oracle geralmente lê e escreve mais de um
bloco ao mesmo tempo, mas isso é para a
Oracle nos dias de hoje. Você costumava ter
um controle mais direto de como a Oracle
gerenciava
É lido e grava blocos, mas agora a
funcionalidade é sintonizada
automaticamente. Você pode ajustá-lo
manualmente até certo ponto, mas a maioria
das instalações é melhor deixada para a
Oracle.
Independentemente disso, os blocos são a
unidade lógica final de armazenamento. Os
dados de suas tabelas e índices são
armazenados em blocos. As seguintes coisas
acontecem quando você insere uma nova
linha em uma tabela:
✓ A Oracle encontra o segmento.
✓ A Oracle pede esse segmento se houver
algum espaço.
✓ O segmento retorna um bloco que não
está cheio.
✓ A entrada de linha ou índice é adicionada a
esse bloco.
Se nenhum bloco for livre para inserções, o
segmento ganha outra extensão livre do
tablespace. Aliás, tudo isso é feito pelo
processo do servidor ao qual está anexado.
Os blocos Oracle também possuem uma
contrapartida física, assim como os arquivos
de dados.
Os blocos Oracle são formados por blocos de
sistema operacional. É o tamanho formatado
da unidade mínima de armazenamento no
dispositivo.
Os blocos de Oracle devem ser

Pluggable Databases
Now that you have a good understanding of the
pieces and parts of databases and instances,
we’ve saved the best for last as we throw a new
concept at you in an attempt to muddy the
waters. Welcome to pluggable databases.
New in Oracle 12c is an optional architecture
where you have one or more smaller subsets of
schemas, data tables, indexes, and data
dictionaries running as Pluggable Databases
(PDB) inside a larger, superset Container
Database (CDB).
The Container Database acts as a root database
instance and each of the Pluggable Databases
run within that single Container Database as
tenants. We call this a multi-tenancy
architecture where one CDB contains multiple
tenant PDBs. Each PDB contains only the
schemas, database, indexes, and mini split data
dictionary to remain self-contained within the
larger supporting CDB.
For example, we could have separate PDBs for
our sales, Human Resources, and new products
departments withing our larger CDB. This breaks
a previous database “rule” where now we have
multiple databases (the PDBs) inside a single
database instance (the CDB). Why in the world
would you want to do this? Well, the first reason
is to be cool kid within your group of Oracle
friends. The reason you tell your boss is you are
supporting the cloud in 12c via multi-tenancy; he
may not know what that means but he’ll put it
in his report to his boss. Seriously, think about
the benefits of off-loading rudunant physical
structures and overhead memory and
background processes to a larger CDB rather
supporting multiple copies for each PDB. This
allows you to consolidate more databases as
PDB tenants into a CDB while consuming few
resources. In very larger environments such as
data center consolidation or where server
resources are constrained,these saves are very
uniformemente divisíveis pelo tamanho do
seu bloco de sistema operacional. Os blocos
de Oracle nunca devem ser menores do que o
tamanho do seu bloco de sistema
operacional. Discutimos o tamanho do bloco
Oracle mais no Capítulo 4.
Pluggable Databases
Agora que você tem uma boa compreensão
das peças e partes de bancos de dados e
instâncias, salvamos o melhor para o último,
enquanto lançamos um novo conceito em
você na tentativa de enlamear as águas. Bem-
vindo aos bancos de dados conectáveis.
Novo no Oracle 12c é uma arquitetura
opcional onde você tem um ou mais
subconjuntos menores de esquemas, tabelas
de dados, índices e dicionários de dados que
funcionam como Pluggable Databases (PDB)
dentro de um contêiner maior e
superconjunto
Banco de dados (CDB).
O banco de dados do contêiner atua como
uma instância de banco de dados raiz e cada
um dos bancos de dados conectáveis é
executado dentro desse único banco de
dados de contêiner como inquilinos.
Chamamos isso de uma arquitetura multi-
arrendamento onde um CDB contém
múltiplos PDB de inquilino. Cada PDB contém
apenas os esquemas, banco de dados, índices
e mini dicionário de dados divididos para
permanecer autônomo dentro do CDB de
suporte maior.
Por exemplo, poderíamos ter PDBs separados
para nossos serviços de vendas, recursos
humanos e novos produtos com nosso CDB
maior. Isso quebra um banco de dados
anterior 'regra' onde agora temos vários
bancos de dados (os PDBs) dentro de uma
única instância de banco de dados (o CDB).
Por que no mundo você gostaria de fazer
isso? Bem, o primeiro motivo é ser um garoto
legal do seu grupo de amigos da Oracle. A
razão pela qual você diz ao seu chefe é que
você está apoiando a nuvem no 12c via multi-
tenancy; ele pode não saber o que isso
significa, mas ele irá colocá-lo em seu
relatório para o chefe dele. Sério, pense
useful.
Also consider the pluggable part of PDBs; you
can create them easily by cloning exiting PDB
copies and you can move them between CDBs
(unplug and plug) as needed to support
migrations, upgrades, and testing. The pluggable
architecture gives you a high degree of granular
control of your PDBs. The self-contained
architecture of the PDBs make this pluggable
flexibility possible and is a great potential
benefit as you manage multiple databases.
Chapter 3 Preparing to Implement Oracle
In This Chapter
▶ Implementing Oracle
▶ Verifying system requirements
▶ Planning server and disk configuration
▶ Taking care of post-software-installation
setup
Before you create databases and store your
data, you need to plan your steps, which will
make your implementation much easier. First
and foremost, you need to determine your
overall database architecture. Databases
don’t exist as standalone entities; they’re part
of an information system, and you need to
understand how that system is laid out. This
chapter looks at two of the most common
implementation methods and helps you
determine which method is right for you.
sobre os benefícios das estruturas físicas
rudunant off-loading e da memória aérea e
dos processos em segundo plano para um
CDB maior, em vez de apoiar múltiplas cópias
para cada PDB. Isso permite que você
consolide mais bancos de dados como
inquilinos do PDB em um CDB enquanto
consuma poucos recursos. Em ambientes
muito maiores como a consolidação do
centro de dados ou onde os recursos do
servidor são restritos,estes salva são muito
úteis.
Considere também a parte plugável dos
PDBs; Você pode criá-los facilmente,
clonando as cópias do PDB removendo e você
pode movê-las entre CDBs (desconecte e
conecte) conforme necessário para suportar
migrações, atualizações e testes. A
arquitetura conectável oferece um alto grau
de controle granular de seus PDBs. A
arquitetura autônoma dos PDBs torna esta
flexibilidade plugável possível e é um grande
benefício potencial à medida que gerencia
vários bancos de dados.
Capítulo 3 Preparando-se para implementar o
Oracle
este capítulo
▶ Implementando o Oracle
▶ Verificando os requisitos do sistema
▶ Planejando a configuração do servidor e do
disco
▶ Cuidado da instalação de instalação pós-
software
Antes de criar bancos de dados e
armazená-los, você precisa planejar
suas etapas, o que tornará sua
implementação muito mais fácil. Em
primeiro lugar, você precisa
determinar sua arquitetura de banco
de dados geral. Bancos de dados não
existem como entidades autônomas;
Eles são parte de um sistema de
informação, e você precisa entender
como esse sistema é colocado para
fora. Este capítulo Olha para dois dos

After you determine the right overall
implementation plan, you need to make sure
that your target environment meets the
necessary requirements to host Oracle. This
chapter not only looks at obvious
requirements, such as server hardware and
software, but it also looks at less reviewed (yet
critical) requirements, such as user,
configuration, and storage considerations. This
chapter gives you the knowledge to make
good judgments of where and how you
implement your Oracle database
Understanding How an Oracle
Database Fits into a System’s
Architecture
Oracle databases don’t simply exist in
isolation; they act as part of a computer
system. Before installing the Oracle software
and configuring your database, you need to
know how your database fits into the overall
system architecture. Some systems are more
complex than others, but most fall into the
following basic categories:
✓ Client-server
✓ Multi-tier
✓ Component configurations
Knowing which category your database fits
into will make a big difference during your
system setup because you’ll know the specific
needs of your database.
Client-server applications
Client-server applications (sometimes called
two-tier applications) are those in which the
user’s workstation has the application
program installed and, during execution, the
métodos de implementação mais
comuns e ajuda a determinar qual
método é certo para você.
Depois de determinar o plano de
implementação geral direito, você
precisará certificar-se de que seu
ambiente de destino atenda aos
requisitos necessários para hospedar
o Oracle. Este capítulo não só olha
para requisitos óbvios, como hardware
e software do servidor, mas também
examina os requisitos menos
revisados (ainda críticos), como
considerações de usuário,
configuração e armazenamento. Este
capítulo dá-lhe o conhecimento para
fazer bons julgamentos de onde e
como você implementa o seu banco
de dados Oracle
Noções básicas sobre como um
banco de dados Oracle se
encaixa na arquitetura de um
sistema
Os bancos de dados Oracle não
existem simplesmente em isolamento;
Eles agem como parte de um sistema
informático. Antes de instalar o
software Oracle e configurar seu
banco de dados, você precisa saber
como seu banco de dados se encaixa
na arquitetura do sistema global.
Alguns sistemas são mais complexos
do que outros, mas a maioria cai nas
seguintes categorias básicas:
✓ Cliente-servidor ✓ Multi-camada ✓
Configurações de componentes
Conhecer a categoria em que sua
base de dados se encaixa irá fazer
uma grande diferença durante a
configuração do sistema porque você
conhecerá as necessidades
específicas do seu banco de dados.
Aplicações cliente-servidor
Os aplicativos cliente-servidor (às
vezes chamados de aplicativos de
duas camadas) são aqueles em que a
program accesses data stored on a remote
database server. Although you have some
wiggle room here, the workstation handles
the presentation and application logic, and the
database server acts as a data store. Figure 3-
1 shows how a client-server configuration
works.
In Figure 3-1, the workstation (client-tier)
handles the application logic and presentation
to the user. Application logic may be
implanted via many different languages, but
common examples include PowerBuilder, MS
Visual Basic, Java applications, and even some
versions of Oracle Forms and Reports. When
these client-side applications need data, they
access the database via ODBC (Open Database
Connectivity), JDBC (Java Database
Connectivity), or Oracle Net by using client-
side tnsnames.ora files. These database
communication protocols allow connectivity
from any client to any database, including
Oracle.
On the database tier, the database stores the
data and, via users, roles, and
permissions, it provides that data to the
application in response to SQL queries
and data manipulation language (DML)
statements (which are simply SQL statements
that manipulate, or change, the data).
Depending on whether
you’re using a fat or thin client, some of the
application logic and processing
may be off-loaded to the database tier.
Processing on the database server
often makes sense because a database server
can do much more intensive
processing and number-crunching than even
the largest workstation. Data
processing is commonly executed via database
procedures, functions, and
packages, which process the data into a
smaller result set to be returned to
estação de trabalho do usuário possui
o programa aplicativo instalado e,
durante a execução, o programa
acessa dados armazenados em um
servidor de banco de dados remoto.
Embora você tenha alguma sala de
mudanças aqui, a estação de trabalho
lida com a lógica da apresentação e
da aplicação e o servidor do banco de
dados atua como um armazenamento
de dados. A Figura 3-1 mostra como
uma configuração cliente-servidor
funciona.
Na Figura 3-1, a estação de trabalho (camada
de cliente) lida com a lógica e apresentação do
aplicativo com o usuário. A lógica da aplicação
pode ser implantada através de diferentes
idiomas, mas exemplos comuns incluem
PowerBuilder, MS Visual Basic, aplicativos Java
e até mesmo algumas versões do Oracle Forms
and Reports. Quando esses aplicativos do lado
do cliente precisam de dados, eles acessam o
banco de dados via ODBC (Open Database
Connectivity), JDBC (Java Database
Connectivity) ou Oracle Net usando os arquivos
tnsnames.ora do lado do cliente. Estes
protocolos de comunicação de banco de dados
permitem conectividade de qualquer cliente
para qualquer banco de dados, incluindo
Oracle.
Na camada de banco de dados, o banco de
dados armazena os dados e, por meio de
usuários, funções e
permissões, fornece dados para o aplicativo em
resposta a consultas SQL
e instruções de linguagem de manipulação de
dados (DML) (que são simplesmente instruções
SQL que manipulam ou alteram os dados).
Dependendo do clima
você está usando um cliente gordo ou fino,
alguns da lógica e processamento do aplicativo
pode ser descarregado para o nível do banco de
dados. Processamento no servidor de banco de
dados
muitas vezes faz sentido porque um servidor de
banco de dados pode fazer muito mais
intensivo
processamento e crunching de números do que
até mesmo a maior estação de trabalho. Dados
O processamento normalmente é executado
the client for presentation to the user.
Many people have claimed that client-server is
dead. If it is, why are so many
client-server applications still out there? Sure,
the client-server architecture
is older, and many newer applications exist in
the multi-tier world. However,
a simple client-server application still meets
the immediate needs of a business
in many situations. Also, the client-server
application may be an existing
legacy application that does its job — so, the
business has no need to
upgrade. Regardless, although we don’t
recommend developing new, largescale
systems on this model, we can’t deny that
client-server applications
still exist in many organizations. Lastly, as a
reader of this book, you may not
be here to implement a new system. You may
be here because you have to
understand Oracle and how it works in an
existing client-server application
environment.
Multi-tier applications
Multi-tier applications are the current industry
standard and compose multiple web,
application, and database servers providing
content to thin clients with presentation via a
web browser. Ever wonder what’s behind the
scenes when you log in to a web application
for online purchases or banking? Well, it looks
something like Figure 3-2.
In Figure 3-2, the client-tier is merely a web
browser accessing a web
server. Displaying content to the user is the
primary purpose of the client
in this architecture; no actual processing
occurs at this layer within the
através de procedimentos, funções e
pacotes, que processam os dados em um
conjunto menor definido para ser retornado
para
o cliente para apresentação ao usuário.
Muitas pessoas alegaram que o servidor-cliente
está morto. Se é, por que são tantos
Aplicações cliente-servidor ainda lá fora? Claro,
a arquitetura cliente-servidor
é mais antigo, e muitas aplicações mais
recentes existem no mundo de várias camadas.
Contudo,
um aplicativo cliente-servidor simples ainda
atende às necessidades imediatas de um
negócio
em muitas situações. Além disso, o aplicativo
cliente-servidor pode ser um
aplicativo legado que faz seu trabalho - então, o
negócio não tem necessidade de
atualizar. De qualquer forma, embora não
recomendemos o desenvolvimento de novos e
grandes modelos
sistemas neste modelo, não podemos negar
que os aplicativos cliente-servidor
ainda existem em muitas organizações. Por
último, como leitor deste livro, você não pode
esteja aqui para implementar um novo sistema.
Você pode estar aqui porque você tem que
Compreender a Oracle e como ela funciona em
um aplicativo cliente-servidor existente
meio Ambiente.
Aplicações de várias camadas
Os aplicativos de várias camadas são
o padrão atual da indústria e compor
vários servidores de web, aplicativos e
banco de dados que fornecem
conteúdo para thin clients com
apresentação através de um
navegador da Web. Já se perguntou o
que está por trás dos bastidores
quando você faz logon em um
aplicativo da web para compras on-
line ou bancário? Bem, parece algo
como a Figura 3-2.
Na Figura 3-2, o nível do cliente é meramente
um navegador da Web acessando uma web
servidor. Mostrar o conteúdo para o usuário é o
objetivo principal do cliente
nesta arquitetura; nenhum processamento real
ocorre nesta camada dentro do
browser. Presentation occurs most commonly
via HTML (HyperText Markup
Language), but it can also be within a Java
applet or an ActiveX component
and use JavaScript for more dynamic
formatting and content.
Communication from the browser to the web
server occurs via HTTP
(HyperText Transfer Protocol) or HTTPS for
secure (encrypted) data. Web
servers conceptually act as web listeners; they
receive requests from browsers
and return formatted result sets with little
processing on their own. Once
on the web server, the browser request is
parsed and sent to the appropriate
application server for processing. The
application server component may be
on the same physical server as the web server,
or it may be on another physical
server. By far, the most common web server is
Apache, or one of its commercial
derivatives, with over 50 percent of the
market share according to
http://news.netcraft.com/archives/web_serve
r_survey.html.
At the application server level, the user
request is processed using the relevant
application logic. One very common method is
to use a Java application
server, such as Tomcat, Orion, or Glassfish. In
this case, the program logic
is executed inside a Java Virtual Machine
(JVM), which acts as the runtime
environment for the program code.
Another popular tool is Oracle Fusion
Middleware (OFM). Within OFM, the
program may run as Oracle Forms, Reports,
Discoverer, or even Java via
Oracle Containers for J2EE (OC4J). Regardless
of the product, it’s within the
application server component that the
application logic is executed.
During processing on the application server,
it’s common to need database
access to query, create, update, or delete data.
The application server communicates
with the database server via protocols, such as
JDBC or Oracle Net,
to access the data. During this time, the
application server is accessing the
navegador. A apresentação ocorre mais
comumente via HTML (HyperText Markup
Idioma), mas também pode estar dentro de um
applet Java ou um componente ActiveX
e use JavaScript para formatação e conteúdo
mais dinâmicos.
A comunicação do navegador para o servidor
web ocorre via HTTP
(HyperText Transfer Protocol) ou HTTPS para
dados seguros (criptografados). Rede
Os servidores funcionam de forma conceitual
como ouvintes da Web; eles recebem pedidos
de navegadores
e retornar conjuntos de resultados formatados
com pouco processamento por conta própria.
Uma vez
no servidor web, o pedido do navegador é
analisado e enviado ao apropriado.
servidor de aplicativos para processamento. O
componente do servidor de aplicativos pode
ser
no mesmo servidor físico que o servidor web,
ou pode ser em outro físico
servidor. De longe, o servidor web mais comum
é o Apache, ou um dos seus comerciais
derivados, com mais de 50% da participação de
mercado de acordo com
http://news.netcraft.com/archives/web_server
_survey.html.
No nível do servidor da aplicação, a solicitação
do usuário é processada usando o relevante
lógica do aplicativo. Um método muito comum
é usar um aplicativo Java
servidor, como Tomcat, Orion ou Glassfish.
Neste caso, a lógica do programa
é executado dentro de uma Máquina Virtual
Java (JVM), que atua como o tempo de
execução
ambiente para o código do programa.
Outra ferramenta popular é o Oracle Fusion
Middleware (OFM). Dentro da OFM, o
O programa pode ser executado como Oracle
Forms, Reports, Discoverer ou mesmo Java via
Oracle Containers para J2EE (OC4J).
Independentemente do produto, está dentro
do
componente do servidor de aplicativos que a
lógica do aplicativo é executada.
Durante o processamento no servidor do
aplicativo, é comum precisar de banco de dados
acesso a consulta, criar, atualizar ou excluir
database on behalf of the user making the
application request. Rather than
connecting as a named, distinct user such as
JSMITH, the application server
connects using a generic web account (such as
WEB_USER). Multiple simultaneous
connections from the application server to the
database form a connection
pool that allows any database connection to
access data for a request.
Connection pooling is a performance benefit
because only a few database connections
can service thousands of requests on behalf of
many users.
When logged into the database instance, the
generic web user queries or
executes DML on behalf of the application
server, which is processing an
actual user request. The connection pooled
web user doesn’t have schema
ownership into the database; it has only those
permissions needed to access
or update data on behalf of the application
server. During this time, normal database
roles, permissions, and grants are used.
Additionally, database program
logic implemented in PL/SQL via procedures,
functions, and packages is
often executed.
After the data result set is generated on the
database-tier, it’s passed back to
the application server for more processing.
Next, the results are relayed back
through the web server and across the
network for presentation to the user
via their web browser.
Sounds complicated with all the various
components? You may think so at
first, but good reasons exist for breaking the
system into web, application,
and database components:
✓ You can use components from different
vendors in a “best of breed”
configuration. For example, you can use a free
Apache web server
instance coupled with Tomcat or Glassfish for
a cheap application
server component. Then tie that to the power
of the Oracle database,
and you have a solid system at lower costs!
✓ As more users come online, you can add
dados. O servidor de aplicativos se comunica
com o servidor de banco de dados através de
protocolos, como JDBC ou Oracle Net,
para acessar os dados. Durante este tempo, o
servidor de aplicativos está acessando o
banco de dados em nome do usuário que faz o
pedido do aplicativo. Ao invés de
conectando-se como um nomeado, usuário
distinto, como JSMITH, o servidor de aplicativos
se conecta usando uma conta web genérica
(como WEB_USER). Múltiplo simultâneo
conexões do servidor de aplicativos para o
banco de dados formam uma conexão
pool que permite que qualquer conexão de
banco de dados acesse dados para uma
solicitação.
O pool de conexões é um benefício de
desempenho porque apenas algumas conexões
de banco de dados
pode atender milhares de pedidos em nome de
muitos usuários.
Quando conectado à instância do banco de
dados, o usuário genérico consulta ou
executa o DML em nome do servidor de
aplicativos, que está processando um
pedido real do usuário. O usuário da rede
compartilhada não possui esquema
propriedade no banco de dados; tem apenas as
permissões necessárias para acessar
ou atualizar dados em nome do servidor do
aplicativo. Durante esse período, as funções,
permissões e concessões de banco de dados
normais são usadas. Além disso, programa de
banco de dados
A lógica implementada em PL / SQL via
procedimentos, funções e pacotes é
muitas vezes executado.
Depois que o conjunto de resultados de dados
é gerado na camada de banco de dados, ele é
passado de volta para
o servidor de aplicativos para mais
processamento. Em seguida, os resultados são
retransmitidos
através do servidor web e em toda a rede para
apresentação ao usuário
através do seu navegador web.
Parece complicado com todos os vários
componentes? Você pode pensar assim em
primeiro, mas existem bons motivos para
quebrar o sistema em web, aplicativo,
e componentes do banco de dados:
more web, application, or
database server instances to boost your
processing power. Rather than
buying bigger servers, just buy smaller servers.
✓ After you have a series of multiple servers,
you gain fault tolerance. This
is called clustering. If a web server crashes or
the application server
needs maintenance, no problem — the
redundant servers will pick up
the workload.
Hopefully, these benefits show why multi-tier
system architectures are the
industry standard and have surpassed client-
server systems.
Component configurations
In client-server and multi-tier systems, the
Oracle database was the core
of the system because it holds the data.
Existing as the primary data store
for the entire system is the most common use
of an Oracle database, but
it’s not the only time you’ll have to install
Oracle. For example, often, these
databases are in a supporting role, acting as
secondary data stores for
larger Commercial Off-The-Shelf (COTS)
applications. In these cases, Oracle
databases act as repositories storing
specialized data for use within a larger
system. During installation of the larger
system, the Oracle database is
installed as a supporting component.
One common example of an Oracle repository
you may be familiar with is
Oracle Designer. You can use this Oracle
developer tool to design, create, and store
application code (among other things), and it
✓ Você pode usar componentes de diferentes
fornecedores em um 'melhor de raça'
configuração. Por exemplo, você pode usar um
servidor web Apache gratuito
instância juntamente com Tomcat ou Glassfish
para uma aplicação barata
componente do servidor. Em seguida, atribua
isso ao poder do banco de dados Oracle,
e você tem um sistema sólido a custos mais
baixos!
✓ À medida que mais usuários acessam on-line,
você pode adicionar mais web, aplicativo ou
instâncias de servidor de banco de dados para
aumentar seu poder de processamento. Ao
invés de
Comprar servidores maiores, apenas compre
servidores menores.
✓ Depois de ter uma série de servidores
múltiplos, você ganha tolerância a falhas. este
é chamado de clustering. Se um servidor web
falhar ou o servidor de aplicativos
precisa de manutenção, não há problema - os
servidores redundantes vão pegar
a carga de trabalho.
Felizmente, esses benefícios mostram por que
as arquiteturas de sistemas de várias
padrão da indústria e superaram os sistemas
cliente-servidor.
Configurações de componentes
Em sistemas cliente-servidor e multi-camada, o
banco de dados Oracle era o núcleo
do sistema porque contém os dados. Existente
como armazenamento de dados primário
Para todo o sistema é o uso mais comum de um
banco de dados Oracle, mas
Não é a única vez que você terá que instalar o
Oracle. Por exemplo, muitas vezes, estes
os bancos de dados estão em uma função de
suporte, atuando como lojas de dados
secundárias para
aplicações comerciais comerciais mais amplas
(COTS). Nestes casos, Oracle
os bancos de dados atuam como repositórios
armazenando dados especializados para uso
em um maior
sistema. Durante a instalação do sistema maior,
o banco de dados Oracle é
instalado como um componente de suporte.
Um exemplo comum de um repositório Oracle
que você pode estar familiarizado é
Oracle Designer. Você pode usar esta
resides on the user’s
desktop. When the user starts Oracle
Designer, it prompts for an Oracle
repository to connect to, and the user specifies
that information. It is within
that repository that all the objects to be used
by the Designer desktop are
stored. In this case, Designer is following the
client-server model described in
the section “Client-server applications,” earlier
in this chapter.
Oracle Internet Directory (OID) is a more
current example of Oracle acting as
a subcomponent within a multi-tiered
environment. OID is the Oracle
implementation
of an LDAP (Lightweight Directory Access
Protocol). LDAPs are
hierarchically defined (not relational) data-
stores (not databases) that allow
systems quick lookup access of data. A
common example is an e-mail address
book, which doesn’t contain a lot of updates
or deeply layered data — it’s
just a need for quick lookups of a piece of
data, which is the core use of
an LDAP.
Another common LDAP use is to store users
and their credentials so that
web application servers can simply look up a
person to see whether she is
authorized to access a system. After all, you
don’t want to allow just anyone
into your system! This credential verification
creates a need for the Oracle
Fusion Middleware products (OFM), and an
LDAP is the solution. And, of
course, with Oracle being a database company
first and foremost, it opted to
put its LDAP implementation inside an Oracle
database, which is OID. (See
Figure 3-3.)
Figure 3-3 shows how a specialized Oracle
database can provide authentication
via OID/LDAP for a larger system that also
happens to use Oracle for the
backend database where traditional customer
data is stored. The OID is just
a necessary component in a larger system.
The idea of this section isn’t to make you an
authority on Oracle Designer or
ferramenta de desenvolvimento Oracle para
projetar, criar e armazenar código de aplicativo
(entre outras coisas), e reside no usuário
Área de Trabalho. Quando o usuário inicia o
Oracle Designer, ele solicita um Oracle
repositório para se conectar, e o usuário
especifica essa informação. Está dentro
esse repositório de que todos os objetos a
serem usados pela área de trabalho Designer
são
armazenado. Nesse caso, o Designer segue o
modelo cliente-servidor descrito em
a seção 'Aplicações cliente-servidor',
anteriormente neste capítulo.
Oracle Internet Directory (OID) é um exemplo
mais atual de Oracle atuando como
um subcomponente dentro de um ambiente de
várias camadas. OID é a implementação do
Oracle
de um LDAP (Lightweight Directory Access
Protocol). LDAPs são
armazenados de dados (não bancos de dados)
definidos hierarquicamente (não relacionais)
que permitem
acesso rápido aos dados dos sistemas de
pesquisa. Um exemplo comum é um endereço
de e-mail
livro, que não contém muitas atualizações ou
dados profundamente em camadas - é
apenas uma necessidade de pesquisas rápidas
de um dado, que é o principal uso de
um LDAP.
Outro uso comum de LDAP é armazenar
usuários e suas credenciais para que
Os servidores de aplicativos da Web podem
simplesmente procurar uma pessoa para ver se
ela é
autorizado a acessar um sistema. Afinal, você
não quer permitir que ninguém
no seu sistema! Esta verificação de credencial
cria uma necessidade para o Oracle
Os produtos Fusion Middleware (OFM) e um
LDAP são a solução. E de
Claro, com a Oracle sendo uma empresa de
banco de dados em primeiro lugar, optou por
Coloque sua implementação LDAP dentro de
um banco de dados Oracle, que é OID. (Vejo
Figura 3-3.)
A Figura 3-3 mostra como um banco de dados
Oracle especializado pode fornecer
autenticação
OID. Rather, it’s to show you that Oracle is
more than just “the database” for
large applications; Oracle also appears in
critical support roles. Your Oracle
installation may be for one of these support
components, but don’t discount
the importance of such a database. Without
the supporting Oracle component
database, the overall system would not be
functional.
Verifying System Requirements
Oracle databases are very good at storing and
accessing data, but a little
prep work helps them to run even better.
Before installing the Oracle software,
you need to do some homework to ensure
that your server can support
the software. We cover a basic Linux
installation in Appendix A, but read and
understand this chapter before jumping to the
software installation.
Each release of Oracle databases is better than
the previous one, but each
version also has minor updates to the
installation requirements. Oracle does
a good job of documenting these updates for
the myriad versions it supports.
This information can be found on the
documentation website at
www.oracle.com/technology/documentation/
d12'atabase.html
Pay particular interest to the Installation Guide
and Quick Installation Guide
for your operating system (OS).
You can avoid many of the installation
problems people experience by just
spending a few minutes reviewing the Oracle
Installation Guide for your specific
OS and meeting those requirements. A quick
review of this guide before
installing a new version can save you hours
troubleshooting issues because
you’re not making mistakes that Oracle has
via OID / LDAP para um sistema maior que
também passa a usar o Oracle para o
backend onde os dados tradicionais do cliente
são armazenados. O OID é apenas
um componente necessário em um sistema
maior.
A idéia desta seção não é fazer de você uma
autoridade no Oracle Designer ou
OID. Em vez disso, é para mostrar que a Oracle
é mais do que apenas 'o banco de dados' para
grandes aplicações; A Oracle também aparece
em papéis de suporte crítico. Seu Oracle
a instalação pode ser para um desses
componentes de suporte, mas não desconto
a importância de tal banco de dados. Sem o
componente Oracle de suporte
banco de dados, o sistema geral não seria
funcional.
Verificando Requisitos do Sistema
Os bancos de dados Oracle são muito bons para
armazenar e acessar dados, mas um pouco
O trabalho de preparação ajuda-os a correr
ainda melhor. Antes de instalar o software
Oracle,
você precisa fazer algum dever de casa para
garantir que seu servidor possa suportar
o software. Cobrimos uma instalação Linux
básica no Apêndice A, mas lemos e
entenda este capítulo antes de saltar para a
instalação do software.
Cada lançamento de bancos de dados Oracle é
melhor do que o anterior, mas cada um
A versão também possui pequenas atualizações
dos requisitos de instalação. Oracle faz
um bom trabalho para documentar essas
atualizações para as inúmeras versões que ele
suporta.
Esta informação pode ser encontrada no site de
documentação em
www.oracle.com/technology/documentation/d
atabase.html
Preste particular interesse ao Guia de
Instalação e ao Guia de Instalação Rápida
para o seu sistema operacional (SO).
Você pode evitar muitos dos problemas de
instalação que as pessoas experimentam
apenas
passando alguns minutos revendo o Guia de
Instalação do Oracle para o seu específico
OS e atendendo a esses requisitos. Uma revisão
rápida deste guia antes
already documented.
User and directory requirements
On UNIX- and Linux-based systems, the
software is installed and configured as a
specific user and group. In most cases, the user
is called oracle, the primary group oinstall, and
the secondary group dba. Here’s a sample of
how this user is defined:
$ id uid=501(oracle) gid=501(oinstall)
groups=501(oinstall),502(dba))
On Windows systems, the software should be
installed as a member of the Local
Administrators group for the machine.
It’s common to have multiple versions of
Oracle running on the same machine
simultaneously. To avoid chaos, you need to
organize how and where each version is
installed. The framework commonly used to
organize and install Oracle software is called
Optimal Flexible Architecture (OFA). As the
DBA, you can use this organizational hierarchy
to install the Oracle software based on
software versions and common directories
used by all versions.
Key to the OFA is the directory environment
variables ORACLE_BASE and ORACLE_HOME:
✓ ORACLE_BASE is where you can find
common software used by all Oracle software
versions; it’s the base of underlying Oracle
code trees.
✓ ORACLE_HOME is a subdirectory and
denotes the location where a specific version
of Oracle database software is installed, often
associated with one or more database
instances.
Here’s the hierarchy:
/directory name/app/oracle/product/version
number/actual software_version_number
Instalar uma nova versão pode economizar
horas em problemas de solução de problemas
porque
você não está cometer erros que a Oracle já
documentou.
Requisitos de usuário e diretório
Nos sistemas baseados em UNIX e Linux, o
software é instalado e configurado como um
usuário e grupo específico. Na maioria dos
casos, o usuário é chamado oracle, o grupo
principal oinstall e o grupo secundário dba.
Aqui está uma amostra de como este usuário
está definido:
$ id uid=501(oracle) gid=501(oinstall)
groups=501(oinstall),502(dba))
Nos sistemas Windows, o software deve ser
instalado como membro do grupo
Administradores locais para a máquina.
É comum ter várias versões do Oracle
executadas na mesma máquina
simultaneamente. Para evitar o caos, você
precisa organizar como e onde cada versão está
instalada. O framework comumente usado para
organizar e instalar o software Oracle é
chamado de Optimal Flexible Architecture
(OFA). Como o DBA, você pode usar essa
hierarquia organizacional para instalar o
software Oracle com base em versões de
software e diretórios comuns usados por todas
as versões.
A chave para o OFA é as variáveis de ambiente
de diretório ORACLE_BASE e ORACLE_HOME:
✓ O ORACLE_BASE é onde você pode encontrar
o software comum usado por todas as versões
do software Oracle; É a base das árvores
subjacentes do código Oracle.
✓ O ORACLE_HOME é um subdiretório e
denota a localização onde uma versão
específica do software de banco de dados
Oracle está instalada, muitas vezes associada a
uma ou mais instâncias de banco de dados.
Aqui está a hierarquia:
/directory name/app/oracle/product/version
Table 3-1 describes each level of the hierarchy.
Table 3-1 OFA Hierarchy
Level Description
directory name - Base directory, file system, or
drive name.
app - Directory name denoting application
software will be located in this tree.
oracle - Owner of the software and is defined
as ORACLE_BASE.
product - Holding directory for software trees.
version number - Directory with unique
version number containing the actual software
installation. Defined as ORACLE_HOME.
Here’s an example of how this hierarchy may
exist on UNIX or Linux:
/u01/app/oracle/product/12.1.0
And on Windows:
d:\app\oracle\product\12.1.0
When you install the database software with
the Oracle installation tool (Oracle Universal
Installer), it guides you through identifying
these locations, but, you need to understand
why each location is defined so you can better
organize your software installations. We
introduce the Oracle Universal Installer in
Appendix A.
In the ORACLE_BASE directory, an Oracle
Inventory directory is created as oraInventory.
Within this directory, Oracle logs a record of
all Oracle software that has been installed,
patched, and removed from the server. This
information is used so that the Oracle
Universal Installer (OUI) and the OPatch utility
can track software dependencies during
installation and patching operations.
The Oracle Inventory is managed
automatically by the OUI and OPatch utilities.
number/actual software_version_number
A Tabela 3-1 descreve cada nível da hierarquia.
Tabela 3-1 Hierarquia OFA
Descrição do Nível
Nome do diretório - Diretório base, sistema de
arquivos ou nome do disco.
app - O nome do diretório que denotar o
software aplicativo estará localizado nesta
árvore.
oracle - Proprietário do software e é definido
como ORACLE_BASE.
produto - Diretório Holding para árvores de
software.
número de versão - Diretório com número de
versão exclusivo contendo a instalação do
software real. Definido como ORACLE_HOME.
Aqui está um exemplo de como essa hierarquia
pode existir no UNIX ou no Linux:
E no Windows:
d:\app\oracle\product\12.1.0
Quando você instala o software de banco de
dados com a ferramenta de instalação Oracle
(Oracle Universal Installer), ele orienta você
através da identificação desses locais, mas você
precisa entender por que cada local está
definido para que você possa organizar melhor
suas instalações de software. Apresentamos o
Oracle Universal Installer no Apêndice A.
No diretório ORACLE_BASE, um diretório Oracle
Inventory é criado como oraInventory. Dentro
deste diretório, o Oracle registra um registro de
todo o software Oracle que foi instalado,
corrigido e removido do servidor. Essa
informação é usada para que o Oracle Universal
Installer (OUI) e o utilitário OPatch possam
acompanhar dependências de software durante
as operações de instalação e correção.
Underneath ORACLE_BASE is an admin
directory with named subdirectories for each
Oracle database, as well as backup, config tool
logs, the Fast Recovery Area, and product
directories:
$ ls $ORACLE_BASE admin backup cfgtoollogs
diag fast_recovery_area product
Of particular importance, under each
ORACLE_BASE/admin/database name
subdirectory is directories for auditing, Data
Pump configuration files, configuration, and
Oracle Security Wallet files:
$ ls $ORACLE_BASE/admin/*
/u01/app/oracle/admin/db01: adump
dpdump pfile xdb_wallet
/u01/app/oracle/admin/dev12c: adump
dpdump pfile xbd_wallet
Table 3-2 shows you directories for auditing,
Data Pump, configuration, and Oracle wallets.
Table 3-2 Database admin Directories
adump - Audit file location. Can generate
many files, but are generally not very large.
dpdump - Location for Data Pump utility.
pfile - Location for database startup
configuration files.
xdb_wallet - Oracle wallets storage area.
These are security devices.
In previous versions of Oracle, bdump, cdump,
and udump directories appeared underneath
each database admin directory storing alert,
trace, and core dump files. However, starting
in Oracle 11g and continuing so in 12c, these
directories appear in trace, alert, and incident
subdirectories under the
$ORACLE_BASE/diag/rdbms/database name
directory. In Figure 3-3, you see the location of
key trace and alert files.
Table 3-3 Trace and Alert File Locations
O Oracle Inventory é gerenciado
automaticamente pelos utilitários OUI e
OPatch.
Por baixo de ORACLE_BASE é um diretório de
administração com subdiretórios nomeados
para cada banco de dados Oracle, além de
backup, logs de ferramentas de configuração,
área de recuperação rápida e diretórios de
produtos:
$ ls $ORACLE_BASE admin backup cfgtoollogs
diag fast_recovery_area product
De particular importância, em cada sub-
diretório ORACLE_BASE / admin / database
name são diretórios para auditoria, arquivos de
configuração da Data Pump, configuração e
arquivos Oracle Security Wallet:
$ ls $ORACLE_BASE/admin/*
/u01/app/oracle/admin/db01: adump dpdump
pfile xdb_wallet
/u01/app/oracle/admin/dev12c: adump
dpdump pfile xbd_wallet
A Tabela 3-2 mostra diretórios para auditoria,
bomba de dados, configuração e
Carteiras Oracle.
Tabela 3-2 Diretórios de administração de
banco de dados
adump - localização do arquivo de auditoria.
Pode gerar muitos arquivos, mas geralmente
não são muito grandes.
dpdump - Localização para o utilitário de
bomba de dados.
Pfile - Localização para arquivos de
configuração de inicialização do banco de
dados.
xdb_wallet - área de armazenamento de
carteiras Oracle. Estes são dispositivos de
segurança.
Nas versões anteriores do Oracle, os diretórios
do bdump, cdump e udump apareceram por
alert - Location of the ever-important activity
log file for your database (XML Format).
cdump - Location of core dump files.
trace - Location of database or user-generated
trace files reflecting an error event. Replaces
bdump and udump directories.
incident - Location of additional trace files
(Plain Text Format).
Oracle manages software installations based
on their ORACLE_HOME directories. Multiple
ORACLE_HOME directories can exist on a
server, each corresponding to a different
version of the database. Different versions can
generally coexist without conflict as they only
share the Oracle Inventory, oratab file, and
database listener process. This separation of
the software into different directories allows
this separation and management to occur.
Here’s an example of multiple ORACLE HOME
directories:
$ ls -1 $ORACLE_BASE/product
12.1.0
11.1.0
10.2.0
In the preceding example, you see multiple
ORACLE_HOME directories installed into
different directories. Defining your
environment variable settings to point to a
specific ORACLE_HOME determines which one
you’re using.
Database files (data, index, control, redo) are
preferably stored in separate file systems
allocated specifically for this purpose and
separated by database names:
/u02/oradata/dev12c
/u03/oradata/dev12c
/u04/oradata/dev12c
The oracle user in group dba needs to be able
to read, write, and execute to the
ORACLE_BASE and ORACLE_HOME directories,
subdirectories, and files, as well as the
database files themselves. If other users on
baixo de cada diretório de administração do
banco de dados armazenando arquivos de
alerta, rastreamento e core dump. No entanto,
começando no Oracle 11g e continuando assim
em 12c, esses diretórios aparecem nos
subdiretórios de rastreamento, alerta e
incidente no diretório $ ORACLE_BASE / diag /
rdbms / database name. Na Figura 3-3, você vê
a localização dos arquivos de rastreamento e
alerta de chaves.
Tabela 3-3 Localizações de arquivos de
rastreamento e alerta
alerta - Localização do arquivo de log de
atividade sempre importante para seu banco de
dados (Formato XML).
cdump - Localização dos arquivos de despejo do
núcleo.
rastreamento - Localização do banco de dados
ou arquivos de rastreamento gerados pelo
usuário refletindo um evento de erro. Substitui
os diretórios bdump e udump.
incidente - Localização de arquivos de
rastreamento adicionais (Formato de texto
simples).
A Oracle administra instalações de software
com base em seus diretórios ORACLE_HOME.
Vários diretórios ORACLE_HOME podem existir
em um servidor, cada um correspondente a
uma versão diferente do banco de dados.
Diferentes versões geralmente podem coexistir
sem conflito, pois compartilham somente o
processo Oracle Inventory, oratab e o ouvinte
de banco de dados. Essa separação do software
em diretórios diferentes permite que esta
separação e gerenciamento ocorram. Aqui está
um exemplo de diretórios ORACLE HOME
múltiplos:
$ ls -1 $ORACLE_BASE/product
12.1.0
11.1.0
10.2.0
No exemplo anterior, você vê vários diretórios
ORACLE_HOME instalados em diretórios
this server need to execute programs on the
server side, such as SQL*Plus or export/import
or SQL*Loader, they need execute permissions
on corresponding executables and, in some
cases, libraries.
Hardware requirements
Oracle software requires a minimum amount
of memory, virtual memory, CPU speed, and
disk space to install successfully. If you lack
these requirements, at best, the software will
run slowly; at worst, it may not even install at
all.
Don’t forget to consider what other software
is executing on the machine, too, both now
and in the foreseeable future. It does little
good to meet the database requirements and
then add more software that will consume
hardware resources beyond what the server
can support.
Several vital server requirements to check
include the following:
✓ Memory: The working area for programs as
they execute, memory is key to fast
diferentes. Definir suas configurações de
variável de ambiente para apontar para um
ORACLE_HOME específico determina qual você
está usando.
Os arquivos de banco de dados (dados, índice,
controle, redo) são de preferência
armazenados em sistemas de arquivos
separados alocados especificamente para esse
propósito e separados por nomes de banco de
dados:
/u02/oradata/dev12c
/u03/oradata/dev12c
/u04/oradata/dev12c
O usuário do oracle no grupo dba precisa ser
capaz de ler, escrever e executar nos diretórios,
subdiretórios e arquivos ORACLE_BASE e
ORACLE_HOME, bem como os próprios
arquivos do banco de dados. Se outros usuários
neste servidor precisam executar programas no
lado do servidor, como SQL * Plus ou exportar /
importar ou SQL * Loader, eles precisam de
permissões de execução nos executáveis
correspondentes e, em alguns casos, nas
bibliotecas.
Hardware requirements
O software Oracle requer uma quantidade
mínima de memória, memória virtual,
velocidade da CPU e espaço em disco para
instalar com sucesso. Se você não possui esses
requisitos, na melhor das hipóteses, o software
funcionará lentamente; na pior das hipóteses,
nem sequer pode ser instalado.
Não se esqueça de considerar o que outro
software está executando na máquina,
também, agora e no futuro previsível. Isso faz
pouco para cumprir os requisitos do banco de
dados e, em seguida, adicione mais software
que consumirá recursos de hardware além do
que o servidor pode suportar.
Vários requisitos vitais do servidor para verificar
incluem o seguinte:
✓ Memória: a área de trabalho para os
performance. The kind you care about here is
Random Access Memory (RAM), and it’s
measured in megabytes (MB) or, more
commonly, gigabytes (GB). Oracle database
SGAs are memory pools. Having large amounts
of memory available allows you to have larger
SGAs. The more memory you have available,
the more options you have when managing
the ever important SGA.
✓ Virtual memory: When a program or data is
being executed, it’s stored in memory. When
that same program isn’t actively being
executed but will be momentarily, it’s stored
in virtual memory (for MS Windows) or swap
(for UNIX/Linux operating systems). This
system administrator defined disk area
operates as a slower extension of memory.
Generally, virtual memory is sized to between
3⁄4 to twice the size of installed memory.
✓ CPU speed: The clock speed of your CPU
(central processing unit) is important. If the
CPU is old (and slow) and is laboring just to
keep the OS running, then adding an Oracle
database isn’t a good idea.
Additionally, if so many other programs are
running and consuming the CPU, you can have
problems trying to run Oracle. For as much
hype as you hear about CPU speeds, a better
solution than having one fast CPU is having
multiple CPUs; even if they are a little slower,
more CPUs are better than fewer.
✓ Disk: The disk is where the Oracle database
software is stored — essentially on your hard
drive. The disk is only where your Oracle
software itself is installed; it’s not where your
actual database files will exist with all your
data. Oracle software installations take only a
few gigabytes, but actual databases can take
terabytes.
Like most software, a minimum value is listed
by the vendor but more is generally better.
Table 3-4 lists the minimum hardware
requirements for 12c databases.
Table 3-4 Minimum Hardware Requirements
programas que executam, a memória é a chave
para um desempenho rápido. O tipo que você
gosta aqui é Random Access Memory (RAM), e
é medido em megabytes (MB) ou, mais
comumente, em gigabytes (GB). O banco de
dados Oracle SGAs são pools de memória. Ter
grandes quantidades de memória disponíveis
permite que você tenha SGAs maiores. Quanto
mais memória você tiver disponível, mais
opções você terá ao gerenciar o sempre
importante SGA.
✓ Memória virtual: quando um programa ou
dados estão sendo executados, ele é
armazenado na memória. Quando esse mesmo
programa não está sendo ativado ativamente,
mas será momentaneamente armazenado na
memória virtual (para MS Windows) ou swap
(para sistemas operacionais UNIX / Linux). Esta
área de disco definida pelo administrador do
sistema funciona como uma extensão mais
lenta da memória. Geralmente, a memória
virtual é dimensionada entre 3/4 e duas vezes o
tamanho da memória instalada.
✓ Velocidade da CPU: a velocidade do relógio
da sua CPU (unidade de processamento central)
é importante. Se a CPU é antiga (e lenta) e está
trabalhando apenas para manter o sistema
operacional em funcionamento, a adição de um
banco de dados Oracle não é uma boa idéia.
Além disso, se tantos outros programas
estiverem funcionando e consumindo a CPU,
você pode ter problemas para tentar executar o
Oracle. Para tanto hype como você ouve sobre
a velocidade da CPU, uma solução melhor do
que ter uma CPU rápida está tendo várias CPUs;
mesmo que sejam um pouco mais lentas, mais
CPUs são melhores que menos.
✓ Disco: o disco é onde o software de banco de
dados Oracle está armazenado -
essencialmente no seu disco rígido. O disco é
apenas onde seu próprio software Oracle está
instalado; Não é onde seus arquivos de banco
de dados reais existirão com todos os seus
dados. As instalações do software Oracle levam
apenas alguns gigabytes, mas os bancos de
dados reais podem ter terabytes.
Operating System RAM Virtual Memory/Swap
CPU Disk
Windows 2GB 2 times RAM 550 MHz 6GB
Linux 2GB 1 to 2 times RAM 550 MHz 6GB
When identifying where you’re going to install
the software, make sure that you allow space
for growth — don’t just go with the minimum
hardware requirements. After you install the
software, you may have patches to apply
(which take space), and log files will grow as
the software runs; you don’t want to run out
of space!
Software requirements
Como a maioria dos softwares, um valor
mínimo é listado pelo fornecedor, mas
geralmente geralmente é melhor. A Tabela 3-4
lista os requisitos mínimos de hardware para
bancos de dados de 12 c.
Tabela 3-4 Requisitos mínimos de hardware
Sistema operacional RAM Memória virtual /
Swap CPU Disk
Windows 2GB 2 vezes RAM 550 MHz 6GB
Linux 2 GB 1 a 2 vezes RAM 550 MHz 6GB
Ao identificar onde você vai instalar o software,
certifique-se de permitir espaço para o
crescimento - não vá com os requisitos mínimos
de hardware. Depois de instalar o software,
você pode ter patches para aplicar (que leva
espaço) e os arquivos de log crescerão à
medida que o software for executado; Você não
quer ficar sem espaço!
Requisitos de software