Você está na página 1de 55

TADM51

Unit 1 - Database Overview


Database Architecture Terminologia: Oracle composto: Processes, Memory (SGA) e Database. Database: Coleo de dados manipulados logicamente como uma unidade (Tablespaces). Fisicamente armazenados em um ou mais data files em discos (Data Files). Tablespaces so compostas de um ou mais Datafiles. Instance: Oracle (background) processes + memria (buffers). Cada execuo de um Oracle Database associado com uma Instance. Obs: Utilizando RAC (Real Application Clusters), um Database pode servir para dois ou mais Instances. SGA: Quando uma Instance iniciada uma SGA (system global rea) alocada. Cada Instancia tem sua prpria SGA. Processes: Quando uma Instance iniciada, Oracle BackGround Processes so tambm iniciados, e tambm finalizados quando a Instance for encerrada. system identifier (DBSID): Cada Database possue uma identificao (DBSID). Para o SAP (SAPSID). Compostos com 3 caracteres sendo o primeiro maisculo.

Quando uma Instance iniciada o processo Listener abre e estabiliza comunicao entre os clientes e a Instance Oracle. O Listener no faz parte da Instance, ele parte do processo de rede (networking). Quando um Work Process faz um pedido, o Listener cria processo dedicado e estabelece uma ligao adequada. Oracle background processes executa vrias tarefas requeridas pelo Database para um funcionamento correto. Para acelerar o leitura e gravao dos dados, eles so armazenados no database buffer cache na SGA. O Oracle Database mantm os executveis na Shared SQL Area (tambm chamada de Shared Cursor Cache), qua faz parte da Shared Pool alocada na SGA. Outra parte da Shared Pool chamada de Row Cache armazena informaes do dicionrio Oracle. Os dados so armazenados nos Data Files, mas quando for necessrio realizar alguma atualizao, eles so copiados para o Database Buffer Cache da SGA caso no estiverem l. A menor unidade lgica do Oracle para copiar dados entre Datafiles e o Buffer Cache o Data Block. Definido durante a criao do database. O SAP sempre 8kb. Por questes de performance os discos tambm devem ser formatados com 8kb.

Writing of Modified Data Alteraes em dados Oracle so sempre feitos no Buffer Cache. Entretanto o Oracle Shadow Process nunca copia dados modificados (dirty blocks) do Buffer Cache para o disco. Esta tarefa feita pelo processo database writer (DBW0). O DBW0 grava dirty blocks nas situaes: Quando precisar de espao no DataBase Buffer Cache; Cada vez que ocorrer um checkpoint process (CKPT); DBW0: Grava dados alterados do DATA BUFFER CACHE nos DATA FILES. Embora um Database Write Process (DBW0) seja suficiente para maioria dos sistemas, um novo DBW1 (e assim por diante) pode ser configurado em casos especiais. Logging of Modifications LGWR: Grava os dados registrados no REDO LOG BUFFER nos REDO LOG FILES.

Redo Entries (ou after images) contm os dados dos novos valores modificados. Tambm utilizados para reconstruir (roll) ou gravar os dados no database aps um commit. O Oracle Shadow Process grava estas entradas no Redo Log Buffer (uncommitted and committed). O Oracle Background Process (LGWR) grava todas informaes do Redo Log Buffer para os Redo Log File no disco. Estas informaes so gravadas quando: Uma transao gravada (commit) A cada trs segundos Quando o Redo Log Buffer est um tero completo Quando o DBW0 escrever dirty blocks no disco, mas esses ainda no foram para o online redo log. Quando um User (Work Process) grava uma transao, ela marcada com um SNC (system change number). O oracle grava o SNC junto com a entrada de transao no Redo Log.

Para garantir consistncia nos dados e na leitura, Oracle mantm redo entries para executar comandos e undo entries para roll back, em caso de crashes.
Undo Entries (ou before images) contm os dados dos velhos valores necessrios para que um RollBack possa ser realizado com os dados alterados por uma declarao SQL sem que tenha sido gravada (commit). Grava as imagens anteriores para opo rollback. Contm informaes para undo ou roll back, e suas entradas so chamadas before images. Essas entradas esto separadas do redo log, em undo tablespaces ou rollback segments. Log Switch Os Redo Logs Files no crescem dinamicamente, portanto quando o arquivo (online) estiver cheio o processo Log Writer(LGWR) fecha este arquivo e inicia a gravao no prximo arquivo. Isto chamado de Log Switch. Os Redo Logs so definidos normalmente por 4 arquivos (sistemas SAP 50mb) e esta gravao cclica. Em cada Log Switch o Oracle incrementa o LSN Log Sequence Number e atravs do LSN o Oracle cria automaticamente uma seqncia numerando os Redo Logs. Control Files

Control Files Cada database possui um control file, que contm entradas que especificam a estrutura fsica e o estado da base, como tablespaces, nomes e localizaes dos data files e redo logs, ou o LSN. Control file apenas alterada pelo Oracle, deve estar disponvel para escrita quando o banco ativado e no SAP ele espelhado em 3 lugares diferentes por segurana. Checkpoints O termo checkpoint tem dois significados: o ponto no qual o DBW0 grava todas alteraes do buffer no buffer cache nos Data Files. DBW0: O checkpoint process (CKPT) sinaliza o DBW0 copiar todos os dirty blocs para o disco. O CKPT ainda atualiza os headers dos data files gravando os detalhes do checkpoint e escreve a posio do checkpoint no online redo log. Checkpoint ocorre a cada log switch e quando especificado em parmetros do Oracle (no SAP esses parmetros no so usados, e o checkpoint apenas no log switch). Database recovery O recorvery na inicializao da base consiste de duas etapas: inicia a partir do checkpoint, refazendo atividades do redo log, incluindo mudanas na undo space; atividades que sofreram roll back explicitamente antes do crash so reprocessadas e o undo garantido porque o Oracle no apaga entradas de transaes abertas na undo space. Durante o restart de uma instance ou no momento de abrir o database Oracle, especialmente aps um crash ou quando uma instance no foi finalizada (shut down) corretamente, nesta situao o Oracle inicia automaticamente uma recuperao chamada de Database Recovery (ou Instance Recover). Redo Log Mirroring Os redo logs devem ser espelhados, em duas ou mais cpias, e cada redo log deve estar em discos separados. O Oracle trs essa caracterstica e usada na instalao do SAP como default. Desta forma, no necessrio utilizar solues externas. Como o online redo log limitado em tamanho e no pode crescer automaticamente, Oracle deve sobrescrever redo logs antigos por novas entradas.

Archiving Para retornar uma situao antes do crash, normalmente necessrio alm do backup aplicar os online redo logs posteriores. Para evitar perda de dados, os online redo log devem ser gravados em um local seguro, tarefa do archiver (ARC0). Archiving deve ser explicitamente ativado, via parmetro LOG_ARCHIVE_START to TRUE. Em ambientes produtivos este parmetro deve ser ativado, e os offline redo log devem ser guardados em discos espelhados (RAID).

Other Background Process (pg 18) SMON (System Monitor): executa o recovery quando a instncia inicializada (se necessrio); escreve log de alertas se outro processo da instncia falha; limpa segmentos temporrios que no esto em uso. PMON (Process Monitor): monitora os shadow processes; no caso de crash, faz roll back dos dados no comitados, para os shadow process e libera recursos que os processos estavam usando.

Estrutura de diretrios Oracle no SAP

No UNIX na <release>, sub-diretrio abaixo do /oracle/<DBSID> tambm contem informaes da verso do Oracle (se usa 32 ou 64 bits). Ex.: /oracle/<DBSID>/920_64 para Oracle verso 9.20 e 64 bits.

dbs (on UNIX) or database (on Windows): Os arquivos (profiles) init<DBSID>.ora or spfile<DBSID>.ora guardam os parmetros de configurao do Oracle Instance; O arquivo init<DBSID>.sap guarda parmetros de configurao da ferramenta de administrao BR*Tools. sapdata<n>: Contm os Data Files das Tablespaces origlogA/B, mirrlogA/B: Os Online Redo Log Files so arquivados nos diretrios origlog e mirrlog. oraarch: Os Offline redo log files so gravados no diretrio oraarch. saptrace: Utilizado para armazenar informaes dos dump Oracle; O arquivo de alerta do Oracle alert_<DBSID>.log gravado em saptrace/background; Os arquivos de Trace do Oracle shadow processes so gravados em saptrace/usertrace. saparch: Armazena os logs da ferramenta SAP BRARCHIVE. sapbackup: Armazena os logs da ferramenta SAP BRBACKUP, BRRESTORE, and BRRECOVER. sapreorg: Usado pelo BRSPACE para armazenar logs de diferentes aes. sapcheck: Usado pelo BRCONNECT para armazenar logs de diferentes aes. Oracle Directories and Environment Variables (pg 21) No database server as variveis de ambiente ORACLE_SID, ORACLE_HOME e SAPDATA_HOME devem sempre ser configuradas para o user <sapsid>adm, bem como para o user ora<dbsid> no UNIX. ORACLE_SID: system ID para a instncia; ORACLE_HOME: diretrio home do Oracle, que contm o Bin, DBS e network; SAPDATA_HOME: contm arquivos do banco de dados; Others variables: o no caso do Windows, se diretrios diferentes do SAPDATA_HOME so usados, SAPARCH, SAPBACKUP, SAPCHECK, SAPREORG. o no UNIX, as variveis ORA_NLS10 so tambm configuradas para o user ora<dbsid>. O valor padro para ORA_NLS10 $ORACLE_HOME/nls/data.

Connecting to the Database (pg 29) Para proteger o SAP, necessrio controlar usurios em trs nveis: Sistema Operacional; Banco de Dados; SAP.

Operating System and Database Users

Oracle System Privileges System Pivileges controla operaes realizadas por um usurio em uma instncia ou database. Object privileges controla operaes em objetos, como select, update, etc. Special system privileges SYSDBA e SYSOPER so oferecidos durante as conexes. Em um sistema SAP no SO usado autenticao para conexo no Oracle com privilgios SYSDBA e SYSOPER.

Operation System Users and Groups Usurios do sistema operacional membros do grupo dba ou ORA_DBA (ou ORA_<SID>_DBA) podem conectar no banco com o privilgio SYSDBA. Membros do grupo oper (UNIX) ou ORA_<SID>_OPER (windows) como SYSOPER.

Oracle Database Users Cada DB Oracle contm duas contas administrativa de usurios , SYS e SYSTEM, criados automaticamente durante a instalao e associados a role DBA. SYS o usurio mais poderoso no Oracle: todas as tabelas e views do data dictionary so guardadas no schema sys. Essas tabelas so crticas para o Oracle, no podem ser alteradas ou novas tabelas criadas nesse schema; SYS garante adicionais privilgios que a role DBA, e pode alterar qualquer dado no banco. OBS: SCHEMA uma coleo de objetos de dados pertencentes a um usurio como OWNER. Um SCHEMA sempre possue o mesmo nome que o OWNER. SYSTEM usado pelo Oracle para criar tabelas internas e views adicionais para exibir informaes administrativas. No possui permisso para alterar tabelas do dicionrio de dados. ** No SAP: SYSTEM recebe funo SAPDBA para que o BR*Tools possam acessar certas tabelas no schema SYS; SYSTEM o usurio default quando se usa SAP tools para administrao do Oracle. **

