Qual é a diferença entre Database, Instance e Service Name?

Se você um dia for trabalhar com RAC, leia este artigo!

Database Name. É o nome usado para a estrutura física do banco de dados. Esta informação é armazenada no cabeçalho do control file e datafile. Usado para identificar todas as estruturas físicas que pertencem ao mesmo banco de dados. Definido no momento da instalação. Originalmente defnido pelo parâmetro estático denominado database_name e não pode ser mudado, a não ser que você recrie seu controlfile e reset a sequência de logs.

Instance Name.É o nome dado às estruturas de memória + processos de Background (MEM + BGP) usado para montar e abrir o banco de dados. No ambiente RAC existem mais de uma instância abrindo o mesmo banco de dados e cada instância deve ter nomes diferentes. Num ambiente sem RAC, geralmente o nome da instância e o nome do banco de dados são iguais. Não é preciso usar nomes diferentes.O nome da instância é definido pela variável de ambiente chamada ORACLE_SID. Usada para estabelecer a conexão com o banco de dados como uma "connect string".

Service Name. É definido pelo parâmetro dinâmico denominado service_names, no plural, porque podem ser definidos diversos nomes de serviços, dependendo da necessidade de configuração. Exemplo de uso: fail over (contingência), resource manager (controle de recursos), balanceamento de recursos.

Vamos nos aprofundar mais um pouco em serviço ou Service Name?

Um serviço é uma representação lógica de uma ou mais instância. Quando você especifica SERVICE_NAMES="AlgumaCoisa" no seu arquivo tnsnames.ora você não está pedindo para se conectar a uma instância especifica. De fato o que você está dizendo é que "não me interessa a qual instância estou sendo conectado, contanto que eu receba o serviço esperado".

Num ambiente onde existe somente uma instância, service_names e instance são sinônimos, ou seja, uma coleção de estruturas de memória e processos que fornecem um serviço. Portanto, não faz sentido alocar mais de um service_names para uma mesma instância.

O conceito de serviço faz muito mais sentido num ambiente onde existem várias instâncias (RAC - Real Application Cluster). Nesse ambiente algumas instâncias podem fornecer um serviço, enquanto outras podem oferecer outros serviços. Um serviço então pode ser uma forma de fazer um particionamento lógico do seu ambiente em RAC em áreas funcionais. Nesse caso, o serviço seria utilizado para dividir e priorizar recursos dentro de um RAC.

O serviço é a chave para um ambiente em contingência uma vez que ele não significa "conecte-me a uma instância". Por exemplo, se você disse conecte-me ao SID=INST1, então você solicitou uma conexão a uma determinada instância, mas se esta instância cair, tudo bem, você perdeu a conexão ao banco de dados, mas foi uma opção feita por você. Você pediu, você recebeu! Se ao invés disso você se conectar ao serviço VENDAS que está sendo fornecido pelas instâncias INST1 e INST2, então se a instância INST1 cair por qualquer motivo, o mesmo serviço estará sendo fornecido pela INST2 e você será conectado a segunda instância como forma de contingência.

Este conceito explica porque nunca deverá existir um banco de dados chamado VENDAS e as instâncias e serviços serem também nomeados como VENDAS. Também não deverão existir instâncias chamadas VENDAS1 e VENDAS2 e serviços chamados VENDAS1 e VENDAS2. Este equívoco contraria o conceito de service_names. O correto então seria ter um serviço chamado VENDAS, as instância denominadas VENDAS1 e VENDAS2 e o banco de dados seria VENDASDB. Nenhum conflito de nomes e conceitos, ok?

É crítico dominar estes conceitos principalmente quando se migra para um ambiente no qual se usa RAC ou Data Guard. Esta sútil diferença ajuda principalmente quando vemos que muitos costumam confundir serviço com instância e depois sofrem quando migram para o RAC porque recebem erros na configuração do ambiente.

Esse não será você!

ORA-00313 ,ORA-00312 - Erro na abertura de redo logs

Sempre que você migrar seu banco de dados, tenha em mente que a opção archive log deve ser desativada, caso contrário você poderá receber estes erros ORA.

ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/oradata2/data1/dbase/redo02.log'

Ah, você esqueceu? Não tem problema, vamos ver como abrir seu banco mesmo assim.

Causa do problema:
-----------------------------
Seu banco de dados estava em modo archive, Você deu shutdown e quando tenta o startup, seu redo log pode não mexistir ou está corrompido (open reset logs)

Solução do problema:
--------------------------------
A)Monte the database.
SQL>STARTUP MOUNT
Database mounted.

B) Verifique a condição do logile para certificar que ele é o corrente.

SQL> SELECT STATUS FROM V$LOG WHERE GROUP#=2;
STATUS
----------------
CURRENT

C) Se ele não for o corrente (CURRENT) ent~/ao simplesmente remova (drop) o log file by,
SQL>ALTER DATABASE DROP LOGFILE GROUP 2;

Se existirem somente 2 grupos de log, então será necessário incluir um novo grupo, antes de remover um deles, pois devem existir no mínimo 2 log groups.

Então antes da remoção:

