"ATENÇÃO" - MUDANÇA ENDEREÇO

Prezados leitores,

para melhor comodidade estamos mudando o blog para o link abaixo:

http://hudsondatablog.wordpress.com/

Espero que o visual seja mais limpo. O campo de pesquisa por palavras funciona que é uma beleza. No menu de categorias é de fácil navegação.

Espero que gostem.


Novidades toda semana.

Renomear um banco de dados SQL Server

ALTER DATABASE <old_name>
SET SINGLE_USER WITH ROLLBACK IMMEDIATE --Colocando o banco em modo de acesso para apenas um usuário e fechando as transações correntes efetuando rollback nas mesmas.

ALTER DATABASE CardManagement MODIFY NAME = <new_name> --Comando para modificar o nome do banco de dados

ALTER DATABASE <new_name>
SET MULTI_USER  --Voltando a base para modo de multi usuários.

Como escrever um bom currículo e aumentar suas chances para ser convidado a uma entrevista

Escrever um currículo balanceado não é uma arte. Ele só exige um planejamento e uma compreensão do que você quer conseguir com ele.

É claro que ai também reside um problema, porque muitas pessoas não sabem exatamente o querem que seu currículo faça por elas. Muita das vezes você encontra uma lista de resumos de candidatos que apresentam uma única tecnologia, ou encontra gerentes de contratação lendo um currículo que é de oito páginas e se perguntando quando a dor desta monstruosidade toda vai acabar. A verdade é que o gerente de contratação nem sequer irá lê todo o currículo, ao invés, simplesmente moverá imediatamente para um próximo sem dar-lhe um novo pensamento. 

 Você quer que seu currículo seja aquele que fica esquecido? Claro que não! 

Compartilharei com você exatamente o que você precisa fazer a fim de criar um currículo vencedor para uma entrevista para um Administrador de Banco de Dados (DBA), ou qualquer outra profissão que você possa imaginar que se enquadre nesta matéria. 

 O segredo para um currículo de sucesso se resume em uma única frase: Mantenha as coisas simples!

A fim de garantir que o seu currículo lhe de a melhor chance possível de garantir sua próxima entrevista, ele deve ser:

1. Legível 

2. Relevante 

3. Preciso 

4. Valioso 

Vamos dar uma olhada em cada regra detalhar um pouco mais para descobrir exatamente o que é necessário. 

1- Legível 

Seu currículo deve ser um prazer de ler. Deve ser uma experiência fácil para o leitor, permitindo-lhes achar imediatamente por zonas a informação que procuram. 

A linguagem que você usa deve ser conciso e direto ao ponto. 

Você tem uma quantidade limitada de espaço para usar, a fim de vender a si mesmo e que pretende faze-lo no prazo de duas páginas. Isso mesmo, o seu currículo deve ser de duas páginas no máximo. Algo alem você não estará sendo conciso ou relevante o suficiente. 

Em resumo alguns dos pontos que você vai querer considerar são?

• Digitalizavel – Seu currículo é de fácil visualização? O leitor pode encontrar facilmente informações? 
• Concise – Fique no ponto. Seja específico e não desfoque. 
• Incorporar as listas de marcadores - Estes irão melhorar a estrutura do seu conteúdo, tornando-o digitalizavel e mais fácil de consumir.
• Considere a escolha da fonte – Mantenha-o claro e profissional. Fique longe de fontes criativas e paletas de cores. 
• Limite de duas páginas - Não esmagar o seu conteúdo. Seja implacável com o que você incluir.

 2- Relevante 

Inclua apenas o que é relevante para o papel “especifico” para direcionar o seu currículo. Pode ser tentador para listar cada habilidade que você pode estar colocando o seu currículo para frente para um numero diferente de oportunidades, mas se as habilidades não são relevantes, então eles não vão demonstrar o valor para o leitor. 

A ironia de ter tudo no currículo é que ele realmente não valerá nada. É comprovadamente preguiçoso. Não faça isso! 

Em resumo alguns dos pontos que você vai querer considerar são: 

• Seja especifico – Incluir apenas as informações pertinentes para o papel. 
• Não inclua referencias – Você será solicitado para eles, se e quando necessário. 
• Use o espaço para conteúdo “valioso”,
• Excluir interesses pessoais – Sua personalidade vai deparar/ser promovido durante a entrevista. 

3 – Preciso 

A invenção do verificador ortográfico foi uma coisa maravilhosa gente, então não há realmente nenhuma desculpa para erros ortográficos ou gramática pobre. 