Durante a instalao do SAP, criado no banco um usurio SAP<SCHEMA-ID> (ou SAPR3 at Basis 4.6D). Todas as tabelas do SAP so guardadas neste schema, porm o usurio no possui direitos administrativos no database (no associado a role DBA ou SAPDBA). Outros usurios criados no Oracle fazem uso do operating system authentication. Se o usurio chamado OPS$<USERNAME> definido como identificador externo no nvel do DB, ele no tem senha e o user <USERNAME> do SO pode conectar no DB sem autenticao, assumindo que os parmetros do Oracle so configurados como: REMOTE_OS_AUTHENT=TRUE; OS_AUTHENT_PREFIX=OPS$; OPS$, autentica user do SO como user DB. Se conectar com JJ no SO, pode-se conectar com OPS$JJ no DB. Oracle Database Role Role DBA contm todos os privilgios necessrios para administrao do DB, entretanto algumas tarefas no so disponveis como start/shut down que precisam dos privilgios de sistema SYSDBA ou SYSOPER. Na instalao do SAP, duas roles so criadas: SAPDBA: permite acesso a tabelas usadas pelas SAP tools para administrao do DB SAPCONN: associada para o user OPS$ na instalao.

Connecting to Oracle (pg 37)

Um user SO pode somente executar com sucesso um: connect / se o correspondente user OPS$ existir no DB; connect / {AS SYSDBA | AS SYSOPER} se o user for membro do grupo do SO (dba ou oper no UNIX, ORA_DBA, ORA_<SID>_DBA, ORA_<SID>_OPER no Windows); Conexes AS SYSDBA e AS SYSOPER substituem o CONNECT INTERNAL em verses Oralce acima de 8.x. Work Process Connect to Oracle

** Quando um SAP WP inicia e tenta conectar com o DB, as seguintes aes acontecem: 1. WP loga no DB com seu user OPS$ correspondente com autenticao do SO;
2. WP realiza um SELECT na tabela SAPUSER e l a senha do SAP<SCHEMA-ID>;

3. WP disconecta do Oracle; 4. WP conecta com o username SAP<SCHEMA-ID> e a senha lida da tabela SAPUSER. A senha do user SAP<SCHEMA-ID> somente pode ser alterada com BRCONNECT **

Net Services Na rede, a comunicao via TCP/IP e no topo, no software layer, o OracleNet (Oracle Network Services). Na mesma mquina o SAP usa o interprocess communication (IPC) protocol Named Pipes. OracleNet existe tanto no cliente quanto no servidor, e responsvel por estabelecer e manter a conexo entre os dois, bem como controlar as mensagens entre eles, usando protocolos padres, como o TCP/IP. Um processo chamado listener (OracleNet Listener) se encarrega de ouvir novas conexes e lig-las ao servidor. Aps a conexo ser estabelecida, a comunicao passa ser diretamente entre cliente e servidor. Trs arquivos so usados para essa configurao: listener.ora: configura o listener e usado apenas no servidor. Contm todas entradas dos sistemas Oracle que devero aceitar conexes; tnsnames.ora: contem a lista de services names que podem ser acessados via rede; sqlnet.ora: pode conter informaes do cliente, como domnio, traces, etc. Oracel Listener O utilitrio lsnrctl usado para parar e ativar o listener, bem como ver seu status. No Unix o processo tnslsnr. No Windows servio Oracle<DBSID><Release>TNSListener. Se vrias instncias so usadas em um nico host, geralmente h apenas um listener com todas entradas. O listener pode ser pingado via utilitrio tnsping <DBSID>. ** Comando lsnrctl status, mostra informaes como verso do OracleNet , tempo de start, e localizao de parmetros e log files do listener. Database server listener tracing pode ser configurado pelo arquivo listener.ora. Opes do listener tracing: NO SET: No tracing (default); USER: Limitado nvel de informaes de tracing ADMIN: trace detalhada ** TNSPING <DBSID> O resultado indica se: A conexo pode ser estabelecida; <DBSID> no pode ser resolvido no tnsnames.ora O Listener no esta configurado para comunicar com <DBSID> atravs do listener.ora; O Listener no est executando no database server; Database Administration Tools (pg 50) Administrao do banco de dados Oracle pode ser feito via SAP administration tools, chamados de BR*Tools. Esto no diretrio /usr/sap/<SID>/SYS/exe/run e podem ser usados em qualquer verso do SAP, a partir do Oracle 9i. BRTOOLS disponibilizado como uma interface baseada em caracteres, para os programas BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE e BRCONNECT. Alm do BRTOOLS, existe o BRGUI, baseado em Java, que usa as funes via BRTOOLS. Oracle TOOLS SQL*Plus

SAP Tools: BRBACKUP: backup de data files, control files e online redo log files; BRARCHIVE: backup dos offline redo log files; BRRESTORE: restore de data files, control files, online e offline redo log files; BRRECOVER: tools interativo para restore e recovery; BRCONNECT: database administration: database check, update statistics, etc.; BRSPACE: database administration: instance management, space management e reorganizao; BRTOOLS: Ferramentas interativas parmetros que chama as outras ferramentas atravs de menu; BRGUI: Interface grfica de usurio para BRTOOLS. Os tools so separados em programas funcionais e de ajuda, bem como batch e interativos: Funcionais: executam atividades no banco de dados: BRBACKUP, BRARCHIVE, BRRESTORE, BRRECORVER, BRSPACE e BRCONNECT; Help: BRTOOLS que oferece menus para navegao e BRTOOLS E BRCONNECT so chamados por outros programas; Batch: BRBACKUP, BRARCHIVE, BRRESTORE e BRCONNECT no possuem menus prprios. Interativos: BRRECOVER e BRSPACE (alm do BRTOOLS) possuem seus prprios menus, e podem ser chamados diretamente via prompt.

A funo chpass do BRCONNECT deve ser usado para alterar a senha do SAP<SCHEMA-ID>. A customizao do SQL*Plus pode ser feita via comando set <varivel> <valor>. Se AUTOCOMMIT for OFF, o commit realizado via comando commit ou quando desconectado do Oracle. SAP Database Monitors (pg 67) DBACOCKPIT fornece vrias Transaes para monitoramento e administrao do banco: DB12: backup logs overview: resultado do backup e status do diretrio de archives; DB13: DBA Planing Calendar: agendamento de backups e outros Jobs administrativos. Caso use vrios sistemas, pode-se usar a DB13C (central planning calendar);

DB14: DBA Operations Monitor: logs de backup, update statistics, database checks; DB16: overview of database checks; DB17: manter os valores usados durante um database system check; DB20: manter estatsticas; DB21: parmetros de gerao de estatsticas; DB26: parmetros do banco de dados; DB02: table and indexes Monitor: monitora o tamanho do BD, e o status dos objetos do banco; ST04: Database Performance Monitor: mostra os indicadores mais importantes (buffers, acessos de usurios, etc.) e a parametrizao atual; RZ20: database alert monitor. A DB13 usada para agendar Jobs administrativos, como database check, backup, adapting next extents e update statistics. So executados os Jobs DBA:*, com base na tabela SDBAC. A DB14 usada para monitoramento dirio, clicar em all activities. Para limitar por data: Edit > Selection Options. DBACOCKPIT Fornece uma rea de navegao no qual visvel atravs da rvore de menu com os pontos: Performance (ST04); Space (DB02); Jobs (DB13, DB12, DB14, DB13C); Diagnostics; Um dos recursos da DBACOCKPIT monitorar e administrar DB externos incluindo sistemas ABAP e no ABAP. Quando adicionar um DB externo na configurao do DBA CockPit, criar sua prpria entrada na tabela DBCON. Administration of Oracle Instances (pg 79) Durante o startup do banco, passa-se por trs fases: NOMOUNT: o arquivo de parmetros lido, a instncia iniciada e os recursos alocados no sistema operacional. Usado para criar a database e recriar control files perdidos; MOUNT: os control files so abertos, informaes da estrutura fsica so lidas, parte do data dictionay carregado. Usado para recovery, alterao do ARCHIVELOG, renomear data files, adicionar, remover ou renomear online redo log files; OPEN: todos arquivos restantes so abertos, instance recovery realizada (se necessrio). Para inicializar via BRTOOLS: Instance Management > Start up database, ou brspace c force f dbstart s <state>. Para parar: Instance Management > Shut down database, ou brspace c force f dbshut m <mode>.

Estados de uma Instance: NOMOUNT: necessrio para criar um database e para recriar control files perdidos; MOUNT: necessrio para media recover, para alterar o modo do ARCHIVELOG, renomear (mover) data files, e para adicionar, dropar, ou renomear online redo log files. Tipos de shutdown: NORMAL: no aceita novas conexes, mas aguarda todos os usurios fazerem logout. Padro do Oracle; TRANSACTIONAL: no aceita novas conexes, aguarda transaes atuais terminarem, mas no executa novas transaes; IMMEDIATE: no aceita novas conexes, no executa novas transaes e faz roll back das transaes atuais. Padro do BRSPACE; ABORT: no aceita novas conexes, no exeuta novas transaes e cancela as transaes atuais, sem roll back. Requer recovery (automaticamente executado) no prximo startup. OBS: Somente na opo ABORT o DB fica inconsistent state, nos demais consistent state. Initialization Parameters (pg 82) O arquivo de parmetros de inicializao tradicionalmente era em formato texto, com nome init<DBSID>.ora. A partir da verso 9i, pode-se manter em formato binrio (SPFILE), com nome spfile<DBSID>.ora, ou spfile.ora. SPFILE totalmente suportado a partir do BR*Tools 6.40 e a SAP recomenda usar SPFILE no upgrade para Oracle 9i. Quando um parmetro alterado no SPFILE, um init<DBSID>.ora gerado automaticamente, permanecendo uma consistncia entre eles. recomendado criar e guardar o SPFILE no local default do Oracle (ORACLE_HOME/dbs ou ORACLE_HOME\database). Quando uma instncia iniciada sem especificao de uma profile em particular, a ordem de pesquisa : 1. spfile<DBSID>.ora 2. spfile.ora 3. init<DBSID>.ora A inicializao com um spfile no padro s recomendado em casos emergenciais. Para modificar parmetros do Oracle, via BRTOOLS acesse: Instance Management > Alter database parameters. Digite diretamente o parmetro que quer alterar, ou c para continuar (pesquisa). Maintenance of Oracel Parameters

** Mensagens de informao, warnings ou erros so gravados em dump files. Os locais so definidos nos parmetros: BACKGROUND_DUMP_DEST (padro: $SAPDATA_HOME/saptrace/background): log de alerta (alert_<dbsid>.log), que loga eventos e mensagens de atividades; traces em caso de erros; USER_DUMP_DEST (padro: /saptrace/usertrace): traces escridos pelos shadow processes, quando ocorre problema com a conexo do cliente. **

Unit 2 Backup, Restore & Recovery (pg 103)


Backup Strategy A estratgia de backup deve ser adequada com as necessidades da empresa. Ela deve ser testada antes do GO Live e sempre aps mudanas na mesma. O SAP oferece ferramentas para diferentes tipos de backup, como full online, incremental com RMAN, split-mirror. Importance of Redo Log Files Para executar um complete recover e recuperar os dados ata o momento do crash, so necessrios todos offline e online redo log files. Devem-se manter pelo menos duas cpias dos offline redo logs em discos ou fitas. Ao se fazer point-in-time recovery, necessrio voltar toda a base, para manter consistncia entre as tabelas. Desta forma, os dados entre o point-in-time e o momento em que a base foi desativada sero pedidos. Desta forma, point-in-time no deve ser a opo padro para erros lgicos em produo. Pode-se ativar outra base com o backup e copiar os dados manualmente.

Disaster Recovery

Verification of Data O backup deve incluir verificao dos dados a sofrerem backup, bem como os dados nas fitas. Para verificar consistncia no banco, um logical data check deve ser executado para descobrir data blocks corrompidos: o Corrupt Oracle blocks (erro ORA-1578) podem aparecer no banco devido erros de sistema operacional ou hardware; o Sem o check, os corrupt data blocks sero encontrados apenas no acesso aos mesmos; o Base com corrupt data blocks sofre backup, porm o mesmo no pode ser usado; O check recomendado uma vez por semana; Para verificar as fitas usadas pelo backup, executa-se o physical data check. Durante este check, as fitas so lidas e se a conexo com os dados possvel; No Offline backup, pode-se fazer um check para ver se os binrios da fita so iguais aos do banco. Isto requer que a base fique desativada enquanto isso; No backup online, apenas verifica-se se os arquivos nas fitas podem ser lidos;