SQL>ALTER DATABASE ADD LOGFILE GROUP 4 '/oradata2/redo3.log' SIZE 10M;

Como a condição de CURRENT não permite remover o grupo, você deverá executar uma recuperação FALSA antes de abrir com a opção "resetlogs".

SQL>RECOVER DATABASE UNTIL CANCEL;
Responda com CANCEL.

Agora você já pode abrir seu banco de dados!
SQL>ALTER DATABASE OPEN RESETLOGS;

EXALOGIC - Solução Oracle para aplicações Web

Executar todas as suas aplicações num servidor único? Essa seria a nova estratégia da Oracle conhecida como "Cloud in a box" - algo como nuvem de processamento numa caixa (servidor). Denominado de Exalogic computação em nuvem, esta solução provê a possibilidade de uma configuração mais simples até a expansão de vários hardwares conectados entre sí.

Este hardware elegante que exibe os logos da SUN e ORACLE pode ser configurado com 30 servidores composto de 360 núcleos, rede (InfiniBand de 40Gbits) e armazenamento (storage SUN). Faz parte do pacote de soluções a tecnologia de virtualização da Oracle (VM) com a possibilidade de escolha entre os sistemas operacionais Solaris e Linux. De fato, o pacote completo Exalogic inclui ainda O software Exalogic, sistema operacional, o Oracle JRockit e HotSpot, e WebLogic e Oracle Coherence caching solution.

O conceito de nuvem da Oracle seria uma plataforma de aplicativos baseados em padrões e plataforma de execução. Isto inclui hardware e software. É virtual e expansível e executa uma variedade de aplicações.

A proposta do Exalogic é atender à aplicações em ambientes AWS, ou seja, voltados à WEB. Os testes de benchmark mostraram uma melhora de 12 vezes na performance das aplicações desenvolvidas para a internet.

Feito para suportar requisições de HTTP superiores a 1 milhão por segundo, seria como se fosse possível suportar o tráfico do Facebook em apenas 2 racks. Além disso, O Exalogic mostrou excelente performance no tratamento de mensagens, na ordem de 1,8 milhões de mensagens por segundo.

De fato, o sistema Exalogic seria mais apropriado para entregar a melhor performance em aplicações Java, com possibilidade de expansão, tolerância à falha, segurança e simplicidade de manutenção.

Outro comparativo, segundo a Oracle, demonstraria que o sistema Exalogic teria um custo 4 vezes inferior ao dos melhores servidores IBM, além da possibilidade de crescimento em até 8 racks. A linha top da IBM, o Power 795 system, não teria essa escalabilidade.

A Orale lançou também uma nova versão do Unbreakable Enterprise Kernel, sistema operacional Linux da Oracle. A promessa é entregar um sistema operacional 5 vezes mais performático que o Linux Rad Hat.

"O Red Hat se encontra 4 anos atrasado tecnologicamente, isto é um problema enorme para nós", informou Ellison (CEO da Oracle). "Não podemos nos dar ao luxo de ficar atrasados em 4 anos" completou Ellison.

A solução Exalogic parece vir complementar o sistema Exadata (recomendado para DatawareHouse), criando um parceria de sucesso em performance. No entanto, ainda não parece ser viável para aplicações transacionais, seja por seu custo ou mesmo pela sua natureza que seria atender grandes bases de dados suportando ambientes Java na Web.

Mas novidades na Oracle não param por aí. Ainda em 2010 deverá ser lançado uma máquina voltada para aplicações OLTP (transacionais).

Abrir Banco de dados sem REDOs e ARCHIVEs, É possível?

Se você não possui salva do seu banco de dados e archivelogs tudo pode estar perdido...

A não ser que você conheça o parâmetro _ALLOW_RESETLOGS_CORRUPTION = TRUE.

Sua única chance de recuperar seu banco. Este parâmetro não é suportado pela Oracle. Então use com moderação.

Inclua este parâmetro no seu pfile e então abra o banco de dados com a opção OPEN RESETLOGS. Depois remova-o e execute os seguintes passos:

1) Faça export full de toda a base de dados.
2) Crie um control file "alter database backup controlfile to trace;".
3) Edite o arquivo de trace (*.trc ), localizado no diretório user_dump_dest, para remover todos os datafiles exceto o SYSTEM, TEMP and RBS/UNDO. Então renomeie o arquivo .trc para .sql com um nome sugestivo.
4) Salve o arquivo INIT<SID>.ORA que será usado mais tarde.
5) Recrie o banco de dados conectando-se com a instância IDLE e execute STARTUP NOMOUNT (use o pfile do passo 4) use o comando CREATE CONTROLFILE ... LOGFILE ... DATAFILE ... a partir do arquivo criado no passo 3.
6) Execute o CATALOG, CATPROC como se estivesse criando um banco de dados novo.

7) Faça um import do arquivo de dump criado no passo 1. Este procedimento criará todos os indexes e dados nas tabelas.
8) As transações perdidas poderão agora ser recriadas a partir de programas que abortaram o momento da perda do banco de dados.

Pronto! Eu já precisei disso, mas o melhor sempre é fazer backup.

"Só Jesus SALVA, o homem faz BACKUP".