Todos os bons profissionais de dados têm uma excelente atenção ao detalhe, não conseguem obter esse direito e você está praticamente apenas demonstrar que você não tem o que é preciso. Em resumo alguns dos pontos que você vai querer considerar são: 

• Ortografia e Gramática - Confira, verifique-o, peça a alguém para ler a prova. 
• Precisão de fatos e informações - O uso de nomes de produto / tecnologia corretas e versões.

 4 – Valioso

Por que devo contratar você? Você sabe o agrupamento do SQL Server, e daí? Por que isso é útil para mim como proprietário de uma empresa? 

Demonstrar o valor do negócio e ter entregue algo a entregar por causa do que você sabe ou tem feito. 

Listar apenas tecnologia e habilidades é chato. Leve o seu currículo para o próximo nível, mostrando claramente ao leitor como você agrega valor com o que você sabe.

 Seja factual em sua entrega e tenha em mente que você levá-la para o outro extremo, você vir à acabar transversalmente como arrogante. 

A ênfase exigido de valor financeiro demonstrará para um diretor de vendas muito mais do que é necessário para o BI Developer. Você precisa encontrar o equilíbrio certo para o seu mercado.

Em resumo alguns dos pontos que você vai querer considerar são:

• Expertise - Demonstre seu valor através dos resultados de suas ações que foram ativados por suas habilidades.
• Principais Realizações - Faça um ponto a destacar suas grandes vitórias e conquistas. Implementação de solução para todo DR proteção de ativos no valor de x milhões de reais? Diga ao leitor. 
• Valor demonstrável - Receita, economia de custos, consciência empresarial. O que faz de você um trunfo para lhe ter na equipe?
•  Paixão - Mostre seu amor pela tecnologia (ou campo escolhido) e para a aprendizagem.

 Sempre simples

Com essas quatro regras simples que você deve fazer se o seu currículo ajudará a lhe dar a melhor chance possível de vencer o próximo ponto da entrevista.

O que você acha que é importante para a criação de uma boa entrevista em cima do  currículo?

Boa sorte com sua busca de trabalho!

Reindexar Banco de Dados SQL SERVER

O que é indexar, reindexar e por que é importante?

Imagine uma biblioteca, onde existam vários livros e muitos estudantes utilizam essa biblioteca diariamente, pegando livros das estantes para ler.

Para facilitar o estudante encontrar o livro, os livros estão organizados em estantes que são separadas por áreas, como humanas, exatas e assim por diante.

Isso se compara a um índice no Banco de Dados, onde a biblioteca é o banco(tabela) e os livros são os registros, e o fato de estarem organizados(indexados) facilita na hora de encontrar um registro.

Porém, os estudantes quando pegam um livro não podem devolver novamente no mesmo lugar, pois poderiam cometer algum erro e estragar a ordem dos livros, então deixam-no sobre uma mesa para que a pessoa responsável organize quando puder, para que esses livros não fiquem indisponíveis quando outro estudante precisar deles, a pessoa responsável mantém uma lista com todos os livros que estão sobre a mesa, para que caso o estudando não localize o livro, ela veja se o mesmo não está sobre a mesa.

Da mesma forma, ela mantém uma lista para livros novos que chegaram e ainda não foram organizados nas estantes e para livros que foram retirados do acervo. E assim que possível, ela reorganiza os livros para que fiquem na ordem novamente deixando mais rápida a busca.

Contudo, este trabalho não pode ser feito o tempo todo, pois os estudantes teriam que ficar esperando que ele se completasse para que então pudessem pegar os livros que estão procurando.

O fato de reindexar uma tabela se compara ao ato de recolocar os livros nas estantes novamente e eliminar as listas paralelas, ou seja, quando inserimos, atualizamos ou deletamos um registro, o índice fica desfalcado desses registros, é como se eles estivessem em uma lista separada, porém a reindexação não pode ser feita o tempo todo e automaticamente, pois necessitária que quem estivesse tentando acessar a tabela em questão precisasse esperar o termino da reindexação.

por isso é importante de tempos em tempos que façamos a reindexação das tabelas do nosso banco de dados, assim deixaremos o acesso aos dados mais rápido.

bom, para reindexar uma tabela no SQL SERVER, precisamos executar o seguinte comando:

DBCC DBREINDEX ('NOME_DA_TABELA', '', 80)

Onde o primeiro parâmetro se refere ao nome da tabela, o segundo ao nome do índice(opcional) e o terceiro é o percentual de cada index em relação ao armazenamento dos dados.