Backup Cycle Um cliclo de backup o tempo em que o backup fica em fita. SAP recomenda o ciclo de backup de quatro semanas. O ciclo de backup do banco e dos offline redo logs deve ser o mesmo: o backup completo online todo dia til (work day); o backup completo offline uma vez no ciclo; o backup dos offline redo logs todo dia til, bem como aps backups online e offline. Gravar os offline redo logs em duas fitas diferentes antes de apagar do disco; o fazer um logical check antes ou aps o backup e pelo menos um physical check no ciclo (recomendado uma vez por semana); o retirar a fita do ltimo backup offline do ciclo e guardar. Substitu-la por uma nova. A freqncia de backups completos se d ao ponto de ter vrios backups deste tipo disponvel. Desta forma, evita-se perda de dados caso o ltimo backup no esteja disponvel. Executar backups adicionais aps reorgs e upgrades, e guardar esses backups em long-term storage. Backup Types (pg 112) Dois mtodos principais de backups em um DB Oracle: User-managed backups: Backup manual no SO (Sistema operacional) Server-managed backup: Usando o Oracle Recovery Manager. Oracle usa shadow process do Oracle Server. Tipos de backup: Offline: o banco parado antes do backup e os data files so copiados. Desta forma, no necessrio restaurar offline redo logs; Online: o banco continua aberto durante o backup, ento modificaes podem ocorrer e necessrio aplicar offline redo logs aps o mesmo. Backup completo: o full (via RMAN): salva toda a base e o catlogo so salvos no control file, permitindo posterior backup incremental; o whole: toda base, porm no salva informaes do catlogo.

Incremental Backup: backup somente dos data blocks modificados aps ltimo full. Todos os data blocks so lidos, ento o tempo pode no ser reduzido: o s pode ser executado aps um full; o controlado via RMAN (utiliza control file para isto); o via SAP tools, apenas acumulativo suportado ( feito com base no ltimo full); o via SAP tools, apenas o backup de todo banco possvel, no d para selecionar apenas alguns data files; o Oracle l todos blocos de todos data files para checar qual possue alterao. Backup parcial: backup de apenas algumas partes do banco.

OBS: A performance do sistema comprometida durante um backup on-line, de modo online backups devem ser agendados em perodos de baixa atividade. Backup Strategy (pg 115) A estratgia de backups pode conter backups incrementais ao invs de completos, economizando tempo de backup. Para recovery da base, necessrio o ltimo full, restore do ltimo parcial e os redo logs. Backup Tools (pg 120)

O BRBACKUP faz backup dos data files, control file e online redo log, se necessrio. usado para backup do diretrio do banco e do SAP. O BRARCHIVE faz o backup dos offline redo logs; O BRRESTORE pode restaurar todos os arquivos do banco de dados: data files e offline redo log. O programa interativo BRRECOVERY verifica se arquivos do banco esto faltando, chama o BRRESTORE para restaurao, executa o recovery e abre o banco.

O BRBACKUP e o BRARCHIVE gravam as aes em arquivos de logs, que so analisados pelo BRRESTORE para restaurao de arquivos inexistentes.

Customizing SAP Backup and Restore Tools O arquivo de configurao init<DBSID>.sap contm parmetros para os BR*Tools. Pode ser editada com um editor de textos. Itens mais importantes: backup_mode: escopo do backup (all, full, incr...); backup_type: offline ou online; backup_dev_type: mdia do backup (tape, disk); tape_copy_cmd: comando de cpia (cpio, dd > recomendado, mais rpido que cpio); disk_copy_cmd: comando de cpia para discos locais; expir_period e tape_use_count: data de expirao da fita e quantidade de vezes que ela pode ser sobrescrita; volume_backup e volume_archive: nome dos volumes para backup e archives; tape_adress: endereo do drive de fitas. Integration of Oracle Recovery Manager (RMAN) into SAP Tools (pg 124) O Oracle Recovery Manager (RMAN) o programa padro para backup e restore. O BRBACKUP suporta o RMAN para backup de duas diferentes formas: classificar um backup como completo (level 0) que servir como base para um incremental (level 1); dados podem ser escritos em fitas via RMAN, ao invs de comandos CPIO e DD. Se o backup levado para fita via RMAN, este deve ser usado para restore e recovery, fato q detectado pelo BRRECOVER. Caso este encontre algum problema, necessrio fazer o restore manualmente. Para copiar para a fita via BRBACKUP, escolha tape_copy_cmd como CPIO ou DD. Para deixar o controle com o RMAN, colocar valor rman. No caso do RMAN, na ltima etapa, o backup_mode setado para full, RMAN escreve informaes no control file e o CPIO copia o control file para a fita. O RMAN copia diretamente para disco, mas no para fita. Nete caso, ele necessita de uma biblioteca System Backup to tape (SBT), provida pela Oracle e que cada fabricante de fitas deve prover uma biblioteca. Antes de usar backup com RMAN, a biblioteca deve ser instalada: caso no a tenha, o SAP instala automaticamente em /SYS/exe/run; para usar um utilitrio de backup externo, deve ser instalada a biblioteca SBT do mesmo. Oracle trs uma verso limitada single-server do Legato Networker. Para usar setar backup_dev_type para rman_disk ou rman_util. ** Vantagens de usar o RMAN: todos blocks so verificados, procurando blocos corrompidos. Neste caso, o backup consistente e futuros checks no so necessrios; apenas blocos usados so gravados (mesmo vazios, se j foram usados); durante backups online, a tablespace configurada para modo de backup, para evitar inconsistncia. ** Obs: A partir do Web AS 6.10, RMAN tambm pode ser usado no BRARCHIVE, o que garante verificao interna de consistncia nos offline redo logs.

Quando se usa o RMAN, a biblioteca de backup SAP prov uma forma de otimizar o uso de fast tape drives, combinando vrios data files em save sets. Neste caso, vrios data files so lidos ao mesmo tempo, maximizando o fluxo de dados no modo streaming. Cada save set contm um header, um trailer e os blocos de pelo menos um data file. O parmetro saveset_members, dentro do init<SAPSID>.sap permite os valores: 1,2,3,4: nmero de files que podem ser agrupados (default: 1); tsp: um save set por table space (contm todos data files da table space) all: um save set com todos data files do DB. Usar save sets grandes ajuda a acelerar o backup, porm tem a desvantagem do restore/recovery se tornar mais lento. Todo o save set deve ser lido da fita. Backups para disco via RMAN (backup_dev_type = disk e disk_copy_cmd = rman), nenhum save set formado. Data files so copiados diretamente para disco, como no uso dos comandos CP ou DD. Em outras palavras, uso de save sets s possvel quando uma SBT library usada para backups incrementais. Preparation Run (SAP SBT Library)

Se um backup via RMAN criar save sets com mais de um membro (saveset_members <> 1) ou se usa tape stations com compresso e se quer levar em considerao a compresso para calcular o tamanho do save set, deve-se executar uma preparao para determinar a distribuio otimizada de tape sets. Esta preparao executada via DB13 > Prepare for RMAN Backup. Neste caso, o BRBACKUP inicializa o RMAN para backup dos data files. Nenhum backup feito nesta etapa, o BRBACKUP apenas comprime os arquivos para estimar a taxa de compresso. O BRBACKUP determina quais data files so alocados nos save sets para cada valor possvel do saveset_members, e calcula a taxa de compresso de cada save set. As informaes de compresso e composio do save set so gravados no banco, para futuras utilizaes. Essas informaes no podem ser alteradas manualmente, apenas via uma nova preparao. Se durante um backup o RMAN identifica um data file no includo na ltima preparao de execuo, um novo save set criado. recomendado executar a preparao uma vez por ciclo, e aps grandes modificaes no banco.

Incremental Backup (SAP SBT Library) (pg 133)

Um backup incremental sempre um backup de todo o banco de dados, no de um individual data file. Ferramentas de sistema operacional no podem ser usados para cpia para fita, os parmetros tape_copy_cmd ou disk_copy_cmd so ignorados e implicitamente alterados para RMAN. Aps, completado o backup incremental, o control file copiado para fita via CPIO. Apenas um save set (.INCR) criado, uma vez que o parmetro saveset_members internamente setado para all. Desta forma, o backup pode ser feito em apenas uma fita. Se um data file foi criado entre o backup full e o incremental, um backup nvel 0 executado antes do incio do backup nvel 1. Todos novos data files so gravados em um novo file set (.FULL). A volta de backup neste caso se d em trs passos: volta os data files do backup nvel 0; os blocos alterados do backup de nvel 1 podem ser importados no data file; finalmente um recovery deve ser executado, do horrio em que o backup nvel 1 foi feito. External Backup Tools (pg 137) Os tools BRBACKUP, BRARCHIVE, BRRECOVER e BRRESTORE podem utilizar uma interface chamada BACKINT para acessar programas externos de backup. Vantagens: Pode-se usar mdias de backup especficas de um fabricante, como robs e magnet-optical media; pode-se fazer um backup consistente de file systems e banco de dados; client/Server backup configuration permite uso de backup Server. De qualquer forma, o backup deve ser inicializado via SAP tools, para manter logs atualizados, monitoramento via CCMS e permitir restore/recover via BRRECOVER. Para configurar uma interface BACKINT, atribua ao parmetro backup_dev_type para util_file ou util_file_online (coloca tablespace em backup mode) no init<DBSID>.sap e altere o parmetro util_par_file para o arquivo de configurao do utilitrio de backup. Para usar com RMAN, colocar backup_dev_type como rman_util, rman_disk ou rman_stage.

Performing Backups (pg 163)

O backup deve incluir todos os objetos, como sistema operacional, arquivos do SAP e do software do Oracle. Geralmente sofrem backup via sistema operacional, uma vez por ciclo. ** Phases of a Database Backup

**

Creating database backups (pg 168) Ttransao DBACOCKPIT ou DB13 pode agendar vrios tipos de jobs BRBACKUP e BRARCHIVE. Este mtodo recomendado para agendamento de estratgias de backup. Os jobs so criados em background (BRBACKUP e BRARCHIVE so chamados a nvel de SO). Podem ser monitorados via SM37. Para executar um backup do DB com BRTOOLS ou BRGUI, selecionar: Backup and database copy > Database backup. As seguintes opes so exibidas: Backup Device Type (device): Especifica o device que o backup deve ser executado; Tape volumes for backup (volume): Se o Backup Device Type tape, tape_auto ou tape_box o volume pode ser informado; Backup Type (type): tipo backup online ou offline; Back up disk backup (backup): BRBACKUP fully suporta duas fases de estratgias de backup: a primeira executada para device DISK e o segundo passo para uma TAPE; Files for backup (mode): Modo do backup (all, full, incr); Creating backups of archived redo log files (pg 173) Aps um Log Switch, o processo ARC0 copia os online redo log file que tem o corrente redo log file antes do Log Switch para o diretrio oraarch como um offline redo log file. BRARCHIVE copia estes arquivos para um backup mdio. Durante um backup para TAPE, um offline redo log file tem o status ARCHIVE. Ele salvo (status SAVED), em seguida copiado (COPIED) e aps deletado (DELETED). Durante um backup para DISK, um offline redo log file tem o status DISK. Uma segunda cpia no suportada. Primeira vez salvo no disco (DISKSAV) e deletado aps cpia (DISKDEL). OBS: SAP recomenda usar a opo -cds (copy_delete_save), que a opo default quando iniciado o BRARCHIVE da DBA Cockpit ou DB13. Para verificar os DB archive log files pode-se utilizar BR*Tools 7.00 com o RMAN. O RMAN VALIDATE chamado internamente. Pode ser ativado usando o seguinte comando: BRARCHIVE: -w | -verify use_rmv | firts_rmv | only_rmv Consistent Online Backups (pg 177) Um backup consistente um backup no modo online que contm logicamente dados consistentes. Neste caso, os offline redo log files gerados durante o backup so salvos para o mesmo volume que os databases files que so backed com o BRBACKUP. Checar regularmente o resultado de todos Backups. DB14 a principal ferramenta para checar; DBA Cockpit (DB13) nos calendrios possvel ver as aes com cores de warnings e errors; DB12 visualiza somente os logs de backup;

