ApostilaBasis

A

Curso TABC10 Curso TABC10 –– Administração Administração

Capítulo 1 – A Tecnologia R/3 Basis

• O Business Framework- É o nome da arquitetura do produto R/3- Ela trabalha com componentes de negócios (módulos configuráveis) como FI, CO, HR- Isto permite facilidade de mudanças e adaptações- Informações correm através dos processos e dos módulos- Outras vantagens da arquitetura Business Framework

- facilidade de integração com novas tecnologias (como Internet)- integração com softwares de outros fornecedores - possibilidade de desenvolvimento de funções complementares pelo próprio cliente- implementação de novas tecnologias sem interromper a operação do negocio

• Componentes do Business Framework- Business Componentes -> são os módulos funcionais (p.e. HR)- Business Objects -> são os objetos de negocio (Empregados, Pedidos, etc)- BAPI Interfaces -> são APIs de negocio, disponíveis no sistema para serem- chamadas pelos módulos do Business Framework- ou por aplicações externas (p.e. criar um pedido)- ALE -> são tecnologias que permitem a distribuição de informações- do negocio dentro do Business Framework

• O R/3 como um sistema aberto- O R/3 usa padrões da industria para garantir esta abertura (TCP/IP, OLE, EDI)- Uso padrões também para códigos de barra, armazenamento ótico, etc- Usa ainda ferramentas de comunicação internas ao R/3

- RFC -> Remote Function Call que usa o CPI-C da IBM para comunicação e processamento - de aplicações e tasks- ALE -> Application Link Enabling que permite a distribuição do processamento o R/3- e outros R/3

• Escalabilidade do R/3- O R/3 segue o modelo de aplicações Cliente / Servidor- Esta arquitetura separa lógica da aplicação, apresentação e gerenciamento de dados- Facilita a distribuição de carga e uso de novas tecnologias de hardware- Benefícios desta arquitetura

- Permite instalar novos servidores para resolver problemas e gargalos - Servidores processam em paralelo com carga homogênea e execução local dos programas- Bufferiza dados e programas perto do processador que vai usa-los- Permite balanceamento de carga e de logon, dividindo grupos de usuários p/ servidor

__________________________________________________________________________________________________________Apostila – Módulo Basis

1

• Configurações Client/Server do R/3- Os principais serviços C/S são aplicação, apresentação e acesso a base de dados- O R/3 possui 3 modelos de configuração para o ambiente Cliente/Servidor

- Central System- os 3 serviços são realizados num Host- configuração típica de mainframes com terminais gráficos

- Two-Tier- um serviço fica num equipamento e os outros 2 em outro- ex 1: PC Windows para apresentação e um servidor para aplicação e database - ex 2: Desktop poderoso para apresentação e aplicação e servidor para database- esta configuração é usada para simulações e desenvolvedores de software

- Three-Tier- Host diferentes para cada serviço- Somente um servidor de Banco de Dados por sistema R/3, embora o SGBD possa utilizar vários servidores físicos para realizar o acesso aos dados- Vários servidores de aplicação, desta forma podemos balancear cargas e executar serviços em paralelo- Vários servidores de apresentação (também chamados de Frontends) conectados em cada host de aplicação, que rodam o software de apresentação (SAP/GUI)- Protocolo de rede sempre TCP/IP- A ligação entre servidores de Banco de Dados e os de Aplicação deve ser sempre que possível a 100 Mb/s- A rede que liga o servidores de aplicação aos servidores de apresentação pode ser de 10 Mb/s

• O Middleware Basis do R/3- A arquitetura Basis também é chamada de Middleware - Ela isola as aplicações das complexidades e variações existentes entre os sistemas operacionais e bancos de dados, - Existe um Kit para cada plataforma/banco de dados- É escrito em C- Este Middleware permite ao R/3 rodar com as mesmas funcionalidades em diferentes plataformas, pois:

- Proporciona o mesmo ambiente de runtime para as aplicações R/3- Cuida de otimizar a relação entre as aplicações e o sistema operacional- Define uma infra-estrutura estável para modificações no sistema- Embute ferramentas para administração de todo o ambiente- Permite distribuição de recursos e componentes do sistema- Proporciona interfaces para descentralização de componentes e de produtos externos

- Características da tecnologia Basis- Aderência a arquitetura Cliente/Servidor- Uso de Bancos de Dados Relacionais- Uso de Interface Gráfica

• Overview do sistema Basis- Garante portabilidade ao R/3, acima deste nível todas as funções são independentes de hardware e software


2

- Executa funções que poderiam ser deixadas ao S.O.(como schedulagem de tarefas e administração de memória), porem são realizadas para garantir portabilidade- A própria interface de usuário (SAP/GUI) proporciona as opções para apresentação da aplicação- Ele proporciona canais para a troca de informações eletrônicas, como EDI, comunicação programa-a-programa via CPI-C ou transferencia de dados com sistemas legados

- A interação entre o DYNPRO (interpretador de telas do SAP), o interpretador ABAP e o dicionário de dados ABAP fornece a infra-estrutura para o desenvolvimento de programas ABAP

• Plataformas disponíveis para o R/3- R/3 roda em Unix, Windows NT, AS/400 e S/390- Pode usar SGBDs como Informix, Oracle, ADABAS D, DB/2 e Microsoft SQL Server- O SAP/GUI é compatível com Windows, OS/2, Motif e Macintosh- Pode interfacear com programas ABAP, C, C++, HTML e Java


3

Capítulo 2 – A Navegação

• Client ou Mandante- É a divisão Organizacional e Administrativa de Sistema- É um numero de 3 dígitos- É uma unidade organizacional auto contida no R/3- Permite que um instalação R/3 rode varias empresas totalmente diferentes

- Cada Client possui suas próprias parametrizações independentes- Um Client não enxerga os dados de outro Client- Balanços são emitidos a nível de Client

- O R/3 divide os dados em- Client Dependent

- Usuários- Customização- Dados das transações de negócio

- Client Independent- Telas- Programas- Dicionário de Dados- Runtimes (programas compilados)

- Tabelas Client Dependet possuem campo MANDT (indica a qual mandante pertence o dado)- Cada usuário só acessa os clients aos quais tem autorização- O Client 000 é um client fornecido pela SAP e não deve ser alterado, apenas usado como modelo para clients adicionais que necessitemos criar

• Elementos das telas- Title Bar –> titulo da tela que estamos usando- Command Field -> campo para digitarmos a transação que queremos executar- Options -> O “Mickey”, onde podemos mudar as opções da interface- Standard Tollbar -> Barra de ferramentas com ícones de navegação, salvar, help, etc- Checkbox -> Caixas para seleção de vários itens ao mesmo tempo- Radio Buttons -> Caixas para seleção de um item entre vários- Status Bar -> Barra de Status e mensagens do sistema

• Chamada de transações- No Command Field

- /Nxxxx -> encerra a transação corrente e inicia outra na mesma sessão- /Oxxxx -> abre outra sessão com a transação desejada- /I -> encerra a sessão corrente

- Podemos abrir até 6 sessões simultâneas


4

• O Help- Permite display via HTML- É instalado a parte do R/3 (não é incorporado na instalação do produto)

• Funções do SYSTEM MENU- Criar e Encerrar Sessões- Modificar User Profiles

- Hold / Set / Delete Data - > salva dados de uma sessao e os carrega a próxima vez que você executar a mesma aplicação- OWN Data -> Permite que altera dados pertinentes à seu usuário, como

- Address dados de endereço do usuário- Default transação inicial, impressora default, etc- Parameters defaults do usuário para determinados campo (p.e. Código da Empresa)

- Favorite Maint -> da manutenção nas transações mais utilizadas pelo usuário- transações favoritas também podem ser mantidas pelo Dynamic Menu

- Executar funções de serviço- Reports- Queries- Batch Input- Jobs- Table Display

- Mostrar o Status do Sistema e da transação Corrente- Executar Logoff

• O Session Manager- É uma outra interface para acesso ao R/3- Disponível a partir do R/3 Release 3.0D para clientes Windows 95 e NT- Permite que se faça login em vários sistemas ao mesmo tempo, cada sistema vira uma pasta que pode ser acessada individualmente- Tem a navegação explicita, ao selecionarmos um caminho os boxes da tela mostram todas as opções daquele ramo da arvore- Existe ainda uma 3ª maneira de se fazer logon no R/3: o SAPICON


5

Capítulo 3 – O Kernel do sistema

• Principais tópicos do KERNEL- SAPGUI- SGBD- Application Server

• O SAPGUI- Interface de apresentação do R/3, que roda no Client- Especifico para cada tipo de Client, porem com idênticas funcionalidades- Não trafega tela, mas informações condensadas de 1 ou 2k- Suporte conexões WAN

• O Banco de Dados Relacional- O R/3 usa o padrão ISO 9075 para queries e manipulação de dados- Num programa ABAP usa-se SAP OPEN SQL para acesso ao SGBD- O OPEN SQL é traduzido p/o gerenciador especifico- Se utilizar EXEC SQL, pode-se perder a independência de plataforma

• O Application Server- Servidor que toda o R/3- O primeiro Application Server é a Central Instance - Roda obrigatoriamente todos os serviços do R/3- Componentes

- Dispatcher- Filas de solicitações dos clients- Work Processs- Shared Memory

• Nomes dos Application Server- DVEBMGS<Sid> ->Central Instance- D<Sid> -> se tiver WP Dialog- DB<Sid> -> se tiver WP Dialog e Background- DBS<Sid> -> se tiver WP Dialog, Background e Spool

• O DISPATCHER- É o controlador dos processos das aplicações

- se conecta aos Clients SAPGui e organiza estas conexões


6

- recebe solicitações do clients- distribui as solicitações entre os Work Process

- Coloca as solicitações em filas e encaminhadas seqüencialmente aos Work Process- No start do R/3, o Dispatcher

- Le as Profiles- Gera os Roll Files- Ativa os Work Process - Efetua Log

• Work Processs

- Executas as tarefas dentro do R/3- Se conecta ao SGBD para acesso aos dados- Tipo de WP

- Dialog Conversação com usuários (acesso ao SGBD R/O)- Update Update V1 ou V2 (acesso ao SGBD para Write)- Enqueue Enqueue- Background Processamento batch(acesso ao SGBD R/O)- Spool Impressão

• O Task Handler- Componente do WP que coordena a atividade de um Dialog WP- Ativa o Screen Processor ou o interpretador ABAP- Controla o Roll in e Roll out do User Context

• Shared Memory- Área de memória compartilhada por todos os WP- Dividida em duas áreas

- Application Buffer- Dados de tabelas- Tabelas em memória- Programas ABAP, sua telas e o Dicionário do ABAP- Parametrização dos módulos de negocio

- Roll Area- User Context (Authorizations do usuário, informações administrativas e informações para processamento no Work Process)- Esta área pode ser paginada para o Roll File

• Serviços do R/3- Tarefas de serviços, que não são rodado em WP- Message -> Verifica a carga e distribui os serviços- -> Sincroniza serviços entre os applications servers- Gateway -> Também chamado de CPI-C handler- permite comunicação com outro R/3, R/2 ou sistemas externos

• Fluxo da Transação R/3- PBO (Processing Before Output)- Tela (usuário responde)- PAI (Processing After Input)- PBO (Processing Before Output)


7

- Tela (usuário responde)- ...- Uma transação é uma serie de diálogos conectados entre si

• SAP LUW- Primeira parte inicia no Start Transaction e se encerra no Commit Work- Segunda parte realiza o Update num Work Process separado- Existe ainda a DB LUW, que é a LUW do banco de dados

• Enqueue- Lock Table mantém registro dos enqueues- Enqueue Work Process realiza enqueues baseado nesta tabela- Message Server comunica Dialog Work Process com Enqueue WP, já que eles podem estar em servidores diferentes

• Lock Objects- Para executar locks, é necessário definir o objeto a ser lockado no dicionário ABAP- Os lock pode ter modo E (Escrita) ou S (Leitura)- O Modo E só pode ser obtido se ninguém mais tem modo E- Quando ATIVAMOS um Lock Object, o sistema gera duas funções

- ENQUEUE_<LockObject>- DEQUEUE_<LockObject>

• O Processo de Update do R/3- O sistema emite enqueue para garantir integridade- As solicitações de Update das Tasks são armazenadas numa tabela intermediaria (VBLOG)- No Commit Work o Update WP é chamado para fazer a alteração do DB- Ao encerrar devolve o controle para o D-WP que encerra a transação e remove os enqueues- Se a conexão com o SGBD cai durante o update, ela é terminada após a reconexao

• Processamento em BackGround- Jobs tem prioridade A, B ou C- São geralmente agendados para uma determinada hora- O Batch Scheduler é o responsável por ativar os job- Ele pesquisa a Scheduling Table por jobs prontos e solicita sua execução- Jobs sem especificação de servidor são distribuídos de acordo com a carga do sistema- Jobs são selecionados de acordo com a hora de execução

- Dentro da mesma hora roda primeiro o de mais alta prioridade- Dentro de uma mesma prioridade roda primeiro o que tem servidor definido

• Serviço de Impressão- Também usado para fax- Trabalha em conjunto com o spool do S.O.- As informações sobre o spool ficam no spool database, o spool mesmo fica num TemSe (Temporary Sequencial Object)- Quando o spool deve ser impresso, o Spool WP le o TemSe e gera spool para o S.O.

• Instancias- Unidade administrativa que provendo 1 ou mais serviços


8

- Os serviços são ativados ou desativados todos ao mesmo tempo- Possui Start Profile e Instance Profile para sua parametrização- Cada instance tem seu próprio Local Buffer, que é sincronizado de tempos em tempos- A central instance possui um message server para comunicação entre as instances

- Dispara updates, coloca e remove locks, etc- Esta comunicação é feita pelo Dispather- O message server pode ser usado pelos clients para realizar logon, selecionando o server mais disponível para a conexão

Capítulo 4 – Interfaces com outros sistemas

• Comunicação com outros sistemas- Conexões possíveis

- R/3 <-> R/3 - R/3 <-> R/2- R/3 <-> outros sistemas

- Protocolos de comunicação suportados- TCP/IP- LU 6.2 (para conexão com mainframes)

- Interfaces de comunicação suportadas- CPI-C- RFC- OLE- ALE- EDI

• O serviço de Gateway (CPI-C handler)- Disponibiliza comunicação entre sistemas R/3 e R/2 (TCP/IP e LU 6.2)- Disponibilizar comunicação também com outros sistemas que suporte CPI-C- Pequenas mensagens são trocadas através do Message Server, grandes volumes de dados através do Gateway- Posso ver conexões ativas através da transação SMGW

• Comunicação via CPI-C- Comunicação programa-a-programa via comandos básicos- Geralmente usada para conexão com R/2 ou mainframes- Precisa definir a conexão na tabela TXCOM (transação SM54)- Executar comandos ABAP para ativação e troca de dados

- COMMUNICATION INIT -> inicio 1º programa- COMMUNICATION ALLOCATE -> estruturação 1º programa- COMMUNICATION ACCEPT -> aceite 2º programa- COMMUNICATION SEND- COMMUNICATION RECEIVE- COMMUNICATION DEALLOCATE -> encerramento

- Faz conversão automática ASCII <-> EBCDIC

• Interface RFC- Interface mais simples de utilizar e com mais funções do que o CPI-C- Usa CPI-C para a comunicação final, porem esconde a complexidade do programador- Usada para conexão com R/2, R/3 ou sistema externos que falem RFC


9

- Permite a chamada de funções (programas) em outros sistemas- Para criar este Function Modules usar transação SE37- Para das manutenção nas conexões RFC usar transação SM59- Tipos de chamadas RFC

- Síncrona -> chamador aguarda resposta para continuar- Assíncrona -> chamador não aguarda resposta, mas R/3 destino precisa esta ativo- Transacional -> executa uma transação com vários Function Modules no chamado

- -> são consideradas como 1 única LUW- -> R/3 destino não precisa estar ativo- -> podemos configurar freqüência e intervalos da chamada

• Business Objects e BAPI- BO -> base de comunicação entre sistemas / módulos- -> orientados a negócios (CLIENTES, PEDIDOS, etc)- -> possuem métodos (CRIAR CLIENTE, ou ENVIAR PEDIDO)- -> são armazenados no BOR (Business Object Repository)- BAPI -> interfaces funcionais- -> usam os métodos do BO- -> podem sem chamadas de fora do R/3

• Interface com OLE- Como Client

- O ABAP pode solicitar funções OLE do Desktop- SAPGui conversa OLE com o Desktop- Para falar com ABAP, o SAPGui transforma estas chamadas em RFC´s- Funções ABAP para OLE

- CREATE OBJECT- CALL METHOD- GET PROPERTY- SET PROPERTY- FREE OBJECT

- Como Server- O desktop pode solicitar funções R/3- As chamadas são feitas como chamadas de métodos de objetos- Estas chamada feitas via OLE são encaminhadas ao SAP Automation Server, que as converte em RFC- Todos os Business Objects do Business Object Repository podem ser chamadas via desktop- O cliente precisa estar logado para poder executar uma chamada (o logon pode automático)

• Interface com a Internet- Disponível desde a versão 3.1 G- O acesso é possível através de um ITS (Internet Transacion Server)- Dentro do ITS existe um A Gate (Application Gate), que conversa com o R/3 e um W Gate (Web Gate) que conversa com o Web Server

• Interface com EDI- EDI é a troca de dados de negocio em formato estruturado entre aplicações e empresas- A arquitetura R/3 para EDI é composta por


10

- Aplicações prontas p/ EDI- permitem que transações de negocio sejam executadas automaticamente

- Interface IDOC- interface aberta para intermediação de documentos- padrão proprietário SAP- possui um IDOC Type que define a forma e estrutura do documento e registros de controle de status do documento

- desenvolvido de acordo com ANSI 12 e o padrão EDIFACT- EDI SubSystem

- Converte IDOCs em mensagens EDI- Não é fornecido pelo R/3

• Interface ALE (Application Linking Enabling)- permite a parametrização e operação distribuída de aplicações R/3- as aplicações são integradas através de troca de mensagens (síncronas e assíncronas), e não através de um banco de dados central- os dados são trocado usando os Idocs da interface EDI

• Import de Dados externos para dentro do R/3- Batch input

- Dados são armazenados como uma BDC Table (Batch Data Communication) num arquivo de batch input session- A seguir o sistema processa esta session, processando cada dado através da transação apropriada- Isto garante integridade dos dados entrados no sistema

- Call Transaction- Dados são armazenado como uma BCD Tabele e chamamos a transação diretamente, apontando a BCD- Também garante a integridade

- Direct Input- Fazemos um programa que grava os dados diretamente na base de dados do R/3- Garantia de integridade é responsabilidade do programador


11

Capítulo 5 – A Interface Gráfica de Usuário

• A administração dos Front-Ends- Os equipamentos não os mesmos em toda a rede- Os usuário não precisam das mesmas aplicações nem dos mesmos componentes do SAPGui, porem desejam todos os aplicativos que necessitam num único computador - Para a construção do ambiente deve-se criara uma matriz com as necessidades dos usuários, deste modo construindo cenários possíveis para os front-ends- Isso auxilia a definição de cenários, facilitando instalação e distribuição

• Requerimento para o SAPGui- SAPGui é protegido contra vírus- Hardware

- Win95- Mínimo -> 486 16 Mb Ram- Recomendado -> P133 32 Mb Ram

- Win Nt- Mínimo -> P133 32 MB Ram- Recomendado -> P133 48 Mb Ram

- Rede- WINSOCKET API (WINSOCK.DLL) c/ protocolo TCP/IP- Para testar a conexão de rede usar PING ou TELNET- Para testar a conexão do SAPGui usar SAPGUI AppServer SAPDP<xx>- Deve-se configurar os arquivos HOSTS e SERVICES do diretório C:\WINNT\SYSTEM32\DRIVERS\ETC para configurar conexão

- SAPDPxx 32<Sid>/TCP- SAPGWxx 33<Sid>/TCP - SAPMSxx 36<Sid>/TCP

• Instalação do SAPGui- INTERATIVA

- Quando é feita individualmente em cada PC- Posso instalar a partir do CD ou baixar o CD no File Server e instalar dele- Para upgrade devemos obrigatoriamente deletar a versão velha- O programa de instalação é o SAPSETUP.EXE

- P/ Win 3.x diretório GUI\WINDOWS\WIN16- P/ Win 95 diretório GUI\WINDOWS\WIN32

- Arquivo de configuração do processo de instalação: SAPSETUP.INI- Dialog Free

- Totalmente guiada pelo arquivo SAPSETUP.INI- É feita chamando o programa SAPSETUP.EXE na linha de comando


12

- O resultado da instalação é gravado no SAPSETUP.LOG- Simples e fácil de instalar

• Help´s para o Front-End- Arquivos de Help ficam no servidor

- Definição do Tipo de Help: /EU/IWB/Help_Type- Definição do caminho help files: /EU/IWB/Patch_Win32- Programa de instalação do Help: \PlainHTM\Install\<OpSystem>\INSTHELP (no CD)- Internet Explorer é fornecido c/o R/3- \HTMLHelp\Setup\IE302 (versão 3.02)- Arquivo de configuração do help no front-end : SAPDOCCD.INI

- Sections: HTMLHelp e SystemId<Sid>- Tipos de Help

- PlainHtmlHttp- Exibe o help em HTML, recebendo as paginas de um servidor WEB- Usado quando um servidor de WEB está disponível (em Intranets)

- PlainHtmlFile - Exibe o help em HTML, acessando as paginas através de um Share do servidor

- HtmlHelpFile - Exibe helps em HTML, porem os arquivos de help ficam em formato comprimido- Existe um diretório de help para cada língua instalada- Para funcionar é necessário que o Browser já esteja instalado quando instalarmos o SAPGui, pois este vai ativar alguns controle HTML no Browser para entender a compactação- Quando usamos este help devemos ter a documentação do 4.0A e 4.0B juntas, no mesmo release do NT ou do 95

• Logon e Trace- Programa SAPLOGON.EXE

- Le arquivo SAPLOGON.INI (contem a lista de sistemas R/3 e seus parâmetros de Logon)- Para evitar edição deste arquivo pelo usuário, torna-lo READ ONLY- Estas informações serão usadas para montar a Connect String e efetuar a conexão- Pode fazer logon Load Balance- A seguir ativa SAPGUI.EXE

- Para Trace do Logon- Clicar no canto superior direito da janela do SAPLOGON- Selecionar um OPTION ACTIVATE SAPGUI TRACELEVEL- Serão gravados: DEV_xxxx.TDW e DEV_xxxx.BIN

• Arquivos do SAPLOGON- SAPLOGON.INI

- Arquivo com o nome dos sistemas R/3 e seu grupo de logon- SAPMSG.INI

- Contem a lista dos Message Server e os nomes lógicos dos seus serviços- Acessado quando usado Logon Group

- SAPROUTE.INI- Contem a lista dos SAP Routers que podem ser selecionados- Contem a Connect String dos servidores- Usado quando seleciono SAP Router


13

- SERVICES- Não é alterado via SAPLOGON, deve se usar editor de texto- Entradas necessárias:

- sapms<Sid> <service number>/TCP- sapmsTC3 3603/tcp

• Connect String- Para um servidor especifico

- /H/<host> /S/<servico do dispatcher>- Para Message Server

- /M/<host do ms /S/<servico do ms> /G/<logon group>- Para SAPROUTER

- /H/<host SAPRouter> /S/<servico do router>

• Instalação do SAPGui- Local

- Instalar o SAPGUI no frontend- Maior disponibilidade, pois independe de um servidor central- Menor consumo dos recursos da rede (o sw é local)

- Central- Instalar o SAPGUI no servidor- A vantagem é a administração centralizada- Porem consome mais recursos da rede- Precisa de um rede bem dimensionada e segmentada em subnets

• SAP MAPI- Interface para usuários do SAPOffice integrada ao SAPGUI- Integrada ao MS Office e MS Outlook

• SAPGui com JAVA- Usa browser para exibir telas do R/3, num ambiente Internet/Intranet- Possui Applets específicos, que são carregados do WEB Server- Na instalação são fornecidos

- As classes Java para o funcionamento da interface- O template IDES.HTML- O ORB ORBIXD.EXE que converte os padrões Internet em SAPGui (e vice versa)- Este ORB é instalado como serviço Windows

• Instalação SAPGUI in JAVA- Necessita

- De um WEB Server- Plataforma Windows NT ou Solaris- Browsers que reconheçam JAVA

- Após instalar, precisamos configurar no IDES.html- sap_connect string de conexão- Width largura do SAPGui na janela JAVA- Heigth altura do SAPGui na janela JAVA- dptrace nível de trace desejado


14

Capítulo 6 – SAP OSS (Online Service System)

• Overview- 24h no ar- Precisa de link com SAP Alemanha para funcionar e IP valido- Permite

- consultas ao DataBase de Notas- registrar chamados técnicos- registro de alterações em programa originais SAP- Consultar e fazer download de HotPackages SAP- Obter informações de treinamento

- Transação para chamar OSS -> OSS1

• EarlyWatch- Usuário do CLIENT066 que é usado para diagnostico de problemas- Equipe do laboratório (Waldorf) usa para se conectar ao R/3- Senha inicial -> SUPPORT- 1ª sessão de diagnostico é usada para verificação de performance

• Pesquisa de notas- Permite especificação de palavras chaves para pesquisa- O uso de palavra conhecidas pelo sistema aumente eficiência da pesquisa

• Registro de problemas- Prioridades dos chamados

- Very High -> sistema parado- High -> sistema em vias de para- Low -> Problema não afeta o funcionamento do sistema

- Entro com a descrição do problema, severidade, características desta instalação (DB, release, etc)

• SSCR (SAP Software Change Registration)- Para alterar objetos originais SAP, é necessário um código de acesso- Este código é obtido informando no SSCR o nome do objeto e o nome do usuário desenvolvedor- O desenvolvedor também deve ser cadastrado no OSS - A chave de acesso tem 20 posições

• Hot Packages- Correções fornecidas pela SAP para problemas que afetem diversas instalações- Devem ser aplicadas somente para o mesmo release- Devem ser aplicadas em ordem numérica- Função HOT NEWS do OSS informa se existem Hot Packages para o meu sistema

• Informações de treinamento- Podem ser obtidas via OSS- A Internet parece ser melhor ferramenta para acessar estas informações

• Acesso ao OSS


15

- Link precisa estar no ar- Chamar transação OSS1- Ele starta outra sessão SAPGui, conectada ao servidor OSS- O Gateway garante a segurança da conexão, verificando a validade dos pacotes que chegam e de seus endereços IP

• SAPNET- Paginas para troca de informações entre a SAP e clientes ou parceiros- Pode ser acessado através do ícone CUSTOMER PARTNER da pagina da SAP- Funções

- Assistance -> correio eletrónico com SAP (Inbox, Outbox, Index, Favorites)- Information -> Release Information, Basis Technology, Core Aplication/Components- Communication -> Forum de discussão, Grupos de usuários, TechNet, Projetos- Service -> Pesquisa de Notas, Download de Hot Packages- -> Cursos, self training e informações sobre o IDES- Self Service -> Quick sizing, textos, Service Quote (??)- Settings -> Defalts pessoais

• TechNet- Knowledge base- Fórum de discussões- Acessível pelo SAPNet


16

Capitulo 7 – Usuários e Authorizations

• Usuários em cada ambiente− Sistema operacional (NT)

− <Sid>adm -> TC3adm− SAPService<Sid> -> SAPServiceTC3 (usuário do serviço)

− Oracle− SYS ->− SYSTEM ->− SAPR3 / SAP -> Proprietários das tabelas R/3

− R/3− CLIENT000

− SAP* / 06071992 − DDIC / 19920706 − SAPCPIC / ADMIN

− CLIENT001− SAP* / 06071992 − DDIC / 19920706

− CLIENT066− EARLYWATCH / SUPPORT

− Novos Clients− SAP* / PASS

− Usuário hard coded− Para desativarmos devemos criar um Master User Record para o usuário SAP*− Pode ser inibido via System Profile

• Conceito de Authorization


17

− Servem para restringir acesso a objetos do R/3− Profiles podem possuir uma ou mais Authorizations− Authorizations podem ser assinaladas para Transações ou por função de uma transação− 1 Profile pode ser composta de outras Profiles

− SINGLE PROFILE− COMPOSITE PROFILE

− Se a profile do usuário não tem uma autorização explicita para um objeto, ele não pode acessar o objeto (Authorizations são positivas)

• Estrutura das Authorizations− Objetos de autorização

- Criado pelos programadores via transação SU21- São agrupados p/ Classe (p.e. FINANCIAL ACCOUNTING)- Cada Objetos de autorização pode possuir diversos campos− Uma Authorization é um determinado conjunto de valores destes campos− As Authorizations são checados por codificação nos programas ABAP

− Exemplo − Objetos de autorização -> CUSTOMER COMPANY CODE− Campos -> COMPANY CODE e ACTIVITY

− A Autorização é o valor que se da a estes campos

− Autorização RESTRITA do objeto CUSTOMER COMPANY CODE− COMPANY CODE = 0001/0009 ACTIVITY = DISPLAY

− Autorização COMPLETA do objeto CUSTOMER COMPANY CODE− COMPANY CODE = * ACTIVITY = CHANGE / DISPLAY

• Authorization Object- Criado pelos programadores via transação SU21- Checados dentro dos programas- Cada objeto pode possuir diversos campos- Uma Authorization é um determinado conjunto de valores destes campos- Cada objeto pode ter quantas autorizações desejemos- Cada chamada para verificar Authorization (programa) checa só uma destas autorizações

• A Arvore de Authorizations dos usuários- 1 usuário (USER MASTER RECORD) pode possuir varias Profiles- 1 Profile pode possuir varias Authorizations- 1 Autorização possui vários campos/valores

• Ferramentas para se criar Authorizations- Profile Generator- Manual Creation

• Verificação de autorização- No momento do Logon do usuário, suas Authorizations são colocadas no User Buffer

- User Buffer -> área do User Context que contem as Authorizations de um usuário especifico- Para revalidar precisa de novo Logon

- O programa emite o comando AUTORITY CHECK para aquele objeto de autorização, testando valores contra as especificações do usuário

- Se o usuário possui aqueles valores, o acesso é permitido- Caso contrario, o usuário recebe mensagem de erro


18

- Existe ainda possibilidade de checar autorização para a transação- Antes de entrar, testa- Se não tem autorização, nem deixa entrar

• O PROFILE GENERATOR- Processo simplificado para geração de Authorizations (PFCG)- Agrupamos em ACTIVITY GROUPS todas as transações que um determinado grupo de usuários

vão acessar- O Profile Generator identifica quais objetos de autorização aquelas transações

precisam e cria uma Profile com valores default para aqueles objetos- Depois, relacionamos Activity Groups aos usuários- Cada usuário de um Activity Group terá no seu User Master Record as Authorizations

daquelas Profiles

• Passos do Profile Generator (sem RESPONSIBILITY)1. Verificar unidades organizacionais (como Company Codes) para todas Authorizations que usam unidades organizacionais2. Verificar as Authorizations sugeridas pelo sistema

3. Verificar os campos (que não são Organization Units) e que não puderam ser gerados pelo sistema4. Gerar as Authorizations Profiles para os Activity Groups5. Assinalar usuários para os Activity Groups6. Atualizar os User Master Record dos usuários assinalados

• Activity Groups com RESPONSABILITY- Responsibility define a área de abrangência da Autorização- Posso definir descrições funcionais idênticas, que Os diferem para entre si em qual

Company Code elas se aplicam- Cada Responsibility de um Activity Group vira uma Profile, que depois é associada aos

usuários- Podemos (mas não devemos) manter esta Profile manualmente- Desta forma

- Só definimos uma vez a transação para cada Activity Group- Devemos definir Organization Level e Authorization para cada Responsibility- Não podemos definir diferentes características funcionais para uma Responsibility sem afetar as outras do mesmo Activity Group

• Passos do Profile Generator (com RESPONSIBILITY)- Selecionar transações que desejamos para um Activity Group- Criar a RESPONSABILITY- Criar Authorization Profiles

- Depois de criar, entramos nas Authorizations e as modificamos para cada Responsability

- Assinalamos os Usuários para cada Responsibility- Mandamos executar UPDATE USER MASTER RECORD

• Modificações nas Authorizations- Ao entrarmos na transação, ele exibe colapsado

- Classes dos Objeto- Authorization Object- Authorization


19

- Values- Existe um semáforo em cada nível indicando

- Verde -> todos valores das Authorizations preenchido- Amarelo -> faltam preencher alguns valores- Vermelho -> precisa preencher dados a nível de organização

• Criação / Modificação de usuário (SU01)- Pastas

- User Data- Default- Address- Paramaters

- Lock/Unlock de usuários e troca de passwords- É possível ver usuários Locked na SUIM

• Relatórios da transação SUIM- User Master Records (lista usuários)

- Authorization Profiles- Authorization Objects- Authorizations- Change History (Verifica alterações feitas)- Activity Groups- Where Used

• Parâmetros da System Profile referentes a usuários- Começam com LOGIN/- login/fails_to_user_lock

- numero de tentativas erradas de senha antes do lockar o usuário- usuário é liberado à meia-noite

- login/failed_user_auto_unlock- não libera automática a meia noite

- login/no_automatic_user_sapstar- desativa o hard code do usuário SAP*

• Regras para passwords- diferente das ultimas 5- não deve começar com os mesmos 3 caracteres do username- não pode ser PASS ou SAP- não deve começar com 3 caracteres idênticos- não pode começar com ? ou !

• Trace de Authorizations- Para verificar Authorization Check

- ST01 System Trace- Para analisar um falha de autorização

- SU53 Mostra quais Authorizations precisaria e quais tem- Para verificar Authorizations do User Buffer

- SU56 Se não estão todas ai ...- -> mudaram seus Activity Group- de logoff e logon)- -> vieram novas Authorizations por transporte - reset seu User Buffer


20

- -> seu User Buffer é muito pequeno- aumente auth/auth_number_in_userbuffer

Capítulo 8 – Processamentos em Background

• Background Jobs- Compostos por programas ABAP, comandos externos ou programas externos- Rodam seqüencialmente sem intervenção do usuário- Usados para

- Execução de tasks automaticamente- Transferencia de dados de sistemas legados- Executar quando eventos (internos ou externos via SAPEVT)- Processar grandes volumes de dados quando o sistema tem baixa carga online

- Distribuídos de acordo com a carga, porem pode-se especificar uma instance especifica- Possuem classes

- A -> maior prioridade- -> pode ter WP específicos- B -> segunda maior prioridade- C -> última prioridade

- É possível trocar o modo do WP de Dialog para Background via Operation Mode- O JOB SCHEDULING MONITOR permite visão gráfica do scheduling dos jobs- Ferramentas para administração de jobs batch

- API´s ABAP- Transações do próprio R/3- External Function Modules que formam o External Job Application Programming

- Permite manusear os jobs do R/3 via sistema externo (MVS, OS/400, NT)

• O processamento de Background Jobs- Qualquer instace de R/3 pode ser configurada para rodar Background Jobs

