O Oracle Cloud File System (CloudFS) é uma suite de gerenciamento de armazenamento da Oracle composta pelo ASM Cluster File System (ACFS) e ASM Dynamic Volume Manager (ADVM) que basicamente lhe permite criar e remover volumes(“discos”) de forma rápida e simples.
Durante o deploy do ODA é possível que seja configurado um CloudFS, especificando seu ponto de montagem (“/cloudfs”) e tamanho.
Caso um cloudFS não seja configurado durante o deploy, não tem problema! É possível criá-lo tanto através da interface gráfica(acessar MOS nota 1435019.1) como sem ela(GUI), como faremos neste artigo.

Proporcionado por necessidades distintas de aplicação, segurança e até mesmo alterações incorretas ou desnecessárias é comum nos depararmos com usuários de banco de dados que contenham roles de forma não default (DEFAULT_ROLE = NO).
*Muitos casos com roles não default são constatados quando liberamos uma role a um usuário e ele retorna informando que ainda não possui as permissões esperadas pela role, ao verificar nos deparamos com DEFAULT_ROLE = NO na DBA_ROLE_PRIVS.

Quando o Enterprise Manager, seja database, grid ou cloud control console é acessado, por default exite um tempo de inatividade até que o client HTTP seja desconectado em função do tempo máximo inativo ser violado. Em um EM Coud Control 12c, por exemplo, o client HTTP recebe a mensagem “The page has expired. Click OK to continue”, já no EM Database Control 10g ao tentar reutiliza-lo ele automaticamente redireciona para a página de logon sendo necessário inserir novamente as credenciais de acesso.
Segundo a documentação da Oracle este timout ocorre para prevenir o acesso de pessoas não autorizadas a console, onde após o tempo de inatividade predefinido a página é automaticamente expirada.
“To prevent unauthorized access to the Cloud Control, Enterprise Manager will automatically log you out of Cloud Control when there is no activity for a predefined period of time. For example, if you leave your browser open and leave your office. This default behavior prevents unauthorized users from using your Enterprise Manager administrator account.”
Apesar do timeout ser uma forma de segurança predefinida, visualizar algumas vezes a mensagem de página expirada e/ou precisar inserir novamente as credenciais pode começar a causar certa aflição, principalmente para quem gosta de estar sempre acompanhando o “ambiente” pela console e não está ativamente interagindo com  ela, fazendo o timeout ser constantemente alcançado.

O AWR Formatter para quem ainda não conhece é uma iniciativa de Tyler Muth que “formata” o AWR report HTML [ veja como gerar um awr report ] em algo mais simples e fácil de ser entendido, principalmente para que está iniciando na análise de relatórios AWR.
A ferramenta agrega ao AWR comentários, conversões (bytes/KB/MB/GB/TB), Links para notas e documentações no MOS referentes ao evento/contenção, gráficos de I/O entre outros.
Atualmente o AWR Formatter é uma extensão (plugin) apenas para o Chrome e funciona para versões de banco de dados Oracle superiores a 10.2 single-node report. Para RAC/Gobal AWR ou comparações de períodos awr ainda não há suporte.
Para instalar é simples:

Uma instance de banco de dados Oracle contém varias estruturas de memória, uma delas é a SHARED POOL composta pela library cache(cache de biblioteca), dictionary cache(cache de dicionário), result cache(cache de resultado), buffers de mensagens de execução paralela e estruturas de controle.
Dentro da library cache encontramos basicamente os SQLs compartilhados, functions, procedures, packages, (…) e planos de execução. É comum vermos DBAs executando um ALTER SYSTEM FLUSH SHARED_POLL para “limpar” esta área simplesmente para forçar um hard parse de um único SQL, mas como descrito acima, um flush na shared pool vai limpar varias outras coisas (sql, planos, functions, packages,…) o que pode gerar um alto custo para um banco carregar toda esta estrutura novamente.
A partir desta necessidade, a Oracle implementou a partir da versão Oracle database 11g a procedure PURGE dentro da package DBMS_SHARED_POOL que permite efetuar a liberação de uma única SQL, package, sequence… da library cache.

Juntamente com o Oracle Database 12c, a Oracle introduziu um novo console de administração chamado Oracle Enterprise Manager Express (EM Express). O EM Express pode ser considerado como uma versão “ligth” do antigo Enterprise Manager Database control que já não é mais disponibilizado na versão 12c. Agora para gerenciar os bancos de dados 12c (cdb ou non-cdb) você pode utilizar o EM Cloud control 12c ou EM database Express.
O Oracle Enterprise Manager Express é uma ferramenta de gerenciamento de banco de dados baseado na web que é construído dentro do banco de dados Oracle. Ele suporta funções básicas de administração de banco de dados e gerenciamento de desempenho.
Configuração:
  • Gerenciamento dos parâmetros de inicialização (init.ora)
  • Gerenciamento de memória
  • Uso das features do banco de dados
  • Propriedades de Banco de Dados
Armazenamento:
  • Gerenciamento de Tablespace
  • Gerenciamento de Undo
  • Gerenciamento de Redo
  • Gerenciamento de Archive log
  • Gerenciamento de Control file
Performance:
  • Hub de desempenho, que inclui os seguintes recursos:
    • Monitoramento de desempenho e tuning em tempo real
    • Histórico de desempenho e tuning
    • Monitoramento de SQL (tempo real e histórico)
    • Monitoramento de operações de banco de dados
    • ADDM, incluindo ADDM em Tempo Real
    • Active Session History (ASH)
  • SQL Tuning Advisor, automático e manual
Sua “instalação” diferentemente do que ocorria nas versões anteriores se tornou muito simples. Na verdade não há nenhuma instalação! Quando o database é criado é possível selecionar a opção Configurar EM (Enterprise Manager) Database Express que já deixa tudo ajustado para o acesso via web.

Na verão Oracle database 12c tivemos o surgimento da Arquitetura Multitenant onde permite que o banco de dados funcione como um container – CDB(Container Database) e que inclua zero ou muitos bancos de dados plugáveis – PDB(Pluggable Database).
Neste novo cenário de CDB e PDB, o startup/shutdown de um banco de dados plugável pode ser feito de algumas formas diferentes do que estamos acostumados. O objetivo deste artigo é justamente demonstrar algumas destas formas de parar, iniciar e verificar o estado desdes pluggable databases.