Para reindexar um banco inteiro, basta utilizar a sotored procedure SP_MSFOREACHTABLE que é responsável por percorrer todas as tabelas do banco e executar um comando designado.

EXEC SP_MSFOREACHTABLE @command1= "DBCC DBREINDEX ('?', '', 80)"

Pronto, todas as tabelas do seu banco estarão reindexadas e provavelmente haverá melhora na performance do mesmo.

Obs: Se possível realize está operação quando não houver usuários utilizando o banco. pois bloqueia o acesso a tabela até que o índice seja refeito.

Otimizando Bancos de Dados Oracle com Database Smart Flash Cache

•
 
Olá pessoal,

     Hoje vou comentar sobre um recurso muito bom que surgiu no Oracle Database 11GR2 e que chama-se Database Smart Flash Cache (DSFC). Ele serve para otimizar a performance de um Banco de Dados (BD) quando a memória RAM disponível no Servidor é insuficiente para atender a demanda da Buffer Cache, criando uma nova área de memória chamada Flash Cache, que ao invés de armazenar seus dados em memória RAM, armazena-os em disco(s) SSD (Solid State Disk).

     Ao utilizar DSFC, a Flash Cache funciona como uma extensão da Buffer Cache e permite armazenar dados que não caberiam ou que consumiriam muito espaço nela. Isso permite evitar o I/O físico que seria gerado caso a Buffer Cache estivesse cheia, pois neste caso ocorreriam leituras/escritas físicas diretas nos datafiles, que estão armazenados em discos rígidos tradicionais. O grande segredo para ganhar desempenho utilizando DSFC é que evita-se o I/O físico nos discos rígidos substituindo-os por I/O nos discos SSD, que apesar de serem bem mais caros e de menor capacidade, são também mais rápidos (média de 2x à 3x mais rápidos). Mas tome cuidado! Apesar de gerar menos I/O, o consumo de CPU irá aumentar. Outro ponto que devemos nos atentar para obter boa performance com DSFC é utilizar somente DRAM SSD e não Flash SSD. Jamais utilize Flash SSD!

  

     É importante ressaltar que o I/O na Flash Cache (em discos SSD) é menos eficiente do que o I/O na Buffer Cache (em memória RAM), portanto, devemos utilizar DSFC somente quando identificarmos depois de um bom diagnóstico prévio (conhecimento que pode ser adquirido nos treinamentos Performance Tuning for Oracle DBAs), que o uso da Buffer Cache não está sendo suficiente, que não há mais memória RAM disponível no Servidor para aumentar a SGA (e consequentemente a Buffer Cache), e quando temos discos SSD no Servidor, disponíveis para a Flash Cache.
     

     DSFC é bom para uso em ambientes OLTP e ambientes com Oracle RAC, e está disponível somente para o Oracle Database Enterprise Edition (versão 11GR2 ou superior) e Sistemas Operacionais (SO) Enterprise Linux ou Solaris (mais um motivo para você evitar instalar Oracle em SO Windows). 

     Após habilitar DSFC, devemos configurar individualmente cada objeto (tabela ou visão materializada) que desejamos armazenar na Flash Cache. Uma dica é configurar apenas aqueles objetos grandes e/ou objetos que não são utilizados constantemente, e que poderiam gerar I/O físico nos discos rígidos. Em um benchmark realizado no Oracle White Paper "Optimizing Oracle Database Performance on Oracle Linux with Flash" (ver referências), o ganho de desempenho ao habilitar DSFC foi de 228% no tempo de resposta das instruções SQL que foram executadas durantes os testes.

     DSFC introduz no BD 2 novos parâmetros (ver Imagem 01), que devem ser configurados para utilizar o recurso: 

  
          1- DB_FLASH_CACHE_FILE: identifica o dispositivo flash (raw device, arquivo em um disco SSD ou ASM disk group). No Oracle DB 11GR2  (patchset 11.2.0.4 ou 11.2.0.3 + Patch 12949806) é possível especificar somente 1 dispositivo flash, mas no 12C já é possível utilizar múltiplos dispositivos. Em ambientes RAC, cada nó deve possuir o seu próprio dispositivo;

  
          2- DB_FLASH_CACHE_SIZE: identifica o tamanho máximo de armazenamento flash. Indica-se configurar entre 2 à 10 vezes o tamanho da SGA.

 Segue abaixo um roteiro para vermos um exemplo de como habilitar DSFC e configurar um objeto para que seus dados sejam armazenados na Flash Cache:

1- Habilitando a Flash Cache:

    Conectado na instância do BD, com privilégios de DBA, execute o comando abaixo para habilitar o dispositivo flash, substituindo o texto em cor cinza pelo valor desejado:

    SQL> alter system set db_flash_cache_file = '/tmp/teste.fc' scope=spfile; 

2- Configurando o tamanho da Flash Cache:

    Conectado na instância do BD, com privilégios de DBA, execute o comando abaixo para configurar o tamanho da Flash Cache, substituindo o texto em cor cinza pelo valor desejado:

    SQL> alter system set db_flash_cache_size = 100M scope=spfile; 

3- Reinicie o BD:

    Execute os comandos abaixo para reiniciar o BD e permitir que as configurações efetuadas nos itens anteriores passem a vigorar:

    SQL> shutdown immediate;

    SQL> startup;

4- Configure um objeto para que ele utilize a Flash Cache:

    Execute o comando abaixo para que uma tabela seja armazenada na Flash Cache, substituindo o texto em cor cinza pelo valor desejado:

    SQL> alter table schema.table storage (flash_cache keep);


Referências:
   - Optimizing Oracle Database Performance on Oracle Linux with Flash, An Oracle White Paper, November 2013;
   - Oracle Database Smart Flash Cache, An Oracle White Paper, September 2010;
   - Oracle flash_cache tips, IT Tips by Burleson Consulting, September 5,  2012

Blogger voltando com força total

Comunicado!

Fui obrigado a me ausentar por problemas pessoais e também para focar na certificação MCTS (Microsoft Certified Technology Specialist) SQL Server 2008, que graças a Deus conquistei.
Os estudos já estão em cima da atualização para a certificação MCSA SQL Server 2012. (Falarei em posts posteriores dos caminhos para quem quer se certificar ou atualizar suas certificações.)

O Blogger voltará com força total. Novidades na área de administração de banco de dados, B.I, Big Data, dicas de administração, tunning e certificação. Um conteúdo mais trabalhado criado com todo carinho.

Aguardem...

Hudson L. Santos

Oracle: Criando campo como chave primário e de sequencial automático

Pessoal, boa tarde!
Hoje vamos falar de uma coisa bem simples, mas que faz uma grande diferença na hora de inserir registros na tabela. Quando queremos criar um sequencial, mas não podemos criar em cima de um campo que será índice.

Para esses casos, vai uma dica,  criar um campo que será PK e que será um sequencial da tabela.
Para continuar no exemplo, iremos criar uma tabela Funcionário, como mostra o Script abaixo:


create table FUNCIONARIO (
FUNC_SEQ NUMBER(10),
NOME VARCHAR2(10),
SALARIO NUMBER(17,2),
CODIGO NUMBER);


Vamos alterar a nossa tabela para receber a Chave Primária.

alter table FUNCIONARIO add constraint PK_FUNCIONARIO primarykey (FUNC_SEQ);


Agora vamos criar uma sequência:

CREATE SEQUENCE FUNC_SEQ MINVALUE 1 MAXVALUE 9999999999
INCREMENT BY 1 START WITH 1;

Essa sequência irá até o valor “9999999999”, já que o tamanho do campo vai até 10.


Após ter criado essa sequência, iremos criar uma TRIGGER para alimentar o campo Func_Seq com a sequência criada.

CREATE O RREPLACE TRIGGER FUNC_TRG BEFORE INSERT ON FUNCIONARIO
FOR EACH ROW
BEGIN
<<COLUMN_SEQUENCES>>
BEGIN
IF :NEW.FUNC_SEQ IS NULL THEN
SELECT FUNC_SEQ.NEXTVAL INTO :NEW.FUNC_SEQ FROM DUAL;
END IF;
END COLUMN_SEQUENCES;
END;  

Toda vez que inserirmos algum registro, não será necessário incluir um valor para o campo Func_Seq.
Exemplo:
INSERT INTO FUNCIONARIO(NOME, SALARIO, CODIGO)
VALUES (‘JOSE’, 1500, 2);

Com a nossa Trigger, ele já irá atribui de forma automática o novo valor para campo Func_seq.
Galera, eu sei que é bem simples, mas as vezes nos ajuda bastante.

Abraços.

Indices (o poder da busca). Parte II

Indicies clusterizados vs Índices não clusterizados