- Parâmetro rdisp/wp_no_disp- JOB SCHEDULING TABLE: tabela única no sistema que contem a relação de Jobs a executar- Job Name + Job Number é uma combinação única nesta tabela- Ao menos 2 Dialog WP devem ser configurados por instance

- 1 para o Batch Scheduler checar a Scheduling Table- Outro para o trabalho dos usuários online

- Não existem mínimo para Background WP- Porem, se usarmos Funções de Transporte, devemos ter no mínimo 2


21

- A cada 60 segundos o Batch Scheduler verifica a Scheduling Table- Este tempo é controlado pelo rdisp/btctime- Toda instance com Background WP tem um Batch Scheduler

- Quando o Batch Scheduler encontra jobs em condição de processar- Solicita ao Message Server o servidor que vai executar- Esta escolha é baseada na carga do servidor- Em seguida, solicita ao Dispatcher para ativar o Job num Background WP

- Jobs pode ser schedulados- IMMEDIATE- DATE/TIME- EVENT BASE- JOB END BASED

- Caso não existam recursos (p.e. Background WP) para processar um job IMMEDIATE ou EVENT BASED ele é transformado em DATE/TIME

- Jobs que foram selecionados por um determinado Batch Scheduler porem não puderam rodar porque não havia Background WP disponível naquele momento podem ser selecionados pelo Batch Scheduler de outro servidor, ´roubando´ o job do primeiro- Se forçarmos uma instance especifica, perdemos esta opaco de Work Balancing

• Operation Mode- Usado para modificar a qtde de Dialog e Background WP

- Apenas troca Dialog p/ Background ou vice-versa, nunca cria mais WP- Permite ainda definir Classe A para um determinado Background WP- Se no momento do Switch houverem jobs rodando do WP, este é marcado como pending, porem o processo é terminado normalmente

• Seleção de jobs- A seleção se da por hora (run time)- Quando a hora de execução é a mesma

- Seleção por Classe- Quando a Classe é a mesma

- Seleção primeiro os que tem servidor explicito

• Criação de Jobs- Via SM36 (CCMS)- Posso usar Spool Recipiente List para enviar o Spool para

- Usuário do SAPoffice- Uma SAPoffice Distribution List- Um usuário R/3- Um usuário externo via correio eletrónico

- Botão STEPS defines Steps- Botão START DATE define condição de start do job (hora, evento)

• Executando Jobs em Background- Podem usar Variantes- Se o job dispara programas ou comandos externos, isto é feito através do programa SAPXPG, que roda no host e é ativado via RFC

- Programa externo - É um programa/comando/batch - Só pode ser executado por quem tem Background Administration Authorization- Não precisamos criar um objeto R/3 para chama-lo


22

- Comando externo - É um programa/comando/batch- Pode ser executada por qualquer usuário com autorização- É necessário definição do comando para poder ser chamado

- Programas externos podem ser rodados em modo síncrono ou assíncrono- Todo job tem seu Job Log

• Eventos- Criação

- Transação SM64- Pode-se criar User Events ou R/3 System Events

- System Events começam com SAP, posso criar eventos com este prefixo, porem corro o risco de novas versões do R/3 usarem o nome escolhido- Exemplos de System Events

- SAP_END_OF_JOB- SAP_OPMODE_SWITCH- SAP_SYSTEM_START- SAP_SYSTEM_STOP- SAP_TRIGGER_RDDIMPDP

- Exemplos de User Events- END_OF_DATA_TRANSFER

- Triggering- Via SM49 (Raise Event)- Pode-se usar função ABAP -> BP_ EVENT_RAISE- Pode-se usa programa SAPEVT do Windows

- SAPEVT <Event_Id> Name=<Sid> NR=<System Number>- SAPEVT <Event_Id> –p<parametros> Name=<Sid> NR=<System Number>- Com o parâmetro –t, o SAPEVT gera um log no diretório corrente

• Manipulação de Jobs- Via SM37 (Job OverView)

- Podemos manipular jobs que estao em Scheduled ou Release- Não é possível manipular jobs que estão rodando ou já rodaram- Caso seja necessário ressubmeter, usar JOB COPY, dar um nome e salvar

- Será outro Job, porem igual ao primeiro- Podemos verificar erros no Job Log ou via Transação SM21- Na SM37 não podemos nos esquecer

- Start After Event -> para ver jobs dependentes de eventos- Jobs Without Start Date -> jobs sem data de start- Jobs With Previous Job -> jobs dependentes de outros jobs

- Via RZ01 (Job Scheduling Monitor)- Display gráfico para controle de Jobs

• Job WorkFlow- Controle default

- Seqüencial A -> B -> C- Paralelo A -> B (B e C são dependentes de A)- -> C

- Controle por Background Job API- Periódico Jobs ativados por outro que roda periodicamente- Com decisão lógica Job roda se outros 3 já rodaram com sucesso antes


23

- Estes Background Job API são function modules do ABAP que começam com BP_

• XBP e XMI- Permite a integração do CCMS com outro sistema de controle de ambiente- A integridade é mantida (core competence) já que as funções são executadas por módulos da CCMS- Function Modules começam com SXMI_- XBP -> eXternal interface for Background Processing

- Interface usada para conectar agentes (processos)- Não schedula jobs no ambiente externo

- XMI -> eXternal Monitoring Interface- Monitora a atividade do sistema

• Authorizations- Para Jobs

- S_BATCH_ADM pode trabalhar com jobs de outros usuários- S_BATCH_NAM quais usuários podem ser usados quando schedulando jobs batch- S_BATCH_JOB DELE -> Deletar jobs de outro usuário- LIST -> Display spool criado por outro usuário- PROT -> Display Job Log criado por outro usuário- SHOW -> Display Job Definitions de outro usuário

- Para acesso a CCMS- S_RZL_ADM Activity Code 01 -> acessa CCMS com função de administrador- Activity Code 03 -> acessa CCMS Read Only

- Para External Commands- S_LOG_COM Capacita usuário a executar comandos externos- Podemos limitar COMMAND; OPSYSTEM; HOST- S_TCODE Da autorização para SM49 (Execute External Command) e SM69 (Define)

- Para XMI- S_XMI_PROD Define qual interface externa e de que companhia se esta usando- Campos EXTCOMPANY, EXTPRODUCT, INTERFACE- S_XMI_LOG Define se usuário R/3 podem acessar log da XMI e como podem- Campos XMILOGACC, SELECT, REORG


24

Capítulo 9 – Processamentos Avançado em Background

• Tipos de jobs que rodam em Background- Jobs de Basis

- Clean up do sistema- Jobs de coleta de estatísticas (definidos na tabela TCOLL)- Alguns deste jobs necessitam rodar em Clients específicos- Outros agem sobre todos os clients do sistema

- Jobs de Aplicação- Jobs de longa duração

- Requerem acompanhamento- Alto consumo de recursos

• Jobs de Basis de Clean up do sistema (normalmente diários e com variantes)- RSBTCDEL job logs SAP_REORG_JOBS- RSPO0041 spools SAP_REORG_SPOOL- RSDBCREO sessões de batch input SAP_REORG_BATCHINPUT- RSSNAPDL Dumps de ABAP SAP_REORG_ABAPDUMPS- RSBPSTDE job statistics SAP_REORG_JOBSTATISTIC- RSM13002 registros de alterações completadas SAP_REORG_UPDATERECORDS

• Jobs de Coleta de Estatísticas (sem variantes)- RSCOLL00 performance do sistema SAP_COLLECTOR_FOR_PERFMONITOR a cada hora- RSBPCOLL jobs de background SAP_COLLECTOR_FOR_JOBSTATISTIC diário

• Acompanhamento de jobs de longa duração- É responsabilidade do IT garantir os recursos para os jobs batch- Informações importantes conhecer para melhor acompanhamento

- Quais jobs precisam ser schedulados- Cuidado em não agendar muitos jobs longos juntos

- Qual a sua freqüência- Se são submetidos automaticamente por transações online- Quem é o responsável- Quais variantes precisam ser criadas

- Cuidado para elas não serem abrangentes demais- É recomendável que, sempre que possível se utilize processamento de jobs em paralelo, usando funções de RFC

• Function Modules da XMI e XBP


25

- Com eles é possível- Schedular um job em background- Startar e stopar um job em background- Monitorar o status e as saídas dos jobs

- Groups principais são- SXJI (prefixados por SXMI_XBP) External Job Management- SXMB (prefixados por SXMI_XMB) External Monitoring Basics- SXMI (prefixados por SXMI) Connect to external tools

- É possível ver todos através da SE37, colocando prefixo SXMI*

• Controle do Externo do ambiente de background- Produtos de terceiros que controlam o ambiente R/3- Podem rodar fora do R/3 (a nível do Sistema Operacional)- Precisam ser certificados pela SAP- Venda, venda distribuição e suporte são do terceiro que vendeu- Sistemas se conectam ao R/3 usando interfaces RFC (precisam de autorização)- Após a conexão RFC, o produto deve fazer logon na XMI- Por ultimo, pode usar as funções de XBP para monitorar jobs- Transação RZ15 pode monitorar jobs criados por XMI

• Vantagens e Desvantagens de Controle Externo de Jobs- Vantagens

- Administração de múltiplos sistemas R/3 numa única interface- Uso de produtos certificados pela SAP- Conexão ao R/3 via sistema externo

- Desvantagens- É um componente externo de outro fornecedor

• Eventos- System Events

- Definidos pela SAP- Começam com SAP- Disparados por determinadas ações do sistema (troca de Op Mode p.e.)

- User Events- Criado pelos usuário- Disparados por

- Programas ABAP (função BP_EVENT_RAISE)- Programa externo (SAPEVT)- Manualmente (transação SM64)

- Podem ter argumentos (parâmetros)- Se um job é disparado por um evento com um determinado argumento, somente se o argumento for aquele é que o job será ativado- Se um job é disparado por um evento sem argumento, mesmo o evento tendo qualquer argumento dispara o job- Para definir ou exibir eventos (User ou System) -> transação SM62

• Parallel Processing- É a divisão de um grande job batch em vários pequenos pedaços- Este pedaços rodam nos Dialog WP e não nos Background WP

- O R/3 automaticamente protege o sistema contra sobrecarga de uso- Funções de RFC assíncronas permitem que se sincronize os pedaços

- Os jobs devem ser divididos em unidades logicamente independentes- Função criada para resolver problemas de falta de BWP ou de falta de tempo durante a noite para rodar jobs


26

- É uma técnica de programação, se não programarmos assim não funciona- Comando ABAP

- CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP

• Pré-requisitos

- Deve haver ao menos 3 Dialog WP livres (1 para processamento paralelo, 2 para tasks de Dialog)- A Dispatcher Queue deve estar menos de 10% de ocupação- Processamento paralelo não server para dados que são processados seqüencialmente ou quando o processamento de um dado é dependente do processamento de outros- Processamento em paralelo não garante que os dados sejam processados em uma ordem especifica ou que determinado resultado esteja disponível num determinado ponto

• External Commands- É possível executar comandos do sistema operacional via R/3- Um application server precisa estar rodando no target server para emitir o comando- O comando é executado pelo usuário <sid>adm do NT

- O <sid>adm deve ter direitos do NT para rodar o comando - O encaminhamento do comando é feito pelo servido de gateway

- O gateway precisa estar ativo- Ele tem que possuir uma conexão ativa com o target server

- O diretório /USR/SAP/<sid>/SYS/EXE/RUN deve estar também no PATH durante a execução do comando- Os comandos são protegidos por autorizações- Podem ser executados via programa ABAP ou através da CCMS

- SM49 -> chama external command- SM69 -> define ou modifica external command- SM36 -> mostra campos separado para externos commands e external programs

- Para funcionar, não podemos esquecer do PATH correto na definição do comando- Podemos passar parâmetros para o external program

• Resolução de problemas com External Programs- O external program não start corretamente- O External program não devolve os resultados para o processo de background- Atitudes

- Verifique se o Target System esta correto- Verifique job log procurando mensagens de erro- Ative o trace de external programs

- Via transação SM36- Permite log de external programs para aquele job

- Via transação SM69- Permite log para todos as chamadas do external command- Precisa também setar a variável ambiental SAPXPG_TRACE = 3 no computador onde o comando será executado

• Reserva de Background WP - Através do Operation Mode- Definir alguns BWP com classe A- Transação RZ04


27

• Schedulando jobs via APIs ABAP- API´s fornecem function modules para

- Gerenciamento de jobs (display, delete, copia)- Verificação e disparo de eventos

- Display de Job Log- Schedulagem de jobs

- BP_JOBVARIANT_SCHEDULE Schedulagem de jobs- BP_JOBVARIANT_OVERVIEW Gerenciamento de jobs

- É necessário autorização para o uso destas API´s- Autorizações que podem ser usadas para limitar poder de usuários

- S_PROGRAM- S_BTCH_NAM- S_BTCH_JOB- S_BTCH_ADM- S_ADMI_FCD

• Vantagens e Desvantagens do uso de APIs- Vantagens

- Interface programável para gerenciar jobs em background- Permite executar e monitorar o ambiente de background- Interface fornecida e garantida pela SAP

- Desvantagens- Tem que programar

• Verificando jobs em background- Alem da SM36 / SM37 pode-se usar SMX- Mostra jobs submetidos com meu Userid- Para verificação de performance pode-se usar a SM39 (Job Analisys)

- Mostra estatísticas dos jobs- Numero de vezes que rodou, tempo médio de runtime, problemas no job- A analise só abrange o que está no log (é deletado pelo SAP_REORG_JOBS)

• Resolução de Problemas- Job não starta

- A start date esta certa (SM37)- O usuário que deu release pode dar release (SU01)- Existem recursos para execução do job (SM50)

- BWP- Servidor (se o job esta dirigido para um servidor especifico)- Classe

- O Batch Scheduler e o Event Controler estão rodando (SM61 e SM65)- Job terminou anormalmente

- Verificar Job Log (SM21)- Job Log não pode ser exibido

- Será que o job rodou ?- Verificar System Log (SM21)- Verificar autorização do usuário para display do job log (SU01)

- Job não termina (fica em ativo)- Confirmar se o job esta rodando (SM50 ou SM66)- Verificar problemas com external programs

- Verificar usuário SAPCPIC__________________________________________________________________________________________________________

Apostila – Módulo Basis28

- Se o servidor que roda o job esta ativo- Caso tenha saído do ar, posso estar vendo um display incorreto

Capitulo 10 – Data Archiving

• O que é Data Archiving− É a remoção de dados dos processos de negócio do DataBase− Estes dados são comprimidos e armazenados em outra mídia

− Disco Ótico, File System , Fita Dat− O arquivo comprimido tem formato proprietário

− Só o R/3 entende seu conteúdo

• Vantagens de se fazer Archiving− Razões Técnicas

− Melhora a performance do acesso no DB− Aumenta Free Space nos discos − Reduz tempo de Backup

− Razões de Negócio− Legislação exige a guarda da informação por certo período− Auditoria externa exige guarda destas informações− Certos dados podem servir para análise futura

• Quando fazer Archiving − Conforme o crescimento do DataBase− Conforme as necessidades dos departamentos− Por razoes do negócio

− A entrada do EURO (troca de moeda)− Fim do ano fiscal− Quando os dados que se tornam obsoletos

• Archiving Object- Entidade principal do processo de Archiving- Podem ser vistas na transação SARA- Contem o nome de uma ou mais tabelas serão arquivadas- Nem sempre toda a tabela é arquivada, muitas vezes apenas parte dela

- Neste caso é possível até ver as chaves que serão afetadas- Elementos principais do Archiving Object

- Nome das tabelas (e as chaves) que serão arquivadas- O programa que seleciona e gravas os dados no Archive File- O programa que deleta os dados das tabelas- A documentação deste processo de Archiving

• O processo de ArchivingTwo-steps, para maior segurança

1. Inicialmente roda o programa de cópia- O dataset tem compressão em fator 5

- Tabelas clustered nunca são comprimidas- Podemos ser rodado junto com as tarefas normais

- Porem pode prejudicar performance2. A seguir roda-se o programa de delecao

- Compara os dados no Archiving com os dados no Database

- Se ainda forem iguais, deleta os do database__________________________________________________________________________________________________________


- Se forem diferentes, mantém dados- Esta fase pode ser:

- Automática -> roda o Arquiving e em seguida a delecao- Manual -> solicitamos a delecao manualmente

• O ADK (Archiving Development Kit)- Interface entre o Archiving Program e o Archive File

- O ADK possui Function Modules que são chamados pelo Archiving Program para gravar os Archive File

- Dados em Archive File, selecionados por um programa são recuperados pelo ADK, que os devolve no mesmo formato do Repository, independe da plataforma no qual o Archive File esteja- O ADK pode segmentar os Archive File em vários arquivos físicos (parametrizado na transação SARA) - É possível criar nossos próprios Archive Objects- Não é recomendado criar Archive Objects p/ tabelas padrão do R/3, pois estes já existem

• Acessando o Archive File- Programas de Análise

- Fornecidos com o Archiving Object- Le Archive File e cria spool com informações do Archive File (estatísticas, qtde de registros)- Pode-se utilizar um Browser ou Ferramenta genérica para ver os dados

- Acessos Direto- Para alguns Archive Object, os programas podem acessar dados do Database e do Archive File sem precisar de nenhuma codificação especial

- Reload- Apenas para poucos Archive Objects- Usado p/ retornar dados do Archive selecionados indevidamente

• Preparação para Data Archiving1. Definir estrutura de Archiving

- Envolver departamentos de negócio (RH, FI, etc)- Verificar a documentação dos Archiving Objects- Identificar tabelas que estão crescendo muito

- DB02 -> mostra SGBD como um todo (index, table, tablespace)- DB15 -> mostra tamanho tables pertencentes Archiving Object

2. Customizar Archiving Objects- Transação SARA e definir ...- Tempo após o qual dados podem ser removido do DB- Tamanho do Archive File- Numero de registros em cada Archive File- Tipo de start do programa de delecao (MANUAL ou AUTOMATICO)- Variantes para TEST e PRODUCTION

- Cada Archiving Object tem seus próprio valores a serem configurados3. Configurar ao menos 2 Background WP no sistema

- É recomendável, pois podemos startar o programa de delecao em paralelo ao programa de write

- É recomendável a execução do programa de write no servidor onde o DataBase esta localizado

4. Verificar espaço em Disco para o Archiving


30

- Verificar espaço necessário através de uma rodada de Archiving com variante de Test

5. Customizar o nome do LOGICAL FILE e do PATH- SF01- FILE

• Execução do Archiving- Ativação

- Pela transação SARA ,opção ARCHIVE- Executada p/ Basis (autorizado pelo pessoal funcional)- Ou pelo pessoal funcional (que tenha autorização)

- Fornecer valores para a variante especificada de Archiving- Monitoração de um execução

- Transação SM37 (acompanhamento do job)- Dependendo da Customização, pode haver vários jobs de Archiving- Para cada job de write, pode haver um de delecao

- Transação SARA (sumario do Archiving)- Ver opção MANAGEMENT DATA

- Mostra tamanho, localização e numero de registros dos archive files- Ver opção NET GRAPHIC

- Mostra dependência entre os Archiving Objects- Sugere um plano ordenado de Archiving

- Manuseio de erros- Algumas causas de erro

- Problemas externos resultaram no cancelamento do job- Existia um Archive File com o mesmo nome- File System esta cheio

- O Archiving cancelou antes dos dados serem deletados (por exemplo, porque tem start manual)

- Delete todos os Archive File- Restart o job de Archive desde o inicio

- O Archiving gravou todos os Archive File, mas não processou todos os delete jobs- Restart os delete jobs

- O Archiving cancelou no meio da gravação de um Archive File- Backup dos Archive Files completos- Delete o parcialmente gravado- Restart o Archive Run to arquivar o resto dos dados

• Authorizations necessárias- S_ARCHIVE

- Especifica quais Archiving Object serão processados- Especifica quais opções serão usadas

- Autorização para o Archiving Object- Verificar em SARA > nome do Archiving Object > INFO quais são as Authorizations necessárias- Atribuir estas Authorizations

- Autorização para criar Job em Background

Capitulo 11 – R/3 Security

• Segurança do R/3 no ambiente Cliente/Servidor− O R/3 tem seu próprio sistema de autorização e controle de acesso− Porem, para completa proteção, a segurança deve ser implementada também


31

− No Database− No Sistema Operacional− Nas camadas da rede

• Parâmetros do System Profile para senhas de Usuário- login/min_password_lng

- tamanho mínimo de password- default 3, de 3 a 8

- login/fails_to_session_end- quantidade de tentativas de password antes de encerrar sessão- defalut 3, de 1 a 99

- login/fails_to_user_lock- quantidade de tentativas de password antes de travar usuário- usuário é destravado á meia noite (ou pelo administrador)- defalut 12, de 1 a 99

- login/failed_user_auto_unlock- impede destravamento do usuário em lock a meia noite

- login/password_expiration_time- tempo para expirar password- valor 0 significa não expira

• Outras regras de password- Não pode começar com ? ou !- Primeiros 3 caracteres não podem fazer parte do Userid- Não pode ser PASS ou SAP*- Posso definir senhas invalidas na tabela USR40

• O conceito de Autorização- Objetivo é proteger dados e funções do R/3 contra acesso não autorizados- Funcionamento

- Criação das Autorizações- Criação de Usuários- Assinalamento de Autorizações para Usuários

• Authorization Object- Criado pelos programadores via transação SU21- Checados dentro dos programas- Cada objeto pode possuir diversos campos- Uma Authorization é um determinado conjunto de valores destes campos- Cada objeto pode ter quantas autorizações desejemos- Cada chamada para verificar Authorization só checa uma autorização por vez

• Profiles- As Authorizations são dadas para Authorizations Profiles (e não a usuários)- É possível agrupar Authorizations Profiles numa Group Profile- Um usuário possui uma ou mais Authorizations Profile ou Group Profiles- Este relacionamento pode ser feita pela SU01, pasta PROFILE

• Recomendação da SAP para Manutenção de Usuários e Authorizations


32

- A divisão a seguir evita que apenas uma pessoa viole o esquema de segurança da empresa- USER ADMINISTRATOR

- Cria usuários- Assinala Profiles e Activity Groups para estes usuários- Não deve podem criar Activity Groups ou gerar Profiles

- AUTHORIZATION DATA ADMINISTRATOR- Cria Authorizations- Modifica campos das Authorizations- Não deve poder dar Authorizations para si mesmo

- AUTHORIZATION PROFILE ADMINISTRATOR- Cria Activity Groups- Gera profiles

• User Groups- Grupo administrativo criado via SU01 > Environment> User Groups- Cada usuário só pode pertencer a 1 User Group- Podemos eleger 1 Administrador do User Group e a ele delegarmos as tarefas de manutenção dos usuários do grupo

- Lock / Unlock de usuários- Set / Reset passwords- Assinalamento de Activity Groups

- Para delegarmos esta manutenção, precisamos de um User Group e de um Administrador

• Verificação de Authorizations- Há 2 tabelas no sistemas que informam

- USOBT_C -> Authorizations Objects que estão em ação e devem ser checados- USOBX_C -> campos de um Authorization Object deve ser checados

- Elas vem pre-configuradas da SAP com os nomes USOBT e USOBX- Logo após a instalação, é recomendado copia-las para USOBT_C e USOBX_C

- Transação SU25- Para modificarmos quais Authorizations estão valendo

- Transação SU24- Podemos fazer isto para

- Melhorar performance do sistema, diminuindo o numero de verificações- Evitar determinadas checagens que não se aplicam numa instalação

• Pré-requisitos para usar o Profile Generator1. Gerar o IMG2. Ativar o Profile Generator no IMG (Basis Components > System Administration > User & Authorization > Maintain Authorizations and Profiles using PG)

- Alterar System Profile (Auth/no_check_in_some_case = Y)- Ativar uma Plan Version

- Configurar uma Transport Connection3. Trabalhar nos SAP check indicator e valores de campos

- Criar uma classe de desenvolvimento- Copiar as tabelas USOB..- Trocar os SAP Check Id default e valores de campos- Reconfigurar check de Authorizations

4. Gerar o menu da empresa5. Gerar Activity Groups


33

6. Gerar Profiles7. Assinalar Usuários para Profiles

• Passos dentro do Profile Generator (PFCG)1. Selecionar as transações para um Activity Group2. Completar (ou modificar) as Authorizations3. Gerar as Profiles4. Assinalar os Agents (usuários)5. Update User Master Record

• Observações sobre o Profile Generator- Ele gera Authorizations baseado nas tabelas USOBT_C e USOBX_C

- Se eu modifiquei as tabelas, as Authorizations refletirão estas mudanças- Podemos assinalar Activity Groups a Agents ou a objetos do Organizational Plan- O Organizational Plan é composto de

- Root Organizational Unit- Organizational Units sub-nivel da Root- Jobs- Positions são baseadas nos Jobs- Um usuário é assinalada para uma Position

• Update User Master Record- Ativado via PFCG -> encadeia transação PFUD- Chamar transação PFUD na amo- Rodar relatório RHAUTUP1 (para chama-lo usar transação SA38)- Todos rodam a Reconciliação daquele Activity Group

- Colocam a Profile nos User Master Records que estão associados- Retiram de quem não está

• A transação SU24- Define o status para o Authorizations Checks de cada Objeto- Pode ser:

- U -> Não modificada Verifica autoridade Campos não aparecem no PG- N -> Não verifica autoridade Campos não aparecem no PG- C -> Verifica autoridade Campos não aparecem no PG- CM -> Modificada Verifica autoridade Campos aparecem no PG

• Transporte de Authorizations, Authorizations Profiles e User Master Record- Num mesmo sistema, entre Clients

- Transação SCCL, profile SAP_USER- Entre sistemas diferentes

- Transação SCC8, profile SAP_USER

- Lembrar de sempre executar estas transações no Client de Destino- Se já houverem objetos com o mesmo nome no destino, estes serão sobrepostos

• Transporte de Activity Groups- Via transação PFCG

- Botão Transport > Enter Change Request


34

- Útil para um único Activity Group- Usar relatório RHMOVE30 (para chama-lo usar transação SA38)

- Executa um Mass Transport (vários Groups)- Para transportar entre Clients (no mesmo sistema)

- Criar um Transport Request (via PFCG)- Se logar no Client Destino- Chamar SCCI

- Quando transportamos o Activity Group, sua Profile não vai junto- Para a gerarmos, podemos usar a transação SUPC

• Para impedir o Import de um Activity Group- Por razoes de segurança, podemos não querer que Activity Groups sejam importados- Para isso devemos usar, no sistema destino, transação SM31 para editar a tabela T77TR

• A transação SUIM (Authorization Information System)- Emite uma série de relatórios relacionados a Authorizations

- USERS- PROFILES- AUTHORIZATIONS OBJECTS- AUTHORIZATIONS- TRANSACTIONS- WHERE USED LISTS- COMPARATIONS

• O SAPRouter- Programa que serve de intermediário entre sistemas R/3- Funciona como um Proxy para acessos dentro do R/3- Pode ser implementado independente de um Firewall- O R/3 possui um componente chamado NI (Network Interface) que atua na camada 7 do OSI- SAPRouter, CPI-C e RFC atuam nesta camada- SAPRouter possui uma Route Permission Table para permitir ou negar acesso a outros sistemas- Usos do SAPRouter

- Fazer log das conexões- Permitir acesso do seu sistema somente alguns outros SAPRouters- Proteger o sistema de acessos não desejados- Controlar a conexão com o OSS- Permitir conexão criptografada apenas com parceiros conhecidos (Via SNC)

• A implementação do SAPRouter- O programa vem no diretório USR/SAP/<sid>/SYS/EXE/RUN- Para maior segurança nos Upgrades do R/3, manter o programa SAPRouter e sua configuração num outro diretório

- USR/SAP/SAPROUTER- Manter também neste diretório a SAPROUTTAB (tabela de roteamento)- Para mudar esta tabela de lugar usar SAPROUTER –R no Command Prompt

- É recomendável baixar a ultima versão do SAPROUTER se fomos instala-lo- Versão mínima recomendada 23- Se usamos SNC, no mínimo 30- Devemos buscar num servidor SAPSERV (pode ser via OSS ou Internet)


35

- O SAPRouter é um serviço do NT, podemos defini-lo como start automático- Para colocar o serviço no ar na amo, usar SAPROUTER –R no Command Prompt- Para conseguirmos help usar SAPROUTER sem parâmetros

• As Route Strings do SAPRouter- Sintax

- /H/hhhhhhh -> host- /S/sssssss -> serviço default é 3299- /W/wwwwwww -> password

- Exemplo- /H/Sap_Router_Origem/H/ Sap_Router_Destino/W/password/H/Application_Server

• A Permission Table- Cada SAPRouter tem sua Permission Table- É uma tabela criada no USR/SAP/SAPROUTER via editor de texto ascii- A tabela contem 5 campos para cada conexão

- Permit / Deny (P ou D)- Source Computer (ip address)- Target Computer (ip address)- Service (default 3299)- Password (se não especificarmos, não precisa de password)

- São válidos *- Source Computer 123.45.*- Services *

- A pesquisa é seqüencial, o R/3 para quando encontra uma match- Para maior facilidade, colocar na tabela primeiro os DENY depois os PERMIT

• O NIPING- É um PING da SAP- Serve para testar a conexão entre 2 hosts de R/3, com ou sem SAPRouter- Sintaxe:

- No hostx -> NIPING –S (vai emular um servidor)- No hosty -> NIPING –C –H hostx (vai emular um cliente)- Neste caso, testa a conexão de hosty para hostx

- Pode testar a conexão passando por um SAPRouter- Sintaxe:

- No hostx -> NIPING –S- No hosty -> NIPING –C –H /H/hostr/H/hostx- Neste caso, testa a conexão de hosty para hostx passando por hostr

• Opções do comando SAPROUTER- Sem parâmetros -> HELP- -r -> ativa SAPRouter- -r -g LogFile -> ativa e gera log de conexões (ou de recusas) num LogFile - -r –V3 -> ativa e gera trace nível 3 no diretório de work (arquivo DEV_ROUT)- -t TraceFile -> muda o nome do arquivo de trace- -s -> encerra SAPRouter

• SNC (Secure Network Communication)


36

- Nome da interface R/3 que o conecta com sistema externo de controle de usuários- Possibilita logon único na rede (o R/3 aceita como sendo também logon R/3)- Pode usar autenticação via Smart Cards- Protege conexões de

- Dialogo com usuário- Impressão- Comunicação programa a programa

- SNC melhora a segurança na comunicação entre componentes do R/3- SAPGui- Kernel- Impressão (SAPlpd)- Conexões RFC- Conexões CPI-C- SAPRouter

- O sistema externo pode disponibilizar 3 níveis de segurança- AUTHENTICATION -> apenas verificação e autenticação de senha- -> sem proteção dos dados que trafegam na rede- INTEGRYTY -> impede mudança nos pacotes trocados entre componentes R/3- -> para isso usa assinatura digital- CONFIDENTIALITY- -> criptografa os pacotes

- Produtos atualmente suportados:- Kerberos 5- SECUDE 5.0- Devem ser comprados a parte (não são fornecidos junto com R/3)- Um landscape deve usar o mesmo produto (não pode misturar Kerberos com SECUDE)- O produto usado é acessa através de um conjunto de APIs do R/3 chamadas GSS API V2

• Convenções de Nome- Deve-se compatibilizar a estrutura de nome do R/3 com a do produto externo- Se produto compatível com x.500, o R/3 possuem um CN, porem não possui O, OU ou C- Sugere-se a utilização de constantes nestes campos- Pode-se usar ainda o System Number e outros atributos instance especifica

- CN=sap01.hs0017,OU=TEST01,O=SAP,C=BR- sap é constante, 01 é o SysNumber, hs0017 é o servidor, etc

• Ativação de usuários SNC- Atenção: SNC só funciona se na instance profile snc/enable=1- Via SU01 criamos o usuário e o relacionamos com o usuário SNC- Podemos usar ainda a transação SM30, view USRACL, que edita a tabela de usuário e entrar com o nome do usuário SNC diretamente na tabela de usuários

- Caso seja necessário mais de 1 usuário SNC para 1 usuário, devemos usar a tabela USRACLEXT- Isso pode ser necessário no caso de usuários RFC ou CPIC

- Para maior segurança- Atribuir apenas 1 usuário R/3 para cada usuário SNC- Atribuir apenas 1 usuário SNC para cada usuário R/3

- Sugere-se a utilização de constantes nestes campos- Pode-se usar ainda o System Number e outros atributos instance especifica

• A autenticação depois do SNC ativado__________________________________________________________________________________________________________


- No SAPGui, não é perguntado o User e Password- O R/3 verifica que usuário esta relacionado com o UserId do produto - Se acha, processa Logon, caso contrario da mensagem de erro- Podemos usar ambientes mistos, usuários com proteção SNC e outros não- Para isso, devemos ativar na instance profile

- snc/accept_insecure_gui=1 ou- snc/accept_insecure_gui=U (para logar sem segurança somente quem defini na SU01)

• Parâmetros de profile- snc/enable=1- snc/data_protection/min=2- snc/data_protection/max=3- snc/data_protection/use=3- snc/accept_insecure_gui=1- snc/accept_insecure_rfc=1- snc/accept_insecure_cpic=1- snc/accept_insecure_r3int_rlc=1- snc/r3int_rlc_secure=1- snc/r3int_rlc_qop=3- snc/permit_insecure_start=1- snc/gssapi_lib=/usr/local/secude/lib/libsecude.sl DEPENDE DA PLATAFORMA- snc/identify/as=p:CN=sap01.hs0017.OU=TEST01.O=SAP.C=DE DEPENDE DA INSTANCE

• Uso de SNC no SAPGui- Via SAPLOGON

- Usar Advanced Setting- Configurar SNC Enable e depois SNC Name e Protection Level

- Via Shortcut- sapgui.exe <servidor> SNC_PARTNERNAME=<appserver> SNC_LIB=<gsslib> SNC_MODE=<modo> SNC_QOP=<protection level>

• Uso de SNC em RFC e CPI-C- Não funciona de R/3 para R/2- Para definir destino com SNC Protection

- Para RFC transação SM59 - Para CPI-C transação SM54

- Para receber conexões SNC Protected- Transação SNC0 (access control list)

• Uso de SNC com SAPlpd- Dentro do R/3

- Transação SPAD- Só vai funcionar se snc/enable=1 e access method = S

- No micro que contem a impressora- Modificar WIN.INI- Numa session [SNC] colocar

- enable=1- gssapi_lib=<path da API Lib>- identify/lpd=<nome SNC da impressora>


38

• Uso de SNC com SAPRouter- Normalmente a proteção do SAPRouter é pela Permission Table- Ela trabalha com a origem (endereço IP) e destino (IP e serviço)- Com SNC deve-se trabalhar não mais com o IP de origem, mas nome do servidor- Para ativar SAPRouter com SNC

- Definir variável ambiental SNC_LIB com o nome da biblioteca externa- Chamar SAPROUTER –K <saprouter_snc_name>