Restore and Recovery Oracle cria sincronizao usando timestamps. Timestamps so inteiros incrementados por certos eventos, como logwriter e checkpoint. Ex.: log sequence number (LSN) a cada log switch e system change number (SCN) a cada commit e checkpoint. Para analisar problemas no banco, verificar o alert log e trace files no diretrio $ORACLE_HOME/saptrace/background.

Se ocorrer um problema no database, analisar e criar uma estratgia para resolve-lo. Faa um backup completo offline do banco corrompido antes de restaurar o backup. Isto recomendado principalmente em point-in-time recovery ou database reset, que envolve perdas de dados. Da mesma forma, fazer um backup dos offline redo logs. Para testar a realidade da estratgia de backup, execute o Recovery report na transao DB12. Ele contm informaes que podem ser usadas em caso de recovery. O report informa o ltimo backup com sucesso, incluindo o tipo de backup e o nome da fita, qual backup deve ser usado para recovery e quais redo log files esto disponvels. O report tambm ajuda a detectar gaps nos backups: redo log files que esto faltando; se a lista de redo logs est grande, o tempo de recovery pode se tornar muito longo.

Concepts: Complete Database Recovery (pg 188)

Usado para restaurar data files que esto faltando, e para restaurar a base at o status imediatamente anterior ao erro ocorrido. Para sincronizao, o Oracle utiliza informaes salvas nos cabealhos dos arquivos. O banco requer todos os offline redo log files desde o ltimo database file. Com o complete database recovery, todas as alteraes so feitas novamente, desde que todos os arquivos tenham o mesmo SCN. Este procedimento chamado de media recovery. Para realizar um Complete Database Recovery com o Brtools, acesse: Restore and recovery > complete database recovery. Fases: 1. Check the status of database files: verifica o status de todos os arquivos do banco, com ajuda das views V$, e escreve os logs no diretrio sapbackup; 2. Select database backup: BRRECOVER determina os backups utilizveis (cdigo de retorno 0 ou 1) via log back<DBSID>.log. Data files ausentes podem ser recuperados de vrios backups. Um backup incremental pode ser escolhido antes de aplicar os offline redo log files. Neste caso, o BRRECOVER escolhe o backup full correspondente. 3. Restore data files: BRRECOVER chama o BRRESTORE para restaurar os arquivos para o local de origem (o diretrio sapdata no criado automaticamente, mas os sub-diretrios sim); 4. Restore and apply incremental backup: se existir backup incremental, aplicado nesse ponto; 5. Restore and apply archive logs: com base no arch<DBSID>.log, a lista de offline redo log files montada. BRRECOVER chama BRRESTORE para restaurar os archivos da fita para o diretrio oraarch. Finalmente o BRRECOVER chama o SQL*Plus para aplicar os offline redo log files. Eles so aplicados em grupos de 100. 6. Open database: BRRECOVER ativa a base e verifica o status dos arquivos e tabespaces.

Concepts: Point-in-time Recovery:

Usado para restaurar a base a em certo horrio, com a ajuda de um backup completo. Point-in-time recovery sempre resulta em perda de dados. Quando a base ativada, usado o comando ALTER DATABASE OPEN RESETLOGS, o que reinicia os contadores de LSN. Desta forma, deve-se fazer um backup full antes de liberar para uso. O point-in-time pode ser usado para toda base ou s para umas tablespaces especficas (ex.: usando MCOD). Para executar via BRTOOLS, acessar: Restore and recovery > Database point-in-time recovery. Fases: 1. Set point-in-time for recovery: LSN, SCN ou horrio especfico; 2. Select database backup: BRRECOVER determina os backups utilizveis (cdigo de retorno 0 ou 1) via log back<DBSID>.log. Data files ausentes podem ser recuperados de vrios backups. Um backup incremental pode ser escolhido antes de aplicar os offline redo log files. Neste caso, o BRRECOVER escolhe o backup full correspondente. 3. Check the status of database file: BRRECOVER verifica status de todos os arquivos e determina quais sero sobrescritos; 4. Restore control file: se necessrio; 5. Restore data files; 6. Restore and apply incremental backup: se selecionado anteriormente; 7. Restore and apply archivelog files: BRRECOVER verifica no arch<DBSID>.log os offline redo log files necessrio, chama o BRRESTORE para copiar da fita para o oraarch e chama o SQL*Plus para importar no banco.

Concepts: Whole Database Reset

Usado para restaurar a base para o momento imediatamente aps o backup completo. Como o point-in-time recovery, database reset resulta em perda de dados. Para executar via BRTOOLS, acessar: Restore and recovery > Whole database reset. Passos: 1. Select consistent database backup: BRRECOVER determina backups que podem ser usados, com base no back<DBSID>.log. Se escolher um backup incremental, o backup full correspondente escolhido para restaurar todos data files; 2. Restore control files and redolog files: sempre restaurados se um backup online escolhido; 3. Restore data files; 4. Apply incremental backup: se escolhido; 5. Apply archivelog files: se escolhido online backup; 6. Open database: ativa o banco (se necessrio com RESETLOGS), cria arquivos temporrios que possam estar faltando, verifica o status dos data files e tablespaces, deleta aquivos desnecessrios .

Disaster Recovery (pg 199) Usado quando no houver arquivos de controle e profiles de configurao. Disaster Recover somente um passo anterior de preparao para um database recovery com database point-in-time ou whole database reset. Pr requisitos: SAP e Oracle corretamente instalados; File system com os diretrios sapdata existentes e configurados como antes do disaster. Para realizar o disaster database recovery, via BRTOOLS: Restore and recovery > Disaster recovery.

Para executar um Disaster Recovery, BRRECOVER primeiro verifica de onde os arquivos sero restaurados, lendo estas informaes do init<DBSID>.sap. Aps restaurar o init<DBSID>.sap, o backup summary log back<DBSID>.log restaurado e o sistema conhece atravs de quais backups far o restore. Outros profiles e logs podem ser restaurados atravs de uma lista. Na maioria dos casos, no necessrio mudar a seleo default, uma vez que o BRRECOVERY j determina quais arquivos devem ser restaurados. Na prxima seleo, Restore of BRBACKUP detail logs, a lista de backup detail logs exibida para restore. Outras funes do BRRECOVER, no tratadas aqui so: Restore of individual backup files: restaurar um arquivo de backup para restaurao manual; Restore and application of archivelog files: para recovery manual. Advanced Backup Techniques (pg 209) Algumas tcnicas podem melhorar a estratgia de backup, mas em compensao exige esforos como: - Hardware; - Treinamento dos administradores; - Aumento na administrao do ambiente. Methods for accelerating the backup and restore process Hardware: (tape drives, disks, system e I/O) Parallel Backup: vrios tape drives; Using DD: com BRBACKUP usar o DD para copia de Data Files (no CPIO); Using the BACKINT interface: conexo com ferramentas de backup externas; Optimizing BEGIN BACKUP runtimes: Incremental Backup; Partial Backup; Two Phase Backup: 1 step tape, 2 step disk; Split Mirror Backup; Snapshots; Standby database;

Split-mirror Disk Backup (pg211) Pode significar reduo de tempo de backup. O backup executado conforme segue: Online: tablespaces em backup mode Break up (quebra) do mirror (espelhamento) Produo sai do modo backup Backup online no mirror Resincronizao do mirror. Offline: shutdown do banco Break up (quebra) do mirror (espelhamento) inicializao da base de produo Backup offline no mirror Resincronizao do mirror. Algumas alteraes so necessrias no init<DBSID>.sap e o BRBACKUP do servidor mirror deve enchergar o servidor de produo.

SAP Tools and the Oracle Standby Database Um Oracle standby database consiste de dois database servers. O banco de dados de produo fica aberto, porm o standby em status mount e frequentemente recebe os offline redo log files do de produo. No caso de falha do Server, este pode ser usado como produo. O backup feito na base standby via BRBACKUP, backup_type = offline_standby, com aes registradas nas tabelas SDBAH e SDBAD do servidor de produo, alm do diretrio sapbackup (devem estar acessveis do standby Server). O BRARCHIVE roda nos dois servidores, sendo no Server colocando os archives em disco, e no standby lendo do oraarch e jogando em fita. Os redo so aplicados com a opo -m | -modify <delay>, onde delay o tempo para atualizao. Structure Retaining Database Copy Usado para criar uma base com outro DBSID no mesmo servidor, ou outra base com mesmo ou diferente DBSID em outro Server.

Unit 3- Monitors and Tools


Introduction to Oracle Data Management Segment contm dados de uma tablespace. Existem 4 tipos de segmentos: - Data: Um data segment contm dados em linhas na tabela; - Index: usado para acelerar o acesso e forar unique constraint; - Temporary: usado para sorts e criao de ndices; - rollback/undo: prover consistncia, roll back ou undo e para recovery. Qualquer seguimento guardado em uma tablespace, mas pode estar em vrios data files. Para atender a demanda de bancos grandes, as tabelas e ndices podem ser particionados, o que permite que dados possam ser quebrados em pedaos menores e mais maleveis. Cada partio guardada em seu prprio segmento, e gerenciada manualmente. SAP recomenda utilizar a mesma tablespace original. No SAP, um segmento possui: todos os dados de uma tabela particionada; ou todos dados de uma partio de uma tabela particionada. At a verso 4.6C, as tablespaceses eram divididas em system, rollback, temp. segments, tables e indexes, dados por tipo de tabela (dados, mster data, pool, logs, etc.) e ndices por tipo de tabela. As vantagens eram: data files poderiam ser guardados em discos diferentes (dependendo do uso) e a reorganizao poderia ser feita em unidades menores. As desvantagens eram o aumento do trabalho de organizao e baixa efetividade do armazenamento. Tablespace Naming Conventions Starting with SAP Web AS 6.10 (pg 229) ** Tablespace Name Segment Type Contents SYSTEM Tables, Oracle Data Dictionary indexes, rollback SYSAUX Tables, indexes Mandatory help tablespace for the SYSTEM tablespace PSAPROLL ou PSAPUNDO Rollback/undo Only rollback/undo segments PSAPTEMP Temp. Only temporary segments segments PSAP<SCHEMA-ID> Tables, indexes Objects of the SAP Web AS ABAP schema PSAP<SCHEMA-ID>USR Tables, indexes Customer objects PSAP<SCHEMA-ID><REL> Tables, indexes Release-dependent data (ABAPs, loads) PSAP<SCHEMA-ID>DB Tables, indexes Objects of the SAP Web AS Java schema ** Este novo layout de tablespaces chamado de MCOD layout (Multiple Components in One Database). Utilizando este layout, possvel armazenar os dados de vrios sistemas SAP em um simples DB.

