A Virtual Portion pode crescer

Segmento inicial Tamanho Configurável

            +

Segmento Adicional   Tamanho Configurável

Por causa da natureza das informações armazenadas na virtual portion da shared memory, a quantidade de shared memory usada pelo servidor varia dependendo da atividade. Em momentos de grande atividade, mais shared memory pools são criados, e os pools existentes podem ser expandidos. Se mais espaço for necessário para a porção virtual, segmentos adicionais de shared memory são acrescentados automaticamente.

Uma vez que os segmentos de shared memory são alocados para o servidor, eles somente podem ser liberados pelo administrador executando o utilitário onmode ou mudando o servidor para o modo off-line.

Shared Memory: The Virtual Portion

A virtual portion da shared memory é usada para muitos propósitos. Alguns destes propósitos são listados a seguir:

• Mapeamento dos Dados das Sessões – cada sessão tem seu próprio pool o qual contem os dados particulares da sessão. O nome de um session pool  é o mesmo session_id que é dado ao usuário. Quando uma sessão desconecta-se de um servidor , este session pool é liberado.
• Cache das informações do dicionário – os dictionary pools mantem em memoria as informações das tabelas de catalogo do sistema.
• Cache das stored procedures – stored procedures usadas por uma sessão são mantidas nos procedures pools.
• Informações de Thread – MT pools mantem estruturas e stacks usadas para controlar as threads.
• Ordenação – o espaço temporário para ordenação de dados é alocado como um sort pool.
• Big Buffer – Big Buffer são usados pelo AIO VPs que gravam um grande bloco de paginas para o disco de uma vez. É alocado um Big Buffer por AIO VP.
• Informação Global – dados diversos não pertencentes a uma sessão em especifico são guardados no global pool.

Alocação de Shared Memory: The Virtual Portion

Quando o servidor necessita de memória para um propósito especifico, ele reserva uma memória não usada dentro da virtual portion. A memória reservada para um propósito especifico é conhecida como um shared memory pool. Um memory pool é alocado para um propósito especifico; por exemplo, para armazenar dados particulares de um usuário. Atualmente, existem mais de 50 tipos de shared memory pools que podem ser alocados. Os pools podem ser alocados a qualquer momento e são liberados quando eles não são mais necessários. Quando o espaço de um pool é liberado, o espaço é disponibilizado para que o servidor possa reutilizá-lo.

O Servidor controla alocações de memória para um memory pool mapeando o uso da memória com paginas bitmap. A memória é alocada da virtual portion para uso do servidor em incrementos de 8Kb, valor este que não pode ser modificado. Cada bit em uma pagina bitmap mapeia um bloco de 8Kb.

The Resident Portion: LRUs

Quando o servidor precisa trazer uma página do disco para a shared memory, ele deve primeiro localizar um buffer para dentro do qual colocará a página. Todo buffer é mapeado através de diversas listas conectadas de ponteiros conhecidas como filas Least Recently Used (LRU). Os pares de filas LRU têm uma fila livre, a FLRU (LRU Livre) e uma fila modificada, a MLRU (LRU modificada).

Quando o servidor é colocado em modo on-line pela primeira vez, todas as páginas dos buffers (as quais estão vazias), são distribuídas igualmente nas FLRU dos pares de LRU. Esta distribuição é para balancear a associação das páginas do buffer dentre as filas de FLRU de modo que uma fila não gere um gargalo.

Quando uma thread de usuário precisa de um buffer, o servidor seleciona um Least Recently Used buffer randomicamente em uma das filas de FLRU que não estão reservadas por nenhuma outra thread de usuário. Se a página está sendo modificada, o buffer é colocado em um Most Recently Used buffer na fila de MLRU. Se a página foi lida, mas não foi modificada, o buffer é retornado para o Most Recently Used buffer na fila de FLRU.

The Resident Portion: Logical Log Buffers

O logical logs é um log, ou atualmente uma coleção de logs, em disco que recebe as entradas DML (Insert, Update, Delete) de banco de dados com log, assim como DDL para todas as tabelas. Com servidores IBM Informix, o mesmo grupo de logs é compartilhado por todos bancos de dados. Transações de diferentes bancos de dados são intercaladas no interior dos logs de transação.

Como a quantidade de dados gravados nestes logs pode ser grande, para ajudar a reduzir a quantidade de I/O físico necessário para gravar os dados no disco, o dado é primeiro colocado em um buffer, o qual será transferido para o disco mais tarde. O servidor aloca três buffers, para uso com os logical logs.

Historia do Shell

A primeira versão do shell padrão do UNIX foi introduzido na V7 (Sétima edição pela AT&T) no final de 1979, e foi batizado pelo nome do seu criador, Stephen Bourne. O Bourne Shell é uma linguagem de programação baseada em uma linguagem de programação chamada Algol. E foi utilizado primeiramente para gerenciar tarefas de administração do sistema. Embora popular pela sua simplicidade e velocidade, ele não tem muitas características para o uso interativo, como o histórico, aliases e controle de tarefas.

