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ê!
Nenhum comentário:
Postar um comentário