** NOTA: Oracle DB 10g tem uma nova tablespace, a SYSAUX. uma tablespace de help obrigatria para a tablepace SYSTEM e se dispe de uma localizao central para meta dados fora da SYSTEM. Por um lado ela reduz a leitura na tablespace SYSTEM e simplifica a administrao. A SYSAUX sempre criada com uma nova instalao ou upgrade do DB. ** Enquanto no layout antigo o SAP SID e o ORACLE SID eram iguais, no novo layout os dois SIDs podem ser diferentes. Definies: SAP SID: identificador do SAP System (DEV, QAS, PRD); Database SID: identificador do banco de dados, pode ser diferente do SAPSID; Schema ID: usado como identificador de parte de tablespace e do user SAP (owner SAPDEV, SAPQAS,..); Todos IDs podem ser diferentes, mas no precisam ser. Se MCOD no usado, todos IDs devem ser iguais. Se usado, o segundo SAP System deve ter um SCHEMA-ID diferente do DBSID. O MCOD pode ser usado a partir do 4.6C SR2, e o BR*Tools pode ser usado em qualquer tipo de layout de tablespace (e sempre suportar).

Data files (pg 232)


Convenses para os data files: criado no diretrio sapdata<n>, onde <n> nmero da diviso da tablespace; possui o nome da tablespace, sem PSAP e com final .data<n>. Se uma tablespace est cheia, trs sadas podem ser adotadas: criar um novo datafile; data file pode ser aumentado; o data file pode ser alterado para autoextensible. Ele crescer at o tamanho mximo (MAXBYTES) em intervalos de INCREMENT_BY. Como o tamanho da base no importante (salvo sistemas 32 bits), o nmero de data files deve ser em torno de 100, quando a base est no tamanho esperado. Neste caso, ser mltiplos de 2Gb, sendo tamanho mximo/100: Tamanho de Database esperado At 200 GB 200 at 400 GB 400 at 800 GB Maior que 800 GB Tamanho do Arquivo (data file) 2GB 4GB 8 GB 16 GB

RAW devices (pg 233)


so somente suportados em UNIX, e nesse caso o Oracle vai gerenciar o uso do disco. No uso de RAC (Real Application Cluster), deve-se usar um cluster file system ou um RAW device, uma vez que existem vrias instncias acessando o mesmo datafile. Vantagens de usar RAW: I/O mais rpido; um pouco menos de espao requerido recovery mais rpido. Desvantagens do RAW: deve ser bem documentado, apenas um data file por raw device, backup somente via RMAN ou dd (ambos suportados pelo BR*Tools).

Dictionary-Managed Tablespaces (pg 234)


Eram usados no formato antigo de tablespaces, mas a SAP recomenta usar Locally Managed Tablespaces (possvel via reorganization).

Cada segmento formado por um ou mais extents (coleo de blocos alocados sequencialmente). O Oracle verifica e atualiza o dicionrio de dados sempre que precisar alocar um novo extent. O tamanho do extent e outros parmetros so chamados de storage parameters, e so guardados do dicionrio de dados. Esses parmetros so configurados na criao da tablespace, e podem ser sobrepostos na criao de uma tabela ou alterado via BR*Tools para as tabelas existentes. Os parmetros principais so: MINEXTENTS: mnimo nro de extents alocados na criao da tabela; INITIAL: tamanho do extent inicial que alocado quando a tabela criada; NEXT: tamanho dos extents criados quando os anteriores esto cheios; PCTINCREASE: no usado no SAP. Porcentagem maior do anterior a ser criado; MAXEXTENTS: quantidade mxima de extents que podem ser criados.

Desvantagens deste tipo de alocao de espao: deve haver rea livre contnua maior que o NEXT. Pequenas reas livres no so usadas neste caso; quando um segmento dropado, ele pode ser usado. Porm reas livres subseqentes no so aproveitadas como uma rea grande livre, at execuo do coalesce; o administrador deve verificar se est perto de MAXEXTENTS. Para evitar erro (ORA-01553 maxextents reached), aumentar o tamanho de NEXT; o parmetro NEXT deve ser verificado freqntemente para evitar que cresa mais que o necessrio para o perodo. O BRCONNECT pode ser usado para adaptar o NEXT extents. O BRSPACE pode ser usado para coalesce manual, e o brconnect f ceck para coalesce de forma automtica.

Locally Managed Tablespaces Todas tablespace criadas pelo SAP so usadas no novo layout MCOD. Cada data file tem um bitmap listando blocos usados e livres. O Oracle procura em cada data file se h espao contnuo para alocar um novo extent. O tamanho do extent no mais definido por parmetro. Ele pode ser idntico para todos extents (UNIFORM) ou escolhido de acordo com o tamanho do segmento (AUTOALLOCATE), escolhidos na criao da tablespace e no mais alterado posteriormente. SAP usa locally managed tablespace, com automatic extent allocation, exceto: PSAPTEMP: criada LM (locally Managed) mas com extent size UNIFORM; PSAPROLL: dictionary-managed (substituda pela PSAPUNDO: UNIFORM); Em sistemas SAP BW, tablespaces que contm tabelas fact ou aggregats, devem ser criadas com uniform extent size de 1Mb. Vantagens adaptao de NETX ou MAXEXTENTS no mais necessrio; devido ao tamanho mximo do extent ser 64Mb, menos fragmentao causado e o espao no data file melhor gerenciado; melhor performance em dropps ou criao de tabelas em paralelo, uma vez que no necessrio atualizar o dicionrio de dados. Desvantagem a busca por blocos usados e livres consome recurso. Rollback tablespace O gerenciamento de extents similar ao da dictionary-managed tablespace, porm com a adio do parmetro OPTIMAL. Quando uma transao sofre commit, o extent marcado para sobreescrito. Em certos casos, o Oracle redimensiona a tablespace para seu tamanho OPTIMAL. Desvantagens: parmetros devem ser experimentados at chegar a um bom valor, pois depende do tamanho e uso do sistema; como o Oracle pode escolher qualquer segmento de rollback, os parmetros devem ser alterados para todos os segmentos de rollback; em caso de grande movimentao de dados, a SAP recomenda criar outra tablespace de rollback. Undo Tablespace (pg 241) A partir da verso 9i a Oracle introduziu o automatic undo management (AUM). Vantagens: gerenciados automaticamente; uma transao pode usar mais de um undo segment; o tempo em que um segmento pode ser sobreposto no mais o commit, e sim o tempo definido em undo_retention, evitando o erro ORA-01555; alterar para undo tablespaces grandes, para grande movimentao de dados, mais fcil. Parmetros adicionados: undo_management: MANUAL ou AUTO (para ativar); undo_tablespace: comando CREATE UNDO TABLESPACE PSAPUNDO; undo retention: tempo de reteno em segundos, antes que o dado possa ser sobreposto; undo_supress_errors: suprime os erros ao tentar mudar manualmente.

** OBS: SAP recomenda que faa switch da tablespace Rollback para tablespace UNDO no Oracle 9.20. Passos para alterar de rollback para undo: 1) Criar tablespace PSAPUNDO; 2) Alterar ou inserir os 4 parmetros; 3) Drop em todos os segmentos de rollback (exceto no SYSTEM); 4) Remover ou comentar o parmetro rollback_segments; 5) Remover a tablespace de rollback Pricipais Erros Oracle Erro Descrio ORA-1578 Corrupt Oracle Blocks ORA-1553 Maxetents reached ORA-1653 Tablespace Overflow - Tables ORA-1654 Tablespace Overflow - Index ORA-1555 Snapshot to old ORA-272 *** Database System Check (pg 248) O BRCONNECT usado para verificar o banco de dados, adaptar NEXT extents, criar estatsticas e apagar DBA logs. Transao DB13 (DBACOCKPIT) : Check the database Checking the Database A ferramenta brconnect -f check deve ser agendada diariamente. Para fazer o check do banco de dados, o BRCONNECT verifica as condies na tabela DBCHECKORA. O log criado /sapcheck/c<encoded_timestamp>.chk, e pode ser visto via editor de textos, BRTOOLS ou DB14. Erros e warnings podem ser vistos ainda na DB16 e CCMS. Pode ser executado via BRTOOLS > Check and verification > Database system check ou comando brconnect f check. Para atualizar os parmetros, acessar DB17: adicionar novas condies DBO, ORA ou PROF; excluir condies do check; especificar valores padro; criar condies para serem excludas do check; criar condies para definir valores padres; especificar aes de correo; manter descries das condies. Tipos de verificao na tabela DBCHECKORA: Database administration (DBAs): operaes de administrao, como configurao, gerenciamento de espao. No podem ser adicionados. Para excluir, usar parmetro check_exclude do init<DBSID>.sap; Database operation (DBO): verificaes de operao, como backup e falhas; Oracle messages: o arquivo e log verificado em busca de erros. Oracle profile parameters (PROF): verificao de parmetros do profile.

Detalhes no Log do Database System Check Tablespaces and Data Files: lista todos tablespaces e seus data files (status, size); Redo Log Files: todos Redo log files (size); Control files: controls files (size); Database disk volumes: lista os volumes dos discos contendo dados do DB; Tablespaces fragmentation: estatsticas de nro data files, tables, index, extents, usage e free space das tablespaces; Check conditions for Database Administration: lista todas condies de check do DBCHECKORA; Adapting the NEXT Extent Size Brconnect f next deve ser executado regularmente para adaptar o parmetro NEXT de todas as tablespaces gerenciadas por dicionrio para evitar: ter vrios pequenos segmentos (degrada performance, perto do limite de MAXEXTENTS); ter segmentos muito grandes (perda de espao em disco, fragmentao, tablespace overflow). Objetos em tablespaces localmente gerenciadas so automaticamente excludos. Comando normalmente utilizado: brconnect u / -c f next t all O algortimo utilizado para determinar o valor otimizado para NEXT garante que NEXT : no valor menor que o valor atual e como especificado no SAP data dictionary para este tipo de tabela ou ndice; em torno de 10% do tamanho total da tabela ou ndice, se o tamanho maior que o esperado; menor que a maior rea livre contnua da tablespace, se esta no autoextensvel. O log guardado em /sapcheck, com extenso .nxt e pode ser visto da mesma forma que o log da database system check. Checking and Updating Database Statistics (pg 260) Oracle usa otimizador baseado em custo para encontrar o melhor caminho quando selecionando tabelas. No SAP, o parmetro optimizer_mode configurado para CHOOSE, o que indica que o Oracle usar o otimizador baseado em custo quando estatsticas esto disponveis. Isto porque algumas tabelas sofrem alteraes de dados frequentemente, e no devem ter estatsticas geradas. Para fazer o update statistics, executar brconnect f stats, que verificar se as estatsticas esto desatualizadas e atualizar as necessrias. SAP recomenda a execuo de brconnect u / -c f stats t all semanalmente. Pode ser agendada via DB13. Para atualizar apenas as tabelas que no possuem estatsticas (ex.: recm criadas): brconnect f stats t missing, ou DB20 > Global statistics > Create missing. O log gerado em sapcheck, com a extenso .sta, e pode ser visualizado como no database system check. Cleaning Up Old Logs and Traces (pg 262) Para limpar logs e arquivos intermedirios (como backups), execute brconnect f cleanup, que limpar: Logs detalhados do BR*Tools; Backups em disco; Export dumps e scripts criados pelo BRSPACE; log records e check results nas tabelas SDBAH, SDBAD, DBA*, e DBMSGORA; Oracle trace e audit files.