Índices clusterizados:

     Cada tabela só pode conter apenas um índice clusterizado.
     Os índices clusterizados fornecem uma ordem de classificação para o armazenamento de dados dentro de uma tabela, mas não fisicamente pois, geraria grande volume de I/O (Entrada e saída de disco).
      Em geral toda tabela deve ter um indicie clusterizado, normalmente definimos como chave primaria.

     Um dos principais objetivos de um indicie clusterizado é eliminar os ponteiros de encaminhamento. Lembra-se da estrutura B-Tree? Caso não tenha lido, recomendo o artigo: Estrutura B-Tree, resumindo, as informações são armazenadas nas folhas e para que o SGDB busque as informações, são 'rastreadas' pelas chaves de indicie que é o numeral que indica o numero da linha em questão.
 
      Existem algumas restrições para os indicies clusterizados: Podem ter 900 Bytes na chave de indicie e no máximo 16 colunas. 
Por padrão, o SQL Server cria indicie clusterizado exclusivo para a chave primaria.

Índices não clusterizados:

      Os índices não clusterizados não impõem uma ordem de classificação na tabela. Podem-se criar vários indicies não clusterizados dentro de uma tabela e como os índices clusterizados, podem ter no máximo 900 Bytes na chave de índice e no máximo 16 colunas.

    Se existe um índice clusterizado na tabela, o índice não clusterizado possuem ponteiros que apontam para o índice a chave de cluster. Se não existe índice clusterizado, o indicie não clusterizado aponta para a linha de dados na tabela. Isto faz com que seja feita mais uma operação necessária para localizar dados dentro de uma linha na tabela degradando um pouco a desempenho em comparação a tabela existir um índice clusterizado.


Performance:

    Podemos imaginar que podemos então encher uma tabela com índices já que são tão formidáveis assim.
Não é bem por ai, cada linha adicionada em uma tabela ou excluída, fará com que o SGDB reconstruía o indicie na arvore B-Tree. Se houver um estouro de pagina, haverá a divisão de níveis e o SGDB terá que recalcular e alocar as chaves de indicies nas paginas da estrutura B-Tree.

    Embora sejam eficientes para consultas SQL, temos esta restrição de recriação de estrutura de dados B-Tree quando ocasionamos operações de INSERT, UPDATE, DELETE.

   Nos bancos OLTP isso pode ser bastante prejudicial devido à quantidade de transações no banco, então cada índice criado temos que analisar suas intenções dentro da tabela e ver se realmente ele é necessário e testar o qual o ganho que podemos ter.
    Dentro de bancos OLAP, como o nível de transações são baixos e a inserção de dados é normalmente através de operações em lote e agendada em horários com baixa incidência de consultas, é bastante interessante ter vários índices nas colunas mais acessadas.

Indices (o poder da busca). Parte I

    Para falarmos dos indicies primeiramente precisamos entender a estrutura de busca de um SGDB à informação.
     A estrutura de busca por indicies das principais ferramentas de SGDB do mercado usa uma arquitetura de busca mais conhecida com B-Tree. 
     A arquitetura de busca B-Tree se baseia em um conceito de paginas de alocação de dados.
Vejamos a figura abaixo:

   
Nota-se claramente que temos 3 níveis, dai o nome B-TREE. Cada nível tem a denominação:

     Primeiro nível: Raiz;
     Segundo nível: Intermediário;
     Terceiro nível: Folhas.

      Em especial no SGDB SQL Server, cada página pode possuir até 8.060 Bytes de dados.
      Se guardarmos um valor de índice INT, (lembrando que para coluna de valor  INT são alocados 4 Bytes), teremos uma conta simples: 8.060 / 4 = 2.015 linhas que será armazenado em cada folha. Caso ultrapasse este valor, 2.016 linhas serão alocadas mais uma folha e a distribuição dos dados entre elas como podemos ver observando a figura de baixo para cima os valores de 1 a 500.

      Na primeira folha foi alocado 1 a 250, quando necessitou do alocamento do valor 201, subitamente quebrou-se a quantidade de dados suportados por uma pagina (8.060 Bytes), assim sendo, foi-se necessário adicionar mais uma pagina de dados para alocar o valor 251. Logo acima, foi criado mais um nível contendo as entradas para os níveis subsequentes. Como se fossem ponteiros onde teremos o ponteiro para o lado esquerdo informando: "Ei, do meu lado esquerdo temos os valores de 1 até 250, e do meu lado direito temos os valores de 251 em diante".. E assim sucessivamente.
  
      É muito difícil de que um SGDB tenha dados suficiente de índice para montar os três níveis, pela simples conta:
      Se cada nível pagina de folha consegue alocar 2.015 entras, ou seja, no nível abaixo temos para cada pagina podemos alocar 2.015 folhas temos a multiplicação de 2.015 folhas por 2015 entradas de dados do nível acima, dando o valo de 4.060.255. Ou seja, só é necessário apenas duas paginas para encontrar qualquer dado entre 1 a 4060255 linhas em uma tabela. "Isso mesmo, apenas duas paginas para 4 milhões de linhas".

     Este tipo de estrutura permite que o SGDB encontre linhas em tabelas extremamente grandes muito rapidamente.
     Como podemos notar a estrutura B-Tree de índices funciona praticamente como índice de um livro ou dicionário. Você abre o começo do livro, procura pela palavra/assunto que deseja e verifica a pagina que está palavra/assunto está. É muito mais ágil do que percorrer todo livro em busca da palavra/assunto que lhe convém.

