Início da Conexão: Rede, Listener e Transport Protocol
1.1. Conexão de Rede
- Biblioteca Usada: O processo de conexão começa no cliente com a biblioteca libclntsh.so (Oracle Client Shared Library), que gerencia a comunicação via Oracle Net Services.
- Protocolo de Transporte: A conexão de rede usa o protocolo TCP para se conectar à porta configurada (geralmente 1521) no servidor Oracle. Se for um ambiente com segurança, pode envolver o protocolo SSL/TLS, utilizando certificados digitais para autenticação, configurados via Oracle Wallet.
1.2. Verificação de Rede e Firewall
O sistema operacional Linux verifica as regras de iptables (ou firewalld) para determinar se a porta está aberta para aceitar a conexão. Se a porta estiver fechada, a conexão é imediatamente negada pelo sistema.
1.3. O Listener: Validação Inicial da Conexão
O Oracle Listener, um processo separado do Oracle Database chamado tnslsnr, gerencia a aceitação de conexões externas.
- Verificação do listener.ora: O Listener consulta o arquivo de configuração listener.ora para verificar a configuração do service_name.
- Biblioteca Utilizada: O Listener usa libntc.so para gerenciar a conexão e é parte do pacote Oracle Net Listener.
1.4. Registro e Status do Listener
- Registro pelo PMON: O Listener consulta o Process Monitor (PMON), que é responsável por registrar informações de serviço do banco de dados no Listener. PMON mantém o Listener informado sobre o estado das instâncias e serviços Oracle.
- Verificação do Estado do Banco: O Listener consulta se o banco está no estado OPEN ou READ ONLY, validando se o banco pode aceitar conexões. Ele também verifica se há permissões de SERVICES que limitam o acesso ao banco (como dbms_service).
2. Autenticação do Usuário e Senhas
2.1. Solicitação de Senha
Uma vez que o Listener redireciona a conexão para o Oracle Database, a instância começa o processo de autenticação. O processo dedicado ou compartilhado começa a verificar as credenciais do usuário:
- Metadados (DBA_USERS): A tabela DBA_USERS é consultada para verificar a existência do usuário. O Oracle também examina a coluna PASSWORD_VERSIONS nesta tabela para determinar se a senha foi armazenada em versões de hashing antigas (como 10G) ou modernas (como SHA-2, utilizado a partir de Oracle 12c).
2.2. Verificação Case-Sensitive
- Case-Sensitive: Se o banco de dados estiver configurado para senhas case-sensitive, o Oracle compara a senha com precisão de maiúsculas e minúsculas. O Oracle começou a usar senhas case-sensitive a partir da versão 11g, com a coluna PASSWORD_CASE na tabela DBA_USERS refletindo se a senha é ou não sensível a maiúsculas.
2.3. Hashing da Senha
- SHA-2 (Oracle 19c): A senha fornecida é convertida em um hash usando SHA-2. O Oracle compara o hash gerado com o valor armazenado na tabela DBA_USERS. Se os hashes corresponderem, a autenticação prossegue.
- Algoritmos Anteriores: Se o Oracle detectar que o hash da senha foi gerado com um algoritmo mais antigo (por exemplo, MD5 ou o hash específico do Oracle anterior ao SHA-2), ele pode forçar o usuário a redefinir sua senha ou gerar um novo hash automaticamente.
2.4. Perfis e Restrições
Após a autenticação bem-sucedida, o Oracle verifica se o usuário está sujeito a um perfil de senha:
- DBA_PROFILES: A tabela DBA_PROFILES é consultada para verificar restrições, como limites de tempo de inatividade, expiração de senha, e número máximo de tentativas de login falhas (o padrão é FAILED_LOGIN_ATTEMPTS).
- Ação do Sistema: Se o usuário exceder o número de tentativas falhas, o Oracle bloqueia a conta e registra o evento em DBA_AUDIT_SESSION (se a auditoria estiver habilitada).
3. Triggers de Logon e Verificação de Permissões
3.1. Triggers de Logon
Antes que a sessão seja oficialmente criada, o Oracle executa triggers de logon, se configurados:
- AFTER LOGON Trigger: O Oracle verifica a tabela DBA_TRIGGERS para encontrar triggers que disparam no logon. Estes triggers podem:Configurar parâmetros de sessão (como configurações de NLS, fuso horário, etc.).Realizar auditoria personalizada, gravando logs em tabelas específicas.Controlar permissões adicionais de sessão, como impor restrições de logon por IP.
Se o trigger falhar, o login é imediatamente rejeitado e o Oracle emite um RAISE_APPLICATION_ERROR.
3.2. Verificação de Privilégios
Após o trigger de logon, o Oracle começa a verificar as permissões do usuário.
- DBA_SYS_PRIVS e DBA_ROLE_PRIVS: O Oracle consulta as visões DBA_SYS_PRIVS e DBA_ROLE_PRIVS para identificar quais privilégios e roles (papéis) o usuário tem. Isso pode incluir permissões como SELECT, INSERT, UPDATE, EXECUTE em objetos do banco de dados, além de privilégios administrativos (GRANT ANY PRIVILEGE, SYSDBA, etc.).
- Atribuição de Roles: Se o usuário tiver roles que precisam ser ativados (via SET ROLE), isso é processado neste ponto.
3.3. Segurança com VPD (Virtual Private Database)
Se o VPD (Virtual Private Database) estiver habilitado, o Oracle aplica políticas de controle de acesso com base em colunas ou linhas da tabela. O Oracle consulta a visão DBA_POLICY_GROUPS e aplica políticas de segurança que limitam o acesso a registros específicos, de acordo com o perfil do usuário.
4. Sessão Criada: PGA, SGA e Processos de Background
4.1. Alocação de PGA e Registro em V$SESSION
Agora que as verificações de permissões foram concluídas, o Oracle aloca uma PGA (Program Global Area) exclusiva para o usuário.
- PGA e Memória Associada: A PGA contém informações como:Cursores abertos para a sessão.Memória de ordenação e hash join.Contexto de execução PL/SQL.
A sessão também é registrada na tabela V$SESSION, que monitora todas as sessões ativas no banco.
4.2. Utilização da SGA e Processos de Background
Com a sessão criada, o Oracle começa a interagir com a SGA (System Global Area). Isso inclui:
- Buffer Cache: O Oracle tenta ler e gravar dados diretamente do Buffer Cache. Se houver um cache hit, os dados são retornados da memória.
- Cache Miss: Se os dados solicitados não estiverem na memória, o DBWR (Database Writer Process) é acionado para buscar os dados diretamente dos datafiles.
4.3. Redo Log Buffer e LGWR
Para qualquer operação DML (INSERT, UPDATE, DELETE), o Oracle registra as mudanças no Redo Log Buffer, e o processo LGWR (Log Writer) grava essas informações no online redo logs em disco. Esse processo garante a recuperação de dados em caso de falhas.
5. Logoff: Commit, Rollback e Auditoria
5.1. Commit Automático ou Rollback
Quando o usuário emite um logoff, o Oracle verifica o estado das transações abertas. Se uma transação estiver ativa:
- Commit Automático: O Oracle realiza um commit automático das transações pendentes, gravando as mudanças permanentemente nos datafiles.
- Rollback Automático: Se o usuário encerra a sessão abruptamente, o Oracle faz um rollback automático de qualquer transação não confirmada.
5.2. Liberação de Recursos
Após o logoff, o Oracle libera os recursos da sessão:
- Liberação de PGA: Toda a memória associada à PGA é liberada.
- Remoção de V$SESSION: A sessão é removida da visão V$SESSION, e o Oracle fecha todos os cursores abertos.
5.3. Auditoria de Logoff
Se a auditoria de logon/logoff estiver habilitada, o Oracle registra a ação de logoff na tabela DBA_AUDIT_SESSION. Esta tabela armazena informações como:
- Nome do usuário.
- Data e hora do logon e logoff.
- Motivo do logoff (normal, timeout, erro de sessão).
O Complexo Processo de Login no Oracle 19c
Cada conexão de usuário no Oracle 19c envolve um conjunto complexo de verificações e operações em segundo plano que garantem a segurança, integridade, e eficiência do banco de dados. Desde a autenticação de senha e execução de triggers até a interação com a PGA e SGA, o Oracle utiliza um conjunto sofisticado de processos de background e bibliotecas que tornam cada conexão uma operação minuciosamente controlada.
Entender cada detalhe desse processo permite que administradores de banco de dados identifiquem problemas de performance e segurança, além de otimizar o uso do sistema.
Muito obrigado por acompanhar até aqui. Grande abraço.