Comando normalmente executado: brconnect u / -c f cleanup Por padro, arquivos anteriores a 30 dias e database log records anteriores a 100 dias so removidos. Esses valores podem ser alterados via parmetros especficos no init<DBSID>.sap. Checking Database Growth (pg 263) Os dados estatsticos sobre o crescimento do banco podem ser visualizados via DB02. A tela de entrada mostra um sumrio das informaes do tamanho do banco de dados e espao livre. Overview das funes na memria space analysis na DBA Cockpit: Space Overview: size DB e free space; Database: estatsticas da memria de todo DB; Users: informaes sobre usurios e objetos associados a ele, (status user acount, user bolcked); Tablespaces: current size, free espace, status (on/offline)... Segments: size e nro segments, extents alocados; Aditional Functions: job que coleta dados, BW; Para mais detalhes, selecionar os botes: Space statistics: estatsticas do espao de toda a base; Current sizes: tamanho e status de tablespaces e tabelas; Space statistics: estatsticas de espao por tablespace; Freespace Statistics: informaes detalhadas do espao livre nas tablespaces, incluindo fragmentao; Space critical obects: todos os segmentos que o next extent maior que a maior rea livre. Para coletar estatsticas do banco de dados, SO e SAP, e guardar os dados em tabelas, o job COLLECTOR_FOR_PERFORMANCE_MONITOR deve estar agendado em freqncia horria, executando o ABAP report RSCOLL00. O report RSCOLL00 l a tabela TCOLL para ver o que ser verificado e em que horrio. O report coleta as informaes e guarda nas tabelas MONI (dados estatsticos) e PAHI (parmetros). CCMS Alert Monitor (PG 274) O CCMS pode ser usado para monitorar e verificar as seguintes funes: Space Management: tablespaces e segments; Performance: otimizador de estatsticas, buffers, logs e checkpoints; Backup or restore; Consistency: entre objetos ABAP e dicionrios do Oracle; Health: system checks do BRCONNECT. O principal coletor de informaes sobre o banco o BRCONNECT, que escreve os resultados na DBMSGORA, lida pelo CCMS. Os MTEs (Monitoring Tree Element) na RZ20 podem ser removidos, aps alterao de parmetros na DB17. Aps remoo, executar programa RSDBMON0 para recri-los, com as novas configuraes. Para evitar acessos excessivos view DBA_SEGMENTS, necessrio executar o brconnect f check uma vez por dia. Caso os dados sejam mais antigos que um dia na DBMSGORA, os dados sero exibidos da DBA_SEGMENTS.

Unit 4 Storage Management


