BD-Oracle – Servidor com processos dedicado/compartilhado

A arquitetura do Dedicated Server
Quando usuários fazem requisição ao banco de dados, o listener do servidor gera processos de servidor dedicado para cada conexão da instância. Dessa forma, num ambiente onde existam 100 (cem) usuários conectados à instância no modo dedicated server, hà pelo menos 100 (cem) processos no servidor de banco de dados, ou seja, para cada conexão com o banco de dados, existe 1 (um) processo oracle de servidor dedicado. Em ambientes como esse, o servidor de banco de dados estaria com pelo menos 120 (cento e vinte) processos sendo executados simultaneamente devido aos processo de background do próprio Oracle. Assim, a performance pode cair se o SO não conseguir gerenciar de forma adequada, um grande número de processos concorrentes, e o problema será maior ainda se o servidor não tiver memória suficiente.

Para suprir as necessidades da demanda dos processos de servidor dedicado, pode-se incrementar memória ou CPU para aumentar os recursos do sistema ou, implementar o Shared Server.

A arquitetura do Shared Server
Quando o Shared Server é configurado, o Oracle adiciona dois novos tipos de estruturas na SGA: Request Queue e Response Queue. Essas estruturas não existem no ambiente de servidor dedicado. Existe um request queue para todos os dispatchers mas cada dispatcher tem seu próprio response queue. Assim, se você tem quatro dispatchers, você terá um request queue e quatro response queue. O request queue está contido na SGA que é exatamente onde os dispatchers colocam as requisições dos clientes. O processo Shared Server executa cada requisição e coloca a requisição completada na response queue de do seu respectivo dispactcher.
Num ambiente de servidor dedicado, cada serviço é um segmento de memória chamado de Program Global Área (PGA). A PGA é a área de memória onde as informações (variável bind, informações de cursor e a área de classificação) de todos os clientes são mantidas. Num ambiente Shared Server, as informações são movidas da PGA para uma área da SGA chamada User Global Area (UGA). O Large Pool acomoda a maior parte da UGA. O Virtual Circuits é um pedaço da área de memória compartilhada com a qual provê a ligação com processos de usuários.

Como o Shared Server funciona
Quando um processo de usuário emite uma declaração SQL, ela é enviada para o dispatcher. O dispatcher coloca todas as declarações recebidas dentro de uma fila (queue). Esta fila é chamada de common queue, porque todos os dispatchers compartilham-na. Todas as declarações são enviadas ao final da fila.
Todos os shared server processes monitoram a common queue. Quando uma declaração chega à common queue, o primeiro shared server disponível a levanta.

Cada dispatcher monitora sua própria fila de resposta, e, sempre que qualquer resultado é colocado na fila, o dispatcher a levantará e retornará ao processo de usuário que emitiu a declaração.
O resultado do mecanismo do dispatcher e queue, é que qualquer declaração de qualquer processo de usuário poderá ser executado por qualquer shared server disponível. Isto levanta a questão de como o estado da sessão pode ser mantida: A PGA, para um dedicated server armazenará os dados da sessão, o estado do cursor, o sorte space e o stack space. Mas, no ambiente shared server, como apenas o stack space reside na PGA, cada declaração pode ser levantada da fila por qualquer shared server.

A memória usada na SGA para cada sessão shared server, conhecida como User Global Área (UGA), inclui tudo da PGA com exceção do stack space das sessões, como dito anteriormente.

Como habilitar o Shared Server
Para uma configuração básica, a maioria dos parâmetros de configuração do Shared Server são opcionais, apenas 1 (um) é obrigatório que é o DISPATCHER.

Pode-se adicionar dispatchers com o comando:

sql> alter system set dispatchers = “(PRO=TCP)(DIS=5)”;

Os dois principais atributos são DISPATCHERS e PROTOCOL. Por exemplo, se você quiser configurar três dispatchers TCP/IP e dois dispatchers IPC, basta setar os seguintes parâmetros:

DISPATCHERS = “(PRO = TCP)(DIS=3) (PRO = IPC)(DIS=2)”

O parâmetro SHARED_SERVER define a quantidade de shared server que será iniciada junto com a inicialização da instância e define também a quantidade minima de shared servers que a instância terá, independente do momento.

CIRCUITS e SHARED_SERVER_SESSIONS, definem como os usuários serão permitidos se conectar através de um shared server. Conexões de usuários entre o dispatcher e o Shared Servers são chamados de Virtual Circuit. Para especificar o número de circuitos disponíveis, basta setar o parâmetro circuits, no arquivo de parâmetros de inicialização. Este parâmetro contribui para a requisição total de SGA para uma instância. Ele deve ser compatível com o atributo SESSION de dispatcher ou igual à 0.
Finalmente, dois parâmetros mais básicos: os parâmetros SESSIONS e PROCESSES não são necessariamente relatados para o shared server. Eis logo à baixo como configurar um arquivo tnsnames.ora para uma conexão dedicada em um servidor que opera com shared server. Observe que a única diferença está no atributo SRVR:

# tnsnames.ora Network Configuration File:
# C:\oracle\product\10.1.0\db_1\network\admin\tnsnames.ora
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ENDERECO01)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = orcl)
(SRVR = DEDICATED) # Necessário para uma conexão dedicada
)
)
Quando usa-se o Oracle Shared Server, faz-se necessário primeiro, iniciar o listener e depois o banco de dados. Isso permite que os dispatcher imediatamente registrem-se com o listener. No caso do listener for iniciado depois do banco de dados, teria que esperar alguns minutos até que o service fosse registrado.

Gerenciando o Número de Dispatchers
É possível iniciar dispatchers adicionais ou remover dispatchers dinamicamente usando o comando ALTER SYSTEM. Pode-se iniciar quantos dispatchers forem necessários acima da configuração do parâmetro MAX_DISPATCHERS. É mostrado abaixo o comando para adicionar 3 dispatchers que fazem utilização do protocolo TCP/IP, em um sistema que já contém dois dispatches:
sql> ALTER SYSTEM SET DISPATCHERS=”(PRO=TCP)(DIS=5)”;

Note que não foi especificada a quantidade de dispatcher que queríamos iniciar, e sim, a quantidade total de dispatchers que queríamos. Tínhamos 2, adicionamos 3 (três) quando especificamos o número total igual à 5 (cinco).

Configurando o Connection Pooling com o parâmetro DISPATCHERS
Pode habilitar a conexão pool adicionando atributos ao parâmetro DISPATCHERS. O atributo POOL especifica que o dispatcher terá permissão para conexões pooling. Configure este atributo para o valor ON para habilitar o connection pooling para o dispatcher. Você também precisa especificar o atributo TICK e setar o número de 10 minutos para conexões inativas serem consideradas IDLE:
DISPATCHERS = “(PRO = tcp)(DIS = 1)(POOL=on)(TICK = 1)(CONN = 500)(SESS = 1000)”

Neste exemplo, nós queremos tornar a conexão pooling. Uma conexão inativa será considerada INATIVA, apenas depois de 10 minutos de inatividade. Queremos também que o dispatcher TCP/IP manuseie o máximo de 500 conexões concorrentes e o máximo 1000 sessões por dispatcher.

Quando utilizar o Shared Server
Em um ambiente OLTP, por exemplo, em uma central telefônica. Existem muitas chamadas recebidas, efetuadas, em espera, etc. Aparentemente, o shared server seria ideal para manter muitas transações pequenas efetuadas onde a massa de trabalho é no lado do cliente na divisão client/server. Nessas circunstâncias, um shared server poderia servir uma dúzia de sessões. Mas para processar as execuções, um dedicated server seria muito melhor. A segunda classe de operações que são melhores efetuadas através de shared server, é o trabalho de administração do banco de dados. Criação de índices, criação e manutenção de tabelas, e o trabalho de backup e recuperação do bando de dados com o RMAN teria uma melhor performance através de um dedicated server. Além disso, é logicamente impossível emitir um comando startup ou shutdown através de um shared server, porque? Porque o shared server é uma parte da instância e, por conta disso, não está disponível uma vez que seja emitido o comando startup ou shutdown. Assim, o administrador de banco de dados teria que ter sempre um dedicated server.


ERROR ORA-12520: TNS:listener could not find avaliable handler for requested type of server

Os comandos abaixo configuram o servidor de forma a corrigir este erro.

Em Oracle for Windows
SQL> Conn system as sysdba
SQL> Alter System Set Dispatchers='(PRO = tcp)(DIS = 1)(POOL=on)(TICK = 1)(CONN = 500)(SESS = 1000)'
System altered.

Em Oracle for Linux
SQL> Conn system as sysdba
SQL> Alter System Set Dispatchers='(PRO=tcp)(DIS=1)(PRO=ipc)(DIS=1)(POLL=on)(TICK=1)(CONN=500)(SESS=1000)'
System altered.

Views relacionadas:
V$QUEUE
V$DISPATCHER
V$DISPATCHER_RATE
V$SHARED_SERVER

Instruções complementares:

Verificar estatisticas que ocorrem enquanto sua aplicação executa as instruções
SQL:
SELECT DECODE(TOTALQ, 0, 'No Requests', WAIT/TOTALQ || ' HUNDREDTHS OF SECONDS') "AVERAGE WAIT TIME PER REQUESTS" FROM V$QUEUE WHERE TYPE = 'COMMON';

Verificar como muitos processos de servidores compartilhados estão atualmente executando as pesquisas:
SELECT COUNT(*) "Shared Server Processes" FROM V$SHARED_SERVER
WHERE STATUS != 'QUIT';