O C Shell, desenvolvido pela Universidade da Califórnia em Berkeley no final de 1970, foi lançado como parte do UNIX 2BSD. O Shell, foi escrito por Bill Joy, oferecendo um numero adicional de características não encontradas no Bourne Shell. O C Shell é baseado na linguagem de programação C, e quando usada como linguagem de programação, compartilha uma sintaxe similar ao C. Ele também oferece melhorias para o uso interativo, como o histórico de linha de comando, aliases e controles de tarefas. o C Shell foi projetado para grandes Servidores e por isso características adicionais foram adicionadas, o C Shell tem uma tendência de ser mais lento, tanto em Servidores de pequeno porte quanto Servidores de Grande porte em comparação ao Bourne Shell.

Tanto o Bourne Shell e o C Shell disponível, usuários UNIX tinha agora uma escolha e conflitos para saber qual o melhor Shell. David Korn, da AT&T, criou o Korn Shell pelos meados dos anos 80. Foi lançado em 1986 e tornou-se oficialmente parte da distribuição UNIX SVR4 em 1988. O Korn Shell, é realmente um superconjunto do Bourne Shell, rodando não somente nos sistemas UNIX, mas também no OS/2, VMS e mesmo no DOS. isso fornece alta compatibilidade com o Bourne Shell, acrescenta muitas características popular do C Shell, e é muito rápido e eficiente. O Korn Shell passou por uma serie de revisões.

Introdução ao UNIX SHELLs

Definição e função

O Shell é um programa especial usado como uma interface entre o usuário e o coração do Sistema Operacional UNIX, chamado de kernel, como mostra a figura abaixo:

O kernel é carregado na memoria no momento do boot e gerencia o sistema ate o momento do shutdown. Isso cria e controla processos, e gerencia memorias, sistemas de arquivos, comunicações, e assim por diante. Todos os outros programas, incluindo shells scripts residem fora do disco. O kernel carrega esses programas em memoria, executa-os, e limpa o sistema quando terminar. O shell é um programa que inicializa quando você faz um logon. Isso permite os usuários interagir com o kernel interpretando os comandos digitados pelo usuário em linha de comando ou em um shell script.

Quando você faz logon, um shell interativo é iniciado e um prompt fica aguardando a sua entrada. Depois de digitar um comando, é de responsabilidade do shell: (a) analisar a linha de comando; (b) lidar com wildcards, redirecionamentos, pipes e controle dos trabalhos; e (c) pesquisar pelo comando e se encontrado, executar o comando. Quando você estuda UNIX pela primeira vez, recomendo passar uma boa parte de seu tempo digitando comandos em prompt. Use a interatividade do shell.

Se você costuma executar um conjunto de comando regularmente, você pode querer automatizar essas tarefas. Um arquivo de script permite que você crie um conjunto de comandos, e então execute esse script. Um shell script é muito parecido com um arquivo de lote do Windows: É uma lista de comandos UNIX e então esse arquivo é executado. Scripts mais sofisticados contem instruções de programação para criar decisões, looping, e muito mais. Escrever um script não requer somente estudar técnicas de programação, mas sim que você tenha um bom conhecimento dos utilitários UNIX e como eles trabalham. Existem alguns utilitários, como grep, sed e awk, que são ferramentas extremamente poderosas usadas em scripts para a manipulação das saídas dos comandos. Depois que você se familiarizar com essas ferramentas e com construção de programas, você estará pronto para escrever scripts poderosos. Ao executar comandos dentro de scripts, você estará usando o shell como uma linguagem de programação.

 

Os três principais Shells

Os três principais Shells e suportados na maioria dos sistemas UNIX são o Bourne Shell (AT&T Shell), o C Shell (Berkeley), e o Korn Shell (superconjunto do Bourne Shell). Todos esses três Shells se comportam praticamente da mesma forma quando executado, mas tem algumas diferenças na sintaxe e eficiência quando utilizado como linguagem de programação.

O Bourne Shell é o shell padrão do UNIX, e o shell é usado para administrar o sistema. A maioria dos scripts de administração do sistema, como os scripts rc start  e stop e shutdown são scripts Bourne Shell, e quando em modo single user, este é o shell usado pelo root. Este shell foi escrito pela AT&T e é conhecido por ser objetivo, compacto e rápido. O prompt padrão do Bourne Shell é o sinal de dólar ($).

O C shell foi desenvolvido e adicionado uma serie de característica pela Berkeley, como o histórico de linha de comando, aliases, cálculos aritméticos controles de tarefas. O C Shell tem sido melhor em comparação ao Bourne Shell para usuários que rodam em shell interativo, mas administradores  preferem o Bourne Shell para script, porque o Bourne Shell são simples e bem mais rápidos comparado com scripts escrito em C Shell. O prompt padrão do C Shell é o sinal de porcentagem (%).

O Korn Shell é um superconjunto do Bourne Shell escrito por David Korn da AT&T. Uma serie de recursos foram adicionados a esse shell além das melhorias do C Shell. As características do Korn Shell inclui um histórico editável, aliases, funções, expressões regulares, cálculos aritméticos, controles de tarefas e debug, entre outras. O Bourne Shell é quase totalmente compatível com o Korn Shell. O prompt padrão do Korn Shell é o sinal de dólar ($).