Tablespace Administration Principais atividades na administrao das Tablespaces: Criar, Deletar, Extender (para adicionar um data file ou tempfile), Mover. Em operao normal, a criao de uma nova tablespace ou a remoo de uma existente no necessria. Este o caso de upgrade e preparao de uma reorganizao online. Para criar uma nova tablespace, acessar BRTOOLS > Space management > Create tablespace. Opes: tablespace: nome da tablespace, seguindo padro SAP (PSAP<SCHEMAID><unique name>; contents: data (dados + ndices), temp ou undo; space: auto (gerenciamento de espaos de segmento automtico) ou manual. Sempre criado locally managed tablespaces; class: opo para table data type quando criar uma tabela (all, old_tsp, old_tsp_list) owner: s em casos de MCOD; data: table, ndex ou both (recomendado para facilitar administrao); joint: se escolheu table ou ndex acima, especificar a tablespace de ndice ou tabelas correspondente. Aps o continue, um novo menu apresentado: file: o nome do novo data file para a tablespace; rawlink: Soft link para um raw disk ou diretrio externo; size: em MB; autoextend: Yes (cresce automaticamente) ou no; maxsize: para autoextensible data files (tamanho MAX em MB); incrsize: para autoextensible data files (increased automatic); Antes e a ps a criao, um backup do control file criado em /sapreorg, alm de log da operao em /sapreorg/struc<DBSID>.log. Para remover, BRTOOLS > Space management >Drop tablespace. Por padro, uma tablespace no apaga se no estiver vazia. O parmetro force = Yes altera isso. Quando dropar um tablespace, BRSPACE vai: criar um backup do control file antes de aps a remoo; verificar se a tablespace est vazia; torn-la offline; remov-la, inclusive seus data files; remover todos os subdiretrios; criar uma entrada no log struc<DBSID>.log. ** Enlarging Tablespace Para aumentar uma tablespace, trs opes so possveis: adicionar novo data file; as propriedades do data file pode ser mudada para autoextensible; um data file pode ser aumentado. **

Add new datafile: BRTOOLS > Space managment > Extend tablespace. O menu similar ao de criar uma tablespace nova (ou BRSPACE -f tsextend > enter). Resize datafile: BRTOOLS > Space Management > Alter data file > Resize data file. (ou BRSPACE -f dfalter > Resize data file). Turn on and maintain autoextend: BRTOOLS > Space Management > Alter data file > Turn on and mantainance autoextend (ou BRSPACE -f df alter > Turn on and mantainance autoextend; Turn off autoextend: BRTOOLS > Space management > Alter data file > Turn off autoextend; Rename data file: BRSPACE > Alter data file > Rename data file; Drop empty data file: BRSPACE > Alter data file > Drop empty data file; Moving ou rename data file, o BRSPACE o faz somente com padro de nomenclatura SAP. BRTOOLS > Space management > Move data file; Informaes de uma tablespace: BRTOOLS > Space management > Additional space functions.

** Para alterar uma tablespace: BRTOOLS > Space management > Alter tablespace Possibilidades: Set tablespaces offline ou online; Todas tablespaces devem ser online Set ou reset the backup status: quando o BRBACKUP apresenta erro, uma ou mais tablespaces podem ficar em status backup mode. Neste caso, um shutdown no funciona e se for um shutdown abort, necessrio recovery manual. Coalesce free extents: Rename Tablespaces: ** Reorganization of Tables(pg 306) Reorganizao normalmente utilizada para retirar a fragmentao de objetos do banco. Executando ela, melhora-se a performance e recupera-se espaos fragmentados. O modelo clssico : export das tabelas; drop das tabelas (e tablespace); recriao da tablespace (se foi removida); import das tabelas. Nas verses de Oracle 8 e 9i, junto com a evoluo de discos e RAID, novas caractersticas foram introduzidas, diminuindo a necessidade de reorganizaes: locally managed tablespaces possuem alocaes mais eficientes; usando automatic segment space allocation, a fragmentao de blocos significadamente reduzida e a performance de queries em paralelo melhorada; discos grandes com RAID e buffers maiores e mais seguros diminuem o I/O.

Usando as facilidades de redefinio online do Oracle, a reorganizao (online table redefinition) ocorre de forma mais fcil. Vantagens e caractersticas: pode ser feita online; pode ser paralelizado; pode ser usado para mover tabelas para outras tablespaces; pode ser usado para recriar uma tabela, reduzindo fragmentao; diminui o risco, onde verificaes so feitas antes do processo e a remoo do objeto apenas aps a criao do mesmo. Razes para desfragmentao no Oracle 9i: tabelas fragmentadas e ndices fragmentados ou degenerados; transformar dictionary-managed em locally managed tablespaces; mover tabelas para novas tablespaces. BRSPACE suporta online table redefinition e mtodos tradicionais de reorganizao. BRTOOLS > Segment Management. Mtodos de Reorganizao: Reorganize Tables: redefinio online, usado para diminuir fragmentao, transformar dictionary-managed tablespaces em locally managed, transformar tablespaces do layout tradicional em layout do MCOD, mover tabelas grandes para uma tablespace separada. Rebuild indexes: recriar ndices; Export e Import tables: mtodo tradicional de reorganizao. Usado em Oracle 9i em tabelas com campos LONG; Alter tables e indexes: algumas funes de performance, como switch on table monitoring, onde o Oracle controlar se a tabela foi alterada (acelerando consulta para update statistics) e set parallel degree, para prover performance em INSERTs (com o aval da SAP, no usado em produo). Steps for online table redefinition (pg 312) BRSPACE usa o PL/SQL DBMS_REDEFINITION; tabelas so verificadas se podem ser redefinidas online; cria uma tabela temporria, com nome <ORIGINAL>#$; copia os dados para a temporria, pode ser paralelizado; cria ndices, contraints, triggers, etc.; termina o processo com o pacote DBMS_REDEFINITION; objetos criados so renomeados; - BRSPACE apaga a tabela temporria. Em caso de erros, a tabela original permanece intacta, e o BRSPACE apaga a tabela temporria. Antes de iniciar a reorganizao usando online table redefinition, verifique: se vai mover para nova tablespace, ela existe? tablespace locally managed? h espao na tablespace/disco? Para reorganizao, BRTOOLS > Segment management > Reorganize tables. Pode-se usar caracteres para tabelas ([<owner>].<prefix>* ou *), especificar a tablespace (todas tabelas sem LONG sofrero reorg) ou deixar em branco (sero apresentadas as tabelas). O parmetro reorg_table no init<DBSID>.sap pode ser usado para informar quais tabelas sofrero reorg. Os parmetros para reorganizao so: newts: nova tablespace ou vazio para atual; indts: tablespace de ndice (se diferente da de tabelas); parallel: paralelismo; degree: paralelismo de cpia para as tabelas temporrias;

ddl: NO (comando DDL gerado apenas internamente, no recomendado), YES (gera ddl.sql em /sapreorg), FIRST (gera o ddl.sql e aguarda confirmao antes de executar). Initial: Categoria do INITIAL extend size; Sortind: acesso seqencial parcial; Mode: default DBMS_REDEFINITION (online). Rebuild Indexes Para recriar ndices, acessar BRTOOLS > Segment management > Rebuild indexes. As opes so similares de reorganizao, porm no Criado DDL ( usado o comando ALTER INDEX REBUILD ONLINE), especificando a tabela, todos ndices dela sero recriados e uma nova tablespace para os ndices pode ser informada. O BRSPACE suporta o mtodo tradicional EXP/IMP, porm s recomendado para tabelas que no podem sofrer redefinio online. Alm do utilitrio, vrios passos devem ser feitos manualmente. Transformation of Dictionary-Managed into Locally Managed Tablespaces (p 319) Para transformar uma tablespace gerenciada pelo dicionrio de dados em localmente gerenciada, faz-se a online reorganization em uma nova tablespace, com os passos adicionais: 1. Criar uma tablespace localmente gerenciada, que conter dados e ndices. Recomenda-se que seja auto-extensvel; 2. BRTOOLS > Segment management > Reorganize tables, escolha a tablespace e coloque * para as tabelas; 3. Continue e confirm; 4. Em Options for reorganization of tables, defina o nome da nova tablespace. Tabelas que no podem ser reorganizadas online permanecero na tablespace antiga. Neste caso: - utilizar export / import aps a reorganizao; Assim que possvel, usar o BRSPACE para converter LONG em LOB antes da reorganizao. Segment Shirinking (pg 320) Oferece uma alternativa para a desfragmentao de uma reorganizao por segmento ganhando assim mais espao livre. Alguns pr-requisitos devem ser atendidos: Deve ocorrer em uma tablespace ASSM; No permitido para Tabelas com campos LONG e LONG RAW, Tabelas mapeadas e overflow segments de IOTs e Tabelas compactadas; ROW MOVEMENT deve estar ativo; Housekeeping and Troubleshooting (pg 327) Reviso das atividades: Database System check deve rodar diariamente, agendada via DB13. DB14 deve ser verificada para warnings/erros. Warnings e erros devem ser solucionados; Check and adapt NEXT extents: executar semanalmente, agendada via DB13. Verificar logs na DB14; Update optimizer statistics: deve rodar semanalmente, agendada via DB13. Verificar logs na DB14; Clean up old logs and traces: deve rodar semanalmente, agendada via DB13. Verificar logs na DB14; Database backup deve rodar diariamente, agendada via DB13 (DBA Cockpit)

Archiver stuck Ocorre quando no possvel copiar o online redo log e o LGWR necessita sobrepor este arquivo. Isto normalmente ocorre quando o disco do diretrio de archive est cheio. Para evitar, recomenda-se: ter bastante espao no diretrio de archives, pelo menos 3x o tamanho dirio esperado; criar um arquivo dummy 10x maior que um archive. Assim ele pode ser apagado, o sistema volta a funcionar e rotinas como backup de offline redo log files podem ser executadas; usar o diretrio de archive em uma unidade diferente de onde o BRARCHIVE guarda os logs. Online Backup Crashed Quando ocorre erro durante o backup online, algumas tablespaces podem ficar em estado de backup. Para verificar, executar brspace c force f dbshow t tslist. Neste caso: Verificar no sistema operacional se o BRBACKUP est em execuo; Iniciar BRTOOLS > Space management > alter tablespace > Reset backup status; coloque 0 para selecionar todas tablespaces; remover arquivo /sapbackup/.lock.brb; executar um teste de backup para ver se est OK. Caso o banco tenha cado durante o backup, o erro ORA 01113: file N needs media recovery. Um recovery pode ser necessrio: brrecover c force t complete; ou via SQL*Plus: ALTER DATABASE END BACKUP, em que o recovery no executado (somente se um data file no precisou ser restaurado).

Unit 5 Introduction to Oracle cache management


Oracle System Global Area Em sistemas SAP, o nico usurio que deve acessar o banco o administrador do banco. Terminologia: database: coleo de dados, logicalmente formam uma unidade, fisicamente um ou mais datafiles. Um objeto do banco de dados (ex.: tabela) est em uma tablespace (unidade lgica), que pode ter um ou mais datafile. Instance = memory + processes: memory: shared memory = system global area (SGA). Cada instncia possui sua prpria SGA, que no compartilhada com outras instances. processes: processos background. No Unix se v processo a processo, no NT apenas um Oracle (usa threads). DBSID: identificador do banco de dados, nome nico, no caso da SAP com 3 caracteres (upercase, sendo primeiro obrigatriamente letra, os outros 2, letras ou nmero)

Listerner no faz parte da instncia, faz parte de processos de rede. Cada work process se comunica com um shadow process. O work process se conecta automaticamente aps queda/startup do banco. O gerenciamento de memria separa rea de memria que pode ser usada por todos os processos (SGA) ou para cada processo individualmente (PGA) parmetros em bytes:

SGA (System Global Area ou shared memory): Buffer Pool (Data Buffer ou Buffer Cache): buffer para data blocks (DB_BLOCK_BUFFERS em blocos ou DB_CACHE_SIZE usando dynamic SGA); Shared Pool: buffer para comandos SQL (Shared SQL Area, Shared Cursor Cache ou Library Cache) e informaes do dicionrio de dados (Dictionary Cache ou Row cache). Parmetro SHARED_POOL_SIZE; Java Pool: cache para java (JAVA_POOL_SIZE); Large Pool: buffer para dados especiais (multi-thread, RMAN com vrios I/O, PL/SQL, etc.). Parmetro LARGE_POOL_SIZE; Redo Buffer: buffer para redo log (LOG_BUFFER). PGA (Program Global Area ou process-local memory): Buffer para sorting, hash joing e outras atividades temporrias (PGA_AGGREGATE_TARGET quando usa automatic PGA administration). Parametrizao do SAP: Buffer pool: grande o suficiente para a qualidade ser maior que 95%; Shared pool: pelo menos 400Mb; Java Pool: se no usado, valor 0; Large Pool: no necessita configurao, pois usa pouca memria; Redo buffer: bom valor: 1Mb, no deve ser excedido; PGA: valor mximo que conseguir. Dynamic SGA(pg 354) At oracle 8.1.7.* as reas de memrias no eram mudadas dinamicamente. A partir da verso 9, com a opo Dynamic SGA, o boot no requerido. Multiple Block Sizes para tablespaces no so recomentadas pela SAP. Parmetros para Dynamic SGA: SGA_MAX_SIZE: tamanho mximo em que a SGA pode crescer automaticamente (soma dos parmetros das subreas da SGA); DB_CACHE_SIZE: tamanho do buffer cache, e que ativa o Dynamic SGA. No usar junto com DB_BLOCK_BUFFERS (Oracle 8i e menores); Parmetros que podem ser alterados dinamicamente quando ativo o Dynamic SGA: DB_CACHE_SIZE: buffer cache; SHARED_POOL_SIZE: shared pool; LARGE_POOL_SIZE: large pool. Parmetros no alterados dinamicamente: SGA_MAX_SIZE: tamanho mximo da SGA; LOG_BUFFER: tamanho do redo log; JAVA_POOL_SIZE: java pool. Oracle Program Global rea - PGA (pg 366) Program Global Area conhewcido como Process Global Area ou Work Area. Optimun: comando feito sort na PGA. Ideal > 90% (OLTP); One-pass: acessa tabela temporria para fazer 1 nvel de sort (separa em blocos de sort e depois junta tudo no banco). Ideal < 10% (OLTP); Multi-pass: necessita criar vrios nveis de sort at chegar no resultado esperado. No deve ocorrer. No Oracle 8i: SORT_AREA_SIZE HASH_AREA_SIZE BITMAP_MERGE_AREA_SIZE BITMAP_CREATE_AREA_SIZE

Parmetros estticos. No Oracle 9i: WORKAREA_SIZE_POLICY = AUTO PGA_AGGREGATE_TARGET = 100MB Define-se o tamanho total da PGA da instncia, e o Oracle gerencia de forma automtica como deve ser. O parmetro dinmico, ou seja, pode ser alterado em runtime. O Oracle avalia toda a memria disponvel na PGA, a quantidade que o comando precisa e aloca a memria necessria. O Oracle calcula, em regra geral (9i): mximo 5% para Shadow Process; mximo 30% para processo paralelos da Shadow Process; mximo 200Mb para Shadow Process. Clculo estimado para a PGA: PGA_AGGREGATE_TARGET = <memria fsica > * 20% (OLTP); PGA_AGGREGATE_TARGET = <memria fsica > * 40% (OLAP); PGA_AGGREGATE_TARGET = (SORT_AREA_SIZE + HASH_AREA_SIZE + ...) * (#Shadow process / 10).

Unit 6 Monitoring of the database instance


A nova transao ST04N pode ser usada para monitoramento do Oracle, seja ele single ou RAC. Ela substitui a antiga ST04 e busca informaes das views V$, GV$ (existe apenas no RAC) e DBA. A nova transao apenas para Oracle 9i+. The Performance Overview Monitor Nova transao DBACOCKPIT fornece estrutura e dados eficincientes nos itens: General informations, Data Buffer, Shared Pool, Log buffer, Calls, Time statistics, Redo logging, Table scans and fetches, Sorts e Instance efficiency. ** Muitos nmeros dependem uns dos outros. Abaixo algumas figuras-chave do desempenho do DB: Data buffer quality: proporo das leituras fsicas em relao ao total de leituras. Deve estar acima de 94% em um total de 15 milhes de leituras; ratio of user and recursive calls: uma boa performance indica proporo maior que 2; number of reads per user call: se exceder de 30, pode indicar expensive SQL; Time/User Call: valores acima de 15 ms indicam necessidade de otimizao; Busy wait tine X CPU time: valores em torno de 60:40 indicam um sistema estvel. Valores muito acima indicam necessidades de melhoria; DD-cache quality: deve estar acima de 80%. ** As novas funcionalidades do Oracle 9i suportadas pela SAP so: uso do SPFILE; Automatic Undo Management (AUM); Automatic segment space management (ASSM), que prov um uso melhor de espao, reduzindo buffer busy waits; Dynamic System Global Area: permite alterar parmetros de buffers online; Automatic Program Global Area memory management; Online reorganization of tables: tambm possvel no 8i; Defaul temporary tablespace: a partir do AS 6.40, tablespace PSAPTEMP a tablespace temporria padro, no usando a SYSTEM para isso; Locally managed SYSTEM tablespace; Suporte ao RAC; Snapshots = dados histricos; Dados histricos do SAP so guardados na tabela MONI; Dados histricos do banco so gravados em tabelas GVD*, atualizadas via report RSORAHCL (ou RSORAHIST);

UNIT 7 - monitoring of the database instance (no deve cair na prova)

Unit 8 - Analysing Application Design


Consequences of Expensive SQL Statements (Conseqncias de instrues SQL caras) Expensive statements so definidos como todas as instrues SQL que fazem com que o banco de dados possa ler muitos blocos (do disco ou buffer). Expensive SQL statements poderia ter consequencias negativas na performance do sistema SAP: O DB ocupado lendo muitos blocos. Todas as tarefas podem ser lentas; Muitos blocos poderiam ser deslocados do DB buffer; pode ter impacto negativo nas prximas requisies; O WP bloqueado (aguardando resposta do DB) e no disponvel para outras requisies; ** Perguntas e Respostas no sistema SAP Pergunta Quais reports/transaes contem Expensive selects? Qual tabela acessada expensively? Qual ndice usado para o acesso? Qual clausula WHERE esta sendo usada? Qual statement melhor parmetros atunning? **
Using SM50/SM66 to Find Expensive SQL Statements (PG 459) SM50 - Local WP SM66 - Global WP Como identificar: Identificar atividades longas relacionadas ao banco (ex.: sequential read, insert, update); Anotar o nome do report e da transao (SM66) para anlise detalhada; Anotar o nome da tabela em que a ao executada; Anotar o nome do usurio para possveis futuras assistncias; Na SM50, possvel ver o SQL atual.

Onde posso encontrar a resposta SM50/SM66 - atual ST03, STAD - passado SM50/SM66, ST04/DBACOCKPIT ST04/ DBACOCKPIT, ST05 ST04/DBACOCKPIT, ST05, SM50 ST03, ST04/DBACOCKPIT

Using ST03N/STAD to Find Expensive SQL Statements Usando a ST03N, possvel identificar transaes que usam uma parte significativa do tempo total de resposta, bem como transaes com tempo de banco de dados grande. Escolha Standard Transaction Profile na transao ST03 e restrinja por Dialog. Como usar a transaction profile: Ordene por Total Database Time: acima de 5% do tempo todal deve ser avaliada; Ordene por Average Database Time per dialog step para encontrar transaes com a maior mdia de load database; Acessar a STAD e escolher: um perodo de tempo; Task Type D; Valor relevante do DB Request Time.

Using ST04N to Find Expensive SQL Statements A ST04N oferece uma viso diretamente nos processos atuais do banco de dados. Isto til para identificar queries em execuo e prover maiores detalhes do qu est acontecendo. Como usar o Oracle Session Monitor: 1. ST04 > Performance > Wait Event Analysis > Session Monitor; 2. Identificar o work process ID (proveniente da SM50/SM66); 3. Verificar a ao em SQL text; 4. Analizar o explain plan da query. ** Logical Reads: Nmero de Oracle buffers blocks para ler a declarao a partir dos data buffers; Buffer Gets: Nmero de Oracle buffers blocks para ler a declarao a partir dos data buffers; identico no sentido lgico para leituras; Physical reads/disk reads: Nmero de Oracle blocks lidos para as instrues do hard disk; ** Obtendo expensives SQL statements usando o shared cursor cache: 1. Chamar ST04 > Performance > SQL Statement Analysis. Shared Cursor Cache: Analysis of Shared Cursor Cache; 2. Selecionar em buffer gets, um numero igual a 5% dos logical reads da ST04N; 3. Verificar as SQLs que causam esse consumo; 4. Analisar o explain plan (com link para o call point no programa ABAP); Using the SQL Trace to Find Expensive SQL Statements (pg 480) ST05 uma ferramenta para analisar acessos ao banco de dados. Grava tempos de acessos em diferentes passos executados no banco. Tambm faz trace de enqueue, RFC e buffer. O tamanho mximo definido pelo parmetro rsrt/Max_filesize_MB, que normalmente 16MB no ECC. Exlusive Lockwaits (pg 488) Os locks podem ser divididos em Database Locks/Database enqueues e SAP Enqueues. Tipos de lock Oracle: User enqueues: TX (Tansaction enqueue); TM (DML Enqueue): quando o objeto todo est em lock (ex.: rebuild, VALIDATE STRUCTURE); System enqueues: ST (space transaction): em tablespaces dictionary-managed em alocao ou liberao de extents; CI (Cross Instance Invocation enqueue call): em truncates, drops, etc. O monitoramento de database locks pode ser feito via anlise do wait event enqueue, via V$LOCK ou ST04N. A durao pode ser acompanhada na V$ENQUEUE_STAT ou ST04N > Detailed Analyses > Exceptional Conditions > Enqueue Monitor.

Quando um processo aguarda um lock para utilizar um recurso, chamado Exclusive Lockwaits. Lockwaits podem ser enfileirados de forma que ocupem todos os WP disponveis, sendo necessria a eliminao do processo via sistema operacional. O Oracle Lock Montor pode ser acessado via DB01 ou ST04N > Detailed Analysis > Exceptional Conditions > Lock monitor, que indica o causador do lock, os bloqueados e a chave bloqueada. Para evitar exclusive lockwaits, o lock deve ser requisitado pelo programa o mais tarde prossvel.

Unit 9 Index Management and Optimization (pg 503)


Index utilization (pg 504) Index serve apenas para acelerar o acesso ao dado, apontando diretamente para onde ele est. A criao de ndices no necessita alterao de cdigos SQL. Um ndice composto de um ou mais campos de tabelas. Cada linha de uma tabela identificada por um ROWID, que o datafile number + data block + row number. No ndice, as colunas so ordenadas para facilitar o acesso. Quanto menos campos em um ndice, a reusabilidade aumenta e a deciso do otimizador melhora. Index scheme: B-Tree: um bloco root, com pointers para outros blocos; Bitmap: bom para vrios valores repetidos, aponta para uma range de valores na tabela. Tipos de ndices: primrio: define normalmente o unique da tabela; secundrio: para acelerar pesquisas sem ser pelos campos chaves; unique secondary: ndice secundrio, com unique constraint. Acesso a ndices: Fast Full Index: campos requeridos esto no ndice. Index Unique Scan: quando a clusula where tem os mesmos campos que no ndice; Index Range Scan: quando a clusula where tem menos campos que o ndice. Nesse caso, a ordem importante para acelerar o processo; Unselective Index Range Scan: quando um campo da clusula where est no ndice, o outro no. Todos os dados so lidos do ndice, onde feito um sort do outro campo. Muita carga gerada, e pode ser interessante o full table scan neste caso; Index Skip Scan: at Oracle 8i, s podia usar ndices compostos (mais de um campo) caso o where contivesse todos os campos necessrios. A partir do Oracle 9i, caso apenas dois campos estejam na query, um ndice com 3 campos no na mesma sequncia pode ser usado. As vantagens so: acelerao de algumas queries e obteno de uma boa performance com menos ndices (ocupa menos espao, acelera manutenes e DMLs). Full Table Scan: so verificados todos os blocos da tabela, sem ndice. Pode ser eficiente se vrios dados so requisitados. Creating an Index (pg 521) Antes de sair criando indices: se o SQL for original, procurar por notas ou abrir chamados; se o SQL for customizado, tentar usar tcnicas como matched tables e SAP business ndex tables, reescrever o cdigo para usar ndices j existentes ou adaptar um ndice j existente. ndices secundrios crescem junto com a tabela, o que torna a pesquisa cada vez mais lenta.

Regras gerais: colocar apenas campos selecionveis na query; usar poucos campos como possvel (mximo de 4); posio dos campos no ndice: campos geralmente no utilizados colocar no final; ndices devem ser disjunct: no se parecer com outros ndices; usar poucos ndices em uma tabela: geralmente at 5, exceto quando tabelas que sofrem muita leitura, como mster data; no alterar ndices originais da SAP. Antes de criar um ndice, deve-se ver quo seletivo ele ser. Para isso, acessar a DB05, ou via SQL*Plus (having count(*) > 100, para ver se retornar mais de 100 linhas diferentes). Na DB05, se adicionado um campo para o ndice e o nmero de valores nicos no aumentar, este campo no deve entrar no ndice. Os ndices so criados e mantidos no ABAP Dictionary, via SE11. Para verificar ndices criados no ABAP, mas que faltam no banco, acessar DB02 >Missing Indexes. Caso um ndice primrio esteja faltando: SE11 >nome da tabela >Utilities Database Utility >selecionar o ndi ce e clicar em Choose >Create Database Index. Caso um ndice secundrio: DB02 >missing indexes >selecionar o ndice >Create in DB.

Unit 10 Cost Based Optimizer


Update Statistics O otimizador baseado em custo procura o caminho (access path) com menor custo esperado de I/O. Casos em que estatsticas no so necessrias: quando se usa Rule Based Optimizer (RBO) ou usando o comando RULE; tabelas de pools e clusters; excees de acordo com a DBSTATC; Oracle DDIC Objects; para comandos Insert. Tipos de estatsticas: table statistics: informaes como nmero de linhas, nmero de blocos usados, exatido (sample_size) e data das ltimas estatsticas; ndex statistics: tamanho da rvore do ndice, nmero de chaves diferentes, etc; column statistics: nmero de valores diferentes, o menor e o maior valor, exatido e data da ltima criao de estatsticas. Para atualizar: SQL ANALYSE TALE: deve cair em desuso; Oracle DBMS_STATS package: forma mais recente. Para mudar de tipo de estatsticas, deve-se deletar a anterior; BR*TOOLS ou BRCONNECT: mtodo recomendado e deve ser agendado via DB13. Utiliza o ANALYSE TABLE, mas pode ser alterado para DBMS_STATs no init<sid>.sap; DB20: para tabelas especificadas manualmente; Report RSANAORA: pode gerar novas estatsticas para tabelas ou ndices. A partir do BRCONNECT 6.10, uma opo chamada table-monitoring pode ser ativada e recomendado pela SAP. Esse monitor acelera a fase de check das estatsticas, pois se baseia em mudanas na tabela. Cost Evaluation Parmetros que influenciam: OPTIMIZER_MODE: deve ser CHOOSE, para ativar o CBO; OPTIMIZER_INDEX_COST_ADJ: fator de multiplicao do custo de acesso por ndice. Ex.: valor 10 significa 10% do custo; OPTIMIZER_INDEX_CACHING: porcentagem de blocos do ndice que iro para cach. DB_FILE_MULTBLOCK_READ_COUNT: quantidade de blocos lidos por vez. HASH_AREA_SIZE / PGA_AGGREGATE_TARGET: quanto maior, menor o custo de hash join; SORT_AREA_SIZE / PGA_AGGREGATE_TARGET: usada para sort. Quanto maior, menor custo. O custo de um full table scan pode ser estimado pelo nmero de blocos lidos, alm do parmetro DB_FILE_MULTIBLOCK_READ_COUNT. Para bases SAP R/3, o acesso deve ser feito via ndice, ento este parmetro deve estar configurado para evitar o full table scan. A experincia mostra que o valor deve ser 8. Oracle hints so comandos para forar o CBO a ir a uma direo estabelecida. Alm de manual hints, tambm existem generated hints, que podem ser controlados via parmetro dbs/ora/use_hints. Valor padro -1 (ativado).

Unit 11 - Analyzing Physical and Logical Layout (pg 581)


Se uma query est consumindo recursos e o uso do ndice est apropriado e o cdigo ABAP est otimizado, pode ser problema de ndice fragmentado. Para desfragmentlo, necessrio reorganiz-lo. Um ndice fragmentado consiste de blocos vazios ou pginas vazias ou com poucos registros, sendo necessria a leitura de vrios blocos para poucas informaes. Um exemplo de ndices que precisam de reorganizao so ndices de tabelas de RFC. ndices se tornam fragmentados: aps archive de dados; aps vrias records serem removidas; tabelas dinmicas. Identifying a Fragment Index (pg 584) Existem treis formas de se medir a fragmentao de ndices: ndex storage quality, que compara espao livre e usado; deleted Leaf rows: compara nmero de leaf rows removidas com todas leaf rows. Comparing the index size and the table size, se um ndice maior que uma tabela, quer dizer que o ndice esta fragmentado. ndex storage quality compara o espao disponvel com o espao usado, onde os dados so levantados como: - espao disponvel: nmero de blocos de ndices usados multiplicados pelo tamanho do bloco, menos cabealho dos blocos; - espao usado: nmero de entradas no ndice multiplicadas pela mdia de tamanho de uma entrada mais 6 bytes para o ROWID e o cabealho para os blocos root e branch. Devido impreciso da anlise dos dois mtodos, eles so apenas indicadores do nvel de fragmentao do ndice, mas no podem dizer o quanto influencia na performance. Para estimar a qualidade de storage, o report RSORATAD pode ser executado diretamente na SE38 ou a funcionalidade pode ser acessada via DB02. A percentagem exibida no precisa, mas em ndices abaixo de 70% a desfragmentao recomendada. Para ndices pequenos, a percentagem pode ser baixa mesmo quando o ndice foi reorganizado. Para ndices abaixo de 10 blocos, outro mtodo recomendado. Vantagens: lock no necessrio; mostra informao exata sobre a fragmentao do ndice; Desvantagens: um ndice por vez; execuo demorada; aumenta a carga do sistema. Estimar a proporo de leaf rows e deleted leaf rows pode ser feita via ANALYZE INDEX VALIDATE STRUCTURE diretamente no Oracle ou via DB02. A relao entre deleted/entries deve ser menor que 25%. No Oracle 9, a adio de online permite a diminuio do lock, porm estatsticas no so criadas.

Vantagens: diretamente no Oracle, todos ndices podem ser analizados (via script); fornece informaes exatas sobre fragmentao do ndice. Desvantagens: a tabela bloqueada para comandos DML; execuo demorada; aumenta carga no sistema. Nos logs de execuo de estatsticas do BRCONNECT, entradas informando que o ndice is unbalanced indicam que o ndice est fragmentado. Razes para esta entrada no log podem ser: - ndice no balanceado; - parmetro STATS_CHANGE_THRESHOLD no init<DBSID>.sap est com valor baixo (padro: 50%); - a preciso do clculo do ndice est baixa, devido aos valores definidos na DBSTATC. Vantagens: - no necessrio lock; - no necessrio aumento de carga no sistema; Desvantagens: - no h garantia que todos ndices fragmentados sejam reconhecidos. Para desfragmentar, 3 formas so possveis: Drop and create view; Rebuild: vantagens: pode-se mudar de tablespace, cria nova rvore do ndice, possvel mudar parmetros sem necessidade de remover o ndice, lock na tabela pode ser evitado via parmetro online. desvantagens: requer espao em disco ou em memria. Pode ser feito via BRSPACE, report RSANAORA e via DB02 (tables and indexes monitor). Coalesce ndex: para liberar espao livre interno. Pode ser feito online. vantagens: no requer espao adicional, soluo rpida, libera blocos para uso futuro, no causa lock; desvantagens: no pode mudar de tablespace, no resolve todos problemas de storage quality baixa. I/O contention (pg 602) Conteno em I/O refere-se altos tempos de I/O, por processos acessando o banco de dados. Quando vrios shadow proesses e o DBWR acessam o mesmo disco ao mesmo tempo, conteno de I/O pode ocorrer. Conteno de I/O pode ocorrer: design de aplicao no eficiente; I/O no distribudo em vrios discos; acessos pesados a tabelas ou ndices no distribudos em vrios discos; configurao incorreta de hardware, file system e sistema operacional. Conteno de I/O normalmente causado por problemas de design da aplicao, ento este item deve ser verificado primeiro. Para identificar, usar o submonitor Filesystem requests na ST04N, que exibe informaes baseadas na V$FILESTAT: I/O per File (data file); Total per devices; I/O per Path. Verificar se a mdia de escritas e leituras est alta, acima de 20ms. Verificar existncia de eventos como write complete waits, free buffer waits e log file switch (checkpoint not complete).

Para resolver problemas de conteno de disco: distribuir o I/O nos discos disponvels; distribuir o I/O em mais discos; usar discos mais rpidos; mover tabelas ou ndices muito acessados para discos prprios. Unit 12 Analysing Memory Configuration (pg 609) - (no deve cair na prova)