Próximo post continuaremos com Índices e seus tipos.
Até..

Entendendo a arquitetura ORACLE

Temos no produto Oracle uma instancia e um banco. Claro, você pode usar varias instancias para acessar um banco de dados Oracle o que ocorre no Real Aplication Cluster ou cluster de aplicativos reais. Também é possível editar links para a instancia acessar outros bancos Oracle, mas iremos focar no um-para-um, ou seja, uma instancia para um banco.

Estrutura da instancia: Memória e Processos.

Uma instancia Oracle consiste em um bloco de memória compartilhada, conhecida como SGA (System Global Área) a que possui basicamente três elementos obrigatórios: Pool compartilhado, cachê de buffer do banco e o buffer de log. Opcionalmente poderá ter pool extenso, Java pool e um pool de streams.

O Pool compartilhado:

No pool compartilhado iremos abordar dois componentes de sua estrutura: O cachê da biblioteca de dados e o cachê de dicionário de dados.

O cachê de biblioteca de dados consiste em armazenar as instruções SQL na sua forma interpretada. Ajuda no desempenho para evitar que se interprete sempre instruções mais usadas no banco. Quando um usuário fornece uma instrução para o banco, ela será armazenada no cachê de biblioteca de dados para que seja usada posteriormente pelo mesmo usuário ou por outros evitando assim processos para a interpretação da mesma.

O cachê de dicionário de dados armazena objetos, descrições de tabelas, índices usuários e outras definições de metadados.

Cachê de buffer do banco:

O cachê de buffer do banco de dados é uma área onde são executados as instruções SQL. Antes dos dados irem para parte física são armazenados na cachê de buffer aguardando uma confirmação para acesso ao disco. Isto evita E/S em disco desnecessário alem de ser uma segurança para os dados.

Buffer de log:

Usado para armazenamento de todas as modificações aplicadas aos dados presentes no cachê de banco de dados. Está parte da memória só é usada quando os dados armazenados no cachê de banco são manipulados.

Pool extenso:

Uma área opcional a ser criada. Usada automaticamente por vários processos que de uma forma tomaria a memória do pool compartilhado. O gerenciador de recuperação (Recovery Manager, RMAN), também usará o pool extenso para seus processos de E/S.

Pool Java:

Requerido para instanciar os objetos do Java.

DICA Exame:  Os três principais elementos da instancia Oracle são: Pool compartilhado, cachê de buffer do banco e pool de log.

SMON Monitor de sistema,

Função de habilitar as conexões entre o banco e a instancia.

PMON Monitor de processos,

Procura e organiza sessões de usuários, mantendo até mesmo historio de sessão caso desconexão imprevista de algum usuário para que o mesmo ao se conectar novamente, volte aos seus processos.

DBWn Escritor do bano de dados,

Escreve as atualizações do cachê de buffer do banco para o disco fisico. Normalmente o Oracle mantém essas atualizações no mínimo de nível possível para evitar assim E/S o que ajuda substancialmente o desempenho do banco.

LGWR Escritor de logs,

Envia todas as modificações que foram feitas entre o cachê de buffer de banco para o disco, atualizando os redo on-line. Ao efetivar uma modificação com o COMMIT, será escrito nos arquivos de redo log on-line a modificação que foi realizada e a partir daí efetivada no banco físico. Isso garante um auto backup onde podemos dizer que o Oracle efetivamente garante que seus dados não serão perdidos.

CKPT checkpoint.

De tempos em tempos o banco atualiza os arquivos de cachê do banco de dados para o disco, este processo é feito pelo CKPT.