- A Permission Table muda- Permit = KP - Deny = KD- Nome do servidor é o nome completo (contexto x.500)

• Recomendações para uso do SNC- Não misturar servidores SNC com não SNC- Verificar aderência dos padrões de nome do produto externo com o R/3- Ter em mãos todas as bibliotecas que serão necessárias e suas localizações em disco- Verificar o nível de proteção desejados para cada componentes

Capitulo 12 – CCMS Monitoring Infraestructure

• CCMS- Computing Center Management System− Possui sua infra-estrutura programada em C− Fornece interfaces C e ABAP para implementação de novos objetos

• Arquitetura e Terminologia − Objetos a serem monitorados no sistema estão definidos numa estrutura em formato de arvore invertida


39

− Esta árvore é chamada de MTE – Monitoring Tree Element− Muitos sistema R/3 podem ser assinalados para uma única árvore− O primeiro nível da árvore é o <Sid>− O segundo nível é o <Host>− Dentro do host, os elementos são organizados em Classes (p.e. Operating System)− Cada elemento é chamado de Monitoring Objects (p.e. CPU, DISK, etc)

− Monitoring Object pode ser um serviço− Pode receber um alerta de um de seus atributos indicando algum problema− Propaga este alerta para os níveis superiores

− Cada Monitoring Object possui vários Monitoring Attributes (p.e. %CPU IDLE)− Cada atributo recebe dados e pode ter um alerta associado a ele− Os atributos podem ser

− Performance Attributes− Message Attributes− Heartbeat Attributes− Text Attributes

• Customização e Ferramentas− Devemos customizar

− Mensagens que serão enviadas− Visibilidade destas mensagens (quem as recebe)− Prioridade dos alertas