The Resident Portion: Physical Log Buffers

Outra parte importante da resident portion da shared memory é usada para log buffers. O physical log é um log especial usado para mecanismos de tolerância à falhas do servidor. Ele contém as Before images (apenas a primeira cópia) de páginas de dados e índices que estão no buffer pool e estão sendo modificadas desde o momento que elas foram lidas do disco.

Para reduzir a quantidade de I/O físico associado com a manutenção desde log, os buffers são usados na gravação do log; ao invés de gravar cada entrada diretamente no disco, as entradas são gravadas em um buffer, o qual é transferido para o disco mais tarde. Como o servidor tem o controle sobre quando estes buffers são transferidos para o disco, ele pode garantir que eles serão transferidos quando necessário.

The Resident Portion: Buffer Pool

A maior parte da resident portion da shared memory é usada para o buffer pool (também conhecido como buffer cache), o qual é uma coleção de buffers dedicados a armazenar em cache, os dados do disco. Armazenar páginas de dados em shared memory permite que muitos usuários leiam e gravem dados sem no momento ter de realizar leituras e gravações nos discos. Nos capítulos seguintes, você aprenderá como especificar o número de buffers para usar em seu servidor.

Shared Memory: the Resident Portion

O principal uso da resident portion da shared memory é para conter o buffer pool. O buffer pooI mantém páginas de dados das tabelas dos bancos de dados. A resident portion também mantém o controle de outros recursos do servidor.

O servidor alocará algumas coleções de estruturas de dados nesta porção da shared memory. Estas estruturas são algumas vezes conhecidas como tabelas internas, mas tenha em mente que não são como as tabelas de banco de dados.

O servidor de banco de dados associa uma tabela interna para cada um dos principais recursos do servidor. O tamanho dessas tabelas internas é configurável ajustando o tamanho do recurso da shared memory usando o onmonitor, ou modificando o arquivo onconfig.

O componente Shared Memory

A shared memory no servidor é dividida em três porções. Cada uma destas porções é listada abaixo e explicada em maiores detalhes nos capítulos posteriores.

· Resident portion – a porção resident portion contém o buffer pool e outras informações do sistema. Esta parte da shared memory pode ser configurada para permanecer residente na memória principal (se esta capacidade é suportada pelo sistema operacional).

· Virtual portion – a virtual portion contém informações sobre as threads e sessões, e os dados que são usados por elas. Estas informações crescem e diminuem constantemente, sendo que o servidor de banco de dados é responsável pelo controle de alocação e liberação de memória nesta porção.

· Message portion – a message portion armazena os message buffers que são usados na comunicação entre o cliente e o servidor quando o método de comunicação é feito através da shared memory.

Componente de Processo: Virtual Processors

Os processos que compõe o servidor de banco de dados são conhecidos como virtual processors.

Cada virtual processor pertence a uma classe de virtual processor. A classe VP é um ou mais processos responsáveis por um conjunto específico de tarefas ( na forma de threads), como gravações para o logical log ou leitura de dados do disco. Isto significa que um VP de uma certa classe pode somente executar threads da mesma classe. Cada VP na classe VP é apenas outra instância do mesmo programa. Um VP pode pertencer somente a uma classe. Uma classe VP pode ter um ou mais VPs, o que em muitos casos é configurável pelo administrador do sistema.

VPs são executados como root. Isto é necessário porque o VP deve executar certas tarefas como o usuário que iniciou a tarefa (como gravar a saída de um SET EXPLAIN ou executar o SYSTEM da SPL). Tendo VPs executando como root, tem-se o beneficio adicional de proteção dos processos do servidor de banco de dados. Somente root ou informix pode eliminar um VP. Se você executar um processo de status no UNIX, o virtual processors aparecerá como processos chamados de oninit.

Visão da Arquitetura

O servidor é composto por três grandes componentes. Os componentes são introduzidos nas paginas seguintes e discutidos em detalhes nos capítulos posteriores.

O Componente Processo

O componente Processo define o database Server. Os processos que definem o database Server são conhecidos como virtual processors. Ao nível do UNIX esses processos são chamados oninit. Cada virtual processor (VP) pertence a uma classe de virtual processor. Uma classe de VP é um conjunto de processos responsáveis por um conjunto especifico de tarefas.

O Componente Shared Memory

O Segundo componente é a Shared Memory. A Shared Memory é feita de três porções: residente, virtual e de mensagem. A Shared Memory é usada para:

· Cópia dos dados do disco para shared memory para acesso mais rápido (resident portion);

· Manutenção e controle dos recursos solicitados pelos processos (virtual portion);

· Um mecanismo de comunicação para os processos cliente e servidor falarem entre si para coordenar suas atividades (message portion).

O Componente Disco

Seguindo, há o componente disco. Esta é um coleção de uma ou mais unidades de espaço em disco designado para o sistema do servidor. Todos os dados nos banco de dados, além de toda a informação do sistema necessário para manter o servidor, são armazenados dentro do componente disco.