− Como fazer estes assinalamentos− No próprio objeto− Numa Classe (objetos assumem assinalamentos por Herança de pai para filho

− A construção de Classes− Feita pelo administrador, de acordo com suas necessidades− Evita repetir a mesma parametrização em todos os objetos− As Classes (ou grupos) devem ter conexão lógica entre os elementos

− Ferramentas associadas a uma Classe TEM− Podem ser assinaladas diretamente a uma Classe ou herdadas− Uma classe pode não ter ferramenta− Ferramentas

− Data Supliers− OnAlert Tools− Analisys Tools

• Data Supliers− São programas que rodam coletando informações para o CCMS Monitoring− Podem ser

− Ativos: rodam permanentemente sem serem disparados− Passivos: disparados pelo autoABAP SAPMSSY8

− autoABAP− São programas que rodam sem terminal− Usam o usuário SAPSYS− São parte do Kernel do R/3− Rodam a cada período de tempo definido por rdisp/autoabaptime

− SAPMSSY8− autoABAP que dispara Data Supliers− Podemos parametrizar quando disparar cada Data Suplier de acordo com situações especificas

• OnAlert Tools− Define reações a um alerta


40

− Reduz o trabalho administrativo, pois cada alerta deve ter uma ação tomada, senão o Monitoring indica que o alerta esta pendente

− Se não indicarmos um OnAlert Tool, devemos manualmente ir ao Monitoring, verificar o alerta, resolve-lo e clicar o botão COMPLETE para resetar o alerta− Se o OnAlert Tool não rodar por algum motivo (cancelamento, programa não existe), o alerta fica pendente no Monitoring

− A ação é tomada imediatamente após o fato− Cuidado: o fato é detectado a cada rdisp/autoabaptime segundos

− Status das Alert Tool no CCMS Monitoring− ACTION REQUIRED -> OnAlert Tool não rodou ainda− ACTION RUNNING -> OnAlert Tool rodando− ACTION FAILED -> OnAlert Tool cancelou

• Exemplos de OnAlert Tools− Se acontecer um problema, desejo que seja enviado um e-mail− Posso definir um programa que, se ocorrer aquele problema, envia um e-mail e coloca-lo como um OnAlert Tool

• Analisys Tools− Programas que rodo quando quero para ler o MTE e fazer analises− São ativados manualmente

• Ampliando a capacidade do Monitoring− Podemos permitir ao Monitoring acessar sistema R/3 externos

− Cada um terá suas próprias definições de threshold and settings− Estas definições ficarão no próprio sistema externo

− Eles devem possuir conexão RFC com o sistema base− Definimos quais sistemas queremos anexar na RZ21− Podemos ainda definir nossos próprios objetos no Monitoring

− Usar APIs do ABAP ou do C

− Para cada Monitoring Object que criarmos, devemos providenciar seus Data Supliers, seus atributos e seus objetos pai na hierarquia da arvore, bem como sua classe (que deveremos criar)

− Monitor Segment é o conjunto de dados e componentes da arquitetura de Monitoring− Monitor Context é uma parte independente da arvore MTE

• Variantes− Podemos definir variantes para um MTE Class− Dessa forma teremos customizações diferentes para situações diferentes− Variantes podem ser

− Para o Sistema Produtivo− Para o Sistema de Teste− Para teste de Stress− Para teste de Upgrade (de maquina ?)

• Monitor Sets− Monitor set é uma forma de organizar os Monitorings− Posso ter um para um conjunto de sistemas (PRO, QAS e DEV) e outro para outro (TRN e TST)− Uma vez definido, estes conjunto é estático


41

• Transport de componentes do Monitoring− Função nova, a partir do release 4.5− Somente tabelas podem ser transportadas entre sistemas− Todas começam com AL

− ALCLASTOOL Assinalamento de ferramentas para classe− ALCONSEG Assinalamento de contexto e segmento− ALCUSTSET Conjunto de dados de customização− ALGRPCUSGE Dados de customização Class-Independent− ALGRPCUSMG Single message Class− ALGRPCUSPF Performance Class− ALMONISETS Monitor Sets para infra-estrutura da CCMS− ALMICUSGEN Customização Class Independent− ALMTCUSPER Performance Class− ALMECUSSMG Single Message Class− ALTIDTOOL Assinalamento de Tool para TID− ALTOOLCHEK Ferramentas que foram verificadas como utilizáveis− ALTOOLDP Nome do Tool Dispatcher− ALTOOLEXEC Assinalamento do executável para o nome da ferramenta

• Resolução de Problemas− Para resolver problemas (com as ferramentas desenvolvidas ??), devemos

− Usar traces de desenvolvedor− Usar trace de SQL− Usar debbuging tools do ABAP− Dicas e truques do runtime analisys

Capitulo 13 – CCMS Configuration

• CCMS (Computing Center Management System)− Ferramenta integrante do R/3− Deve ser configurada corretamente antes do uso− Fornece facilidades para monitorar, controlar e configurar o R/3

− Possui display gráficos− Funções principais

− Manutenção de Profiles− Definição de Operation Modes, Instance definitions e Scheduling− Start e Stop de instances− Processar e controlar Jobs em background− Schedular backups do banco de dados− Avisos automáticos de System Alerts− Dynamic logon load balacing− Monitoração e analise do sistema e da rede

• Passos para configuração da CCMS1. Import e Manutenção das Profiles (Default, Instance e Start)2. Definição dos Operations Mode3. Criação das Instance Definitions4. Adaptação das Instance Definitions e Operation Mode5. Definição da Timetable

• Manutenção de Profiles


42

− Transação RZ10− Permite manuseio das profile do sistema

− Default DEFAULT.PFL− Start START.<sid>.<instance_name><instance_number>_<host>.PFL− Instance <Sid>.<instance_name><instance_number>_<host>.PFL

− Opções de manutenção− Administrative Data− Basic Mode (alterações mais comuns, não mostra nomes dos parâmetros)− Extended Mode (mostra todos os parâmetros, com seus nomes técnicos)

− Faz controle de Versões− Permite comparação da Profile do Database com a Profile Ativa ou entre versões− Para alterações:

− Salvar -> grava no banco− Ativar -> copia para o NT− Cuidado: no start le a do NT− Se altero a do NT posso importar novamente para o Banco

• A criação inicial das Profiles− Default Profile é gerada quando instalamos a 1ª instance (na instalação do R/3)

− A instalação é feita pelo programa R3SETUP.EXE− Para cada instance (inclusive para a central instance), é gerada uma Start Profile e uma Instance Profile−

− Para as instances subsequentes a primeira, não é gerada Default Profile (ela é única no sistema), porem ela e alterada para refletir o novo ambiente− As Profiles são gravadas num Global Directory, Shared pelo File System do Sistema Operacional− Uma das primeiras tarefas a ser realizada num R/3 recém instalado é importar estas profiles do NT para o DataBase

− Transação RZ10 (Utilities > Import Profile > Of Active Servers)− As Profile são importadas, checkadas sintaticamente, gravadas no Database e regravadas no NT− Na regravação no NT elas recebem um header novo, com nome do usuário, data, hora

• O esquema de manutenção das Profiles− Profiles existem em 2 lugar

− No NT, de onde o R/3 le as profiles no start− No Database do R/3, a partir do qual realizamos as manutenções

− O esquema de manutenção implementado pelo R/3 visa mante-las compatíveis, com 2 gravações das profile:

− Gravação na base de dados− Sempre com controle de versões

− Ativação no NT− As profile recebem um header com data, hora, usuário, etc

• Alterações nas Profiles− Se alterarmos a profile via RZ10, ao gravarmos a alteração será feito uma verificação− Caso ocorram erros ou inconsistências, estas serão exibidas− Todas as alterações são registradas no DataBase e no arquivo ativado no SistOper− As alterações não tem efeito imediato, é necessário restar do sistema

− Para Default profile muitas vezes é necessário restartart o serviço NT


43

− É possível Dynamic Switching para alguns parâmetros de memory management da Instance Profile

• Verificação de Profiles− Podemos (e devemos) checar a sintaxe das profiles antes de gravarmos alterações− Se o check for feito numa profile individualmente, ela será consistida para validade sintática dos parâmetros− Se o check for feito em todas as profiles ao mesmo tempo (é uma opaco da RZ10), as profiles serão consistidas entre si para ver se estão consistentes

− Se existe um message server definido em qualquer das instances− Se um enqueue esta configurado em uma das instances

− Outra verificação feita é quando um application server é ativado− Ele checka ser a profile armazenada no Sist Oper é a mesma do Database− Caso não for, ativa um Alert Monitor

• Operation Mode− A quantidade de Background WP e Dialog WP de cada instance é definida na Instance Profile− Se quisermos modificar este parâmetro, seria necessário alterar a profile e dar um novo start da instance

− Para evitar esta perda de tempo, existe o Operation Mode, que define como e quando cada instance deve trabalhar com BWP e DWP− Cada instance pode ter vários Operation Modes, que são trocados de acordo os horários definidos na TimeTable

− Se houver um processo rodando no WP no momento da troca, o sistema espera ele encerrar e depois troca o tipo de WP− A performance é mantida, não há refresh de buffer de tabelas ou de programa ABAP

− A troca de um Operation Mode para outro é conhecido como Operation Mode Switch− Caso seja necessário uma troca não programada na TimeTable, isto pode ser feito manualmente

• Criação de Operation Modes− Feito pela transação RZ04 − Para configurar a CCMS é obrigatório ter ao menos 1 Operation Mode− Existe 1 Operation Mode default chamado DUMMY

− No entanto não pode ser usado para switching− Não pode ser assinalado para a TimeTable

− Operation Modes podem ser definidos como− Productive vão ser ativados de acordo com a TimeTable− Test não vão ser ativados de acordo com a TimeTable

− Cada instance deve ter uma definição dentro da RZ04 p/ podermos criar Operations Mode− Esta definição se chama INSTANCE DEFINITION e é feita importando os dados das profiles de definição da instance

− É possível, mas não recomendado, criar Instance Definitions manualmente− Opções para import de Instance Definition

− Todos os servidores ativos− De uma instance especifica que esteja ativa

− Após termos feito as instance definitions, podemos criar seus Operation Modes− Na redistribuirão dos WP, não podemos criar, somente redistribuir− Nesta configuração, podemos criar WP para jobs de Classe A− Não podemos nunca menos de 2 DWP numa instance


44

• A TimeTable− Transação SM63 -> Relaciona Operation Modes na TimeTable− A TimeTable pode ser dividida em 60, 30 ou 15 minutos− Existem 2 TimeTable

− Normal Operation (usada no dia-a-dia)− É repetida a cada 24h− Se não tivermos uma Normal Operation definida, o sistema rodará de acordo com a definição da profile e não ocorrerá switch de opmode− É obrigatório definirmos OpMode para todos os períodos do dia

− Expectional Operation− Ativada 1 vez num período especifico− Tem prioridade maior que a Normal Operation− Podemos especificar parte do dia

• Ativação manual de OpModes− Via transação RZ03− Pode trocar para todos os servers ou apenas 1

− Podemos solicitar uma simulação de troca, para verificarmos se é possível ela ser executada− Este OpMode ficará ativo até a próxima troca programada na TimeTable

• Diagnostico de problemas no Switch− Devemos olhar no System Log (SM21)− Verificar como estão os WP (SM50)− Causas comuns de erro: numero errado de WP no sistema. Verificar

− Instance Profile no Sistema Operacional− Instance Profile no DataBase− Definição de numero de WP no OpMode

− A verificação do numero de WP nestes 3 locais deve ser feita regularmente− Se alterarmos as profiles e restartarmos o sistemas devemos adequar o OpMode e Instance Definitions ao novo panorama

• START e STOP de instance na CCMS− É possível dar Start e Stop em instances via CCMS− É necessário que ao menos 1 instance (a central instance) e o db esteja no ar− A transação para Start e Stop é a RZ03


45

Capitulo 14 – System Monitoring

• Monitoring− O que Monitorar ?

− Componentes do R/3− Aplication Servers− Buffers− Aplicações− Serviços

− Database− Performance− Backups

− Sistema Operacional− CPU− File System

− Para que ?− Para manter o sistema rodando− Para analisar e corrigir erros− Para melhorar performance

− Quem deve fazer?− Administradores do R/3− Administradores de banco de dados− Administradores do Sistema Operacional

− Quando ?− Periodicamente, ao menos 1 vez por dia

• A Arvore de Monitoring− Uma única árvore para o sistema− Futuros release vão implementar monitoring do transporte e de transações na árvore− Alertas que ocorrem nos Monitoring Attributes podem subir pelos níveis da árvore, se forem alertar de alta prioridade

− Desta forma, os níveis mais altos da árvore sumarizam os alertar mais importantes

• Customização do Monitor


46

− Definindo Class− Definimos classes para os Monitoring Objects− Criamos definições para esta classe, poupando trabalho− Para cada classe definimos

− Descrição− Nível de visibilidade (administrador, operador, etc)− Prioridade do Alerta

− Definindo Customazing Groups− Monitoring Attributes logicamente ligados são agrupados em Customazing Groups− Customazing Groups são ou grupos de parâmetros de performance ou grupos de mensagem− Para estes Groups definimos

− Valor do Threshold− Quando criar o Alert (p.e. quando o valor real passar o do threshold)

− Texto do Alerta− Configurando Tools

− Após configurar os Alertas, posso assinalar as Tools− Tools são programas relacionados aos objetos TEM que podem

− Coletar dados quando ocorre o alerta (p.e. rodar a SM50 se cpu muito alta)− Analisar o alerta− Reagir ao alerta (p.e. cancelar batchs se cpu muito alta)

− Podemos definir as Tools a nível de Classe, gerando herança desta ferramenta para todos os objetos da classe− Podemos definir a Tool para um objeto especifico, overridando a especificação da classe

• O assinalamento de Tools- Tool predefinidas pela SAP começam com CCMS- É recomendado que Tools de clientes comecem com Z ou Y1. Definição da Tool

- Tipo (Relatório, Transação, Function Module)- Localização (servidor, database server)- Operation Mode (background, start manual)

2. Definir propósito de Liberação da Tool- propósito de alerta- propósito de analise

3. Assinalar a Tool- Podemos não assinalar Tool- Podemos assinalar para uma classe- Podemos assinalar para um objeto especifico

• Uso do Monitor

- É uma estrutura em forma de árvore com todos os objetos de monitoring- O Monitor pode exibir Alerts que estão ocorrendo ou o Status atual do sistema

- Podemos trocar ficar trocando entre estas telas para acompanhamento- Alertas são marcados em Vermelho e avisos são marcados em Amarelo- Alertas de alta prioridade são passados para os níveis mais altos e exibidos também nos nós superiores da árvore- Após selecionar um Monitoring Attribute, podemos ir (BRANCH) para a customização do atributo ou chamar a ferramenta de analise- Podemos criar uma View do Monitor para situações especificas- Por exemplo, DBA pode querer um Monitor só com os parâmetros do Banco- Para isso, devemos assinalar os objetos desejado do MTE e salvar a nova árvore


47

• Monitoring Object a Tools correspondentes- R/3 Syslog (SM21)

- Exibe o Log do Sistema - Possui mensagens

- S -> Start e Stop do R/3 ou WP ou Switch de Opmode- W -> Operações de Rollback- K -> Erros de programas do Kernel- T -> Transações ABAP com short dumps

- R/3 Services- R/3 Servers (SM51)

- Exibe servidores disponíveis- Exibe usuários no sistema (por servidor)- Acessa o System Log- Exibe o status do OS Collector

- R/3 Work Process (SM50 e SM66)- Processos no servidor onde estou logado- Processos em todo o R/3

- R/3 Users (AL04 e AL08)- Usuários em um servidor especifico- Usuários em todo o R/3

- R/3 Locks (SM12)- Usuário que iniciou o lock- Client no qual ele esta logado- Tabela que esta locked- Lock argument

- Asyncronous Update (SM13)- Mostra Updates que não saíra das tabelas VB* (VBLOG)

- ABAP Dumps (ST22)- Exibe dumps ABAP

- WorkLoad Analisys (ST03)- Tempo médio de resposta- Tempo médio de acesso ao DB- Numero de Steps- Tempo de Roll In e Roll Out- Tempo médio de wait

- Logon Groups (SMLG)- Exibe Logon Group para Load Balancing

- Basis System- Buffers (ST02)

- Hit ratio- Allocated Space- Remainig Free space- Swaps- Nametab Buffers- Program, Screen e Calendar Buffer- Table Buffers

- DataBase Monitoring (ST04)- Buffer busy wait- File system requests (i/o físicos)


48

- Wait events- SQL requests- Exclusive Lock waits- Latch waits- V$ Values- Paramentes changes

- Operating System (ST06)- CPU utilization

- Page rates- Disk Statistics- Para monitorar File System -> RSHOST10

- Mostra ainda CPU Utilization e swap space- Analise capacidade e free space em disco- Mostra paging rate

• Passos para analise de Problemas- É problema de performance?- Afeta todos os usuários ?

- Não -> fazer trace do ABAP e do SQL que esta com problema- Sim -> Verificar carga dos servidores e analisar

- CPU Time- CPU Time muito menor que o Response Time- Wait Time- Load Time- DB Request Time

• Analise do Problema- CPU Time

- Muito processamento- CPU Time muito menor que o Response Time

- Gargalo de I/O- Problemas na rede

- Wait Time- Falta de Work Process- Todos os Work Process ocupados

- Load Time- Poucos R/3 Buffers- Falta de Índices nas tabelas

- DB Request Time- Sobrecarga de CPU no DB Server- Falta de memória no DB Server- Muito disk sort – falta de Índices

• Mais Jobs de Basis de Clean up do sistema (diários)- RSPO0043 Verifica consistência do Spool- RSSTAT60 Reorganiza tabela MONI- RSORA811 Deleta brbackup e brarchive do Oracle- RSORASNP Reorganiza SNAP e STAT$ log do Oracle


49

Capitulo 15 – Workload Distribution

• Load Balancing- Dialog, Background e Update WP podem ser distribuidos através de Operation Mode- Spool WP podem ser distribuidos via RZ10 (Edit Profile)- Background, Update e Spool podem ser despachados para outra instance- Dialog só pode rodar na mesma instance

• Filas do Dispatcher- Cada Dispacther tem sua fila- Tamanho da fila default é de 2000 elementos

- Tamanho configurado em rdisp/elem_per_queue- Se estoura, é gravada mensagem em SYSLOG- Para UP2 o default é 5

- Pode ser monitorada pela SM51 > Select Server > Goto > Queue Information- Solicitacoes armazenadas na Dispatcher Queue são divididas em

- NOWP (envia solicitacoes dos WP ao Message Server)- DIA, BTC, UPD, UP2, SPO, ENQ

- Dá para ver a Dispatcher Queue - via RZ03 > Edit > Other Views > Dispatcher Queue- via comando do S.O dpmon pf=instance_name

• WP Load Balancing Monitoring- Via ST03 > Detail Analisys Menu > Compare all Servers > Graphics > Avg Resp Time

- Mostra grafico com tempo de resposta e dialog steps por servidor- Via SM50

- Olhar os WP de cada tipo- Os ultimos de um tipo devem ter seu uso zerado, senao esta faltando WP deste tipo

- Dicas- R3SETUP instala todos UPD WP na mesma instance

- Podemos separar- Alta carga na Central Instance é indesejada

- Retirar dela RFC e CPI-C -> usam muita memoria e CPU- Muitas interfaces podem ser movida para Dialog WP

• Logon Load Balancing- Vantagens

- Se um servidor falha, logon procura outro- Usuarios de mesmas caracteristicas usam mesmos programas e aplicacoes

- Logando no mesmo grupo melhoramos consumo de recursos- Usuario podem usar Code Page que só pertencem a um grupo de servidores

- Usuario logam num nome logico, não fisico- Usuarios são distribuidos entre os servidores do grupo baseados

- Servidor com melhor tempo de resposta (peso 5)- Servidor com menos usuarios (peso 1)


50

- Para ver resultado da eleicao SMLG > Goto > Syst Diagnostics > Msg Serv Stat Area

- Dados são coletados pelo programa RSRZLLG0- Roda a cada 5 minutos ou 4 logons

- Se for usuario RFC só atualiza a cada 5 minutos- Para checar distribuicao dos logons entre os servidores

- SMLG > Goto > User List -> mostra usuarios e instances onde estao logados- AL08 -> todos os usuarios logados- SMLG > Goto > Load Distrib -> qtde de usuarios por servidor

- Dicas na construcao de Logon Load Balancing Groups- Construir grupos com ao menos 2 servidores

- Se 1 cai, tem o outro- Evitar sobrecarregar central instance

- Maior disponibilidade da central instance- Menor seguranca porque a central instance não faz parte de todos os grupos

- Construir subsets com overlapping dos grupos- Tem que configurar parametros na SMLG

- Para otimizar uso de buffer, não fazer overlapping- Os usuarios estarao usando buffers nos servidores que os possuem- Como a central instance não vai estar no grupo, diminue seguranca

- Configuracao- Via SMLG -> Create Entry- Adcionar servidores para o grupo

• Background Load Balancing- Monitoracao

- Detectar jobs que comecaram atrazado ou que excederam o runtime medio- Via RZ01 Job Scheduling Monitoring- Mostra jobs que comecaram atrazado e que excederam runtime medio

- Monitorar jobs XMI- Via RZ15

- Detectar servidores com Background WP não usados ou sobrecarregados- Usar SM66

- Dicas- Reservar 0 ou 1 Background WP Classe A

- Se pusermos 2, quando entrar 1 job classe A o sistema reserva outro Background WP para classe A, de forma a sempre ter 2 disponiveis

- Usar recursos eficientemente- Evitar sobrecarregar Central Instance e DB Server- Definir diferentes valores para o rdisp/btctime se não a instancia que começa pegando os jobs vai pegar sempre

- Construir um Job Schedule eficiente- Evitar usar jobs com start Immediate ou Event Triggered

• Spool Load Balancing- Monitoracao

- Colocar alertar no CCMS Alert Monitor- Verificar via SM66 se existe falta ou excesso de Spool WP- Usar CCMS para verificar

- Spool Utilization < 99%- Service Queue < 80%


51

- Spool WP wait Time < 1% do Reponse Time- Dicas

- Definir Logical Spool Servers com Non-Exclusive Spool Servers

- Não definir Sequential Request Processing para o Output Device- Definir Do Not Ask For Print Request On Host Spool para o Output Device- Evitar metodo do acesso U (Remoto)- Reservar 1 ou + Logical Spool Servers para impressoes Time Critical ou High Volume

• Update Load Balancing- Deve haver ao menos 1 Update WP num sistema R/3- É recomendado ao menos 1 UP2 WP- Distribuir estes WP distribui a carga- O Dynamic Update Assignment automaticamente distribui V1 e V2 updates entre os servidores disponiveis- Se um servidor falha, outro pode tomar seu lugar- Load Balancing Mecanism

- Cada update da fila é atribuido ciclicamente aos servidores- Quando um servidor chega no seu limite (rdisp/wp_no_vb), ele sai do ciclo- Este processo é serializado no NOWP, que depois encaminha para os servidores

- Monitoring- SM66 -> verificar se a qtde de Upd WP é suficiente- SM51 ou RZ03 -> para ver a Dispatcher Queue- SM13 -> para ver o status dos Updates (SM12 mostra lock entries)

- Dicas- Configurar Updates WP de acordo com a potencias dos servidores do Landscape- Configurar UP2 para evitar que UPD tenham que esperar estes requests- Manter ao menos 1 UPD por instance- Podemos centralizar update na central instance

- Outras instances tem mais memoria para suas tarefas- Update Work Balancing bastante limitado- Para esta configuracao devemos manter Dialog fora da Centra Instance

- Podemos descentralizar updates- Permite Update Load Balancing- Tira espaco das instances para outros modulos (FI, CO, etc)

- Parametros- rdisp/vbname -> UPD server dedicado (se dispatching desativado)- rdisp/vb_dispatching -> não mudar, parametro SAP- rdisp/vb_context -> ?- rdisp/vb_included_server -> lista dos servidores que participam do dispatching- -> se não configurado, significa todos- rdisp/vb_refresh_info -> Automatic Refresh da Dispatching List- rdisp/max_vb_server -> numero maximo de update servers- rdisp/wp_no_vb -> numero de Update WP para V1- rdisp/wp_no_vb2 -> numero de Update WP para V2


52

Capitulo 16 – Software Logistics

• Instance- Grupo de serviços R/3 que aso ativados e encerrados juntos (por um Dispatcher) and que tem uma Instance Profile comum- Serviços da Instance: DVEBMGS

• Central Instance- Instance R/3 que contem o message server e tipicamente contem todos os serviços R/3

• Dialog Instance- Instance que contem somente Dialog WP

• Application Server- Computador com 1 ou mais serviços R/3 instalados

• Dados do R/3- Client Dependent

- Afeta apenas 1 cliente, como User Master Data, Application Data e boa parte do Customizing Data

- Client Independent- Dados que afetam todo o sistema, como Objetos do Repositório e alguns dados de Customização

• ABAP Dictionary- Parte do ABAP Repository- Contem os programas, telas e as definições das tabelas- Único para todo o sistema- Cada vez que rodamos um programa, ele é gerado e vai para o buffer (early building)- Se efetuarmos uma alteração, quando for usado novamente ele é regerado (late binding)

- Este processo torna o ABAP Dictonary ativo, sem impactar fortemente na performance

• Clients R/3- Unidade R/3 que é tecnicamente, organizacionalmente e comercialmente auto-contida- Possui seu próprio conjunto de Usuários, Dados de Aplicação e de Customização- Todo usuário deve se logar em 1 client- Application Data e Transaction Data pertencem sempre a 1 client- Possui um sub-nivel que é o Company Code

• Sugestão de Cliente da SAP- Ambiente 1

- Development e Customizing- SandBox


53

- Test- Ambiente 2

- Quality Assurance- Training

- Ambiente 3- Production

- Esta estrutura permite- manter a consistência dos objetos do repositório- a segurança e estabilidade do sistema de produção- evita perda de performance na produção por testes ou atividades de desenvolvimento- evita que alterações em dados client independent entrem imediatamente em produção- evita que se transporte objetos recém desenvolvidos para o sistema de produção sem o teste num ambiente preliminar- esta estrutura é básica para o upgrade de release do R/3

• Aims of the R/3 System Landscape- Proteger dados das aplicações através

- Regras de Client- Autorizações

• Transporte- É a distribuição de alterações dentro de 1 landscape- Unidirecional, não dá pra transportar no sentido inverso- Só é permitido transporte entre sistemas de mesma versão- Ferramentas para gerenciamento de transporte permitem

- Auditar modificações feitas - Controlar por quem e aonde estas alterações foram feitas- Definir aonde e quando alterações serão distribuídas- Implementar upgrades do R/3

• CTS – Changing and Transport System- Composta por

- CTO – Change and Transport Objetct- Workbench Organizer (SE09)- Customizing Organizer (SE10)- Transport Organizer (SE01)

- TMS – Transport Management System- STMS

- Operating System Transport Tools- TP conversão com o R/3- R3TRANS faz realmente o transporte


54

Capitulo 17 – Change and Transport System Prerequisites

• Setup do System Landscape- Antes de instalar o R/3 e o Database

- Definir a infraestrutura de rede- Definir equipamentos e sistema operacional

- Durante a instalação do R/3 e do Database- Criar um diretório compartilhado de transporte- Podemos ter apenas o ambiente de desenvolvimento nesta fase

- Depois da instalação do R/3 e do Database- Configurar o TPPARAM

- Na instalação vem no diretório USR/SAP/<sid>/SYS/EXE/RUN- Na operação normal deve ficar no USR/SAP/TRANS/BIN

- Inicializar o CTO (SE06)- Setar a TMS (STMS)

• Fases do Transporte- 1ª Exporte das Change Requests do database para o diretório de transporte no NT- 2ª Importe destes objetos no QAS- 3ª Importe destes Objetos nos Delivery Systems (após a validação, é claro)

• O Diretório de Transporte- Nome base é \SAPMNT\TRANS (precisamos ter o Share SAPMNT)

- É estimado um tamanho de 10 Mb para cada Customizer ou Developer que houver- São criados pelo R/3 durante a instalação- Subdiretorios

- BIN -> onde fica o TPPARAM e DOMAIN.CFG- BUFFER -> Arquivos com o nome e a ordem dos Change Requestes a serem importados- COFILES -> K9______.<sid> - Comandos/informações da Change Request (tipo, classe) - DATA -> R9______.<sid> - Change Requests exportadas - OLDDATA -> Change Requests velhas, já importadas- LOG -> Logs dos transportes, traces, estatísticas- ACTLOG -> Logs das tasks e requestes (manuseado pelo R/3)- SAPNAMES -> Log das atividades de cada usuário- EPS -> usado na aplicação de Hot Packeges- TMP -> dados e logs temporários (depois vão para o DATA e LOG)

• O Programa TP- Configuração feita no arquivo TPPARAM- Template TPPARAM.NT é enviado pela SAP, mas precisa ser customizado e colocado no USR/SAP/TRANS/BIN- Parâmetros principais


55

- # Global Parameters- transdir=/usr/sap/trans- # Local Parameters for system T11- T11/dbname=T11 <- cai no teste- T11/dbhost= HOSTDB11 <- cai no teste- ...

- # Local Parameters for system T12- T12/dbname=T12- T12/dbhost=HOSTDB12

- Para checar se o programa TP esta disponível em todos os sistemas- R/3 System -> Check -> Transport Tool

- Para display dos parâmetros do TP- Goto -> TP Parameters

• Inicialização do CTO (Change and Transport Organizer)- Transação SE06

- Deve ser executada 1 vez, em toda nova instalação- Define o status do Sistema

- New Installation- Database copy ou migration

- Se escolhermos esta opção, todas as change requests pendentes serão liberadas

- Estabelece o numero inicial da Change Request- Define o System Change Option

- Not Modifiable- Allow changes to Repository objects and Client Independent Customizing

- Neste caso podemos especificar namespace, name range e tipos de objetos que podem ser modificados

• O TMS – Transport Management System- Vantagens

- Configuração Centralizada- Gerenciamento centralizado das Change Requests- Estratégia de transporte baseada em rotas predefinidas

- Outras vantagens- Um editor gráfico e um hierárquico para rotas- Display de todas as queues do sistema no transport domain- Pode fazer import Preliminar- Pode fazer transport entre R/3 sem um diretório compartilhado

• A configuração centralizada- As definições são configuradas centralmente e depois distribuídas entre todos os participantes do Domain Controler- Só podemos realizar estas configurações no Domain Controler- Os participantes do Domain Controler não precisam compartilhar o mesmo diretório- As configurações são distribuídas via RFC- Dentro de uma mesma TMS todos os sistemas pertencem ao mesmo transport Domain- Dentro do Transport Domain, algumas configurações (como rotas) valem para todos os sistemas- O Domain Controler é o sistema de referencia para todos os outros, enviando copias da configuração


56

- Um grupo de sistemas R/3 que compartilham um mesmo diretório de transporte é chamado de transport group- Não podemos usar o TMS para transportar objetos entre computadores de transport Groups diferentes

• Configurando a TMS

- 1º Configurar o Transport Domain- Assinalar os sistemas R/3 para o Transport Domain- Especificar quem será o Domain Controler

- 2º Configurar as Routes- Definir a rota de consolidation- Definir rotas de Delivery

- 3º Check and Monitor TMS setup- Verificar setup usando ferramentas do TMS

• Configurar o Transport Domain- O Transport Domain contem todos os R/3 que queremos administrar juntos- Um deles será o Domain Controler- O Domain Controler deverá ter

- Alta disponibilidade- Alta segurança- Excelente nível de manutenção

- Normalmente o Domain Controler é o sistema de produção- Não causa perda de performance, o uso é pequeno e de baixa carga

• Inicializando o Transport Domain Controler- É feita usando a transação STM- Precisa ser feita no CLIENT000- O usuário que a faz precisa da autorização S_CTS_ADMIN- Ao rodar a STMS

- Se o sistema já esta assinalado para um transport domain, isto é exibido na tela inicial- Se não esta assinalado, o R/3 tenta localizar um Transport Domain lendo o DOMAIN.CFG. Se não existe, cria e o sistema corrente é assinalado como System Domain Controler

- Na criação do Domain Controler- É criado o Transport Domain e o Transport Group- É criado o usuário TSMADM- É criada uma conexão RFC para o TMS- É criado o arquivo DOMAIN.CFG no /USR/SAP/TRANS/BIN

- O nome default do Transport Domain é DOMAIN.<sid>- <sid> é o Sistem Id do Domain Controler

• Acrescentado novos sistemas R/3 a um Domain Controler- Rodar no novo sistema a STMS no CLIENT000 (não devemos nos esquecer de rodar a SE06 antes)- O novo R/3 procurará no DOMAIN.CFG o nome do Domain Controler

- Vai pesquisar no diretório compartilhado para saber quem é o Domain Controler- Todos os sistemas usam o mesmo arquivo, que é lido durante a inicialização da STMS- Ele contem o Domain Controler e o Transport Group Address


57

- Se o sistema não tem um diretório compartilhado, podemos configurar manualmente a TMS com o endereço do Domain Controler

- Criará o usuário TSMADM no CLIENT000- Gerará a conexão RFC- Enviará ao Domain Controler uma solicitação requisitando entrada no grupo

- No domain Controler deveremos- Aceitar esta inclusão- Verificar a configuração e comunicação com o novo sistema

• Gerenciamento do Transport Domain- Na STMS > Tools > Administration > Transport > Transport Management System > Overview > System

- Podemos ver o Status da configuração e se ocorreram erros na distribuição das mesmas

- Para o caso do Transport Domain cair, podemos definir um Backup Transport Domain

• Configuração de Routes- SAP tem modelos de rotas para

- One-System Landscape- Two-System Landscape (Development e Production)- Three-System Landscape

- As principais rotas de transport- Consolitation

- Do Integration System (DEV) para o Consolidation System (QAS)- Possui Transport Layers com o nome Z<sid>- Caso possa transportar alterações em objetos da SAP deve possuir uma Transport Layes SAP

- Delivery- Do Integration (QAS) para o Delivery (PRD)- Não possui Transport Layer- Só posso criar uma Delivery Route para uma Consolidation Route que já exista

- Podemos configurar as rotas usando- Graphical Editor- Hierarquical Editor

- Após configurar, devemos distribui-la a todos os sistemas do Transport Domain- Usando função Configuration > Distribute- Só é possível do Domain Controler- Usa conexão RFC gerada no primeiro uso da STMS de cada sistema

- Para garantir segurança esta conexão não pode ser modificada- Quando distribuímos a configuração, pede usuário e senha do sistema destino- Um sistema R/3 fora do Transport Domain não pode acessar sistemas R/3 do Transport Domain- A comunicação RFC usa 2 usuários

- TMSADM@<sid>.<domain_name> -> possui poucas autorizações- -> usada para acesso read only entre sistemas- TMSSUPM@<sid>.<domain_name> -> não possui senha e password- -> assume as autorizações do usuário- -> por isso precisamos dar usuário e senha

- Após distribuição, devemos ativar as configurações- Pode ser feita remotamente


58

- Função Configuration > Activate > In All Domains- Vai usar novamente conexão TMSSUP- Vai pedir usuário e senha

- Pode ser feita localmente- Entra no sistema e solicita ativação individual

- Configuration > Activate > Local- Por último, devemos verificar o Setup da TMS

- Verificar Conexão RFC- Overview > System > R/3 System > Check > Connection Test

- Verificar transporte via diretório- Overview > System > R/3 System > Check > Transport Directoty

- Verificar programa de transport (TP)- Overview > System > R/3 System > Check > Transport Tool


59

Capitulo 18 – Change Management for Development

• Adaptação do R/3 para as necessidades do cliente- Customizing

- Definição dos business process usando o IMG- Personalizing

- Alterações na forma de exibição de dados ou de menus- Modification

- Alteração de Objeto SAP do repositório por clientes- Enhancement

- Criação de objetos no repositório que são chamado ou incluídos via User Exits- Customer Development

- Criação de objetos novos no repositório

• Change Requests- Forma de manutenção de objetos do Repositório- Providencia o meio de transportar alterações- Fornece meios para documentar novos desenvolvimentos ou alterações de objetos do repositório- Nela definimos os objetos que serão alterados e desenvolvedores autorizados

- Todos os desenvolvedores desta CR podem executar alterações nos objetos definidos nela

- Depois de todas as alterações completadas, libero a change request- Uma nova versão completa dos objetos daquela CR é gravada no repositório- É possível acessar e retornar versões antigas dos programas

- Existe na CR um mecanismo de lock para evitar alterações de objetos na CR para desenvolvedores não catalogados nela- A transação SE09 (Workbench Change Request)

- Criar, administrar e liberar change request para o Workbench- Incluir desenvolvedores para uma CR- Mostra informações sobre transporte- Possui uma visão gráfica do status da CR transportadas

• Gerenciando CR- Através da SE09- Exibe uma estrutura hierárquica com as CR para um usuário- Dentro de uma CR vemos todas as Tasks assinaladas- Dentro de uma Task, vemos os objetos (caso tenham sido alterados)- Os tipos de uma Workbench Change Request são

- Transportable- Local- Unclassified

- Existe ainda a Customizing Change Request, para o IMG


60

- Change requests da SE09 são do tipo SYST- Change requests podem ser do tipo

- Development / Correction- Quando modifico objetos originais no sistema

- Repair- Quando modifico objetos copia (como os objetos SAP)- Objeto fica em lock pela task, impedindo import de objetos sobre ele- Impede que outros desenvolvedores na mesma CR tenham acesso ao objeto enquanto a task não termina

• Gerenciando Projetos de Desenvolvimento- No inicio de um projeto, o Lider do projeto cria a CR e assinala desenvolvedores para ela- O sistema assinala um numero para a CR

- <sid>K9<nnnnnn>- É criada uma task para cada desenvolvedor na CR- Se um desenvolvedor altera um objeto e o relaciona a CR, o objeto é armazenado na task do desenvolvedor

- Desta forma, a CR armazena todas as atividades do desenvolvedor para aquele projeto

- Quando o desenvolvedor termina seu trabalho, ele libera sua task- Quando todos os desenvolvedores terminam suas tasks, o Lider do Projeto libera a CR

• Autorizações para trabalhar com CR- Profile S_A.SYSTEM autorização S_CTS_ADMIN

- Para o System Admnistrator, contem todas autorizações Change and Transport System

- Profile S_A.CUSTOMIZ autorização S_CTS_PROJEC- Para Customizing, para todas as atividades de setting do sistema (Lider do Projeto)

- Profile S_A.DEVELOP autorização S_CTS_DEVELO- Para Developers e Customizing team member que trabalham na CR a nível de task

- Profile S_A.SHOW autorização S_CTS_SHOW- Para Basis ou usuários finais, apenas Display

• SSCR - Chave de Desenvolvedores e Objetos SAP- Sistema de registro chama SSCR (SAP Software Change Registration)- Pode ser feito via OSS- Desenvolvedores precisam ser registrados junto a SAP

- Cada desenvolvedor recebe uma chave chamada ACCESS KEY- Esta chave é associada com o Logon e Numero da Licença do R/3- Deve ser informada apenas 1 vez, quando o usuário faz a primeira alteração ou criação de objetos no repositório

- Objetos da SAP modificado pelo cliente precisam de uma chave para ser alterados - Esta chave também só é registrada uma vez por objeto- Vale até o próximo update de versão- Esta chave não é necessária para

- Matchcodes- Índices de Database- Buffers settings- Objetos gerados pelo Customizing


61

- Correções - Vantagens

- Rapidez na correção de erros (por parte da SAP)- Evita modificações não intencionais- Segurança

- Facilidade de Upgrade

• Name convention para objetos do repositório- Os nomes dos objetos de desenvolvidos pelos clientes não podem coincidir com nomes de objetos da SAP- Objetos de cliente normalmente começam com Y ou Z- View V_TRESN define name conventions para uma Development Class- O prefixo do namespace identifica objetos criado por partners

- /XXXXXXX/ZABAP

• System Change Options- para cada sistema, o System Change Option define se é possível alterar objetos do repositório- esta definição é feita por namespace e name ranges- para fazer esta customização é preciso autorização S_CTS_ADMIN- para permitir uma modificação em objetos locais, devemos setar o name range Local Objects para Modifiable

- Local Objects são objetos cuja development Class começa com T ou $- Estes objetos não são do sistema

• Development Class- Todo objeto do repositório deve ter uma development class- Uma Development Class pode ser criada pelo Workbench ou pela tabela V_TDEVC

- Na V_TDEVC podemos especificar também qual name range pode ser definido em cada Development Class

- Ao criarmos uma Development Class, é automaticamente assinalada para ela uma Transport Layer

- Podemos criar uma Transport Layer alternativa se quisermos- Development Class de clientes devem começar com

- Y ou Z para objetos que serão transportados- $ para temporary development class, ou seja objetos que não serão transportados e portanto não precisam de um transport layer- T indica development class de objeto local, com o Workbench provendo serviços de lock e gerenciamento de versões- Development Class $TEMP indica que o objeto é salvo como um Local Object e não deve ter suas alterações armazenadas numa Change Request

- Ela proporciona um agrupamento lógico para coordenar o desenvolvimento- Define uma Transport Layer para os objetos- Pode ser usada para controlar o nomes dos objetos

• Transport Layer e Development Class- Uma Development Class é assinalada para um Transport Layer- Se a Transport Layer é uma Consolitation Route valida, os objetos daquela development Class são transportados para o consolidation system- Os objetos da SAP modificados pelo cliente no Integration System seguem a rota SAP


62

• Repository Object Locking- Objetos podem ser modificados por todos os desenvolvedores assinalados para uma Change Request

- Somente os desenvolvedores assinalados para uma Change Request podem modificar os objetos presos pela request- O lock do editor garante que nunca 2 usuários estarão modificando o mesmo programa ao mesmo tempo- Objeto é assinalado para a change request no momento que o desenvolvedor salva um programa- Somente na liberação da CR os locks dos objetos alterados naquela Change Requeste são liberados para alteração por outra Change Request

• Liberação da CR e da Task- Precisa liberar todas as task para liberar a CR- Quando libera a task, pede documentação

- Precisa ser feita pelo dono da task- Após liberação, não pode mais ser utilizada para alterações, devemos criar uma nova task

- Quando libera a CR as novas versões são gravadas no DB de versões- Os objetos são liberados para novas manutenções- Se a CR é transportável, os dados são exportados para o Transport Directory

- Return codes : 0 ok- 4 warning, todos os objetos transportados- 8 warning, porem pelo menos 1 objeto não foi- 12 ou mais, erros críticos do processo

- Se acontecerem erros no Tranport, eles podem ser vistos na tela inicial do Workbench Organizer

- Semáforo com luz vermelha ou amarela- Podemos entrar no log e verificar problemas- Após corrigi-lo, clicar no botão ERROR CORRECT para limpar este erro

• Controle de versões- A gravação de novas versões no Version Database é feita no momento da liberação da Change Request- Podemos criar versões temporárias (para testes p.e.)- Podemos comparar versões ou restaurar versões antigas- Não podemos tranportar versões antigas, devemos restaura-la primeiro- Existem versões

- no Development Database- versões ativas ou temporárias- são as versões correntes do objeto, que estão em alteração

- no Version Database- Versões salvas depois de release da CR- Contem a ultima versão exportada

• Ajuste antes de um Upgrade- Quando fizermos um Upgrade devemos nos preocupar com as alterações e desenvolvimentos efetuados no ambiente- Ferramenta PREPARE lista programas

- Originais não alterados- Originais com flag de repair


63

- Desenvolvidos pelo cliente- Ferramenta SPDD verifica dicionário de dados- Ferramenta SPAU faz merge dos outros objetos do repositório

• Objects Diretório- Catalogo de todos os objetos do Repositório

- Objetos da SAP- Objetos gerados pelo Cliente

- Atributos dos objetos- Tipo (PROG, DEVC, VIEW, FORM)- Development Class- Responsável- Sistema Original- Linguagem- Repair Flag- Generation Flag (objetos gerados pelo sistema, durante a customização)

- Objetos originais e copias- Originais

- São os objetos que estão que foram gerados naquele sistema- Não são produto de transporte

- Copias- Objetos que chegaram ao sistema através de transporte

- Repair- Uma cópia que foi alterada

• Workbench Organizer Tools- Relatórios com informações sobre as alterações processadas via Change Request- Permite acessar

- Objects in Request- Search for Objects in Request (SE03)

- Pesquisa objetos nas change requests- Analyze objects in request/tasks- Place objects in transport request- Unlock objects

- Objects- Modifications Monitor- Objects in Customer Namespace- Namespace info utilities

- Object Directory- Altera atributos dos Objetos, modificando tabela TADIR- Change object directory entries of objects- Change object directory entries of objects in a request- Change peston resposability for objects

- Requests/Tasks- Display transport logs- Search for request / tasks- Merge objects lists- Performa ADO import

- Administration- Set System Change Options- Display / Change namespaces


64

- Global Customizing Workbench Organizer (SE01)

- Opções podem ser ativadas para todo o sistema ou para um usuário especifico- Opções de Display Errors at Logon

- Mostra erros de transporte no sistema operacional- Check Object on request Release

- Mostra erros de sintax nos programas a serem transferidos no release da Change Request

- Consistency Check of Table TLOCK against table E071

• Diretrizes para Change Management for Development- Restringir alteração aos objetos

- Somente num sistema (DEV)- Verificar o System Change Options e Client Change Options daquele ambiente- Definir autorizações

- Nas equipes de desenvolvimento- Treina-los nos uso das Change Requests- Assinalar os Teams Leaders

- Montagem do Ambiente- Criar Development Classes para agrupar os projetos em desenvolvimento- Definir padrões de documentação- Manter versões dos objetos


65

Capitulo 19 – Change Management for Customizing

• Customizing- Business Process- Client Dependent- Usa Table Views -> virtual table que apresenta dados de varias tabelas físicas- Change requests do tipo CUST- Se preciso transportar dados de customização Client Independent, devo usar uma CR de Workbench- CR de customizing não possui lock de objetos- Podemos criar visões do IMG para projetos específicos (projeto 300 usado na aula)

- São só visões, sempre afetam todo o IMG real- O IMG é client dependent, alterações so afetam o client que estamos logados

- A opção ARC – Automatic Recording of Changes- Obriga todas as alterações no IMG a serem armazenadas numa Change Request- Opaco a nível de Client- Definido na Client Change Options

- Configuração do Client Change Options- Transação SCC4- Para Client Dependent Objects

- Modifica a tabela T000 (Tabela de Clients)- Indica se pode ou não alterar o IMG (Client Dependent Objects)- Indica se vai ou não gravar automaticamente numa Change Request

- Para Client Independent Objects- Indica se pode alterar Client Independent Customizing- Indica se pode alterar Client Independent Repository

• Transporte da Customização- Transporta linhas das tabelas- Podemos ativar log de todas as alterações efetivadas na customização

- Programa RSTBHIST- Podemos solicitar que uma Customização que não foi alterada seja transportada

- Pode servir também para o caso de ARO não estar ativa- Para isso

- Entrar na customização a ser transportada- Clicar no botão Include in Transport- Salvar

• Teste da customização- Unit Test

- Ativar alterações da Customizing Change Request em outro Client p/ ver se funciona

- Isto porque normalmente o Client de Customização não tem dados- A Change Request não é liberada, somente sua customização é copiada- Depois de testado com sucesso, libera o transporte para o sistema definitivo- A copia do conteúdo da CR é feito com a SCC1

- Só copia um CR por vez- Se houverem dados client independent a SCC1 não copia


66

- Pode copiar

- Uma task- Uma CR- Uma coleção de CR (inserir varias CR numa outra para ganhar tempo no transporte)

- System Test- Teste de toda a Customizing junta- Feito no QAS

• Release da CR- Release and Export- To Request (to new request ou to existing request)

• Update Settings- Alterações de customização em produção para coisas que não precisam ser amplamente testadas

- Taxas de imposto- Tabelas de rateio

- Relação de coisas esta na tabela CUSAMEN.SAP- Funciona apesar de termos nas Client Change Options

- Changes and Transport Client Dependent objects - No changes allowed

- Client Independent objects Changes – no changes allowed- No changes to repository and client independent customizing

- Client Role- Production

• Client Independent Customizing- composto por

- Client independent customizing object- Objetos do repositório gerados pela Customização- Ex. Matchcodes- Condition Tables- Hierarchies

- Global customazing setting- Calendários- Impressoras- Communications setting- Schedules

- Objetos do repositório- Programas e tela

- Para transportar estes objetos usar Workbench Change Requests

• Diretrizes para Change Management for Customizing- Definir políticas de Customizing

- Criar projetos no IMG- Documentar- Usar um client para toda a customização

- Restringir o acesso as CR- Somente para quem tem necessidade


67

- Criar times de projeto- Treina-los para uso da CR- Estabelecer o Lider do projeto


68

Capitulo 20 – Transport Management

• Import Queue- Podemos fazer import das CR em qualquer dos sistemas daquele Transport Domain

- Se o import não é daquele sistema, abre uma tela de logon para startar o TP naquele sistema

- Refresh da queue é feito na primeira vez que entramos na TMS naquele dia- Podemos fazer refresh manual ou schedularmos o relatório RSTMSCOL para rodar de hora em hora (ele faz o refresh quando roda)- Podemos abrir e fechar a fila (coloca END MARK) em qualquer ponto dela para limitar a qtde de CR a serem importadas

- No buffer o nome é STOPMARK- O TP pode fazer isso, mas só para o fim da fila mesmo

- TP SETSTOPMARK sid- TP DELSTOPMARK sid

- Podemos fazer import preeliminar (só de 1, mas não tira da fila)- Podemos fazer forward (para treinamento por exemplo) de uma CR

• O Import- Após import, a fila é automaticamente aberta- Possui um Expert Mode para

- Overwrite Original- Overwrite Objects in unconfirmed repairs

- Podemos fazer import preeliminar- Expert Mode

- Overwrite Original- Overwrite Objects in unconfirmed repairs- Ignore that the tranport request has already been imported- Ignore invalid transport type

- Import entre Transport Groups- Podem ser feitos para qq grupo no Transport Domain- São usados quando

- Temos conexão lenta de rede (???)- Não podemos compartilhar o diretório de transporte (S.O. de tipos diferentes)- Não podemos compartilhar por razoes de segurança

- Opaco de Import Groups: EXTRAS > OTHER REQUESTS > IN FOREING GROUPS- Restrições

- Os logs serão específicos do sistema que estamos usando- Transportes exibidos no CTO (Change and Transport Organizer) serão específicos do sistema que estamos usando- TPPARAM deve ser o mesmo para todos os Transport Groups

• Ferramentas de Monitoração- Import Monitor Mostra status da tabela TPSTAT- TP System Log (SLOG) Mostra todos os Calls para o TP e seus erros- ALOG Mostra todos os steps do Transport- Import Queue Consistency Check verifica consistência do DATA e COFILES- Transport Directory Check verifica se consegue gravar no diretório transport- RFC connection test verifica conexão RFC


69

- Existe ainda o Alert Monitor- Registra todas as ações ocorridas no TMS- O ícone é um sino no TMS

• Code Freezing- É uma técnica, uma recomendação para não deixarmos alterar código no desenvolvimento enquanto esta sendo testado no QAS

• Definição do Change and Transport Management- Definição dos canais de distribuição para todos os sistemas do Landscape- Identificar os pontos de transporte- Estabelecer técnicas de Code Freezing- Definir procedimento de verificação dos imports- Estabelecer a agenda de transporte- Definir procedimentos de Preliminary Import


70

Capitulo 21 – Advanced Transport Management

• Diretórios do Transport- ACTLOG

- Registra cada ação realizada contra a Request ou Task (criação, release, etc)- Nomenclatura: sidZnnnnn DEVZ900872

- SAPNAMES- Loga ações tomadas pelo usuário na sistema de transporte

- BUFFER- Contem o diretório do que deve ser importado

- DATA- Dados dos objetos que foram exportados- Nomemclatura: R9nnnnn.sid R900872.DEV

- COFILES- Command Files dos objetos exportados (contem os steps a serem executados)- Nomemclatura: K9nnnnn.sid R900872.DEV

- LOG- ULOG Nomenclatura: ULOG_98_1- SLOG Nomenclatura: SLOG9803.DEV- ALOG Nomenclatura: ALOG9803- Log Files: Nomemclatura: <source sid>A9nnnnn.<action sid> DEVP900872.QAS

- Contem : ação a ser realizada- Error message- end user logs- details

• Parâmetros do TPPARAM- TRANSDIR- ALLLLOG name convention do ALOG- STOPONERROR rc para stop- SYSLOG nome convention do SLOG- TESTIMPORT flag para ativar test import no consolidation- TESTSYSTEMS add change request to multiple r/3 buffers- R3TRANSPATH- RECCLIENT log para clients específicos - SAPEVTPATH

• Parâmetros do comandos TP- HELP- GO sid exibe as variáveis devem ser setadas para conexão com aquele sistema- CONNECT sid verifica se a conexão esta ativa- SHOWINFO request mostra informações sobre uma Change Request- COUNT sid qtde de Change Request para import em um sistema- CHECKIMPDP sid mostra como esta o schedulado o RDDIMPDP- SHOWPARAMS sid mostra parametrização do TPPARAM- STATUS sid informações de um sistema


71

• Parâmetros do TP para Import- IMPORT ALL <target sid> CLIENT=<client> importa todas- IMPORT <Change Request> <target sid> CLIENT=<client> Un preliminary import

- Valor do Um (U0, U1, ...)- U0 -> importa mas deixa no buffer para import definitivo- U1 -> ignora se aquela Change Request se já foi importada- U2 -> Sobrescreve os originais (da SAP)- U3 -> Sobrescreve objetos system-specific- U6 -> Sobrescreve objetos com repairs não confirmados- U8 -> Ignora restrições da Table Classification- U9 -> Ignora se aquele sistema esta travado para este tipo de transport

• Parâmetros do TP para acesso ao Buffer- SHOWBUFFER <sid> mostras as entradas do buffer- ADDTOBUFFER creq <sid> adiciona entrada ao buffer- DELFROMBUFFER creq <sid> deleta entrada do buffer- CLEANUFFER <sid> retira as entradas que já foram importadas do buffer- SETSTOPMARK <sid> colocar stop mark- DELSTOPMARK <sid> retira stop mark

• O R3Trans- Programa chamado pelo TP para fazer o transporte

- Usa o comando CreateProcess do NT- Podemos exportar dados numa versão do R/3 e importa-lo numa versão posterior- No entanto, o programa TP e o R3Trans não poder realizar transportes entre relesses diferentes do R/3

• Programas ABAP envolvidos numa transferencia- O TP roda a nível de S.O. mas precisa de programas ABAP para algumas tarefas- Cada Client tem que ter um programa de gerenciamento desta interface schedulado para rodar no R/3

- RDDIMPDP_CLIENT_xxx- Podem ser schedulados utilizando o programa RDDNEWPP

- Eles são disparados por um evento que o TP manda através do SAPEVT- Evento SAP_TRIGGER_RDDIMPDP- Ou SAP_TRIGGER_RDDIMPDP_CLIENT

- A comunicação de dados é feita através da tabela TRBAT e TRJOB- TRBAT para envio dos dados- TRJOB com o status da execução

• Seqüência de execução da transferencia- Cada fase é executada para todas as CR

- Execução por fase e não por CR- DDIC I - ABAP Dictionary Import Inactive- ACTIV - Active Dictionary, Distribution, Structure conversion, Move nametabs- MAIN I - Main Import- MC ACT - Activation of enqueue definitions- MC CONV - Enqueue Convertion- ADO I - Import of ADO


72

- LOG I - Logical Imports- VERS F - Versioning- XPRA - Execution of User Defined Activities- GENERA - Generation of ABAP programs and Screens

• TP Steps e seus logs no ALOG- E -> main export- P -> test import- H -> DD objects import- A -> DD objects activation- S -> DD objects distribution- N -> DD objects convertion- 6 -> DD objects move nametabs- i -> main import- T -> import of table entries- M -> enqueue activation- G -> generation objects do repositorio- V -> version update

• O processo de Import- TP (O.S. Level)

- TP Call (via TMS ou TP IMPORT)- TP STOPMARK -> execução automatica a cada TP Call- Processo de Import- TP CLEANBUFFER -> após a transferencia- Gravação do Log- Se RC > 8 TP aborta o processo

- Definição do nível de RC para abort esta no TPPARAM, parâmetro STOPONERROR- R3TRANS (O.S. Level)

- TP le o Command File (COFILE)- Copia o Command File para o diretório TMP- Chama o R3TRANS, que le o TMP e copia o DATA correspondente para o DataBase- Ao final R3TRANS grava log no TMP e retorn RC para TP- TP move o log para LOG- R3TRANS ainda é chamado pelos ABAP no processo de Dictionary Import

- COMUNICACAO TP <-> ABAP RDDIMPDP- Feita através da TRBAT- La TP coloca as funções a serem executadas- Trigger do RDDIMPDP feito através do SAPEVT- RDDIMPDP le a TRBAT e descobre o que deve ser feito- Chama programa RDD que executa aquela função e marca aquela entrada da TRBAT como ativa- TRJOB recebe o numero do job que esta executando a função- Ao final da função RDD, ela grava na TRBAT o RC e deleta o entrada na TRJOB- Quando todas as funções daquela tarefa estão completas, é colocado F (Finished) na TRBAT- TP monitora a TRBAT, quando esta com F copia logs p/o diretório LOG

- Se ocorreu problemas (RC > 12) TP restart RDDIMPDP (trigger) que analisa e restarta o job


73

• Logs gerados- ULOG -> log de todos os comando TP sem erros de sintax- SLOG -> atividades de transporte num sistema R/3- ALOG -> RC das fases do transporte no common directory

• TP Return Codes- 0 < rc < 16 -> max rc das transport tool- 16 < rc < 100 -> rc da tool + tp warning- 100 < rc < 200 -> tp warning- rc > 200 -> tp error

• Troubleshooting1º Alert Monitor -> tp connections, problemas de permissao, RFC2º SLOG -> tp RC3º ALOG -> Verificar Change Request que produziu o erro4º Log Files -> Verificar Log Files no S.O.

• Troubleshooting no R/3- RDDIMPDP -> esta schedulado ?- RDD* jobs -> rodaram (SM37)- Versão certa do TP ?- Espaço no diretório ?- Problemas no Share ?- Verificar entradas na TRBAT e TRJOB (SM31) contra log- Tentar ativar RDDIMPDP via trigger do SAPEVT na mão

• CleanUp- TP CHECK ALL -> arquivos que não são mais necessários ou seja, cujas entradas não- são mais necessárias em nenhum R/3 do Domain- TP CLEAROLD ALL -> baseado relatório gerado p/ CHECK (ALL_OLD.LIS), deleta entradas- Usa parms datalifetime, olddatalifetime, filelifetime do TPPARAM- SAP recomenda copiar antes da delecao


74

Capitulo 22 – Cliente Tools

• Overview- Client Copy e Client Transport Tools

- Desenhadas para substituir dados de um Client com dados de outro Client- Não desenhadas para combinar dados de diferentes Clients

- Client Data é categorizado como- Customizing Data- User Master Data- Application Data (conforme definido pela Data Table Delivery Class)

- Application Data não pode se copiada sem o Customizing Data- No transporte

- Customizing e Appl Data apagam o anterior e o substitui- User Master Data faz merge

• Tipos de copia de dados entre Clients- Local Client Copy

- Entre Clients no mesmo R/3- Remote Client Copy

- Entre Clients em diferentes R/3- Usa RFC para fazer a transferencia

- Client Transport- Entre Clients em diferentes R/3 via transporte- Dados são exportados para o Sistema Operacional e depois importados- Como é entre sistemas, é a única que pode levar Client Independent Customizing Data

- Nenhuma destas ferramentas serve para transportar programas ABAP- Estes objetos tem que ser por Change Request

• Local Client Copy- Deve ser iniciada no Client Destino- Se Client não existir deve ser criado (Client Administration > Client Maintenance)- Usar usuario SAP*/PASS para logon- Chamar transacao SCC1- Selecionar profile a ser usada

- Profile indica se copiaremos User Master Data, Customizing Data, Application Data

- A copia vai iniciar- Não logar no Client Destino durante a copia- Não logar no Client Origem durante a copia

• Remote Client Copy- Deve ser iniciada no Client Destino- Definimos profile e source RFC destination (RFC do sistema origem)- Checa a consistencia do R/3 Repository, se não forem iguais o processo aborta- Restricoes

- Não há dados no disco para copia, assim 2 copias são realmente 2 copias- Antes do release 4.5 não pode ser copiado dados Client Independent

• Client Transport- Entre R/3 diferentes


75

- R/3 destino deve fazer parte do Transport Domain- 2 etapas

- Extract dos dados do client no Source System- Administration > Client Admin > Client Transport > Client Export- Selecinar os dados a serem exportado (via profile)- Vai usar o TP para fazer o expor- Pode gerar até 3 arquivos- RT<numero> - client dependent data- RO<numero> - client indepentend data- SX<numero> - SAP Script texts

- Import dos dados do Client no Target System- Entrar na TMS e fazer import

- Import All não importa Clients - O Client aparece como <SourceSid>KO<numero> e <SourceSid>KT<numero>- Devemos importar primeiroo KO (independent) depois o KT (dependent)

- Após importe rodar SCC7 (Post Process Import)

• Profile Selection- Todas são fornecidas pela SAP (não posso criar mais)- Dá para salvar a selecao de copia feita como Variant para uso posterior- Profile para User Master Record

- SAP_USER -> so User Master Record, sem Initialize and Recriate- Outras Profiles

- Todas transportam Customization Data e todas tem Initialize and Recriate- SAP_CUST -> só leva Customizing- SAP_UCUS -> leva Customizing e User Master Data- SAP_UAPP -> Leva Customizing, User Master Data e Application Data- SAP_ALL -> Leva tudo, até Variants- SAP_CUSV -> Leva Customizing e Variants- SAP_UCSV -> Leva Customizing, Variants e User Master Record- SAP_EXBC -> Leva Customizing, Variants, Client Independent e UMD- SAP_EXPA -> Leva Customizing, Variants, Client Independent, UMD e APPL Data- SAP_EXPC -> Leva Customizing, Variants e Client Independent

• Number Ranges no Client Copy- Todos os dados no Client Destino são apagados antes da copia- Number Ranges são deletados - ??? não entendi

• System Requirements- Tempo

- Pode levar horas- Consistencia do dados

- Não de logon no Client Origem (recomendavel) nem no Destino (proibido)- Espaco do DB

- 300 a 500 MB para Customizing- Gbytes para Master e Appl Data- Alguns DB permitem analise antes da copia

• Monitoracao e Logs- Logs


76

- Transport Logs -> SE01- Local ou Remote Copy -> Client Admin > Copy Logs

- Dados de controle estao na view V_CCCFLOW- Contem runtime, status, numero de tabelas já copiadas, nome da tabela sendo copiada

- Logs estao no sistema operacional- arquivos CC<numero>.<SourceSID>

- Copia pode ser monitorada pela transacao SCC3

• Monitoracao e Troubleshooting- Em caso de erros

- Verificar Logs- Verificar System Log -> erros do DB que causaram erro na copia

- Restart- É possivel e é o default- Se a copia a ser restartada for novo deve ser usado- Se não Restart > New Start

- Para evitar problemas na copia, verificar espaco antes- Client Copy não tranporta objetos da Development Class $TMP

• Client Delete- Para deletar Administration > Client Admin > Special Function > Delete Client- Para melhorar o processo de copia de um Client, isto pode ser feito antes

- É bom principalmente por causa das Cluster e Pool Tables- A partir do release 3.0E deleta tambem o SAPScript data e Batch Inputs do Client- É melhor ativar delecao em Background

• Client Compare- Transacao SCU0- Usada para comparar Customizing Settings entre Clients- Os Clients podem estar no mesmo sistema ou em outro sistema- Usa conexao RFC- Podemos comparar

- Um projeto do IMG- Todo o IMG- SAP Reference IMG- Uma Change Request - Um Application Component- Fazer selecao manual de objetos

- Como SCU0 trabalha- Mostra um overview das tabelas que vai comparar- Compara- Cria a lista de diferencas- Para exibir as diferencas, duplo clique no objeto

- Resultados da listagem de comparacao- Branco -> sem diferencas- (E) -> tabelas/views identicas, diferencas de estrutura- M -> tabelas/view não idênticas

- (M) -> tabelas/view não identicas, diferancas na estrutura- F -> Comparaca impossivel

• Ajuste de Customizing Objects__________________________________________________________________________________________________________


- Transacao SM30- Ajusta a maior parte dos objetos (view e tables)- Se o objeto não pode ser mantido via SM30, entao não há forma de ajusta-lo- Ajusta objetos

- Por linha- Pelo campo que selecionamos com o Cursor- Por coluna (só serve para colunas adcionadas, não replace dados já existentes)

• Protecao de Client Copy / Client Compara- Evita Client Copy ou Client Adjustment- Path Adminitration > Client Admin > Client Maintenance - Niveis de protecao

- 0 -> sem restricao- 1 -> No Overwriting -> não pode ser overridado pelo programa de Client Copy- 2 -> No Overwriting and No External Availability- -> sem copia e sem compare- -> sugere-se para ambiente de producao

- Para efetivar esta definicao precisa de autorizacao S_CTS_ADMIN

• Outros objetos de autorizacao necessarios para Client Tools- S_TABU_CLI -> Client Independent Data Maintenance- S_TABU_DIS -> Generica Data Maintenance- S_CLNT_IMP -> Data import during Client Copy- S_DATASET -> File Access- S_USER_PRO -> Profile Maintenance- S_USER_GRP -> User Groups- S_TRANSPRT -> Change and Transport Optimizer

Apostila II


78

Capítulo 1 – Preface

• Nothing to do

Capítulo 2 – R/3 System Management (Start and Stop)

• Serviços ativados no NT- SAP<sid>_<instance_number> -> SAPDEV_01 SAPSQA_02- OracleService<sid> -> OracleServiceDEV OracleServiceQAS- SAPOSCOL -> só um por computador- Todos com Automatic Start no NT

• Startando o R/3- Logar no NT como <sid>adm- Ativar o R/3 via SAPR Service Manager

- O SAP Service Manager envia mensagen via Named Pipe para SAP<sid>_<instance_number>- SAP<sid>_<instance_number> le Start Profil \\SAPGLOBALHOST\sapmnt\<sid>\SYS\profile - SAP<sid>_<instance_number> ativa o banco se ele estiver fora do ar- SAP<sid>_<instance_number> ativa Message Server e Dispatcher- Dispatcher le Default Profile e Instance Profile e cria WP e Gateway- WP se conectam com o Banco

- Para ver o Trace do Start -> SAP Service Manager > View Trace- Podemos ativar Oracle via SAPDBA, Oracle Instance Manager ou Oracle Server Manager- Programas STARTSAP e STOPSAP ativam e desavitam o R/3 via command prompt

• Parameter Read Sequence- Ordem

- Registry do NT- NT ystem Environment Variables- C Source- Default Profile- Instance Profile

- Podemos ver replace de parametros no RSPFPAR- SAP Service le

- Default Profile- Start Profile

- O R/3 Kernel (DISP+WORK) le- Default Profile- Instance Profile

- Para alterar Default Profile precisa tirar R/3 e o Serviço

- Para alterar Instance Profile precisa só tirar o R/3

• Logs e Trace do Start do Oracle- Log de Start, Stop e erros do DB


79

- C:\Oracle\<sid>\SAPTRACE\BACKGROUND\<SID>ALRT.LOG- Traces do proprio Oracle

- C:\Oracle\<sid>\SAPTRACE\USERTRACE\ORA<no>.TRC- Se usarmos SAPDBA temos ainda os logs

- No SAPREORG- No SAPCHECK- No SAPBACKUP

• Logs e Trace do R/3 via NT- Estao no Event View do NT

- System Log -> mensagens produzidas pelo R/3 o Oracle e enviadas ao NT- Application Log -> eventos no R/3 ou Oracle e retornadas pela aplicacao- Security Log -> Logon, Logoff, acesso a arquivos, etc

• Logs e Traces no R/3- No diretorio \\SAPLOCALHOST\SAPLOC\<sid>\<instance_number>\WORK- Definido pelo parametro rdisp\trace na instance profile- Pode ser 0 (só erro), 1 (erro e warning), 2 (erro e short trace), 3 (erros e traces)- Grava

- STDERR1 - database log- STDERR2 - Message Server Log- STDERR3 - Dispatcher Log- SAPSTART.TRC - trace do SAPNTSTARTB- SAPARTRT.LOG - startup log e trace do database, dispatcher e message server- dev_ms - trace do Message Server- dev_disp - trace do Dispatcher- dev_w0 - trace file dos WP

• Diagnostico de problemas no Startup do R/3- Possiveis problemas

- SAP Service Manager não consegue contatar o servico- O serviço esta ativo ?

- Serviço não start- Password do usuario do serviço esta correta ?- Executavel esta no disco ?

- Database Statup fails- Variaveis ambientais estao corretamente definidas ?- Database esta corrompido ?- Trocaram o nome dos Data Files e não informaram ao Oracle ?

- R/3 falha ao ativar- Os shares NT necessarios estao feitos ?- Servico esta corretamente configurado (usuario esta correto) ?- Há problemas de permissao no File System ?- Há erros de configuracao no TCP/IP ?

• DownTime do R/3- Planejado

- Troca de parametros das Profiles- Upgrades- Manutencoes no sistema ou no database

- Não Planejado __________________________________________________________________________________________________________


- Falha de hardware- Problemas de configuracao

• Antes de desativar R/3- Verificar Bach Inputs schedulados (SM35)- Verificar se existem jobs batch rodando (SM37)- Verificar updates em progresso (SM13)- Enviar mensagem aos usuarios (SM02)- Verificar usuarios logados (SM04 ou AL08)- Verificar conexoes externar (SMGW)

• Desativando o R/3- Para encerrar o R/3 (usuario R/3 com poder de administracao)

- Via CCMS- Via SAP Service Manager

- Para encerrar o Banco (usuario NT <sid>adm)- Via Oracle Instance Manager- Via Oracle Server Manager (comando svrmgr30)- Via SAPDBA

• Backup Offline: Database Reconnect- Para backup offline configurar

- rsdb/reco_trials = n -> quantas vezes WP irao tentar se reconectar ao DB- rsdb/reco_sleep_time = m -> tempo entre tentativas

- Desta forma buffer R/3 não será limpo

• Causas de erro no Stop do R/3- Banco não quer sair

- Database fazendo rollback (pode demorar se o commit esta longe)- Backup online esta rodando (só sai depois de acabar)- Archiver stuck (precisa salvar o archive antes)

- Se não for nada assim obvio, verificar SM21 e Alert File

Capítulo 3 – Installation Check

• Windows NT - Pre-Requisitos

- Hardware - Checar via Winmsd ou Windows NT Diagnostics- Certificado pela SAP


81

- Numero de processadores- Capacidade de Memoria- Disk Space

- Checar via NT Disk Administrator- Formatar discos com NTFS

- High Availability- Software

- Windows NT em Ingles- Service Pack- Resource Kit- Softwares Adicionais

- Rede - TCP/IP- Checar TCP/IP via Control Panel

- Configuracao de Hostname- Ver hostnames no WINNT/SYSTEM32/DRIVERS/ETC/Hosts (case sensitive)- Ver nomes NetBios no WINNT/SYSTEM32/DRIVERS/ETC/Lmhosts- Se houver 2 placas de rede, os nomes devem ser diferentes

- Conceito de Dominio- Conceito R/3 de seguranca

- Front-ends - Backups

- Do Registry via RDISK ou NTBACKUP- Criar Repair Disks- Para aumentar disponibilidade do sistema, podemos criar 2 particoes de boot, ambas com Window NT

• Oracle- Pre-Requisitos do Database

- Versao compativel com o sistema operacional- Database name deve ser identico ao SID do R/3- Name conventions dos diretorios usado pelo R/3 no Oracle não devem ser modificados- Online Redo Log Files devem ter mirror- Restricoes do Oracle

- Redo Log Files, Archive Files e Data Files não podem ficar no mesmo Disco Fisico

- Pre-Requisitos das Profiles- INIT<sid>.ORA -> profile do Oracle, vem com valores default- Do NET 8

- LISTENER.ORA -> só no Servidor, configura o Listener- TSNAMES.ORA -> só no Client, strings de conexao para os DB Servers- SQLNET.ORA -> só no Client, informacoes administraticas sobre conexões

- PROTOCOL.ORA -> Só para UNIX- INIT<sid>.SAP

- Configura backups (BRARCHIVE e BRBACKUP)- INIT<sid>.DBA

- Configura SAPDBA

• Estrutura de Diretorio__________________________________________________________________________________________________________


- No Servidor - ORACLE_HOME ORANT

- BIN- DATABASE- RDBMS80

- SAPDATA_HOME ORACLE/<sid>- SAPCHECK- SAPREORG- SAPBACKUP- SAPTRACE- SAPARCH- MIRRLOGA / B- ORIGLOGA / B- SAPDATA

- No Client - ORACLE_HOME

- NET80- RDBMS80- NLSRTL31/DATA- NLSRTL32/DATA- NLSRTL33/DATA

• Variaveis Ambientais- ORACLE_SID = sid- ORACLE_HOME = c:/orant- SAPDATA_HOME = c:/oracle/<sid>- SAPDATAn = c:/oracle/<sid>/sapdatan

• Database Security- Trocar Password do

- SYSTEM- SYS- SAPR3

- Backups- Regularmente

- Modalidade do Banco- Archivelog

• Performance- Manter PSAPBTABD e PSAPSTABD em discos separados- Manter PSAPBTABI e PSAPSTABI em discos separados- Não colocar indices e dados no mesmo disco fisico- Não usar RAID 5 para online redo log file, SAPARCH ou PSAPROLL

- A caracteristicas destes arquivos e gravacao e leitura sequencial, o que não se presta às caracteristicas do RAID 5

• System Name- Único no landscape- Sempre em Uppercase- Comecando com letra- Identico ao do Database- Existe uma serie de nomes reservados


83

• Memory Management on Windows NT- Zero Administration Memory Management- Definir memoria a ser data ao R/3 no parametro

- PHYS_MEMZSIZE- Inicialmente, a Extended Memory será setada para este valor- Se mais memoria for necessária, serao alocados metade deste valor até que se atinja em/max_size_MB ou se esgote o espaco de swap

• Dominio SAP e PDC e BCD do Windows- Por razoes de segurança, não colocar o banco ou uma instancia do R/3 no PDC ou BCD

• Dominio NT e grupos de autorizacao- usuarios

- <sid>adm- SAPService<sid> não pode logar interativamente- Não troca a password

- Local Group para R/3- SAP_<sid>_LocalAdm

• Shares do NT- SAPTRANSHOST\sapmnt\trans -> diretorio de transporte- SAPGLOBALHOST\sapmnt -> diretorio system wide- SAPLOCALHOST\saploc -> Instance Directory

• Name Resolution- Existem nome TCP/IP e NetBios- TCP/IP -> no Control Panel > Network > TCP/IP > Protocol DNS

- Normalmente em letras minusculas- Usa arquivo WINNT/SYSTEM32/DRIVERS/ETC/Hosts

- Computer Name -> My Computer- Normalmente em letras maiusculas- Usa arquivo WINNT/SYSTEM32/DRIVERS/ETC/Lmhosts

- Todas as referencias do R/3 são para o Host Name TCP/IP- O SAPGLOBALHOST é escrito em maiusculas, mas é host TCP/IP

• Sockets Portas TCP/IP- Configurada no arquivo WINNT/SYSTEM32/DRIVERS/ETC/Services

- 3200 - dispatcher - sapdp 32<instance_number>/tcp- 3300 - gateway - sapgw 33<instance_number>/tcp

- 3600 - message server - sapms 36<instance_number>/tcp- no diretorio SAPGLOBALHOST/<sid>/EXE/RUN existe a ferramenta SAPNTCHK e SAPSYCHK que validam os seting do TCP/IP (hostname, IP address, service entries)

• Setup do Transport Management- Configuracoes

- Transport Domain- Transport Group- Routes

- É bom um Backup Domain Controller para poder alterar as definicoes quando o Domain Controller esta fora do ar


84

- Dentro de um Transport Domain, as configuracoes do TPPARAM devem ser iguais- Só o TRANSDIR pode ser diferente

• Verificacao da Instalacao- NT Event Viwer- Kernel Patch Level (SM50)- Installation Consistency (SM28 ou SICK)- Correct Hostname (SM51) case sensitive- Buffer Syncronization (ST02)- Activate Performance Monitor: report RADDBDIF- SAP Lincense: SAPLICENSE- Trocar Password SAP* e DDIC- Remote access using SAPROUTER- Imported Hotpackegs (SPAM)- Imported Languages (SMLT)

• Backup pos instalacao- S.O. e o seu Registry- Disk Configuration (NT Disk Administrator)- Diretorios do Oracles

- ORANT- ORACLE

- Diretorio do R/3- \usr\sap- \usr\sap\trans- <homedir>\ do <sid>adm

- O database- SAPDBA ou CCMS ou BRBACKUP e BRARCHIVE

Capítulo 4 – R/3 Spool and Print

• Outputs- Podem ser impressoes, fax, EDI- Tipos de impressao

- Immediate Printing- Delayed Printing

- Spool interno do R/3 -> para compatibilidade com diversos sistemas operacionais- Tipos de objetos no Spool

- Spool Request -> dados a serem impressos, não formatados para impressor especifica


85

- Output Request -> dados em formato device specific- -> um spool request pode gerar varios output request, cada um com- atributos especificos- -> usar uma impressora de tipo diferente em relacao ao qual o output- request foi geradao pode ocasionar erros de impressao

- TemSe- Arquivos onde são armazenados os Spool Requests- Contem

- Origem do Request- Data de Criacao- Nome do Criador- Nome Logico da Impressora- Numero do Client

- Parametro rspo/store_location define o local do spool- G -> no disco, Global Directory- DB -> no Oracle

• Spool Work Process- Responsavel por recuperar os TemSe e gerar as saidas device-specific

- Converter os comandos genericos de impressora em comandos especificos- Colocar sequencias de inicializacao e encerramento- Converter o character set interno de armazenamento para o da impressora

- Um Spool Work Process sempre manipula apenas um spool por momento- Uma instancia que roda um Spool WP é chamada de servidor de spool- Depois de convertido, tranfere para o spool do S.O.

• Output Devices- Definicao da Impressora para o R/3- Feita usando a transacao SPAD- Aponta para o Device Type daquela impressora, que contem

- Character set do device- Printer Driver para formatar o SAPScript- Comando device-specific para converter comandos genericos R/3

• Local Printing- Data Transfer do R/3 para o sistema operacional é chamado de Access Method- No metodo Local Printing se usa o Local Method

- É o metodo mais facil e confiavel de transferência

- Usado quando o R/3 e o S.O. de spool estao na mesma maquina- A impressora não precisa estar nesta maquina, apenas seu share- Para Windows NT usar Access Method C

- Vai passar os dados ao sistema operacional usando API do Win Nt

• Remote Printing- Usa Metodo de Acesso remoto- É mais lento e só deve ser usado em ambiente de LAN- Em sistemas operacionais que possuem Daemon, o R/3 envia os dados para este daemon (como o lpd do Unix) que passa ao sistema operacional

- A impressora pode ser local ou remota a este sistema operacional, ela tem apenas que estar definida nele


86

- Em Windows NT usar o SAPLPD que é um daemon com a mesmo funcao do lpd Unix- Impressoras de rede (via JetDirect)

- Tambem podem receber impressoes do R/3- Metodos de acesso remoto em Windows NT

- Network Printer -> U- Via SAPLPD -> S

• Transacao SPAD- Vamos focar a administracao simples usando SPAD- Tarefas

- Criacao, modificacao e transporte de Output Devices- Criacao, modificacao e delecao de Spool Servers- Listagem de metodos de acesso disponiveis para uma impressora- Listagem de destination hosts usados na definicao de impressoras remotas- Manutencao dos TemSe

• Definicao de impressoras locais- Output Device -> nome da impressora no R/3 (case sensitive)- Short Name -> nome curto- Device Type -> device type- Spool Server -> o nome da instancia do Spool WP- Host Name -> nome no servidor acima- Host Printer -> nome da impressora usado no S.O. case sensitive- Device Class -> classe, p.e. impressora ou fax- Access Method -> access method

• Definicao de impressoras remotas- Todos os anteriores mais- Destination host -> nome do servidor de destino (tem que estar na Hosts do servidor)

• Frontend Printing- É a impressao de dados na impressora do proprio PC- Quando solicitado, o sistema automaticamente aciona o SAPLPD- O processo de spool é realizado no Dialog WP o que pode causar problemas de performance- Usa metodo de acesso F

• Definicao de Fronend Printing- Usar device tupe SWIN- Usar Host Printer __DEFAULT

- Vai imprimer na impressora default do Windows daquela maquina- Cuidado, se não for Windows, vai procurar uma impressora com exatamente este nome

• R/3 Logical Spool Server- Nova camada na arquitetura do Spool- Permite enderecar Spool Server como um nome virtual- Depois assinalamos o nome real- Vantagens

- Spool server switchover -> troca do spool server facilmente (manutencao p.e.)- Facilidade para transportar a arquitetura de spool para outro sistema


87

- Protecao quanto a falhas no servidor- Load balancing entre spool servers

• Definicao de Logical Spool Server- System Name -> Logical spool server name - Logical Server -> é um box para marcar, signigicando que o servidor é logico- Mapping -> especifica o nome do spool server real

• Transporte de Impressoras- Definido na SPAD- Permite transportar toda a arquitetura

• Manuseio de Spool Request- Via SP01- End user podem

- Display e delete de seus proprios spools- Trocar atributos de seus proprios spools- Imprimir seus proprios spools- Não precisam de autorizacao especial para isto

- Administradores podem- Checar consistencia no spool- Realizar spool maintenance- Precisam de autorizacoes adicionais

• Delecao de Old Spools- Via SPAD

- Somente para o Client no qual estou logado- Atraves do relatorio RSPO0041

- Informar- Expiration date- Minimum age- Target Client

- Devemos schedula-lo para rodar periodicamente

• Spool Consistency Check- Via SPAD- Atraves do relatorio RSPO0043

- Release locks after __ minutes (30)

• Spool Problem Analisys- Se gerou a impressao e contem erros

- A impressora esta correta ?- A definicao da impressora esta correta ?- O defice type esta correto ?

- Se não gerou a impressao- Se criou o spool request

- E esta em WAIT- Servidor R/3 está Down ?- O Spool WP está busy ?

- E esta em COMPL/ERROR


88

- Stuck in host spooler ?- Destination host unreachable ?- SAPLPD not Running ?- Printer Offline ?

- E esta em outros estados- Request não foi submetida com Print Immediately ?

- Se não criou o spool request - Falta de autorizacao- Problemas na aplicacao- Problema de basis (ver dumps)

• Autorizacoes- S_SPO_ACT

- Define que acoes podem ser tomadas num spool reques- Listar, imprimir, redirecionar, deletar

- S_ADMI_FCD- Permite tarefas de administracao como criacao de output devices, manutencao de device types, administracao dos TemSe

- S_SPO_DEV- Limita acesso a impressoras pelo nome

- S_SPO_PAGE- Numero maximo de paginas que um usuario pode imprimir numa impressora- Só funciona se rspo/auth/pagelimit = 1

Capítulo 5 – Output Management

• Device Pool in R/3- Agrupa multiplos device num único nome- Pode ser usada para

- Enviar o mesmo output para todos os dispositivos do pool- Enviar o output para 1 dispositivo de acordo com Load Balance

- Tambem pode ser usado para criar nome logicos. Neste caso o pool vai conter apenas 1 device. Permite ao administrador trocar o nome do device sem grandes traumas- Para definir um Device Pool

- Na SPAD configurar metodo de acesso P- Depois escolher botao Device Pool e definir as impressoras deste pool- Definir ainda se output será enviado a todas as impressoras ou só a uma delas

• External Output Management Systems (OMS)- Para R/3 External OMS são sistemas de impressao em grandes e complexos landscapes


89

- Para comunicacao com External OMS R/3 fornece interface CCMS-XOM e o API é o XOM-API- Facilidades fornecidas

- Comand Line interface- RFC Callback permite OMS informar status dos output request e output devices ao R/3- Polling mechanism permite ao R/3 perguntar ao OMS status dos outputs- Adcionals Command Line que implementam queries dos outputs ou cancelamento deles

• Real OMS e Logical OMS- Definidos através da SPAD > External Administration- ROMS -> external OMS

- define caracteristicas do OMS- se suporta polling, RFC CallBack, cancelamento de outputs

- LOMS -> grupo particular de output devices do OMS- LOMS é definida sobre um ROMS- Define como aquele grupo de output devices trabalha (se eles tem RFC Callback p.e.)- 1 ROMS pode ter varias LOMS

• Definindo ROMS e LOMS e OMS Devices - ROMS

- Principais configuracoes- Definir Nome, Descricao - Definir Job Status -> se suporta Query, Delecao, Polling, Callback- Definir Device Status -> se suporta Query ou Callback- Definir Reconfig Request -> de quanto em quanto tempo atualiza configuracao

- LOMS - Principais configuracoes- Tasking Target -> para que server responder- Callback Targe -> para que server responder- Command Group -> comando a ser usado no External OMS- Command Path -> caminho do comando

- OMS Device - Principais configurações

- Output device (nome R/3), Device Type, Spool Server, Logical OMS- Host Printer -> nome real da impressora no OMS- Device Class -> impressora ou Fax- Access Method -> E para External OMS

• Metodos de Acesso e Classes- Classe de Impressoras e de Spool Servers

- P -> Production- V -> High Volume- D -> DeskTop - T -> Test- Definida via SPAD

- > Output Devices > Edit Classification- > Spool Server > Server Class

- Impressoras de uma classe deve ser alocada para spool server de mesma classe- Se não bater, R/3 deixa alocar, mas emite warning avisando

- Sugestao de uso de metodo de acesso__________________________________________________________________________________________________________


- P -> Local (C,L) - - Pool (P) ExtOMS (E)- V -> Local (C,L) Remote (U,S) - Pool (P) ExtOMS (E)- D -> Local (C,L) Remote (U,S) FrontEnd (F) Pool (P) ExtOMS (E)- T -> Local (C,L) Remote (U,S) FrontEnd (F) Pool (P) ExtOMS (E)

• Alternate Spool Server- Posso usar Alternate Spool Server para Load Balancing- Pode trabalhar com Logical Spool Servers e Real Spool Servers- Algoritmo é recursivo, ou seja, pode enderecar o alternate spool server de um alternate spool server- Para isso

- Na SPAD > Spool Server - Marcar Non-exclusive Spool Server- Definir Alt Server

- Selecao é feita com base no server que tem menor numero de requests na fila

• Caracteristicas Especiais de um Output Device- Via SPAD > Attribute Screen

- Sequential Request Processing- Garante que os spool serao encaminhado ao host na ordem que foram gerados- Reserva temporariamente um Spool WP para isso- Parametro rspo/global_shm/job_list define o tamanho maximo da internal queue que pode ser gerada por este processo

- Se esta exceder este tamanho, usa outro Spool WP- Pode impactar performance porque diminue o numero do Spool WP disponivel

- No Longer Ask for Print Request in Host Spool- Impede que o R/3 acompanhe o andamento do spool no host system- Melhora performance, especialmente se o host não é local- Varios parametros de profile

- rspo/tcp/....- rspo/lpq/....

- Monitoring Using Monitoring Infrastructure

- Coloca a impressora no CCMS Alert Monitor- Impressora fica sendo monitorada pelo Alert Monitor

- Fica na R3Services Spool Devices- Usar só para impressoras criticas, porque consome memoria

• Definicao de Impressoras Não Standard- Criar via COPY de uma impressora parecida

- SPAD > Utilities > For Device Type > Copy Device Type- Principais caracteristicas que podem ser alteradas

- Character Set- 2 fases; primeiro criamos um novo Character Set e depois o associamos ao device- Novo Character Set deve ter numeracao entre 9000 e 9999- Se possivel é recomendado copiar um Character Set parecido e alterar- Cada Character do Character Set tem nome, numero e valor hexadecimal

- OTF Driver- Nome do driver usado para converter formato OTF em formato do device

- Print Controls- Controles para tipo de fonte, line spacing, bar codes- Copiar, modificar e assinalar


91

- Usar nomes comecando com Z- Format

- Tipos de papel suportados pelo Device- Letter, DINA4

- Format Actions- Define sequencia de caracteres para END OF PAGE; END OF LINE; 6PI; PRINTER INITIALIZATION; END OF PAGE- Copiar, modificar e assinalar (via SPAD)

- Page Format- Define dimensoes da pagina

• Analise de problemas- SPAD > Utilities > For test data permite geracao de spool para testar impressora- Pode-se exibir tela em Hexa para debug

• Message Control Overview- Message Control é usado por modulos funcionais- Message Type BA00 é usada para Order Confirmation no SD- Na Transacao VK02 podemos ver sua definicao- Esta mensagem pode gerar impressao imediata de Sales Order ou quando rodar o relatorio RSNAST00 (Time Options 1 ou 2)- Podemos ainda especificar na VK02 Transmission Midia (1 é printout, poderia ser FAX)

• SAPConnect- Solucao para EDI da SAP- Address Format suportados: FAX, STM-400, SMTP e SAPOffice- Conexao entre sistemas R/3 é suportada sem outros produtos, caso contrario precisa de External Adapters- SAP proporciona conexao com Microsoft Exchange Server, que se comunica com X.400, Internet e outros

- Isto pode viabilizar comunicacao com estes ambientes- Para configurar SAPConnect

- Definir Node -> transacao SCOT- Definir RFC Destination and User -> transacao SM59

- Usuario da conexao deve ser do tipo CPIC- Deve ter autorizacao S_A.SCON

- Definir Address Areas -> transacao SCOT

Capítulo 6 – Database Administration Oracle

• Nothing to do


92

Capítulo 7 – DataBase Fundamentals

• Oracle Review- Dedicate Shadow Process -> agentes do Oracle- Shared Process -> tasks de gerenciamento do Oracle

- DBWR -> no Checkpoint grava blocos alterados da SGA para disco- -> gravação assíncrona- LGWR -> grava dados do online redo log buffer para online redo log files- -> gravação síncrona- ARCH -> copia dados do online redo log file para archive- -> bancos de produção devem rodar em ARCHIVELOG mode- -> devem ter ainda log_archive_start=TRUE no INIT<sid>.ORA- -> copia archive p/ log_archive_dest=path do INIT<sid>.ORA (default SAPARCH)- -> template fname log_archive_format=aaa% do INIT<sid>.ORA- -> falta de espaço para copiar archive pode causar stuck do Oracle- CKPT -> sincroniza DB- PMON -> gerencia usuários, detecta deadlocks- SMON -> gerencia instancia

- É recomendável mirror de Control File e Online Redo Log File- SGA é composta por


93

- Shared Pool - > contem a Shared SQL Area, onde estão os statements SQL executados - Database Buffer Cache- Redo Log Buffer

- Work Process se conectam com user SAPR3- Oracle Start

- Nomount -> aloca SGA, abre traces, aloca processos, cria instancia- Mount -> abre control files para conhecer a estrutura do banco- Open -> abre datafiles e online redo log files e executa recovery se necessário

- Oracle Shutdown- Normal -> espera logoff de usuários e encerra o banco; não permite novos logons- Immediate -> Apenas o comando corrente é executado; rollback dos outros- Abort -> encerra o banco imediatamente; próximo start fará recovery

• Tablespace Convention Name- PSAP<tablespace_name>_<extencao>- Name convention é utilizada pelo SAPDBA e outras ferramentas

- Alem disto, facilita a determinação de problemas- SAP recomenda nunca mudar

- TableSpaces- Do usuário SYS ou SYSTEM

- SYSTEM Oracle Dictionary- PSAPROLL Oracle Rollback- PSAPTEMP Oracle Sort Process

- Do usuário SAPR3- Todos tem extensão D ou I- PSAPELxx SAP Environment Load Basis- PSAPESxx SAP Environment Source Basis- PSAPLOAD SAP Load Basis

- PSAPSOURCE SAP Source Basis- PSAPDDIC SAP Dictionary Basis- PSAPPROT SAP Spool Applications- PSAPCLU SAP Cluster Tables Applications- PSAPPOOL SAP Pool Tables Applications- PSAPBTAB SAP Transaction Data Applications- PSAPSTAB SAP Master Data Applications- PSAPDOCU SAP Documentacion Applications- PSAPUSER1 Customer Tables Applications

• Estrutura do Diretório- Não esquecer de colocar os Control Files em pelo menos 3 lugares diferentes- ORANT

- DATABASE profiles- INIT<sid>.ORA -> Oracle- INIT<sid>.DBA -> SAPDBA- INIT<sid>.SAP -> BRARCHIVE e BRBACKUP

- BIN executáveis- ORACLE

- SAPARCH archives


94

- SAPDATA data files- SAPBACKUP BRARCHIVE, BRBACKUP, logs- SAPREORG logs da SAPDBA e diretório de compressão para reorganização- SAPCHECK logs da SAPDBA para –next, -check, -analyze- SAPTRACE Oracle Alert File (no subdir BACKGROUND)- ORIGLOGA Online Redo Log files- ORIGLOGB .- MIRRLOGA .- MIRRLOGB .

• Variáveis ambientais- ORACLE_HOME -> aponta para o C:\ORANT- SAPDATA_HOME -> aponta para o C:\ORACLE- Usuário Oracle do S.O. -> <sid>adm- -> ORA<sid>

- precisa das variáveis- ORACLE_SID=<sid>- DBA_ORA_TNSNAME=<sid>

• Usuários do O.S. e do Database- O.S. User

- <sid>adm grupo ORA_<sid>_DBA conecta INTERNAL com full control- SAPService_<sid> grupo ORA_<sid>_OPER conecta INTERNAL com restricted DBA

- Database User- INTERNAL (SYS) full control- OPS$<sid>adm full control- OPS$SAPService<sid> restricted database administration- Usuário OPS$<user_name> pode conectar no Oracle apenas com a autenticação do S.O.

- OS_AUTHENT_PREFIX=OPS$ do INIT<sid>.ORA

- Para usar SAPDBA basta autorizações de OPER

• Database Roles e Users- Database Role

- SYSDBA -> DBA- SYSOPER -> start, shutdown e backup, sem acesso a tabelas- SAPDBA -> para o SAPDBA –check, -checkopt, -analyze, -next, -backup

- Database User- SYS -> acessa todas as tabelas- SYSTEM -> acessa todas as tabelas, menos a DDIC- SAPR3 -> acessa todas as tabelas do R/3

- Connect Request- INTERNAL -> conexão dependente so S.O.- -> se usuário pertence ao grupo DBA do S.O., tem direitos de SYSDBA- -> se usuário pertence ao grupo OPER do S.O., tem direitos de SYSOPER

• Senha SAPR3- WP tenta conectar como SAPR3 senha SAP- Se não consegue usa OPS$SAPService<sid>- Com este privilegio le a tabela SAPUSER com a password do SAPR3


95

- Conecta com usuário SAPR3 e a senha descoberta- Para isso precisa da

- REMOTE_OS_AUTHENT=TRUE na INIT<sid>.ORA

• NET 8 - ou SQL*NET- Conecta usuários Oracle via TCP/IP ou IPC- Arquivos de configuração (ORACLE_HOME/NET80/ADMIN)

- Devem existir no DB Server e no R/3 Application Server- TNSNAMES.ORA contem a relação de serviços de banco disponíveis na rede- SQLNET.ORA configuração do SQL*NET e parâmetros de logon e trace

- Só existe no DB Server- Deve existir um listener rodando, sem ele as conexões são recusadas- Utilitário LSNRCTL80 é usado para start e stop do listener, bem como verificar conexões SQL*NET- LISTENER.ORA DBs Oracle para o qual o Listener deve atender solicitações

• Monitoring do Database- DB16 -> Database main alerts- DB12 –> Backup log monitor- DB02 -> Estado da memória e dos objetos do Database- ST04 -> Carga e configuração do Database- DB14 -> Log das Database Administration Actions

• Parâmetros do INIT<sid>.ORA- control_files path- db_block_buffers > 9000- db_block_size 8192- db_files 254

- db_file_multiblock_read_count 8- log_archive_start true- log_buffer 327680 - 1048576- log_checkpoint_interval 30000000000- log_checkpoint_timeout 0- max_rollback_segments > rollback_segments- open_cursors 800-2000- optimizer_mode choose- processes > R/3 WP + 20 e > 80- rolback_segments R/3 WP / 4 e >= 10- row_cache_cursors 300 - 1500- sessions > processes e >= 96- shared_pool_size 50Mb a 300 Mb- sort_area_retained_size 262k a 500k- sort_area_size 2097k a 2500k- timed_statistics true


96

Capítulo 8 – Backup Strategy

• Por que backup- External Factors fogo- Phisical Errors hardware- Logical Errors delecao indevida

• Diminuindo o Risco de Perda de Dados- Soluções de Mirror

- Data Files -> Can be mirrored hardware- Online Redo Log Files -> Must be mirrored by the database- Control Files -> Must be mirrored by the database- Offline Redo Log Files -> Should be mirrored using hardware

- Prevenção de problemas- Logical Data Check

- Verificação dos blocos do database a procura de inconsistências- Phisical Data Check

- Verificação das fitas de backup a procura de data checks


97

• Tipos de Backup- Offline

- Backup com o banco fora do ar - Copia todos arquivos: Profiles, Control Files, Data Files, Online Redo Log Files- Para maior garantia, devemos fazer backup dos offline redo log files neste mesmo momento

- OnLine- Backup com o banco no ar- Copia todos arquivos: Profiles, Control Files, Data Files- Causa uma redução da performance do sistema enquanto roda- Só é consistente quando aplicado em conjunto com os Log Files gravados durante o processo de backup (as tablespaces podem estar em pontos diferentes)- O BRBACKUP da um switch para um novo online redo log file ao final do backup

- Se copiarmos estes logs teremos um backup realmente utilizável

• Estratégias de Backup- Backup parcial dos Data Files

- Cada dia backupeia alguns Data Files, não todos- Recupera aplicando o Log- Aumenta o tempo de recovery, pois pode haver muitos logs para aplicar

- Parallel backup- Backup com varias fitas ao mesmo tempo- Recupera aplicando o Log

• Recuperação de dados em um ponto no passado- Caso haja perda lógica de dados, por erro de aplicação, erro de usuário, etc- Volta backup e aplica logs ate aquele ponto- Se for só uma tabela, fazer isto num outro sistema, salvar a tabela e transporta-la para o sistema real

• Caso tenhamos perdido um dos Offline Redo Log Files- Dançou -> só pode recuperar até o ponto que tem todos os logs

- Sempre ter 2 copias do Offline Redo Log File- Outra situação que pode levar a perda de Redo Log Files

- Erro de hardware -> perda dos disco- -> ainda não tiramos backup de alguns Offline Redo Log Files- Só será possível recuperar o que já está em fita

• Backups Adcionais- Tirar sempre que mudar estrutura física do banco

- Add DataFile por exemplo

• Ciclo de Backup Recomendado Pela SAP- Ciclo de 28 dias (4 semanas)- Calcular quantas fitas precisa e disponibilizar 30% a mais- Fitas de backup podem ser utilizadas após o ciclo (28 dias)- Estratégias

- Full Online Backup todo dia- Full Offline Backup pelo menos 1 vez por semana- Backup dos Offline Redo Log Files todo dia, sempre depois do Full Backup

- Copiar os Offline Redo Log Files 2 vezes, em 2 fitas, por segurança


98

- Verificar o DataBase procurando Logical Errors e as fitas, procurando Phisical Errors, pelo menos 1 vez por ciclo

- Tentar fazer isto 1 vez por semana- Separar o ultimo Full Backup Offline em um cofre e colocar novas fitas em substituição- Fazer backup adcionais sempre que ocorrerem mudanças na estrutura do DataBase

• Ferramentas de Backup da SAP- Ferramentas suportam backup para disco ou fita- BRBACKUP

- Backup dos Data Files, Control Files e do Online Redo Log File - Gera log do processo- Consulta tabelas SDBAH e SDBAD para escolha da fita de backup

- BRARCHIVE- Backup dos Offline Redo Log File- Gera log do processo- Consulta o Summary.log para escolha das fitas de backup

- BRRESTORE- Utiliza logs gerados e restaura o Banco

• Outros backups- Não esquecer

- Backup do S.O.- Backup dos executáveis do DataBase- Backup dos Archives- Backup das Interface do R/3 como Change Requests p.e.- Programas de terceiros que acessam o R/3

Capítulo 9 – Tape Management

• Funções- Ajuda a encontrar as fitas para um backup- Ajuda a encontrar as fitas para um restore- Evita que fitas sejam sobrescritas antes da sua expiração

• Tape Pools- Um para BRARCHIVE e outro para BRBACKUP

• Inicialização- Comandos valem para BRARCHIVE e BRBACKUP- -i –v <tape_name> -> indico explicitamente o tape name- –i <force> -> se uso force, inicializa mesmo que a fita esteja retida

- se não uso o tape_name, é escolhido um nome não usado do pool de fitas- pool é definido na INIT<sid>.SAP nos parâmetros

- volume_backup- volume_archive

- convenção de nomes sugerida- BRARCHIVE -> <sid>A01, <sid>A02, etc- BRBACKUP -> <sid>B01, <sid>B02, etc

• Verificação de Labels- Informações do label


99

- Tape Name- DataBase name na fita- Timestamp do ultimo backup- Numero de backup já gravados nesta fita (contador de uso)

- No uso, a fita é checada contra- Expiração do arquivo -> expir_period INIT<sid>.SAP- Numero de utilizações -> tape_use_count INIT<sid>.SAP

- Só warning, não impede o uso- Para ver as informações do Label

- -i show

• Tape Locking- Fisico

- No label da fita- Fitas cuja data de expiração não foi atingida não podem ser utilizadas

- Lógico- Via tabelas SDBAH e SDBAD - Fitas retidas nesta tabela não podem ser utilizadas - Para backup do Offline Redo Log File, é utilizado o Log para saber se a fita está retida

- Desta forma é possível controle da fita com o banco fora do ar

• Seleção automática de fitas1 – Automática Tape Selection (deixamos por conta do R/3)

ele pesquisa no INIT<sid>.SAP e nas tabelas e escolhe uma fita

opaco BRARCHIVE ou BRBACKUP –q mostra qual fita ele vai escolher opaco BRARCHIVE ou BRBACKUP –q check verifica se a fita esta montada2 – Manual Tape Selection (controlamos na mão)

startamos o Backup ou Archive com –v SCRATCH o R/3 checará se a fita colocada esta retida se não estiver, grava e devemos controla-la na mão útil para backups não previstos startamos o Backup ou Archive e colocamos fita com o nome SCRATCH vai gravar na fita, independente do nome da fita solicitada a fita será renomeada para a que foi pedida útil para substituição de fitas3 – Tape Selection by a External Tool

um software externo diz qual fita utilizar startar o backup ou archive com –v <tape_name> vai checar se a fita está liberada

• LayOut das Fitas após backup 1. .tape.hdr0 label da fita2. Profiles INIT<sid>. ORA, DBA e SAP3. DB ou offline redo log depende se BRBACKUP ou BRARCHIVE4. Control Files5. reorg.log / struct.log info de reorganização e estrutura do DB (SAPREORG)6. detail.log log desta rodada do BRARCHIVE ou BRBACKUP7. summary.log lista dos backups realizados p/ BRBACKUP e BRARCHIVE


100

Capítulo 10 – Scheduling, Performing and Monitoring Backups

• Ferramentas para ativar Backup- CCMS

- Via DB13, Planing Calendar- Forma recomendada pela SAP para backups- Podemos ver logs e tapes requeridas

- SAPDBA- Starta backup interativo- Deve ser utilizada em casos excepcionais

- BRBACKUP e BRARCHIVE- Também para uso em casos excepcionais- Podemos programar a execução do backup via comando AT do NT

• Backup Profile Parameters- compress -> informar hardware se há compressão por hardware- compress_dir -> diretório descompressão p/ verify ou software compression- exec_parallel -> numero de processos ativados simultaneamente- tape_copy_cmd -> comando de backup utilizado (dd ou cpio)

- se for dd, parametrizar dd_flags e dd_in_flags- tape_address -> endereço do tape station (para backup ou archive)


101

- tape_adreess_rew -> endereço do tape station (para backup ou archive)- tape_address_arch -> endereço do tape station (só para archive)- tape_address_rew_arch -> endereço do tape station (só para archive)- tape_size -> tamanho da fita em Mb- tape_size_arch -> tamanho da fita para archive em Mb

• Recomendações- tape_size deve ser 10% menor que o tamanho da fita

- assim não corremos o risco de faltar espaço e abendar o backup- BRBACKUP calcula a quantidade de dados que cabem numa fita e, ao final, pede a follow-up tape- BRARCHIVE somente a quantidade de offline redo log files que caibam numa fita serão copiados- Se o software de copia (dd ou cpio) pedir fita de continuação não controlada pelo BRBACKUP, pode ocorrer problemas no restore- Se houver hardware compression, estimar este valor ainda menor, visto que a compressão pode variar de acordo com os dados a serem gravados

- compress_cmd- informar o comando que ativa a compressão no hardware de compressão

- exec_parallel- 0 é 1 processo por volume lógico- n é no máximo n processos (o que pode economizar CPU)

• Backup do Database- ONLINE

- Copia Control Files para disco

- Le database para saber quais datafiles e online redo log files existem- Le INIT<sid>.ORA para saber onde fica o Control File- Backup das Profiles- Backup das TableSpaces

- Para cada tablespace emite begin backup mode, faz backup e emite end backup mode

- Backup do Save Control File- Log switch- Backup do reorg.log, struct.log, detail.log e summary.log

- OFFLINE- Ativa banco- Le database para saber quais datafiles e online redo log files existem- Le INIT<sid>.ORA para saber onde fica o Control File- Desativa banco- Backup das Profiles- Backup dos Datafiles- Backup do Online Redo Log File (somente em caso de full backup)- Backup do Control File- Ativa banco- Backup do reorg.log, struct.log, detail.log e summary.log- Desativa banco

- Ao final do backup, o BRBACKUP le o header gravado, para verificar se é possível le a fita

• Realizando o Backup do Database


102

- Via DB13- Planing Calendar

- Via SAPDBA- h – Backup Database- Podemos usar g - Query Only para sabermos quais fitas serão utilizadas se fizermos um backup

- Via BRBACKUP- Podemos chama-lo com opaco H | more para conhecermos as opções do comando

• Logical Verification of Database Backup- BRBACKUP –w ou BRBACKUP verify

- Verifica se a fita pode ser lida- BRBACKUP –w use_dbv ou BRBACKUP verify use_dbv

- Realizar ao menos 1 vez por ciclo de backup- Verifica se a fita pode ser lida- Copia o arquivo para disco (diretório compress_dir)- Verifica se o tamanho é o mesmo do arquivo original (checando o log)- Detecta blocos de dados corrompidos no sistema

• Verificação física num Offline Backups- Se usarmos a opaco BRBACKUP –w use_dbv num offline backup, após a comparação do tamanho será feita uma comparação binaria do arquivo restaurado com a tabela original- Só é possível no offline backup, no online eles podem estar diferentes mesmo- SAP recomenda um offline backup com verify 1 vez por ciclo

• Monitorando o Backup do Database- Logs ficam no diretório SAPBACKUP

- Podem ser consultado via editor de texto- Via SAPDBA

- l: Show Cleanup- a: Show log files / profiles- e: BRBACKUP log files

- Via DB12- Mostra relação de todos os backup logs

- Tabela SDBAH e SDBAD possuem log também- Informações resumidas

- Arquivos de log- back<sid>.log -> uma entrada para cada detail log- b<timestamp>.<ext> -> descrição completa da atividade do backup

• Backup do Archive- Após cada o log switch, o processo ARCH copia o online redo log file para o SAPARCH- Sumario desta copia esta no arch<sid>.log- Num backup do Offline Redo Log File para fita seus status são

- ARCHIVE após ser gerado- SAVED depois do 1º backup- COPIED depois do 2º backup- DELETED após sua delecao

- Num backup do Offline Redo Log File para disco seus status são


103

- ARCHIVE após ser gerado- DISKSAV depois do 1º backup- DISKDEL após sua delecao

- Estratégia recomendada pela SAP para backup BRARCHIVE -cds- 1º - copia todos os archives em SAVED para uma fita- 2º - copia todos os archives em ARCHIVE para a mesma fita- na próxima rodada, os archives do 2º passo serão copiados para outra fita

• Realizando o backup dos Offline Redo Log Files- Via DB13

- Planning Calendar- Via SAPDBA

- i – backup offline redo log files- Podemos usar g - Query Only para sabermos quais fitas serão utilizadas se fizermos o archive

- Via BRARCHIVE- Podemos chama-lo com opaco h | more para conhecermos as opções do comando- Podemos usar a opaco -f (fillup) que copia o archive e fica rodando, esperando mais archives para copiar. Encerra quando acaba a fita ou emitimos -f stop

• Verificação dos offline redo log files backup- Usando a opaco –w ou verify- Depois do backup restaura o redo log file para o diretório compress_dir para garantir que a fita pode ser lida

- Se o backup foi feito com opaco de delecao do redo log file após o backup (-cds p.e.), é feito uma comparação do archive restaurado com o tamanho dele no log- Se o backup foi feito sem delecao, é feito uma comparação binaria com o redo log file original

• Monitorando o backup do Offline Redo Log File- Logs ficam no diretório SAPBACKUP

- Podem ser consultado via editor de texto- Via SAPDBA

- l: Show Cleanup- a: Show log files / profiles- f: BRARCHIVE log files

- Via DB12- Mostra relação de todos os backup logs

- Tabela SDBAH e SDBAD possuem log também- Informações resumidas

- Arquivos de log- arch<sid>.log -> uma entrada para cada detail log- a<timestamp>.<ext> -> descrição completa da atividade do backup

• Clean Up de Logs- Não fazer na mão porque os nomes dos arquivos são muito parecidos, podem confundir- Via SAPDBA

- l: Show / Cleanup- b: Cleanup Log Files / directories


104

- Deleta logs dos diretórios- SAPREORG- SAPCHECK- SAPBACKUP- SAPARCH- SAPTRACE / BACKGROUND- SAPTRACE / USERTRACE- <ORACLE_HOME>_RDBMS/AUDIT

- Deleta entradas da tabela SDBAD- A tabela SDBAH é limpa pelo BRBACKUP, que deleta entradas com mais de 400 dias

- Os arquivos deletados são os que passaram do limites de idade armazenados no INIT<sid>.SAP

- expir_period- Podemos chamar também SAPDBA -cleanup

• Espaço livre para SAPARCH- Monitorar- Via DB12- Via SAPDBA

- f: Archive Mode- c: Show all archive information

- Se faltar espaço no diretório SAPARCH, o Oracle entra em ARCHIVER STUCK

- Podemos colocar um arquivo dummy no diretório para, em situações de emergência, deleta-lo

• One Run Estrategy- Rodar BRBACKUP e BRARCHIVE numa única chamada

- BRBACKUP opcoes_brbackup –a opcoes_brarchive- O BRBACKUP efetua o backup e, no que sobrou da fita, faz o archive- Se o archive não couber no fim da fita, pode ocorrer um archiver stuck- Para resolver archiver stuck, não podemos utilizar a one-run-strategy

- Devemos usar BRARCHIVE, que pegara as fitas do volume_archive


105

Capítulo 11 – Advanced Backup Techniques

• Consistente Online Backup- Backup dos Data files e dos logs gerados enquanto o backup ocorria

- Ao final do backup dos datafiles, gera um log switch e copia logs- Garante consistência de um backup online- Copia log files para a mesma fita do backup- Permite reset do database para o ponto do fim do backup

- Temos que executar recovery para atualizar ate este ponto- Não chama o BRARCHIVE, tudo é feito pelo BRBACKUP,

- Nem no ARCH<sid>.log é registrado- Comando: BRBACKUP –t online_cons- Desvantagem

- Maior tempo de backup

• Parallel Tape Support- Uso de mais de uma tape station para backup e restore- Quanto mais fitas em paralelo, menor o tempo gasto- BRBACKUP

- exec_parallel = 0 permite que seja ativado 1 processo de copia para cada fita definida no parâmetro tape_address

- BRARCHIVE - Suporta até 2 tape stations para backup do archive- Usa tape stations definidas no tape_address_arch- Se não existe, usa as 2 primeiras do tape_address- Devemos ainda colocar no INIT<sid>.SAP


106

- archive_function = double_save ou double_save_delete- BRRESTORE

- Suporta todas as tape stations definidas no tape_address para restore- Vantagem

- Melhora tempo de backup- Diminui time window para recovery

- Desvantagem- Aumenta trabalho administrativo (é um ambiente mais complexo)- Aumenta custo

• Partial Database Backup- Backup apenas de algumas tablespace- Ao final de um curto período, todas as tablespace devem ter sido backupeadas- Para recuperar um banco, devemos voltar as tablespaces que houverem e aplicar todos os logs do período- Para executar

- CCMS so pode selecionar tablespace- SAPDBA d: Objects for Backup pode selecionar tablespace ou datafile- BRBACKUP –m <tablespace> idem

- Para garantir que ao final do período todos as tablespaces foram backupeadas, utilizar opaco

- SAPDBA l: make partial backups complete informar o numero de dias anteriores- BRBACKUP –f <days> informar o numero de dias anteriores

- Obs: da pra usar estas opções para completar um backup que abortou- Vantagem

- Melhora tempo de backup- Desvantagem

- Aumenta time window para recovery- Aumenta trabalho administrativo (gerenciamento complexo)

• Backing Up Data TableSpace Only- Backup apenas das TableSpace de dados- Índices serão reconstruídos via script SQL gerado pelo dicionário Oracle- BRBACKUP tem opaco que escolhe tablespaces que deverão ser copiados

- Copia sempre SYSTEM, PSAPROLL e PSAPTEMP- Comandos para backup

- BRBACKUP –m all_data- SAPDBA d: Objects for Backup > all_data

- Comandos para restore- BRRESTORE –m all_data

- Vantagem- Melhora tempo de backup

- Desvantagem- Precisa de treinamento da equipe para reconstruir as tabelas

• Two-Step Disk Backup- Copia primeiro para disco e depois para fita- Pode ser usado para Database ou Archive- Reduz o tempo do backup, já que o disco é mais rápido que a fita- Copia os dados para backup_root_dir do INIT<sid>.SAP- Se exec_parallel = 0 ativa um processo de copia para cada diretório


107

- Podemos limitar parametrizando SAPDBA h: Special Options ou no BRBACKUP –e <numero>

- Para Database Backup- A primeira fase pode ser feita via

- CCMS- SAPDBA- BRBACKUP –d disk e 4

- A segunda fase pode ser feita- SAPDBA j: backup from disk backup- BRBACKUP -b last –d tape

- Para Archive- A primeira fase pode ser feita via

- CCMS- SAPDBA- BRBACKUP

- A segunda fase pode ser feita- SAPDBA j: use disk backup- BRARCHIVE -a <opções>

- Vantagem- Melhora tempo de backup- Melhora time window para recovery

- Desvantagem

- Precisa de treinamento da equipe- Aumenta trabalho administrativo- Precisa ter disco disponível

• Structure Retaining Database Copy- Copia todo o DB para disco, numa estrutura idêntica à da produção- A estrutura precisa ser criada pelo Administrador - É apontada pelo parâmetro new_db_home- Pode ser usada em combinação com a Two-Step Disk Backup- Pode ser ainda utilizado para

- Criar um novo R/3 fazendo um Database Copy para o novo ambiente- Para criar um Oracle Standby System- Para mover o sistema para um novo local

- Não copia o sistema operacional, executáveis, etc, só os diretório do ORACLE_HOME- Comando: BRBACKUP –d disk_copy- Se usarmos o BRRESTORE, ele vai voltar os dados para o diretório ORACLE_HOME, ignorando o new_db_home- Vantagem

- Melhora tempo de backup- Melhora time window para recovery

- Desvantagem- Precisa de treinamento da equipe- Aumenta trabalho administrativo- Precisa ter disco disponível

• Split Mirror Disk Backup- Em ambientes com mirror, podemos quebrar o mirror e fazer backup da copia- Depois ressincronizamos o mirror


108

- O backup pode ser- Online

- Trocar as tablespaces para backup mode- Quebrar o mirror- Tirar o backup mode da parte em produção- Fazer online backup da outra parte (que vai estar com tablespace em backup mode)- Ressincronizar mirro

- Offline- Parar o banco- Quebrar o mirror- Ativar a parte de produção do banco- Backup offline da outra parte- Resincronizar o mirror

- Parâmetros do INIT<sid>.SAP que devem ser ativados- primary_db -> define quem sera produção- split_cmd -> define como quebrar o mirror- resync_cmd -> define como resyncronizar o mirror

- Comando: BRBACKUP –t online_split / offline_split –d tape- Vantagem

- Melhora tempo de backup- Melhora time window para recovery

- Garante alta disponibilidade- Desvantagem

- Precisa de treinamento da equipe- Aumenta trabalho administrativo- Custa caro

• SAP Tools and Oracle Standby Database- Temos 2 Database servers, um open e outro mount- O open gera log files que são aplicados no mount- Se cair o servidor de produção, o outro assume- Esta montagem não replica mudanças estruturais no database- Para backup, copiamos os datafiles do standby

- BRBACKUP –t offline_standby- SAPDBA e: Backup type e: offline_standby

- BRARCHIVE roda nos dois servidores- No de produção, copia continuamente os logfiles para o SAPARCH

- BRARCHIVE –sd –d disk –f -w- No de standby, copia os logfiles do SAPARCH para fita

- BRARCHIVE –ssd –f –m 60- O –m serve para hot ou warm connection (se houver um erro na aplicação no server de produção, temos 60 segundos para impedi-la de atualizar o standby

- Vantagem- Melhora tempo de backup- Melhora time window para recovery- Garante alta disponibilidade

- Desvantagem- Precisa de treinamento da equipe- Aumenta trabalho administrativo- Custa caro


109

• External Backup Tools using BC-BRI- Podemos ter um servidor de backup que converse com o SAP via interface BR-BRI- Fornecedores deste produto devem ser certificados pela SAP- Backup continuam a ser disparados pelas ferramentas de backup do R/3

- Desta maneira, continuamos com logs das ações- Podemos ainda usar o SAPDBA ou BRRESTORE para fazer restore e recovery

- Precisa de configuração para funcionar- backup_dev_type = util_file_online- util_par_file = INIT<sid>.UTL arquivo de parâmetros do BACKINT

- Desvantagem- Precisa de treinamento da equipe- Aumenta trabalho administrativo- Custa caro

Capítulo 12 – Restore and Recovery

• Tipos de erros- Statements- Process- Instance- User -> vamos estudar- Media -> vamos estudar

• Cenário Partial Restore and Complete Recovery- Motivo: perda do database (p.e. perda de disco)- Esta técnica permite recuperar dados até momentos antes da perda do disco- Passos

- Retornar o database do backup- voltar somente o necessário, p.e. uma tablespace- pode ser de varias fitas diferentes- afinal é um partial restore

- Retornar os Offline Redo Log Files do backup- O mais velho deve ser compatível com o mais antigo backup retornado- Não pode faltar nenhum da seqüência

- Efetuar recovery dos dados- Recupera o DB, desta forma todos os data file terão o mesmo SCN

- Startar o Banco- Todas as transações que não terminaram, sofrerão rollback baseadas nos dados dos segmentos de rollback

• Cenário Database Reset- Motivo: Alterações indevidas foram aplicadas no DB. Existe um backup imediatamente antes da alteração- Este tipo de situação sempre implica em perda de dados (entre o backup e o erro)

- Ela pode ser desejada


110

- Passos- Full Restore

- Retorna todos os Data File e o mais antigo Online Redo Log File e os control files- Não precisa de recovery (todos os dados devem vir da mesma fita)

- Depois do restore, startamos o banco- Novos offline redo log files serão gerados, com numeração idêntica as dos offline redo log file que estavam sendo gerados no momento do erro -> cuidado

• Cenário Point in Time Recovery- Motivo: Alterações indevidas foram aplicadas no DB. Não existe um backup imediatamente anterior, mas existe um mais antigo e os logs- Passos

- Full restore, a partir de um online ou offline backup- Restauramos os Data Files- Talvez devamos restaurar Control Files. Ele devera ser compatível com a estrutura do banco desejada ao final do recovery

- Recovery até o ponto desejado- Indicação pode ser feita através da hora, do arquivo de log ou do SCN desejado

- Start do Banco- Usando alter database open resetlogs -> limpa os online redo log files- Depois deste comando, não podemos mais fazer recovery, desta forma é necessário fazer um full backup para termos um ponto consistente de partida

• Como tratar um problema- Não tomar decisões apressadas

- Se possível, tirar um full offline backup antes de tomar qualquer atitude- Verificar

- Causa do problema- Database Alert Log- Trace files- É erro de mídia ou do usuário- Quais arquivos estão corrompidos ou perdidos- Existe um mirror disponível para este arquivo

- Espaço em disco para trabalhar- Se há necessidade de expansão do hardware- File system e mount points- Disponibilidade de backups- Disponibilidade dos offline redo log files

- Criar uma estratégia para resolução

• Função Partial Restore and Complete Recovery do SAPDBA- Para poder ser utilizada, online redo log file e os control files devem estar validos

- Eles não são restaurados do backup1. Check Database

- Verifica o status de todos os arquivos do database (Control File, Online Redo Log file, Data File)- Verifica as V$Views- Se algum erro ocorre nesta fase, deve ser efetuado um safe check


111

- Database shut down- Database start mount- SAPDBA reporta os erros encontrados no diretório SAPREORG com sufixo .RCV

2. Find Backups- determina fitas a partir do back<sid>.log (rc 0 ou 1) e, depois, do log do backup- SAPDBA sempre sugere o backup mais recente

3. Restore Data Files- restaura os data file- se so estão faltando arquivos de index, SAPDBA pode recriar estes índices a partir do Database Dictionary

4. Find Offline Redo Log Files- determina quais Offline Redo serão necessários para recovery completo- verifica as fitas no arch<sid>.log- SAPDBA leva em consideracao Online Redo Log File e os Offline que estão no SAPARCH

5. Restore Offline Redo Log Files- restaura Offline Redo Log Files para SAPARCH

6. Recover Database- cria scripts no SAPREORG e

- Salva Control Files

- Faz Recovery do Banco (comando RECOVERY DATABASE)- Mensagem final RECOVER DATABASE TERMINATED SUCCESSUFULY

• Limitações da Partial Restore and Complete Recovery- Não funciona se

- Outros arquivos que não Data Files forma perdidos- Não há logs disponíveis do BRARCHIVE e BRBACKU

- Podemos restaura-los de um backup- Não encontra INIT<sid>.*

- Podemos restaura-lo de um backup- No caso do INIT<sid>.SAP, podemos adaptar um template

- Control Files estão danificados- Verificar o mirror

- Online Redo Log Files estão danificados- Verificar o mirror

• Database Reset usando um Full Offline Backup- sempre envolve perda de dados- desta forma é recomendável backup antes deste procedimento- opções do SAPDBA

- reset database and startup open- reset database and startup mount

1. Find full Offline Backup- baseado no back<sid>.log

2. Save Current Online Redo Log File and Control File- copia control files e online redo log files para SAPREORG, já que eles vão ser resetados- para isto ocorrer o database deve estar pelo menos em MOUNT

3. Override all Data File, Control File and Offline Redo Log Files- restaurando das filas escolhidas

4. Ativação do Banco


112

- em startup open- se optarmos por open, ele será ativado com noresetlog

- em startup mount- se optarmos por mount, poderemos utilizar um ainda um recovery para atualizar mais os dados via Server Manager do Oracle

• Database Reset usando um Consistente Online Backup- sempre envolve perda de dados- desta forma é recomendável backup antes deste procedimento- como ele vai usar os Offline Redo Log Files, todos eles devem estar salvos via BRARCHIVE- depois do reset, podemos ter inconsistências nas tabela SDBAD e SDBAH, já que elas voltaram para uma posição antiga- da mesma forma, o BRARCHIVE pode não reconhecer que o novos offline redo log files precisam ser salvos1. Find Online-Cons Backups

- baseado no back<sid>.log- encontra o backup do database e, no fim, esta o archive

2. Save Online Redo Log File and Control Files

- copiados por razoes de segurança para o SAPREORG3. Override All Data Files and Control File | Offline Redo Log Files

- só restaura os Offline Redo Log Files gerados durante o backup4. Recover Database until Cancel

- comando é recover database using backup control file until cancel5. Database open resetlogs

- resetlog inicializa (ou cria) online redo log files- Desta forma, podemos deletar qualquer offline redo log file restaurado, pois não serão mais necessários- após isto, o database deveria ser checkado para blocos corrompidos

- DB_VERIFY- Como não é possível recovery (resetlog), o SAPDBA encaminha para a opção de backup, já que ela é recomendável neste ponto

• Full Restore and Recovery Using SAPDBA- Coloca o database num estado consistente num ponto entre um full backup e o momento atual- Função point in time recovery do SAPDBA

- Podemos usar o SAPDBA se o banco conseguir entrar em open ou mount- Como envolve perda de dados

- Recomendável Full Backup Offline- BRARCHIVE de todos os offline redo log files do SAPARCH (podem vir a ser usados)

- depois de um recovey point in time, podemos ter inconsistências nas tabela SDBAD e SDBAH, já que elas voltaram para uma posição antiga1. Find Full Offline / Online backups

- encontra as fitas de um full offline, online_cons ou full online2. Recover Until ??

- devemos responder até que ponto executar o recovery- para recovery completo, responder NOW

3. Find Offline Redo Log Files- pela resposta anterior, encontra, via arch<sid>.log os archives


113

4. Status ???- SAPDBA informa se podemos realizar a ação desejada- Pode ser impossível porque

- Não encontrou full backup ou não encontrou os offline redo log files em fita- Ocorreu uma reorganização de tablespace no período a ser recuperado- O backup encontrado é anterior a um resetlog

5. Save Online Redo Log Files and Control Files- copiados por razoes de segurança para o SAPREORG

6. Override all Data Files and Control Files (if necessary) | Offline Redo Log Files

- restore de todos os data files- se uma tablespace foi estendida no período compreendido pelo recovery, os control files tambem serão restaurados

- neste caso, o DBA deverá depois reexecutar o comando de add datafile- é recomendado sempre um backup depois destas alterações

- os offline redo log files necessários são restaurados para o SAPARCH7. Recover Database until

- comando é recover database using backup control file until time zz:zz:zz8. Ativar o Database

- Recoveries incompletos obrigam o database a ser ativado com o resetlog

- Depois da recuperação, é recomendado um DB_VERIFY a procura de blocos corrompidos- SAPDBA vai levar o usuário para o menu de backup, que é recomendado depois de um resetlog- Desta forma, podemos deletar qualquer offline redo log file restaurado, pois não serão mais necessários


114

Capítulo 13 – Storage Management

• Erros Oracle- ORA1653 -> falta de espaco para novo extent de data- ORA1654 -> falta de espaco para novo extent de index- ORA1631 -> maxextent atingido para data- ORA1632 -> maxextent atingido para index

• Fragmentacao- internal fragmentation

- fragmentacao dentro do bloco pela delecao de linhas- Oracle resolve no insert ou update de linhas no bloco

- External fragmentation- Fragmentacao de extents- Extents livres são reaproveitados somente no caso de um nova alocacao menor que o free extent

- Space Critical Objetcs- São tabelas que, se tentarem uma nova alocacao de extent, não vao encontrar espaco suficiente dentro da tablespace

• Fragmentacao do Bloco- As regras para permissao de inclusao causam zonas de limbo, onde um bloco fica não totalmente preenchido, porem não pode receber mais inclusoes- Acima de PCTFREE não pode mais receber inclusoes, so aceita update

- Default 10 % SAP- So mudar sobre orientacao da SAP

- Abaixo de PCTUSED volta a receber inclusoes


115

- Default 40 % SAP- So mudar sobre orientacao da SAP

- Row migration- Ocorre quando, num update, uma linha não pode ser contida no bloco e é gravada em outro bloco

• SAPDBA -check- Verifica

- Quantidade de extents das tabelas e dos indices- Tablespace filling- Consistencia fisica do database (control files, redo log files e data files)- Mensagens de erro graves no Alert Log- Parametrizacao do INIT<sid>.ORA- Problemas especificos do database no ambiente R/3

- Gera log <datetime>.chk no diretorio SAPCHECK- Grava tambem dados na table DBMSGORA- Podemos visualizar DBMSGORA via DB16

- Recomendacao SAP- Rodar SAPDBA todo dia, durante um periodo de baixa atividade do sistema- Schedular via DB13 – Planning Calendar- Rodar SAPDBA –check quando ocorrer problemas no database ou no sistema

• Configuracao do SAPDBA -check- Via DB17- Configura DBCHECKORA- Parametros

- Error Type- DBA -> possiveis erros que SAPDBA vai reportar (p.e. many extents)- ORA -> erros que o Oracle registra no log (p.e. I/O Error reading block)- PROF -> valores incorretos na INIT<sid>.ORA (p.e. block size <> 8192)

- Parameter ID -> nome do parametro- Active -> se esta ou não ativa aquela determinacao de problema- Check Oper, Check Val, Check Unit

- Operadores -> p.e. > 80 P (maior que 80 %)- Corr Type -> ferramenta para resolver o problema (P=SAPDBA, T=transacao R/3)

• Extensao de uma TableSpace- Via SAPDBA

- TableSpaced > Alter TableSpace > Add Data File- Informa um default, alterar a gosto- Depois S > Start

- SAPDBA checará se existe espaco na TableSpace- A seguir SAPDBA vai para menu de Backup- Outras acoes- No SAPREORG

- Grava action log <timestamp>.ext- Grava a versao velha e a versao nova do Control File (SAPREORG/<timestamp>)-


116

- Observacoes importante sobre extensao de Tablespace- Parametro Oracle MAXDATAFILES define a quantidade de data files para aquele DB e é definido na criacao do banco- Parametro Oracle DB_FILES define a quantidade maxima que o database pode manipular

• Storage Categories de Objetos SAP no banco- Cada objeto tem sua categoria especificada no Dicionario de Dados- Categorias refletem valores de INITIAL, NEXT e MAXEXTENT das tabelas- Esta definicao é chamada de Technical Setting- Estes valores estao definidos nas tabelas

- TGORA - Tabelas- IGORA - Indices

- SE11 permite altera a tabela, SE12 permite exibir- INITIAL é sempre 16- Quanto maior a categoria, maior NEXT

- Comecao com 40 e termina com 20.971.520- MAXEXTENT pode ser 300 (para categoria 0-9) ou 150 (para categoria 10-14)- Embora possivel, SAP não recomenda colocar UNLIMITED MAXEXTENT em nenhuma categoria

• O SAPDBA -next- Opcao que permite evita o crescimento descontrolado do numero de extents das tabelas do banco- Geraq LOG de sua execucao no SAPCHECK, nome <timestamp>.nxt

- Funcionamento:- Verifica o total de espaco alocado pela tabela e divide por 10- Compara este valor com o valor de NEXT definido na tabela, o maior será o NEXT CANDIDATE- O Next Candidate é comparado com o Technical Setting da tabela e, se este for maior, ele é usado como NEXT definitivo- Se não for, pesquisa na TGORA e IGORA um valor menor que o Next Candidate em até 5 blocos- Se não for achado um valor menor em ate 5 blocos, é usado o proximo valor- Se não houver um valor maior na TGORA / IGORA, o Next Candidate é usado

- Recomendacoes da SAP- Rodar SAPDBA –next ao menos 1 vez por semana

- Pode schedular via DB13- Rodar após mudancas grandes no DB- Rodar um SAPDBA –check para ver se com as alteracoes não vai estourar nenhum proximo extent

• Monitorando Tabelas e Indices- Via DB02- Informacoes para ela são geradas via programa RSORATDB

- Tabela TCOLL defini quando o programa RSORATDB vai rodar (via SM31)- RSORSTDB coleta dados e coloca na tabela MONI- MONI armazena dados estatisticos das tabelas e indices- Tambem é necessário que o COLLECTOR_FOR_PERFORMANCEMONITOR esteja rodando de hora em hora

- Opcoes da DB02- Missing indexes -> indices default que estao faltando


117

- Checks > Check Next Extent -> objetos com grande crescimento no num de extents- -> objetos com mais de 80% dos extentes alocados- -> possue bota History Per Week- TableSpace > Space Statist –> tamanho, free space e storage usage- Detailed Analisys -> analise detalha de uma tabela ou indice- Space Critical Objects -> vai estourar no proximo extent (?)

• Monitorando Fragmentacao Internal- Via SAPDBA –analyze

- Usa o comando Oracle ANALYZE- Este comando fornece informacoes sobre storage allocation e fragmentacao- Podemos tambem checar informacoes de uma única tabela- É usado pelo otimizador Oracle para acessos baseados em custo

- Pode ser schedulado via DB13- Para acessar as informacoes geradas

- Via DB13 -> Double Click no calendario > Detail Log- Via DB14 -> DB Optimizer (mostra optimizer statistics)- -> Fuction Ids (mostra action log)- -> Detail Log (resultado da analise da tabelas e indices)

- Caminho no SAPDBA- Reorganization- Check extents and fragmentation

- Metodos de Analise- COMPUTE STATISTICS -> mais acurado e mais demorado- -> usado para tabelas- VALIDADE STRUCTURE -> usado para indices- -> se usado tab e indice são locked, não podem ter alteracao

- Verificacoes efetuadas- Tabelas que tem grande diferenca entre EMPTY e NEVER_BEEN_USED

- EMPTY é a diferenca entre o espaco alocado e o usado pela tabela- NEVER_BEEN_USED é o espaco alocado mas nunca usado

- Indices que tem grande diferenca entre USER_BY_BTREE e USED- USED é o espaço realmente usado- USED_BY_BTREE é o espaco alocado para B*Tree

• Reorganizacao- Permite reorganizar blocos e juntar extents- Se reorganizamos Data Files, podemos minimizar o numero deles- Para Tabelas

- Export Table- Drop Table- Import Table- Recriate Index

- Para Indices- Drop Index- Recriate Index

- Precisa espaco para o export- SAPDBA tenta prever o valor da quantidade de memoria adcional necessaria- Erros comuns


118

- No data file has enough freespace to hold new larger extent or a temporary second copy of object- SAPREORG too small to hold export sets- PSAPTEMp too small for index recriation

- Para evitar perda de dados na reorganizacao, tirar backup- Após a reorganizacao, tirar backup

• Reorganizacao- So em casos extremos, é caso e o sistema tem que parar- Motivos

- Disk Hot Spots -> distribuicao de acesso tornou um disco muito acessado- Alta fragmentacao de indices -> pode afetar bastante a performance- -> a fragmentacao das tabelas não afeta tanto

- Como evitar- Rodando SAPDBA –next -> é melhor aumentar NEXT e MAXEXTENT do que reorganizar- Estimar crescimento das tabelas e extende-las em data files com tamanho apropriado- Fazer ARCHIVE de dados obsoletos

- Vai evitar que se chegue ao limite de DB_FILES- Se estiver chegando ao limite MAXFILES e DB_FILES, aumente este limite, não reorganize tablespace

• Tipos e fases de uma reorganizacao- Via SAPDBA

- Phase 1 – gera script de reorganizacao no subdir <timestamp> do work directory- - gera arquivo de restart: restart.ext- - checa se há espaco para reorganizacao- Phase 2 – executa script

- Reorganization of a single object (RSI)- Usado para eliminar fragmentacao interna ou de extents (tab ou index) ou mover tabelas entre disco

- Reorganization of a list of objects (RLI)- Idem, mas faz para uma lista de objetos. Devemos criar um arquivo com a lista dos objetos

- Reorganization of a Tablespace (RTC)- Reorganiza tablespace sem alteracao na estrutura ou seja sem diminuir o numero de data files

- Reorganization of a Tablespace with a data file (RTC)- Reorganiza tablespace com alteracao na estrutura

- Moving and renaming data files ((RMV)- Não é reorganizacao, é feita a nivel de file system

• Metodos de reorganizacao- ORACLE EXPORT / IMPORT

- Export e Import do Oracle- Usa SAPREORG como area temporaria e PSAPTEMP para recriacao do Indice

- SAPDBA UNLOAD / LOAD- SAPDBA Unload e Load ou Oracle SQL*Loader- Usar SAPREORG como area temporaria e PSAPTEMP para recriacao do Indice

- CREATE TABLE ... AS SELECT


119

- Copia a tabela com o mesmo nome mais sufixo #- Depois da Drop na tabela velha e renomeia a nova- Não pode ser usada para tabelas com campos LONG- Não pode ser usada para reorganizar tablespaces- Precisa de espaco adcional, pois a tabela existe 2 vezes num determinado periodo- Precisa de bastante espaco de PSAPROLL

- ALTER INDEX / REBUILD- Reconstroi o indice na PSAPTEMP- Copia o indice de volta para a tablespace original- Dropa o indice antigo e ativa o indice novo- Tabela e indice ficam locked durante o processo- Precisa de espaco na PSAPTEMP

- RECREATE INDEX- Dropa o indice e recria- Precisa de espaco na PSAPTEMP

• Options da SAPDBA para reoganizacao- Compress Extents

- Junta os extents num so- Se não usado usa os parametros correntes do objeto

- Reduce Object Size

- Usa o comando ANALYZE para tentar reduzir o tamanho do objeto- A geracao do script demora um pouco e da lock na tabela a ser reorganizada

- Chop- Quebra o arquivo exportado em pedacos de ate 2 Gb. Não funciona em NT

- Compress- Comprime o arquivo exportado usando funcoes do S.O.

- Parallel Export / Import- Exporta e Importa o arquivo em paralelo- Precisa parametrizar INIT<sid>.SAP (exp_imp_degree)

- Oracle PARALLEL clause- Usa funcao PARALLEL Query do Oracle para acelerar a reorganizacao


120

Capítulo 14 – Performance Monitoring

• Performance Issues- Cost Based Optimizer- Memory Configuration- Application Design- Physical and logical layout

• Cost Based Optimizer- Razoes para problemas de performance

- Informacoes velhas ou imprecisas sobre estatisticas- Atualizar com o modelo de 2 fases da SAP- Melhorar a precisao modificando o procedimento padrao

- Presuncoes incorretas- O otimizador pode achar que os dados estao uniformemente distribuidos e isto não ser verdade- Para tanto, pode-se usar o Role Based Optmizer, modificando-se a definicao padrao da SAP- Pode-se alterar a forma da aplicacao acessar os dados

- Não uso das ferramentas da SAP para atualizar estatisticas- Falta de uso mesmo- Isto pode causar serios problemas de performance

- Atualizacao das estatisticas - 1ª fase – SAPDBA determina quais objetos precisam de novas estatisticas

- verifica se mudou o numero de linhas (10% para tab pequenas e 100% para grandes)- para isto usa comando ANALYSE da Oracle- tabela DBSTATC armazena quais objetos serao atualizados


121

- não gera solicitacoes para tabelas pool e cluster- o comando para ativa-lo é SAPDBA –checkopt- sugestao SAP é roda-lo uma vez por semana (via DB13)- para rodar para todas as tablespaces SAP usa SAPDBA –checkopt PSAP%- podemos mudar theshold (o % de crescimento) ou limitar o runtime via parametros- grava log <datetime>.opt no SAPCHECK

- 2ª fase – atualiza estatisticas destes objetos- Baseado na tabela DBSTATC- Possue colunas Object Name, Method, Option, New Statistics Need- Podemos modifica-la na mao- Para atualizar devemos executar SAPDBA –ANALYZE DBSTATC0

- Podemos ainda limitar o tempo de runtime ou escolher uma única tabela, uma lista de tabelas ou uma lista de tablespaces

- Rodar ao menos 1 vez por semana (via DB13) depois do –checkopt PSAP%- Para cada linha da DBSTATC executa ANALYZE com a precisao de Method e Option- Gera log <datetime>.ALY no SAPCHECK

- Modificando procedimentos padrao - Pela transacao DB21- Podemos modificar o procedimento padrao

- Aumentando a precicao das estatisticas para uma tabela- Podemos alterar type of usage (O=Optimizer)

- Podemos mudar o metodo de analise (Estimated ou Compute)- Porcentagem de linhas a serem analisadas (para Estimated)- Quantidade de linhas a serem analisadas (para Estimated)

- Deletando estatisticas para uma tabela- Desta forma definiremos que esta tabela usará Rule-Based Optimizer- Podemos especificat Active = N ou R, para definir se o objeto sera analisado em termos de espaço

- Sempre que modificarmos os procedimentos padrao, devemos ativar o flag TODO para que as estatisticas sejam atualizadas na proxima vez

• Usando o R/3 para monitorar problemas de performance- Ser houver um problema de performance verifique

- As estatisticas estao atualizadas- A precisao é a correta- Há alguma nota relacionada com este problema- É necessario alterar as condicoes de estatistica para esta tabela- O Rule Based Optimizer esta usando a melhor opcao

- Se não houver solucao, abrir uma nota- Usar objeto BC-DB-ORA

• Memory Configuration- Usar a ST04 para verificar- Não verificar logo após startup, esperar ao menos um 20.000.000 de reads- Data Buffer

- Hit ratio deve ser de ao menos 94% - Problemas de codigo SQL causar baixo Hit mesmo com grandes buffers- Para aumentar Data Buffer, modificar DB_BLOCK_BUFFERS

- Monitorar via ST06 a paginacao do S.O. para não comecar a causar Swap- Shared Pool


122

- Dividida em- Shared SQL Area

- Usada para armazenar comandos SQL que vao ser executados- Row Cache

- Onde ficam informacoes do Dicionario de Dados Oracle- User Call é uma chamada para um comando na Share SQL Area- Recursive Call é uma chamada para o Row Cache que causou uma leitura fisica- Eficiencia do Share Pool

- User Call to Recursive Call should be 2 : 1- DD Cache quality > 80%- Pin Ratio > 95%

- Se precisar aumentar- SHARED_POOL_SIZE- Ver paginacao do S.O. antes

• Application Desing- Lockwait situations

- Identificacao usando DB01- Mostra o numero de lock holders, numero de lock waiters e a primary key locked

- Para reduzir os Exclusive Lockwaits

- Aumentar a frequencia de commits- Não permitir que um processo segure um lock por muito tempo- Emite o lock o mais tarde possivel (dentro do programa)

- Unnecessary SQL Statements - Comandos que são executados repetidamente com a mesma clausula WHERE- Tentar pegar pela ST04

- Possui as seguintes informacoes para cada comando SQL da Shared Pool Area- Total Execution- Buffer Gets- Bufgets/record

- Se classificarmos por Buffer Gets, podemos localizar comando executados frequentemente que trazem muito pouco Bufgets/record- Este pode ser um comando dentro de um loop -> analisar- Usar WHERE-USED no Data Dictionary (SE12)

- Para reduzir o acesso, podemos redesenhar a aplicacao, tirando o comando do loop- Ou podemos colocar a tabela na memoria

- Expensive SQL Statements - Tem um grande numero de Buffer Gets em relacao ao Total Reads

- Pegar o Buffer Gets na ST04 e o Total Reads na abertura do monitor- Se passar de 5% a relacao, investigue o comando- Rode um Explain para ele, verifique quais tabelas acessa

- Duplo click na linha do comando na Shared SQL Area e click Explain- Pode-se usar Explain with Hints, que permite sugestoes de acesso via Role-Based- Possiveis saidas do Explain

- INDEX RANGE SCAN -> recupera o numero de registros usando indice- INDEX UNIQUE SCAN -> recupera uma linha- INDEX NAME -> recupera o nome do indice a ser usado- CONCATENATION -> une linhas recuperadas de uma query


123

- NESTED LOOP -> junta tabelas- TABLE ACCESS FULL -> recupera todas as linhas de uma tabela- SORT -> classificas os dados antes de devolve-los

- Possiveis correcoes- Verifique o Cost-Based Optmizer setting desta tabela- Se o codigo é parte de um programa SAP, abra uma chamada na OSS- Se o codigo é do cliente, redesenhe a aplicacao- Verifique se o statement esta pouco qualificado

- Poorly Qualivied Statements - Possuem um alto indice de BufGets / Record- Provavelmente não tem um indice naquele campo- Se for programa da SAP, abrir chamada na OSS- Outras causas

- Falta um indice secundario- O indice incorreto esta sendo usado- O indice esta sendo usado mas o full scan seria mais eficiente, p.e. se a tabela tem poucas linhas ou se um grande numero de linhas sera recuperada

- Para verificar se esta usando indice, rodar Explain Plan para o Statement- A causa mais comum deste erro é um indice estar definido no Dicionario SAP mas não no Database

- Usar a opcao Missing Indices da DB02 para verificar

- Isto normalmente é causado por falha na reorganizacao, falta de ativacao do indice no Dicionario de Dados ou Drop manual do indice- O Performance Collector emite um relatorio sobre indice faltando

- RSCOLL00 que chama o RSORATDB- Devemos verificar falta de indices 1 vez por semana

• Phisical and Logical Layout- I/O Contention

- Podem acontecer por- Design ineficiente das aplicacoes (comandos expensives ou desnecessarios)- I/O mal distribuidos em disco- Discos lentos- Alto acesso a tabelas or indices que não foram distribuidos entre discos- Configuracao de hardware incorreta

- Usar ST04 > Detailed Analisys > File System Request > I/O per path- Se há pouco acesso, não é caso de contencao de i/o- Se esta muito acessado e average read time > 30 ms ou - Average write time > 50 ms -> contention- Se algum disco tem mais de 20% de i/o do que os outros temos um hot disk- Para resolver

- Distribua o I/O entre varios discos disponiveis- Compre discos mais rapidos- Mova hot spot table or indexes para discos exclusivos

- Checkpoint not Complete - Ocorre quando

- Todos os online redo log files estao efetuando checkpoint ao mesmo tempo- Isto pode ocorrer se os log files estao muito pequenos (levando menos de 3 minutos para serem preenchidos) e sao muito poucos, nao dando tempo de efetuar a gravacao dos dados do redo log buffer para o log e ja tendo lotado todos os


124

outros online redo log files dispoinveis, ou seja, outro log switch ocorreria para este o log file que esta fazendo checkpoint

- O Oracle trata automaticamente esta situacao ‘Checkpoint Not Complete’ e grava alerta no ALERT<sid>.LOG- Só é problema se ocorre com muita frequencia- Para resolver, aumentar o numero de online redo log files- Se os logs demorarem menos de 3 minutos para serem preencihdos, aumentar o tamanho deles

- Rollback Statement Problems - Segmenos de rollback sao usados para

- Salvar imagens anteriores num processo de atualizacao- Prover consistencia de leitura quando uma query roda

- Se uma tabela é modificada entre o momento que uma query é iniciada e os registros serem entregues, o dado é lido do segmento de rollback- No entanto segmentos de rollback nao entram em lock para uma query. Se a query nao terminou ate fim do update, o segmento de rollback pode ser apagado para liberar espaco- Isto gera ORA1555 – Snapshot too old e aborta a query- Para evitar ORA1555

- Tuning do comando SQL que abenda, tente otimiza-lo para diminuir seu runtime

- Diminua o tempo de processamento entre 2 fetches de um comando SQL- Schedule os relatorios e os updates em momentos diferentes- Em ultimo caso, aumente o numero de segmentos de rollback (isto vai diminuir a frequencia de liberacao dos segmentos de rollback)

- Para melhorar a performance dos segmentos de rollback, distribua-os em discos pouco acessados, eles tem uma alta carga de acesso

- Fragmented Indexex - Sao indices com baixa taxa de preenchimento- Podem ocorrer

- Depois de data archive- Depois de muitos registros serem deletados- Em tabelas muito dinamicas

- A fragmentacao faz com que muitos blocos de indice tenham que ser lidos- Isto pode fazer com que outros blocos de indice sejam tirados da memoria para trazer estes novos blocos- Analisar este problema via DB02 > Detailed analizys- Fill level de menos de 50% indica necessidade de reorganizacao

- Somente se é um indice muito acessado- Cuidado: durante o Validate Structure a tabela fica locked


125

Capítulo 15 – Top 10 Problmes

• Fontes para pesquisa de problemas no Oracle- Oracle Files

- ORACLE_HOME/saptrace/background/ALERT<sid>.LOG -> mensagens ORA-xxxx- Oracle background process trace no diretorio SAPTRACE/BACKGROUND- Oracle user trace no diretorio SAPTRACE/USERTRACE- Arquivo STARTDB.LOG, no diretorio home do <sid>ADM -> msg de startup

- No R/3 - SM21 -> System Log

- Para abrir chamados no OSS- Syslog Message - Short Dump- Error message do Alert Log- Erro message do Background Process e User Trace- Erro message do Startdb.log- Log do SAPDBA ou BR*

• Archiver Stuck- Mensagens -> ORA-255 ou ORA-272

- Gravadas no ALERT<sid>.LOG- Podemos evitar criando o Dummy File- Por segurança, SAPARCH deve ter 3 vezes o necessario para os logs de 1 dia- Verificar se log_archive_start = true -> copia automatica dos logs- Verificar se usuario ORA<sid> tem autorizacao para gravar no SAPARCH

• Incorrect tape size on drivers with hardware compression- Deixar um sobre de aproximadamente 200 Mb no parametro tape_size por segurança


126

- Recalcular este parametro 1 vez por ciclo de backup- Rodar BRBACKUP –compress | -k only

- Recalcular quando houverem mudanças significativas na base de dados- Mudança de release- Muitas inserçoes

• Missing “end backup”- ORA-1149 Missing End Backup

- SAPDBA > DB Check Verification > DB System Check > Set end backup automactily- ORA-1113

- SPDBA > Partial Restore and complete Recovery

• Tablespace Overflow- ORA-1653 Table Overflow- ORA-1654 Index Overflow- SAPDBA > Tablespace Administration > Alter Table > Add Data File- Fazer backup depois desta alteracao

• Table or Index reaching MAXEXTENTS

- ORA-1531 Tables reaching MAXEXTENTS- ORA-1532 Index reaching MAXEXTENTS- Para evitar

- Monitar extents- SAPDBA –next 1 vez por semana- Ajustar MAXEXTENTS se necessario - SAPDBA > Reorganization > Alter/Show table

- Não utilizar MAXEXTENTS unlimited-

• Shapshot too old – ORA1555- Long running queries cujos dados foram alterados e commitados por outro usuarios- Causas

- Long running queries por comandos SQL mal qualificados- Pode ser falta de indice, falta de estatistica, excesso de indices

- Alto tempo de processamento entre os fethcs da query- Incorrect rollback segment setup

- Podemos aumentar o numero de segmentos de rollback ou seu tamanho

• NET 8 TCP/IP delay- So para unix

• Oracle error ORA-1578 – data block corruption- Só é detectado quando a informaçao daquele block é necessária- Se for de dados, devemos fazer restore and recovery da tablespace- Se for de indice, podemos reconstrir o indice- Backup não detecta - Para detectar

- BRBACKUP –verify | -w only_dbv | use_dbv- SAPDBA > k: DB Check / Verification > DB Verificdation using DB Verify


127

• Oracle error ORA-600 – internal database error- Anotar o codigo emitido em seguida- Consultar este codigo na OSS- Se não achar, abrir chamado- Verificar ainda ALERT<sid>.LOG e SM21 (Syslog)- Pode ainda existir um state dump nos tracefiles

- SAPTRACE/BACKGROUND- SAPTRACE/USERTRACE

• Poor performance of the Cost-Based Optmizer- Atualizar estatisticas constantemente- Para verificar se elas são recentes

- DB14 > Optmizer

Apostila III

Capítulo 1 – Preface

• Nothing to do


128

Capítulo 2 – R/3 Workload Analysis

• Workload Analysis- Objetivos

- Maximizar throughput- Minimizar response-time

- Estrategia- Encontrar bottlenecks- Encontrar programas com problemas na implementaçao

- Problemas tipicos- Problemas system wide (erro no sizing da maquina) ou more limited (comandos de acesso ao database)

- Encaminhamento: analisar medias de tempo de resposta- Problemas em transacoes especificas

- Encaminhamento: analisar response time de dialogos nas transacoes individuais

- Reponsabilidades- Basis e DBA -> distribuir carga para evitar gargalos

- Otimizar System Parameters (memoria, database, o.s. e networking)- Otimizar database disk layout- Otimizar workload distribution (numero de WP, logon groups)- Verificar hardware sizing

- ABAPers, DBA e Applications -> otimizar programas - Aplicar notas e correcoes do OSS- Otimizar a customizacao- Otimizar codigo ABAP dos desenvolvimentos feitos no cliente- Criacao, alteracao e drop de indices- Definir table buffering

• Dialog Step - Wait Time


129

- Tempo que o request que veio do presentation server fica na Request Queue- Normalmente é o tempo necessario para vagar um WP

- Roll-in Time- Inicio efetivo da transacao- Tempo que leva para transferir os dados do USER CONTEXT (logon atributes, authorizations) do roll buffer, extended memory or roll file para o WP- Transferencia pode ser feita por copy o mapping

- Load Time- Tempo necessario para carregar e gerar objetos como programa ABAP, CUA e telas

- Database time- Tempo entre a chamado ao banco e o retorno da resposta- Realizada pelo database interface- Conta o tempo de rede gasto na solicitacao

- Access to SAP Buffers- Antes de emitir chamada ao banco, o SAP pesquisa nos seus buffers pela informacao- Se não a encontra, solicita ao database que encontre os dados- Esta atividade tambem é feita pelo database interface

- Response Time

- Quando a transacao é completada, o dispatcher é notificado e a tela enviada ao presentation server

- Roll Out Time- Depois que a transacao termina, o user context é rolled out do WP

- CPU Time- Tempo que um WP teve controle ativo da CPU

- Response Time- Tempo decorrido entre o transacao chegar na Request Queue e o envio da tela ao usuario- Não conta o tempo de rede antes da chegada nem depois do envio

• Workload Statistics para RFC - Quando ocorre chamada RFC, o User Context é Rolled Out e, quando a chamade se completa, o User Context é Rolled in novamente- Tempos envolvidos

- Roll-out time - Roll wait time -> tempo do wait da chamada RFC- Roll-in time

• Roadmap para Analise Inicial- Usado quando o problema afeta todas as transacoes

1. Wait Time < 10% do Response Time2. Response time do Main Menu < 100 ms3. Media de roll-in time < 20 ms4. Media de roll-out time < 20 ms5. Media de Load time < 10% Response Time6. e < 50 ms7. Media de DB request time < 40% de (Response Time – Wait Time)8. Media CPU time < 40% de (Response Time – Wait Time)9. Media CPU time não muito menor Processing Time

- Possiveis causas- Large Roll Time -> CPU ou Configuracao de Memoria do R/3- Large Load Time -> Program Buffer, CUA Buffer ou Screen Buffer pequenos


130

- Large CPU Time -> ABAP expensives- Proc Time >> CPU Time -> CPU, Rede ou communication problems- -> Proc Time > CPU Time * 2- Large DB Request Time -> CPU / Memorio do DB Server- -> problemas na rede- -> comando SQL expensive- -> falta de indices ou estatisticas- -> locks no DB

• Monitoring de BASIS- Comecar com ST03 (Workload Monitor)- Em caso de

- DB request time > 40% de (Response Time – Wait Time)- Analisar DB

- Processing Time > 2 * CPU Time - Analisar hardware

- Load time > 50 ms- Configuracao de memoria (program buffer, etc)

- Roll-in ou Roll-out > 20 ms- Configuracao de memoria (extended memory ou roll buffer)

- Usar- SM50 / SM66 -> Work Process Overview- ST06 -> Operating System Monitor- ST04 -> Database Monitor- ST02 -> Setup Buffers

• Monitoring de R/3 Applications- Comecar com ST03 (Workload Monitor) e chamar Transaction Profile- Em caso de

- Programas com CPU Time > 40 % (Response Time – Wait Time)- ABAP Trace

- Programas com DB Time > 40 % (Response Time – Wait Time)- Analise detalhada dos Comando SQL

- Usar- STAT -> Statistical Record- ST05 -> SQL Trace- ST07 / ST14 -> Application Monitor- SE30 -> ABAP Trace


131

Capítulo 3 – Performance Analysis Monitor

• Basis- Transacoes SM50 ou SM66 (Work Process Overview)

- WP em status de Running- Action -> Dir. Read, Seq. Read, Insert, Update, Delete, Commit

- Verificar problemas no database- WP em status de Stopped

- Reason -> PRIV- Verificar Memory Configuration

- Reason -> CPIC- Verificar CPIC connections (All Work Processes Blocked in Destination System)

- Transacao ST02 (Operation System Monitor)- Informacoes importantes

- Media de CPU (1 Min, 5 Min e 15 Min)- Utilizacao de CPU momentanea- % disk utilization- O.S. Parameters

- Indicativos de gargalo de CPU- Idle CPU < 10%- Load Average: N processes waiting in front of the CPU

- Indicativos de gargalo de Memoria- Crescimento do numero de Page Ins

- Outras informacoes relevantes- TOP CPU PROCESS- TUNE BUFFERS

- Hit Ratio > 95 %- Roll Area Max Used < In Memory (senao entra no Swap File)- Extended Memory Max Used = In Memory (entrou em Heap Memory)


132

Capítulo 4 – Performance Analysis Monitor

• R/3 Memory- Local Work Process Memory (individual para cada WP)

- Usada para- Executaveis- Dados e Stack- Buffer para database transfer- Local Roll area- Local Paging area

- Shared Memory (compartilhada por todos WP)- R/3 Buffer

- Usada para objetos globais como- Programas- tabelas de customizacao

- Extended Memory- Contem o User Context

- Variaveis- Listas- Tabelas Internas

- Heap Memory- Memoria alocada quando se esgota a Extended Memory

- Roll Buffer- Contem os pointers do User Context- Contem pointers para os programas usados pelo usuario- Autorizacoes- Report lists- Pode ser paginada no Roll File

- R/3 Paging Buffer- Contem objetos ABAP (não programas)- Context Independent Objects- Application Data para comandos especificos do ABAP

- EXTRACT- IMPORT TO MEMORY


133

- EXPORT FROM MEMORY- CALL TRANSACTION

- Pode ser paginada no Paging File

• Alocacao de Memoria- Roll

- Quanto menos dados para fazer roll, mais rapido o processo de ativaçao, desativacao da transacao- No Roll so existem as informacoes basicas, os ponteiros para os dados que estao na Extended Memory- Roll Area = Roll Buffer + Roll File

- Paging- Paging Area = Paging Buffer + Paging File

- R/3 usa mapping ao inves de Copying de memoria para

- Acesso rápido a tabelas internas e listas via pointers- Rapida troca de User Context- Uso de hardware com grande quantidade de memoria- Diminuir carga de CPU e disco- Porem isto precisa de memoria RAM suficiente

• Sequencia de Alocacao de Memoria para Dialog WP- Inicialmemte se aloca para o usuario uma porcao da roll area

- Esta porcao é definida no ztta/roll_first- Se definida como 1 significa alocacao minima pelo R/3 (+ ou – 100k)- A area total da Roll Area é ztta/roll_area

- A seguir aloca dados na Extended Memory - Extended Memory por usuario pode variar de 1Mb a 100Mb- Tamanho é definido por ztta/roll_extension- Ele evita que 1 usuario esgote a Extended Area

- Se o precisa de mais memoria do que o roll_extension ou acabou a Extended Memory - Usa o resto da Roll Area

- Se ainda precisa de mais memoria, aloca Heap Memory - O WP é marcado como PRIV e vai ser reconstruido ao final desta transacao- Isto porque a Heap Memory alocada para um WP só pode ser endereçada por este WP- Para garantir que isto ocorra, o WP fica preso a esta transacao ate seu fim- Isto pode prejudicar o desempenho dos outros usuarios do sistema, que vai trabalhar com 1 WP a menos durante a execucao desta transacao- O limite para alocacao de Heap Memory é dado pelo parametro abap/heap_area_dia

• Sequencia de Alocacao de Memoria para Non-Dialog WP- Aloca para o usuario uma porcao da roll area ztta/roll_first- A seguir aloca dados na em/address_space_mb- Se precisar de mais memoria, aloca usa o resto da Roll Area ztta/roll_area- Se precisar de mais memoria, aloca heap abap/heap_area_nondia

• Liberacao da Heap Memory- O R/3 libera a Heap Memory depois do seu uso mas o Sistema Operacional não libera area de swap que por acaso tenha alocado- Para garantir esta liberacao, quando se passa do valor abap/heaplimit o R/3 marca o WP como sendo para restart automatico- Desta forma, o S.O. libera memoria e salva espaço no swap file


134

• Outros parametros relativos a memoria- rdisp/roll_SHM -> tamanho do roll buffer- rdisp/roll_MAXFX -> tamanho da soma do roll buffer + roll file- em/initial_size_MB -> tamanho fixo da extended memory- abap/heap_area_nondia -> tamanho da heap area para non dialog WP- abap/heap_area_total -> tamanho maximo da heap memory alocada para todos os WP

• Analysis Roadmap- Se houver problemas visiveis na ST02

- Muito R/3 buffer swap- Aumetar buffers do R/3

- R/3 extended memory full -> Max Used > 80% In Memory- Analise detalhada da memoria com MODE LIST- Se algum usuario tiver alto consumo de memoria, identificar e analizar a transacao e o programa- Se houver memoria RAM disponivel, aumentar Extended Memory

- ztta/roll_first > 1024- colocar 1

- Roll Buffer esta cheio -> Roll Memory Max Used > 80% In memory- Aumentar rdisp/roll_SHM

• Zero Administration Memory Management- Simplifica gerenciamento de memoria do R/3- Aloca dinamicamente Extended Memory

- Permite Extended Memory crescer até em/max_size_MB ou até esgotar o Swap do S.O.- Usa um novo parametro o PHYS_MEMSIZE

- Proporciona base para os outros parametros de gerenciamento de memoria- Torna desnecessario configurar em/initial_size_MB e abap/heap_area_total

• Extended Memory no NT- Cota do usuario

- Criado parametro em/adress_space_MB para ser usado no lugar do ztta/roll_extension

- ele determina valor da quota do usuario na Extended Memory- O valor default de ztta/roll_extension é 2 Gb, o que torna parametro sem efeito

- Incrementos da Extended Memory- Na ativacao, a Extended Memory é alocada no valor do em/initial_size_MB- A quantidade de Extended Memory pode pode ser incrementada até em/max_size_MB, desde que aja memoria virtual para isto- Provavelmente relacionado ao PHYS_MEMSIZE


135

Capítulo 5 – Hardware Capacity Verification

• O que é Hardware Bottleneck- Para o usuario

- Tempo de resposta ruim- Para o sistema

- CPU perto de 100%- Muitos processos aguardando por CPU (Load Average)- Paginacao alta- Alto tempo de acesso a disco- Alto tempo de resposta da rede

• Razoes- Sizing errado da maquina- Distribuicao incorreta da carga- Comandos SQL muito gastoes- Disk layout incorreto ou discos lentos- Topologia da rede incorreta

• Hardware Analysis Roadmap para CPU- CPU mais de 80% ocupada na ST06- Existem mais servidores

- Redistribua a carga- Não existem mais servidores

- Chamar ST06 Top Processs CPU e verificar que consome CPU- Processos do R/3

- Verificar com SM50 ou SM66- Analisar a transacao ou o report

- Processos do Banco- Monitorar DB via ST04 - Analizar comandos SQL

- Processos Externo- Parar o processo ou- Redistribuir processo para outra maquina

• Hardware Analysis Roadmap para Memoria- Paginando mais de 20% da memoria RAM por hora na ST06- Existe memoria livre em outros servidores- Não existe memoria liver em outros servidores

- File System Cache > 10% RAM__________________________________________________________________________________________________________


- Diminuit File System Cache- Chamar ST02 Setup/Tune Buffer e entrar em Mode List

- Encontrar programas que consomem muita memoria- Analisar estas transacoes ou relatorios

• Response Time- Componentes

- Wait Time

- Database Request Time- Roll Time- Load Time- Enqueue Time- Processing Time

- Processing Time = Response Time – Wait Time – DB Request Time – Roll Time – Load Time – Enqueue Time

• Hardware Analysis Roadmap para Workload- Wait Time > 10% Response Time na ST06- Significa que os processos estao rodando lentamente, bloqueando o WP- Indica um problema geral de performance- Pesquisar em

- Tempo alto de acesso ao DB (+ 40% do response time – wait time)- Database analysis

- Tempo alto de processamento (+ de 100% do CPU Time)- Hardware bottleneck

- Tempo alto de Load (+ de 50ms)- Memory configuration (Program buffer)- Talvez tirando os programas da memoria e os regerando na carga

- Tempo alto de Roll in / Roll out (+ de 20 ms)- Memory configuration (Extended Memory ou Roll buffer)

• Regras gerais para configuracao de memoria- Memoria para o DataBase (1 por sistema)

- 20% do total de memoria de todos os servidores do sistema- Memoria para Buffer R/3 (1 por sistema)

- De 200 Mb a 500 Mb- Memoria para Work Process

- 7,5 Mb por WP- Extended Memory

- 5 a 10 Mb por usuario

• Otimizacao de memoria- Se temos 100 Mb de RAM, o used memory não deve passar de 150 Mb- Swap Space deve ser de ao menos 2Gb e 3 vezes o tamanho da memoria RAM- Workload

- Depende dos modulos e do numero de usuarios

• Regras gerais para configuracao de CPU- O DB deve usar de 10% a 30% da CPU do sistema- Update WP deve usar de 10% a 20% da CPU do sistema


137

Capítulo 6 – Expensive SQL Statements

• Consequencias- database busy- cpu alta- WP bloqueados- Muitos blocos removidos do DB Buffer

• Como detectar- Em programas com DB Request Time muito grande em relacao ao Response Time- SQL statements com muitos buffers gets- Para cada comando detectar

- Tabela- Clausula WHERE- Indices usados- Relat ou trans do comando

• Formas de encontrar- ST03 > transaction Profile transacao ou programa- SM50 / SM66 tabela e programa ou transacao- ST04 > Detail Menu > SQL Request tabela e indices via explain (mas sem programa)- ST05 tabela e indices via explain- SE12 > Utilities > Where Used para achar programa que usa tabela

• Formas de Encontrar II - No Transaction Profile

- Analisar quem tem tempo de Response Time alto e ver onde demora (DB por exemplo)- No Work Process Overview

- Ver se um relatorio fica rodando muito tempo e que tabelas ele acessa- Continuar pesquisa pela ST04 (database process monitor) para ver comando SQL- E pela DB01 para ver exclusive Locks

- ST04 (Database Monitor: Oracle Sessions)- Mostra ainda as sessoes Oracle que estao ativas por Oracle Process com o comando SQL sendo executado- Pelo PID posso relacionar com SM50 e saber quem é

- DB01 (Exclusive Lock Waits)- Permite verificar lock holder e os waiters- Permite cancelar transacao que esta segurando o lock (ela vai sofrer rollback)

• Monitorando Buffer Gets / Disk Reads- Via ST04 > Detail Analisys Menu > SQL Requests- Classificar por Buffer Gets e verificar numero de Bufgets/Record e Total Execution- Se estiver alto, tentar fazer tunning


138

- Olhar comando SQL e tentar indentificar de onde é- ABAP é tudo em letras maiusculas e entre aspas- Ferramentas e selecao das tabelas de basis não tem aspas- Letras minusculas são comando recursivos do Oracle

• Traces- Via ST05- Só um por instance por vez- Tamanho maximo do trace é definido em rtrc/max_diskspace (maximo é 16Mb)- Com esta tecnica da para detectar problemas de rede entre o Appl Server e o Db- Mostra FETCHs com o numero de registros tranferidos

- FETCH é a leitura de dados dos blocos já na memoria

• WHERE USED List- Via SE11 / SE12- Se procuramos que programa usa uma tabela, podemos ter muitos programas como resposta

- Neste caso pode não ser muito util

• RoadMap

- SM50 (pega Tabela e Relat ou Trans)- ST04 (no Oracle Session verifica comando)- Explain

- ST03 Transaction Profile (Pega Transacao com alto Wait Time)- ST05 (faz trace)- Explain

- ST04 (Shared SQL Area verifica quem tem muitos BufferGets)- Explain

• Tipos de Expensive SQL Comands - Le muitos blocos e devolve muitos registros

- Processa alto numero de registros- Caminho de acesso esta adequado- Buffer get per record < 5- Menos de 100 ms por FETCH (no Trace)- Podemos tentar modificar o codigo ABAP para diminuir o numero de regs tranferidos

- Le muitos blocos e devolve poucos registros- Estrategia de acesso inadequada- Buffer gets per record > 5- Mais de 500 ms no FETCH- Podemos criar um indice- Podemos atualizar estatisticas- Podemos reescrever comando ABAP (talvez tornando a clausula WHERE menos complexa)- Podem ser comando com pooly qualified commands, ou seja

- Comandos que selecionam dados que não são indice- Comandos que usam indices incorretos- Comandos que usam indice mas o full scan seria mais eficiente


139

- Comandos que usam indice, mas este indice esta especificado incorretamente

• Uso de indices nos comandos SQL- Saida do Explain

- Access Method

- Table Full Acess- Index Range Scan- Index Unique Scan- Concatenations quando existe OR ou IN- Sort- Index Used diz qual o indice que vai usar

- Join Method- Nested Loop- Hash Join

• Regras para criar novos indices- Usar em campos seletivos

- se precisar ler + de 5% da tabela, otimizador usa Full Scan- Poucos campos no indice (não mais de 5)

- Alteracao de dado que faz parte do indice exige esforço computacional- Aumenta espaco do indice- Se os campos indice forem só de leitura, pode colocar mais de 5- Dicionario ABAP fixa este limite em 16

- Colocar o campo mais seletivo no comeco do indice- Evitar definir indices para tabelas de dados transacionais- Não criar indices para as tabelas de BASIS

- DD*- D010*- NAST

- Antes de criar um indice, veja se não existe nenhum indice faltando no R/3 (DB02)- Antes de criar um indice, verifique as notas do OSS

• Optimizer- Pode-se encontrar o Last Statistics Date no Explain Plan- Atualizar estatisticas 1 vez por semana- DB20 atualiza estatisticas para 1 tabela especifica- Estatisticas podem estar velhar ou terem sido obtidas com um baixo nivel de accuracy- Estatisticas podem falhar se os dados não estao uniformemente distribuidos- Tips e Trick podem ajudar a desenvolver programas ABAP eficientes- Podemos ainda comparar o tempo de resposta de 2 comando SQL (escrevemos os 2 e a transacao executa e dá o tempo de cada um)

• Tunning Roadmap- Quando analisarmos comandos SQL

- Tranfere muitos registros ?- Otimizar o codigo ABAP

- Usar o Explain- Se esta usando o melhor indice

- Usar metodos especiais para tunning do database- se não esta usando o melhor indice


140

- se as estatisticas estao atualizadas- atualizar estatisticas

- A clausula WHERE é muito complexa- reescrever a clausula WHERE

- Existem missing index ?- Recriar os indices

- Devemos criar novos indices ?- Analisar e criar se necessario


141

Capítulo 7 – Table Buffering

• Buffers do R/3- Repository Buffers- Program Buffer- Table Buffer- Roll and Paging Buffer- GUI Buffer- Calendar Buffer

• Table Buffering- Tipos

- Full- Generic -> só para o primeiro campo chave da tabela- Single Record (partial buffering)- Há ainda um instllation-dependent buffering, onde se bufferiza a tabela dependendo da instalacao, esta é uma decisao do programa

- Definido via SE13 (Technical Settings)

• Buffer Sincronization- Necessario quando existe mais de uma instancia e ocorrem updates na buffer tables- Buffer outras instancias não ocorrem imediatamente

- Durante um certo tempo as outras instancias leem dados velhos- Tabela DDLOG informa quais tabelas foram alteradas e precisam ser recarregadas- Parametros correlatos

- rdisp/bufrefmod- sendon,exeauto -> se há mais de 1 instancia- senoff,exeauto -> se há so uma instancia

- rdisp/bufreftime- tempo de refresh

• Granulacao da invalidacao- Full -> toda a tabela- Generic -> todas as chaves iguais- Single record -> so aquele registro- Cuidado: o texto fala que isto é valido em WORK AREA MODE- Pode existir outro tipo de MODE ???

• Bypass do Buffering- SELECT ... BYPASS BUFFER- SELECT DISTINCT- SELECT FOR UPDATE- Funcoes de COUNT, MIN, MAX, SUM, AVG- SELECT de view que não sejam projection view- WHERE que contenha IS NULL


142

- ORDER BY que não da Primary Key- Comandos SQL nativos- O DBInterface não faz estas funcoes, por isto solicita ao DB, bypassando o buffer- O DBInterface não faz pesquisas por indices secundários

- Para Single Record (Partial Buffer) - Tem que usar o comando SELECT SINGLE- Se usar SELECT * FROM -> não usa buffer

- Para Generic Buffer - Se não especificar a chave generica -> não usa buffer

• Criterios para Buffering de Tabelas- Tabelas menores que 1 MB

- Somente bufferizar tabelas com mais de 10 MB em circunstancias especiais- Pouco alteradas (menos de 1% dos acessos para alteracao)- Possam estar defasadas em relacao a outras instances por 1 ou 2 minutos- Somente bufferizar novas tabelas se houver espaco no Table Buffers- Transacion Data nunca é bufferizada- Master Data normalmente não é bufferizada- Customizing Data normalmente é bufferizada

• Buffer Strategy – Condition Tables- Tabelas de preço, descricao de materiais, parter,..

- Axxx, Bxxx, Cxxx, Dxxx, KOTExxx, KOTFxxx, KOTGxxx- xxx até 499 é tabela SAP, manter como fornecida- acima de 500 é do cliente, verificar e bufferizar se necessario

- outras recomendacoes para bufferizar- mais de 300 sequential reads/dia, menos de 1% de alteracao, menos de 1 Mb- mais de 1000 sequential reads/dia, menos de 0,1% de alteracao, de 1 a 5 Mb

• Tarefas a realizar- O que procurar

- Verificar tabelas que não estao bufferizadas, mas deveriam estar- Verificar tabelas que estao bufferizadas, mas não deveriam estar

- Verificar tabelas via ST10 (Table Call Statistics)- Roadmap

- Tabelas bufferizadas com grande numero de Invalidations - Tabelas bufferizadas com grande Buffer Size

- So aparece o tamanho para tabelas bufferizadas- Se não estao podemos descobri-lo na DB05 (Analisys of Table according Index)

- Tabelas bufferizadas com grande numero de Rows Affect no Database- Tabelas não bufferizadas com grande Total ABAP Processor Request

• Problemas relacionados a Table Buffering- Podem aparacer programas com alto tempo de resposta devido ao DB - Verificar na ST03 > Transaction Profile

- Detectar programas com DB Reponse Time > 40% do (Response Time – Wait Time)- Entrar na STAT para estes programas / transacoes e verificar se ocorreram buffer reloads para ele

- > Clicar em DB e verificar mensagem TABLES WERE SAVED IN THE TABLEBUFFER- Se houver muitos statistical records assim, indica problemas


143

- Entrar na ST10 para verificar a tabela

• ATP Server- Servidor de Table Buffer das tabelas transacionais mais usadas em alguns modulos

- RESB, VBBE -> modulo PP, SD, MM- Servidores comunicam-se via gateway para efetuar alteracao de compra e previsao de materias- Para customizar

- memoria - em/initial_size_MB > 256- rdisp/roll_SHM > 4000

- RFC - rdisp/tm_max_no > 500- rdisp/max_comm_entries > 500- rdisp/max_conn > 500

-- atp server

- rdisp/atp_server = <nome> instance profile- atp_server deve residir no enqueue server- precisa de + de 5 Dialog WP

- rdisp/obj/buffersize = 20000 (sem atp é 4096K)- rdisp/obj/max_objetcs = 20000 (sem atp é 5000)

- como usa 2 entradas dá para 10000 objetos- Monitoracao

- Buffers -> Qualidade, tamanho e numero de acesso - Enqueue -> ver se ficou algo preso a toa -> mais de 1 dia


144

Capítulo 8 – SQL Chache Analysis

• Nothing do to

Capítulo 9 – Introduction to Shared SQL Area

• Expensive SELECT Statements- Comandos de usuario (USER CALLS) que acessam mais de 20 blocos no buffer (reads) são comandos que devem ser analizados

- Relacao de 1 : 20- Relacao entre Physical Read e Reads é chamada Hit Ratio

- Deve ser superior a 94 %- Para este numero ser aceitavel, deve-se considerar que não haja Expensive SQL Commands no sistema, pois eles podem fazer este numero subir- Como base, podemos considerar 94% desde que a relacao User Call por Reads não ultrapassem 1 para 20- Verificar via ST04 > Detailed Analisys Menu > SQL Request


145

Capítulo 10 – Analysing SQL Statements

• Tipos de Expensive SQL Statements- Many buffer gets and only a few records per executions

- WHERE mal especificado- Falta de indice- Indice mal especificado- Indice onde não deveria existir indice

- Many buffer gets and many records per executions- Verificar programa ABAP- Verificar processo de negocio- Melhorar a selecao feita pelo usuario

• Analise via ST04- Classificar por Buffer Gets

- Prejudicial a performance do sistema como um todo- Classificar por Disk Reads

- Prejudica performance de acesso aos discos- Classificar por Record

- Prejudica performance do DB e do Appl Server

• Mais Analise via ST04- Muitos Buffer Gets

- Procurar por comandos que representem + de 5% do total de Buffer Gets- Verificar comandos que tem uma taxa maior de 1:20 de User Call por Reads

- Muitos Buffer Gets per Execution - Devem tem poucas execucoes- Não devem ser executados em momentos de pico

- Muitos Buffer Gets per Record - Não devem ter um indice apropriado

- Muitos Records per Execution - Logica inadequada (talvez comando CHECK ao inves de WHERE)

- Muitos Disk Reads - Verificar comandos com mais de 2% do total de Phisycal Reads - Pode ocorrer por

- Tabelas muito grandes- Baixo numero de linhas por blocks (reorganizar ?)- Dados paginados para fora do buffer- Muito uso de Full Scan nesta tabela

• Execution Plan- Custo representa o numero estimado de buffers a serem lidos ou de acessos ao disco- Valor 0 significa que não existe estatistica- Tabelas com menos de 50 Mb realizar estatisticas com COMPUTE- Tabelas com mais de 50 Mb realizar estatisticas com ESTIMATEDED 10% ou 50 Mb


146

Capítulo 11 – Update Statistics

• Update Optmizer Statistics- Necessária para o Optimizer encontrar o melhor caminho de acesso- Feita em 2 fase

- SAPDBA –checkopt PSAP%- SAPDBA –analyze DBSTATC0

- Ao meno 1 vez por semana- Pode ser feita

- COMPUTE- ESTIMATED- No Statistics, quando

- Tabela muda muito- É mais economico usar o Rule Based Optmizer- Isto é usado em tabelas Pool, Cluster e SAP Update

• Two Phase Strategy- SAPDBA –checkopt PSAP%

- Pode ser schedulado via DB13 (Check Optmizer Statistics)- Verifica necessidade de atualizacao das estatisticas- Marca necessidades na tabela DBSTATC ativando o flag TODO- Tabela contem tambem o metodo de analise (COMPUTE ou ESTIMATED e sua porcentagem)- Damos manutencao na DBSTATC via DB21

- SAPDBA –analyze DBSTATC0- Pode ser schedulado via DB13 (Create New Optmizer/Space Statistics)- Usa comando ANALYSE do Oracle e atualiza estatisticas

- Transacao DB02 - Mostra um resumo de como estao as estatisticas- Quantidade de tabelas com mais de 1 semana sem atualizar estatisticas

- Transacao DB19- Atualiza estatisticas para uma tabela especifica

- Transacao ST03 > Detailed Analisys Menu > SQL Request- No Explain, com duplo clique no nome da tabela, mostra resumo das estatisticas


147

Capítulo 12 – Identify Coding

• Roadmap para encontrar Comandos SQL em programas- Identificar o comando (e a tabela)- Pesquisar WHERE USED LIST (SE11)- Se achar

- Encontrar nome do desenvolvedor (SE38 > Display > Goto > Attributes)- Avisar responsaveis (se for SAP, avisar via OSS)

- Se não achar (codigo gerado Runtime ou Native SQL ou Where Internal Table Empty)- Usar SM66 para encontrar programas e processos que o utilizem

- Pode-se especificar Select Process e especificar uma tabela- Somente as transacoes ou relatorios que acessam esta tabela aparecerao

- Usar ST04 > Detailed Menu > Oracle Session Manager- Mostra os Shadow Process do Oracle e o PID do comando sendo executado- Mostra ainda o comando que esta sendo executado- Se for um comando expensive, pelo PID dele e pela SM66, podemos identificar o programa/transaca/usuario

• Diferencas entre o ABAP OPEN SQP e o Comando SQL emitido- Comando IN ITAB

- Comando WHERE xxx IN I1- -> I1 é uma tabela que controi a clausula Where

- Comando FOR ALL ENTRIES- Comando FOR ALL ENTRIES IN ITAB- –> toda as entradas da tabela ITAB serao checadas- -> isto ocasiona um SELECT com inumeras clausulas OR seguidas

- Projection Views- Se o SELECT não é *, pode-se tratar de uma R/3 Projection

- Não é projection Oracle, e sim do R/3- Não é possivel encontrar o programa com o WHERE USED, porque ele usa a View- Para encontrar, usar WHERE USED de Table em View- Depois pesquisar as Views

- Relatorio RSSTATUS- Lista a Application Area, Table, Transaction, Program e Data Elements- Informamos um deste e ele nos lista os outros- Enviamos a listagem para o desenvolvimento para pesquisa


148

Capítulo 13 – Workflow and Reporting

• Reponsabilidades- System Administrator é reponsavel pela performance

- Analisa queries- Sugere indices

- Usuários são os reponsaveis pelas informacoes- Visao funcional

- Desenvolvedores trabalham olhando os dois ambientes- Desenham e codificam - Implementarm indices

• Documentos do Workflow implementados pela SAP- Executive Summary of Expensive Commands

- Documentacao feita pelo BASIS- System Administration Change Request

- Solicitacao feita pelo BASIS- Development or Application Departament Feedback

- Devolve a CR com a alteracao necessaria- BASIS pode monitorar a seguir

- Information Required from User- BASIS envia documento questionando usuario

- Programa pode ser rodado em batch ?- Usuario pode melhorar criterio de selecao para agilizar o processo ?

• Se for comado da SAP- Pesquisa OSS (usando o nome da tabela, o programa, a palavra performance ou indice)- Se não encontrou, abre OSS para SAP- Cuidado

- Transacoes SART e SE16 são browser, dependem do input do usuario e podem demorar- Se o comando veio de um matchcode


149

Capítulo 14 – Index Utilization

• Indices- Primario (sempre único), secundario e secundario de chave unica- Se nenhum dos campos indice forem especificados num WHERE, é necessario FULL SCAN- B*Tree do Oracle tem normalmente até 4 niveis- Leaf Blocos são o ultimo nivel da arvore- Index Unique Scan

- Possivel com a chave única completa- Acessa 4 blocos para recuperar um registro

- Index Range Scan- Quando nem todos os campos da unique key estao especificados- Em indices secundarios não unicos, tambem é usado este metodo

- Full Table Scan- Usado quando nenhum dos campos colocados no WHERE é o primeiro campo da chave- Usa uma pequena memoria para pesquisa, não mantendo todos os blocos na memoria

- Unselective Index Range Scan- É um Index Range Scan- Ocore quando campos do WHERE são pouco seletivos (CLIENT) ou fazem parte do DATA- Os dados lidos ficam no buffer (pode causar grande swap de blocos sdo buffer)- Se uma grande parte do indice for lido, pode ser melhor o Full Scan- O Cost Based Optmizer não escolhe acesso por indice se ele acha que isto vai acontecer, porem as estatisticas podem estar desatualizadas

- Processing not Fully Qualified Indexes- Quando faltam campos no meio da chave para completar o indice- Neste caso, os campos após a interrupcao são usados apenas para filtro- Resolve tudo no indice, mas tem que ler varias linhas para processar o request

- Outros Execution Plan- Concatenation -> usado quando temos IN ou OR, acessa o indice varias vezes- Nested Loop -> Join de tabelas, da menor para a maior (Views p.e.)


150

Capítulo 15 – Criacao de Indices

• Criacao de Indices- Antes de criar, verificar se não esta faltando (DB02 > Missing Index)- Desaparecimento de indice pode ocorrer na reorganizacao (todos indices são dropped)- Deve existir no dicionario e no DB, senao acusa falta

- Indice deve existir, estar ativo (activated) e ter sido gerado- No Dicionario ABAP pode trazer confusao, mas não afeta performance

• Regras para criacao de indices- Usar campos seletivos- Usar poucos campos- Usar campos seletivos no comeco do indice- Não criar indices pouco seletivos- Criar poucos indices- Não criar um indice que possa ser usado equivocadamente- Não alterar indices da SAP (a menos que ela peça)

• Analise de Seletividade- Via DB05 ou SQLPlus

- Estas analises são custosas para o sistema- Analisa o numero de registro retornado para cada chave (combinacao)- O bom é quando muitas chaves retorna muito pouco registros

• Ordem preferencial de Otimizacao- Verificar Missing Index- Atualizar estatisticas- Mudar o codigo de programas ABAP de forma a utilizar indices existentes- Mudar o indice, de forma a atender as queries normais e mais as expensives- Criar um novo indice para satisfazer a query


151

Capítulo 16 – Similar Statements

• Comandos que- Usam o mesmo Access Path- Tem a mesma clausula WHERE ou clausulas muito parecidas- Possuem diferentes entradas na SQL Shared Area- Podem ser melhorados atraves de um tunning- Individualmente não são expensive, mas em conjunto podem ser

• Para encontrar- Na Shared SQL Area procurar por comando com

- mesmo numero de Buffer Gets / Execution- mesmo numero de Buffer Gets / Record

- Porque ?- Se o comando é o mesmo, ele deve possuir as mesmas caracteristicas

• Porque acontece ?- Comandos só são iguais se tem a mesma string- String diferente pode acontecer se

- Existem numero diferentes de IN - Existem numero diferentes de OR- Existem diferentes fields no WHERE- São escritos em minusculas e maiusculas

• Solucao- Trocar codigo ABAP- Usar FOR ALL ENTRIES ao inves de IN- Otimizar o comando (como nos não similares)


152

Capítulo 17 – View Processing

• Tipos de Views- Projection -> reduz numero de campos a serem vistos pelo programa- JOIN View -> conjugam dados espalhados por diversas tabelas

• Processamento de Views- Nested Loop

- Determinado pelo Optimizer- Escolhe tabela que supostamente retornará menor numero de linhas para ser primaria- A partir desta acessar as outras

- Sort Merge Join- Dados das tabelas são lidos e é feito Sort de acordo com as condicoes do Join- Depois é feito o merge- Só é bom se vai selecionar muitas linhas das tabelas

Capítulo 18 – Polled and Clustered Table

• Polled and Clustered Table- Varias tabelas logicas armazenadas numa tabela fisica- Não podem receber novos indices- Não podem ser processadas por comandos de SQL Nativo- Polled

- Chaves primarias diferentes armazenas num campo chamado VARKEY- Dados armazenado no VARDATA- Campo TABNAME armazena o nome da Polled Table- Definidas no Dicionario ABAP com tipo POLLED TABLE- O WHERE tem LIKE no VARKEY já que a chave é parcial- Normalmente tem muitas tabelas dentro do Poll- Não dá para ver qual é a Polled Table sendo acessada ns Shared SQL Area- Polled Table usam metodo de acesso definido pelo Rule Bases Optmizer- Analise de problemas

- Via ST10 (para descobrir qual tabela tem muitos dados sendo lidos)- Verificar qual a Poll Table aparece com muitos fetchs- Tabelas Polled aparecem com o pool name na frente do nome da tabela- Usar WHERE USED LIST do dicionario ABAP

- Via SM66 (para descobrir qual tabela esta sendo acessada ineficientemente)- Não da para usar ST10 (só totais de acesso) nem Oracle Session (porque o comando é sempre o mesmo- Verificar programa pela SM66- Pelo Editor ABAP verificar a tabela

- Clustered- Chave primarias iguais e dados logicamente dependentes entre si- Campo VARDATA tem os dados de cada tabela- Normalmente há poucas tabelas dentro do Cluster- Podemos especificar um numero diferente de campos na chave em cada SELECT


153

- Isto ajuda a achar o programa- Clustered Table usam metodo de acesso definido pelo Rule Based Optmizer

- Analise de problemas- Via ST10 (para descobrir qual tabela tem muitos dados sendo lidos)

- Verificar qual a Poll Table aparece com muitos fetchs- Tabelas Clustered aparecem com o pool name na frente do nome da tabela- Usar WHERE USED LIST do dicionario ABAP

- Via SM66 (para descobrir qual tabela esta sendo acessada ineficientemente)- Verificar programas pela SM66- Pelo Editor ABAP verificar a tabela

- Via Repositorio ABAP (para descobrir tabelas sendo acessada ineficientemente)

- Listar tabelas num Cluster- Listar programas que acessam as tabelas- Editar programas e validar codigo- Pelo Editor ABAP verificar a tabela

• Erro comum no acesso a Clustered Table- Selecionar apenas campos do DATA e não do KEY

• Ordem preferencial de Otimizacao- Para Pooled Tables

- Especificar mais campos chaves no ABAP- Bufferizar a Poll Table se possivel- Tirar a Table do Pool (torna-la transparente e com indice)

- Para Clustered Tables- Especificar somente campos chaves no ABAP- Investigar tabelas alternativas que contenham o mesmo dado- Tirar a tabela do Cluster


154

Capítulo 19 – Apendix

• Problemas e solucoes- Expensive Statementes and SAP Table Buffers

- Se ocorrer verificar se tabelas estao bufferizadas corretamente- Não são muito alteradas- Estao Single Key mas são lidas sequencialmente- Tabela é pequena suficiente para estar no buffer

- Solucoes- Determinar a buferizacao apropriada- Aumentar SAP Table Buffer

- ORA-1555 – Shapshot Too Old - Para suportar consistencia de leitura, Oracle pega dados do segmento de rollback- ORA-1555 é quando o segmento foi overridado enquanto estava sendo usado- Causas

- Expensive Queries- Long processing between queries

- Para analisar- Ver shortdump (erro DBIF_RSQL_SQL_ERROR)

- Solucoes- Mudar o codigo para processar query de forma mais eficiente- Reestruturar nested selects- Outras otimizacoes (criar indices)

- Expensive Sort Statements (ORDER BY) - Existem Memory Sort e Disk Sort- São exibido na ST04 (linha SORTS)- Se precisa de disco usa PSAPTEMP- Para analisar sobrecarga, usar ST04 > File System Monitor- Se um dos data file mais acessados for o do TEMP, é problema- Para identificar quem faz muito Sort, verificar coluna SQL SORT no Database Monitor

- A seguir ver se o numero de Gets / Execution ou Records /Execution esta alto- Se não estiver alto não é problema, é um pequeno sort

- A seguir entrar na SQL Request e ver o comando e tentar identificar programa- Solucoes

- Não fazer sort- Selecionar e sortear poucos registros- Sortear por colunas onde existe indice- Classificar no ABAP ao inves de no DB

- Outras otimizacoes (criar indices)- Fragmented Index

- Se não der para descobrir porque comando demora, verificar fragmentacao do indice- Sintomas: muitos Buffer Gets / Execution embora o indice seja o mais apropriado- Muitos Buffer Gets / Record embora o indice seja o mais apropriado- detectar pela DB02 > Table and Index > B*Tree analysis


155

- reorganizar se- fill level < 20% (ou seja esta quase vazio)- fill level < 50% e usado frequentemente

- Recriando um índice

- Verificar se há espaco no PSAPTEMP- Durante periodos de baixa atividade do sistema- A tabela pode ficar locked durante este periodo- Não pode rodar se exite usuarios utilizando a tabela ou o indice

- Shared Memory Problems- Comandos SELECT...IN ITAB vira uma series de OR- Cada OR consome o mesmo que um comando, ou seja, 20K- Se houverem 600 OR o comando consome 12 Mb- Isto pode causar falta de espaco na Shared Memory e pode ate abendar o processo- Para melhorar isto usar FOR ALL ENTRIES IN xxxxxx WHERE campo = campo_auxiliar- Isto causa a criacao de uma serie de SELECTS ao inves de um único com OR


156

Capítulo 20 – Technical Optimization of ALE Processing

• ALE- Usado para ligar sistemas R/3 com outros sistemas R/3 independentes- Interface que proporciona funcoes de alto nivel para troca de dados entre 2 ou mais sistemas- Possue suas proprias tabelas e gerencia conversao de dados, comunicacao, enderecamento e manuseio de erros- Proporciona interface para alguns cenarios de negocio predefinidos- Pode distribuir

- Master Data -> Cadastro de materiais, Clientes, etc- Transactional Data -> Contratos, Ordens de Compra- Control Data -> Customizing Data que precisam ser sincronizados

- Funcionamento interno do ALE- ALE transfere IDOC – Intermediate Documents- Cada IDOC contem 1 objeto de negocios (1 ordem de vendas com seus itens)- Fase 1 – Sender

- IDOC´s são criados pelos modulos de aplicacao- A aplicacao cria o Master IDOC, a partir deste Master são criados os Comunitactions IDOC, 1 para cada receiver- ALE armazena estes IDOC´s no seu database para envio posterior para os receiver- IDOC´s são armazenados num formato proprietario R/3 em ASCII

- Fase 2 – NetWork- Baseado em informacoes de controle dos IDOC´s (que ficam na IDOC DB), se encontra o receiver- Cada documento é encaminhado para apenas 1 receiver- Comunicacao com o receiver é TCP/IP e CPI-C

- Fase 3 – Receiver- Receiver armazena os dados no seu proprio DB- A partir deste ponto as aplicacoes podem buscar os IDOC´s e processa-los- O documento foi recebido, porem não a garantias de que esta correto pois podem existir inconsistencias (p.e. Grupo de Vendas não existente)

- Isto deve ser tratado pela aplicacao e comunicado via ALE Auditing Messages

• Sender Details – meios de criar IDOC`s- Aplicacao cria Change Pointers para processamento posterior

- Somente para Master Data- A aplicacao não cria o IDOC diretamente, mas posterga esta tarefa para processamento posterior

- Criacao de IDOC´s pode consumir muito recurso, é melhor fazer em momentos de baixa atividade do sistema

- Tabela BDCP contem as chaves dos dados a serem usados para geracao do IDOC e o tipo de operacao (Insert, Delete, Update)- Relatorio RBDMIDOC le BDCP e gera IDOC´s

- Podemos rodar em batch ou online via BD21


157

- Através de customizacao da SALE podemos definir que um tipo de mensagem não mais gerará IDOC´s e sim Change Pointers

- Isto é da interface, não da aplicacao- Outros objetos relacionados

- Relatorio RBDCPCLR -> Clear Change Pointers

- Relatorio RBDTBD22 -> Mapeia Change Pointer e IDOCS- Tabela BDCPS -> Status dos Change Pointers- View BDCPV -> Join da BDCP e BDCPS

- Aplicacao cria IDOC´s diretamente- Usado para normalmente para Transaction Data mas pode ser usado para Master Data- O IDOC é criado imediatamento o IDOC DB

- Aplicacao cria uma Message Entry para processamento posterior- Usado para Transaction Data- Gravamos dados de controle na tabela NAST- Se o processamento é imediato, é automaticamente criado um IDOC no IDOC DB- Se não é imediato, o IDOC é criado quando chamamos o relatorio RSNAST00- A vantagem de fazer não imediato é que os dados não ficam em enqueue. Se o tempo de enqueue é critico, esta tecnica é melhor

• Metodos de Comunicacao- TRFC – Transactional Remote Function Call

- Usado normalmente quando ligamos sistemas R/3 externos- Neste metodo existe uma fila (TRFC Queue) com os dados a serem transmitidos

- A fila é implementada nas tabelas ARFCSSTATE e ARFCSDATA- Podemos monitorar esta fila via SM58- O TRFC implementa uma serie de chamadas que garantem a chegada dos dados

- O processo le o IDOC do IDOC DB e o coloca na TRFC Queue para ser transferido- Quando os dados chegam na TRFC Queue destino, é ativado um processo de inclusao do mesmo no IDOC DB de destino- Quando este processo esta completo, é enviada uma mensagem para a origem que causa a delecao do request da TRFC Queue de Origem

- Se ocorrerem erros de comunicacao depois do IDOC ter sido tirado de sua fila e colocado na TRFC Queue, o IDOC só é informado quando rodamos o relatorio RDBMOIND

- Faz parte do menu da BALE- FTP – File Transfer Protocol

- Usado normalmente para EDI ou sistemas não R/3- Customizado pela SALE- Relatorio RSEOUT00 transforma IDOC´s em arquivos sequenciais- FTP envia arquivos pela rede para o receiver- Programa RSEINB00 le os sequenciais e inclui no IDOC DB- Transacao WE12 converte o file num inbound file

• Comunicacao do R/3 com External Programs- Feita atravez do SAP Gateway- Pode se comunicar com External Programs registrados ou não

- Se forem registrados- Comunicacao é feita através de SEND DATA- Registro é feito na SM59 - Registration melhora performance

- Se não forem registrados- Comunicacao é feita através de START PROGRAM


158

- A cada transferencia o programa deverá se ativado no receiver- O program start deverá ser feito via gateway

- Pode-se fazer Multiple Registration of Programas

- Isto permite parallel processing de IDOC´s entre o sender e o receiver- Implica que o programa chamado deve ser capaz de processar em multitask- Perde a serializacao dos IDOC´s

• Comunicacao de External Programs com o R/3- Não existe conceito de registro- O programa externo faz logon no R/3 e transfere dados- A conexao pode ficar ativa e o external program enviar dados de tempos em tempos

• Detalhes do processo Receiver- Pode ser feito via

- Application Modules Update- O processo de Inbound pode chamar diretamento os modulos de update das aplicacoes correspondentes à mensagem que chegou- É mais rápido mas possue menos consistencias

- Call Transaction Using ...- O processo de Inbound pode gerar Batch Input e emitir o comando CALL TRANSACTION USING ... para a transacao que cria o application data- É mais lento mas todas as consistencias são feitas durante o Input

• IDOC Processing Options- No Sender

- Scheduled -> via report RSEOUT00 - Vantagens

- Podemos gerar Packets- Distribuicao da carga no tempo

- Processing mode Parallel -> muitas transfers podem estar em curso ao mesmo tempo- Unidade de Processamento pode ser

- Single IDOC- Packets

- Immediate - Em alguns processos de negocio, a transferencia precisa ser imediata- Processing mode Parallel -> muitas transfers podem estar em curso ao mesmo tempo- Unidade de transferencia

- Sempre Single Idoc- No Receiver

- Scheduled _-> via report RBDAPP01 - Vantagem é a melhorar work load rodando o processo em momentos de baixa carga- Outra vantagem é que menos Dialog WP serao usados para processamento de Inbound- Neste relatorio definimos qual é o Packet Size que o Inbound terá- Podemos especificar Packet Size de tamanho diferente do enviado originalmente- Sempre vai rodar num Dialog WP- Podemos especificar o Processing Mode desejado

- Sequential -> usa call RFC sincrono no mesmo Dialog WP


159

- Neste caso somente 1 IDOC é processado por vez- Util para não causar sobrecarga no sistema- Unidade de processamento pode ser

- Single IDOC- Caso especial de packets com 1 IDOC dento

- Usa um Dialog WP para processar este Single IDOC- Packets IDOC

- Contem sempre IDOC´s do mesmo tipo- Usa o mesmo Dialolg WP para processar todo o Packet

- Parallel -> usa call ARFC asincrono em outro Dialog WP- Podem causar sobrecarga no sistemas- São processados em Dialog WP e podem esgotar todos os Dialog WP- Unidade de processamento pode ser

- Single IDOC- Packets IDOC

- Immediate -> usa ARFC para processar IDOC´s - Neste caso o processo de Inbound é disparado logo após a chegada do IDOC- A TRFC é commitada logo após o IDOC ser armazenado do IDOC DB- Evita que se bloqueie o sender porque o recebimento é imediato

- Parallel -> usa call ARFC asincrono em outro Dialog WP- Unidade de processamento é determinada pelo Sender

• Funcoes basicas usadas no ALE- Remote Functions Processing

- RFC- RFC sincrono- O chamador conhecerá o resultado da chamada

- ARFC- RFC Assincrono- ABAP Call Function ... Starting New Task- Usada no parallel processing

- TRFC- RFC Transacional- Envia um grupo de chamadas ao receiver como numa transacao de database- Se uma falha, todas elas sofrem rollback- Usada para transferir IDOC´s

- Grupos RFC no ARFC- Definimos grupos de servidores do landscape na SM59- No ABAP usamos STARTING NEW TASK xxx DESTINATION IN GROUP yyyy- O message server pergunta aos servidores do grupo sua carga e escolhe para qual servidor enderecar a chamada- Se não houver recurso disponivel, chama na mesmo WP que originou o request

- Isto é feito normalmente, não é implementacao do grupo RFC- IDOC Database

- Cada IDOC contem uma chave de 50 bytes- EDIDC -> Control Data

- Contem 1 ou mais registros para cada IDOC- Mantem um historico do IDOC

- EDID2 -> IDOC Data- É uma cluster table (Cluster EDI30C)- Dados são comprimidos automaticamente


160

- Não é transaparente porq tem campos longos e alguns DB não aceitam (1000 bytes)

- EDIDS -> Status Data- ´READY FOR PROCESSING´

- ´SUCESSFULLY PROCESSED´

• Customizacao- ALE

- Distribution Model- Define como os dados vao fluir entre sistemas- Feita pela transacao SALE

- Partner Profile- Define os tipos de mensagens que serao trocadas entre os sistemas

- COMMUNICATION (SM59)- Logon User-id Definitions- RFC Servers - TRFC Scheduling on Communication erros

• Relatorios envolvidos- RSEOUT00 -> ALE Outbound- RSDAPP01 -> ALE Inbound- RSNAST00 -> Criacao de IDOCs via Message Entry para processamento posterior- RBDMIDOC -> Criacao de IDOCs via Change Pointers- RSARFCEX -> Reprocessamento de TRFC que falharam - RBDMANIN -> Reprocessamento de inbound IDOCs que falharam- RBDMOIND -> IDOC Status Update (fila x processado)- DBDCPCLR -> Reorganiza Change Pointer- RSARFC01 -> Reorganiza TRFC queue- RBDAUD02 -> Reorganiza ALE Audit

• Archiving- Via transacao SARA- Archive da tabela EDI30C- Programa de archive RSEXARCA (ele pode ler os IDOCs arquivados depois)- Archiving object para workitens é WORKITEM


161

Capítulo 21 – Content Analysis Toll and Optimization Methods

• Transacoes- BALE -> IDOC Monitor- -> Time Ditribution- -> IDOC Trace- SM37 -> Monitora jobs ALE (comecam com ARFC)- WE20 -> Configura Outbound Processing- -> Configura Inbound Processing- DB87 -> ???- SM59 -> Configura RFC destinations

• Regras para usar ALE1. Evitar modo IMMEDIATE (no Sender e no Receiver)2. Usar Packets (1000-2000 IDOC por packet)3. Desativar automatic retry do TRFC e usar relatorio RSARFCEX em seu lugar4. Schedular mass transfer/update em horas de baixa atividade do sistema5. Archive IDOC e reorganize Change Pointer, TRFC queue e Audit DataBase6. Use Registration para External Programs e mantenha-os conectados7. Use Multiple Registration para External Programs (se possivel)8. Use RFC Groups para Parallel Update9. Ajuste o numero de Dialog WP nos sistemas envolvidos10. Use parametros RFC para evitar que todos os recursos do sistema sejam consumidos


162

Capítulo 22 – Principais problemas no ALE

• Possiveis problemas de performance- Application Data não chega

- Dados foram criados ?- Relatorio RBDAPP01 rodou ? -> relatorio schedulado que recebe IDOC´s- Relatorio RSNAST00 rodou ? -> transformou Change Pointers em IDOCs- Endereco RFC está certo ?- External Program esta startado ?

- Application Data chega atrasado- Verificar frequencia de execucao dos reports RBDMIDOC, RBDAPP01, RSNAST00- Bottleneck nos WP do sender ?- Network Connection lenta ?- Bottleneck no WP do receiver ?- External Program pode rodar em paralelo ?

- Application Data chega muito devagar- Verificar os mesmos problemas do item anterior- Verificar Packet Size

- Trabalhos no Dialog são prejudicados- Montar pacotes- Schedular processo em horarios de menor carga- Checar parametrizacao de RFC Resources- Aumentar Dialog WP no sender ou receiver- Usar RFC Server Groups

Capítulo 23 – Content Reporting Form

• Nothing to do

Capítulo 24 – Content Apendix

• Nothing to do


163

Capítulo 25 – Technical Implementation Phases

• Estratégias- Envolvimento do cliente

- Se é pequeno, precisa de um forte parceiro de implementacao- Operacao do R/3 após implantacao

- Help desk- Support services (IT´s, Network, etc)

- Estratégia de implementacao- ASAP- Fixed Price -> pacote predefinido de funcionalidades, com suporte incluido- Read to Run -> R/3 pre-configurado para smaller-scale operations

• ASAP Phases- Project Preparation

- Explain Project Roles and procedures- Prepare Project Charter -> objetivos do projeto- Define Schedule, Budget and Resources -> ASAP tem ferramentas que fazem isto- Provide Initial Training for Team -> Level 1- Define Technical Requirements -> sizing e hardware contract- Prepare Executive Kickoff Meeting -> motivacao e definicao de responsabilidade

- Business Blueprint- Estimar customer requirements -> entrevistas- Training -> Level 2- Instalacao do R/3 para desenvolvimento- Revisao do Business Blueprint

- Realization- Customizing- Final Integration Test

- Final Preparation- Planning for Go Live Data- Training End-Users- Testing Integration, Volume and Stress- Establising internal Help Desk- Cutover to Production Environment

- Go Live and Support- Start of Production Operation- Setting up Support- Verifying accuracy of Production System- Measuring Beneficies- Optimizing R/3 performance

- Continuous Change

• ASAP Implementation Assistant- Ferramenta que permite checar os principais passos da implementacao ASAP- Possue Roadmap, Project Plan, Q&A Database, Business Procedures, Glosary

• Remote Consulting Services- Early Watch -> system availability, performance, database, network


164

- R/3 Conversion Services -> fusoes de corporacoes ou migracao de OS ou DB- SAP Going Live Check -> verificacao da SAP antes de colocar R/3 em producao

• R/3 Implementation- Big Bang- Phased Implementation

• Fatores de sucesso na implementacao do ASAP- Forte apoio dentro da companhia- Rápido retorno do investimento pelo cliente- Escopo gerenciavel de funcionalidades a ser implementado- Não precisa de reengenharia- Implementacao baseada nas Best Business Practices


165