resumo_academia_alex..
Transcrição
resumo_academia_alex..
TADM10_1 .................................................................................................................................................. 7 Unit 1 – SAP Solutions ............................................................................................................................ 7 mySAP Business Suite and mySAP ERP ........................................................................................... 7 Definition of SAP NetWeaver ............................................................................................................ 7 The SAP Release Strategy .................................................................................................................. 7 Unit 2 - Navigation .................................................................................................................................. 8 Navigation in General ......................................................................................................................... 8 Advanced Navigation in the SAP GUI ............................................................................................... 8 Unit 3 – The System Kernel ..................................................................................................................... 9 Principal Architecture of the SAP Web Application Server ............................................................... 9 Dialog Processing in the SAP System ................................................................................................ 9 Communication with the Database ................................................................................................... 10 Appendix - The SAP Transaction ..................................................................................................... 10 Appendix - Lock Management in SAP Systems ............................................................................... 10 Appendix - Update Processing .......................................................................................................... 10 Unit 4 –Software development in SAP systems ...................................................................................... 10 Data Structure of an SAP System and Transports between SAP Systems (ABAP Stack) ................ 10 Accessing and Editing ABAP Repository Objects ........................................................................... 11 Appendix: Table Definition and the Two-Level Domain Concept ................................................... 11 Appendix: Modeling in the ABAP Dictionary .................................................................................. 11 Introduction to the SAP NetWeaver Java Development Infrastructure ............................................ 11 Unit 5 – Communication and Integration Tecnology ............................................................................ 12 Cross-System Business Processes ..................................................................................................... 12 Remote Function Calls and BAPIs ................................................................................................... 12 Web Services .................................................................................................................................... 12 SAP Business Workflow. .................................................................................................................. 12 Unit6 - Tools for SAP System Administration........................................................................................ 12 Daily Tasks in System Management ................................................................................................. 12 SAP Service Marketplace ................................................................................................................. 13 SAP Developer Network ................................................................................................................... 13 Unit 7 - SAP NetWeaver and Enterprise Services Architecture............................................................. 13 SAP NetWeaver: An Overview ........................................................................................................ 13 From SAP R/3 to mySAP ERP and the Enterprise Services Architecture ........................................ 13 Unit 8 - Basics ....................................................................................................................................... 13 What is a SAP System?..................................................................................................................... 13 Process of a System Logon ............................................................................................................... 13 Configuring SAP Logon ................................................................................................................... 13 Analysis Transactions ....................................................................................................................... 14 Unit 9 – Starting and Stopping the SAP System .................................................................................... 14 System Start: Process ........................................................................................................................ 14 System Start: Logs ............................................................................................................................ 14 System Shutdown: How and Why? .................................................................................................. 14 Appendix: Starting and Stopping Under Other Operating Systems .................................................. 14 Appendix: Database Logs ................................................................................................................. 14 Unit 10 – Introduction to System Configuration .................................................................................... 14 How the System Evaluates its Parameters ........................................................................................ 14 How to Set System Parameters ......................................................................................................... 15 Setting up Operation Modes ............................................................................................................. 15 Unit 11 – Fundamentals of Working with the Database ........................................................................ 15 Architeture of Database Systems ...................................................................................................... 15 Backing Up the Database Contents ................................................................................................... 15 Overview: Monitoring the database .................................................................................................. 15 Unit12 – Basics of User Administration ................................................................................................ 15 User Administration Concept............................................................................................................ 15 Autorization Concept ........................................................................................................................ 15 Login Parameters and User Info ....................................................................................................... 15 Appendix: Adcanced User Administration Topics ........................................................................... 16 Unit 13 – Setting Up Remote Connections ............................................................................................ 16 Fundamentals and Types of RFC ...................................................................................................... 16 Setting Up RFC Connections ............................................................................................................ 16 Unit 14 – Working with the Transport System ....................................................................................... 16 Data Structure of SAP Systems and System Landscapes.................................................................. 16 Performing and Checking Transports ............................................................................................... 16 Unit 15 – Support Packages, Plugins and Add-nos ............................................................................... 17 Term Definition: Support Packages .................................................................................................. 17 Importing Support Packages ............................................................................................................. 17 Updating the Tools............................................................................................................................ 17 Importing SAP Notes ........................................................................................................................ 17 Unit 16 – Scheduling Background Tasks ............................................................................................... 17 Fundamentals of Background Processing ......................................................................................... 17 Time-Based Scheduling of Jobs ........................................................................................................ 18 Event-Based Scheduling of Jobs ....................................................................................................... 18 Background Processing: Other Topics .............................................................................................. 18 Job Scheduling: Extending the Standard........................................................................................... 18 Unit 17 – System Monitoring ................................................................................................................. 18 Monitoring Architecture ................................................................................................................... 18 Including Remote Systems ............................................................................................................... 18 Creating Your Own Monitors ........................................................................................................... 19 Properties Variants and Threshold Values ........................................................................................ 19 Concept of the SAP Solution Manager ............................................................................................. 19 TADM10_2 ................................................................................................................................................ 21 Unit 1 – Fundamentals .......................................................................................................................... 21 Fundamentals Concepts of Java ........................................................................................................ 21 The Architecture of SAP Web Application Server ........................................................................... 21 Java Cluster Architecture .................................................................................................................. 21 The Internal Structure of SAP Web AS Java .................................................................................... 22 Load Balancing in the SAP Web AS Java Environment................................................................... 23 Unit 2 – Starting and Stopping a SAP Web AS Java ............................................................................. 23 Overview of the Process of Starting and Stopping a SAP Web AS Java .......................................... 23 Java Startup and Control Framework ................................................................................................ 23 Starting under Microsoft Windows and UNIX ................................................................................. 23 Logs of the Start and Stop Processes of SAP Web AS Java ............................................................. 24 Unit 3 – Installation in the SAP Web Application Server Java Enviroment .......................................... 24 Installing an SAP Web AS Java ........................................................................................................ 24 Installation of SAP NetWeaver Developer Studio ............................................................................ 24 Unit 4 – Basic Configuration of SAP Web AS Java ............................................................................... 24 Administration and Configuration Tools for SAP Web AS Java ...................................................... 24 General Configuration of the SAP Web AS Java Cluster with Config Tool .................................... 25 General Configuration of the SAP Web AS Java Cluster with Visual Administration..................... 25 Other Administration Tools .............................................................................................................. 25 Selected Configurations .................................................................................................................... 25 Unit 5 – User Administration in Java Environment .............................................................................. 25 Overview of User Administration in Java ......................................................................................... 25 User Management Engine (UME) .................................................................................................... 25 User Administration Tools ................................................................................................................ 26 User Administration .......................................................................................................................... 26 The Java Authorization Concept ....................................................................................................... 26 2 UME Parameters ............................................................................................................................... 27 Special Users and UME Log/Trace Files .......................................................................................... 27 Unit 6 – Monitoring SAP Web AS Java ................................................................................................. 27 Java Monitoring: Overview .............................................................................................................. 27 Monitoring SAP Web AS Java ......................................................................................................... 28 Appendix: Background Information About the Monitoring Service ................................................ 29 Connecting to a Central Monitoring Service; ................................................................................... 31 Log Viewer and Log Configuration .................................................................................................. 31 Availability Monitoring .................................................................................................................... 33 Statistics and the Performance Trace ................................................................................................ 33 Unit 7 – Change Management and Software Logistics in the SAP Web AS Java Environment ............ 34 Overview of the Standard J2EE Development Process..................................................................... 34 Introduction to the SAP NetWeaver Java Development Infraestructure (JDI) ................................. 35 Configuring the SAP NetWeaver Java Development Infraestructure ............................................... 36 Preparing for the Development of Java Applications ....................................................................... 37 Developing Java Objects in SAP NetWeaver Developer Studio ...................................................... 37 Transporting Java Developments ...................................................................................................... 38 Unit 8 – Importing Corrections ............................................................................................................. 39 Installing Corrections for SAP Web AS Java ................................................................................... 39 Installing Corrections for a Java Application .................................................................................... 39 Unit 9 – Backing Up SAP Web AS Java ................................................................................................ 40 Backing Up SAP Web AS Java ........................................................................................................ 40 Unit 10 – Technology Components for Browser-Based User Dialogs .................................................. 40 Internet Schenarios with SAP Systems ............................................................................................. 40 SAP Internet Transaction Server (Standalone) ................................................................................. 40 Internet Communication Manager .................................................................................................... 41 Internet Communication Framework ................................................................................................ 43 SAP Web Dispatcher ........................................................................................................................ 44 TADM12_1 ................................................................................................................................................ 46 Unit 1 – mySAP ERP Solution Architecture .......................................................................................... 46 Introducing to mySAP ERP Solution ................................................................................................ 46 New Features of SAP ERP Central Component and SAPinst........................................................... 46 Unit 2 – Planning the Installation of SAP Central Component ............................................................. 47 Planning the instalation ..................................................................................................................... 47 Unit 3 – Preparing for the Installation of SAP Central Component ...................................................... 47 General Preparation for Instalation ................................................................................................... 47 Futher preparation for Installation on Windows ............................................................................... 47 Futher preparation for Installation on Unix ...................................................................................... 48 Unit 4 – Installing SAP GUI .................................................................................................................. 48 Installation of SAP GUI for Windows .............................................................................................. 48 Installation of SAP GUI for Java ...................................................................................................... 48 Unit 5 – Installing the SAP ERP Central Component ........................................................................... 48 Introducing SAPInst ......................................................................................................................... 48 Installing and Patching Oracle Database Software ........................................................................... 49 Central Instance Installation ............................................................................................................. 49 Database Instance Installation ........................................................................................................... 49 Dialog Instance Installation .............................................................................................................. 49 SAP Web AS Java Central Instance Installation ............................................................................... 49 SAP Web AS Java Dialog Instance Installation................................................................................ 49 Appendix: SAP Gateway Installation ............................................................................................... 49 Unit 6 – Performing Post-Installation Activities ................................................................................... 50 Installation of SAP License and Other Components ......................................................................... 50 TMS and Basic Configuration .......................................................................................................... 50 Additional Tasks ............................................................................................................................... 50 3 Appendix: Specific Post-Installation Activities ................................................................................ 51 Unit 7 – Implementing Patches .............................................................................................................. 51 Applying Patches .............................................................................................................................. 51 Unit 8 – Converting Non-Unicode to Unicode ...................................................................................... 51 Procedure for Converting Non-Unicode to Unicode......................................................................... 51 Unit9 – Troubleshooting Installations Problems ................................................................................... 51 Solving Problems During SAP ERP Central Component Installation .............................................. 51 Unit 10 – Introduction to Software Logistics ......................................................................................... 51 SAP System Landscape .................................................................................................................... 51 Client Concept .................................................................................................................................. 51 System and Client Change Options .................................................................................................. 52 Unit 11 – Setting Up an SAP System Landscape ................................................................................... 52 Setting Up the Transport Management System (TMS) ..................................................................... 52 Extended Transport Control .............................................................................................................. 53 Unit 12 – Customizing and Development in ABAP................................................................................ 54 Customizing and Customizing Projects ............................................................................................ 54 Customizing Tools ............................................................................................................................ 54 Customizing Procedure ..................................................................................................................... 55 Managing Workbench Change Requests .......................................................................................... 55 Prerequisites for development ........................................................................................................... 56 Handling Repairs and Modifications ................................................................................................ 57 Unit 13 – Transport Management in ABAP ........................................................................................... 57 The Transport Process....................................................................................................................... 57 Imports Using TMS .......................................................................................................................... 58 QA Approval Procedure and Transport Proposal ............................................................................. 59 Monitoring Tools .............................................................................................................................. 59 Transport Directory Structure and Files ............................................................................................ 60 tp, The Transport Protocol Program ................................................................................................. 60 Import Process .................................................................................................................................. 61 Troubleshooting transports ............................................................................................................... 62 Cleaning Up the Transport Directory ................................................................................................ 63 Unit 14 – Client tools............................................................................................................................. 63 Client Copy and Transport Tools ...................................................................................................... 63 Client Compare and Maintenance Tools ........................................................................................... 64 Unit 15 – Note Assistant, SAP Support Packages and Upgrades .......................................................... 64 SAP Note Assistant ........................................................................................................................... 64 SAP Support Packages ...................................................................................................................... 65 SAP System Upgrade ........................................................................................................................ 67 TADM12_2 ................................................................................................................................................ 69 Unit 1 – Introduction to Workload Analysis .......................................................................................... 69 Components of Dialog Step .............................................................................................................. 69 Statistical Records and the Workload Monitor ................................................................................. 69 Unit 2 – Performance Analysis Monitors .............................................................................................. 70 SAP Performance Monitors .............................................................................................................. 70 Analysing SAP Web AS Java Performance ...................................................................................... 72 Analysing ICM Performance ............................................................................................................ 72 Performance Analysis on Integrated ITS .......................................................................................... 72 Unit 3 - SAP Memory Management ....................................................................................................... 73 Memory Areas .................................................................................................................................. 73 SAP Memory Allocation ................................................................................................................... 74 Implementation Of SAP Extended Memory ..................................................................................... 75 Memory Usage for SAP Web AS Java ............................................................................................. 75 Unit 4 – Hardware Bottlenecks ............................................................................................................. 76 4 Hardware Bottlenecks ....................................................................................................................... 76 Optimizing Hardware Utilization...................................................................................................... 77 Unit 5 – Expensive SQL Statements ....................................................................................................... 77 Detecting Expensive SQL Statements .............................................................................................. 77 Analysis and Tuning of Expensive SQL Statements ........................................................................ 78 Unit 6 – SAP Table Buffering ................................................................................................................ 78 Introduction to Table Buffering in SAP Systems.............................................................................. 78 Analyzing Table Buffering ............................................................................................................... 79 Unit 7 – RFC Monitoring ...................................................................................................................... 79 Remote Function Call Basics ............................................................................................................ 79 Monitoring RFC Load and Solving RFC Load Problems ................................................................. 80 Unit 8 – Acess to Help ........................................................................................................................... 81 Configuring the Online Documentation ............................................................................................ 81 Unit 9 – Introduction to System Security ............................................................................................... 82 Security in the SAP Environment ..................................................................................................... 82 Unit 10 – Archiving ............................................................................................................................... 83 Fundamentals of SAP Data Archiving .............................................................................................. 83 Performing Data Archiving ............................................................................................................... 83 Accessing Archived Data .................................................................................................................. 84 Unit 11 – Including Printers in SAP Systems ........................................................................................ 84 Configuring Printers in SAP Systems ............................................................................................... 84 Concept of Logical Spool Servers .................................................................................................... 85 Managing Spool Requests ................................................................................................................. 86 Unit 12 – Structured Troubleshooting ................................................................................................... 86 Trace options..................................................................................................................................... 86 Unit 13 - Advanced User Administration Topics ................................................................................... 88 Introduction to CUA ......................................................................................................................... 88 Setting UP a CUA ............................................................................................................................. 88 User Administration with the CUA .................................................................................................. 88 Introduction to Directory Services .................................................................................................... 88 Technical Connection of Directory Services .................................................................................... 89 TADM51 .................................................................................................................................................... 90 Unit 1 – Database Overview.................................................................................................................. 90 Database Architecture ....................................................................................................................... 90 Connecting to the Database .............................................................................................................. 93 Database Administration Tools ......................................................................................................... 95 Administration of Oracle Instances................................................................................................... 96 Unit 2 – Backup, Restore & Recovery ................................................................................................... 97 Backup Strategy ................................................................................................................................ 97 Backup Tools and Tape Management ............................................................................................... 98 Performing Backups........................................................................................................................ 103 Restore and Recovery ..................................................................................................................... 104 Advanced Backup Techniques ........................................................................................................ 106 Unit 3 – Monitors and Tools ................................................................................................................ 107 Introduction to Oracle Data Management ....................................................................................... 107 Database System Check .................................................................................................................. 110 CCMS Alert Monitor ...................................................................................................................... 112 Unit 4 – Storage Management ............................................................................................................. 112 Tablespace Administration ............................................................................................................. 112 Reorganization of Tables ................................................................................................................ 113 Housekeeping and Troubleshooting ................................................................................................ 115 Unit 5 – Introduction to Oracle cache management............................................................................ 116 5 Oracle System Global Area ............................................................................................................ 116 Oracle Program Global Area........................................................................................................... 118 Unit 6 – Monitoring of the database instance ..................................................................................... 118 The New Oracle Database Monitor provided by SAP .................................................................... 118 Oracle Wait Interface ...................................................................................................................... 120 Unit 7 – Analysing Application Design ............................................................................................... 122 Consequences of Expesive SQL Statements ................................................................................... 122 Using SM50/SM66 to Find Expensive SQL Statements................................................................. 122 Using ST03N/STAD to Find Expensive SQL Statements .............................................................. 122 Using ST04N to Find Expensive SQL Statements .......................................................................... 122 Using the SQL Trace to Find Expensive SQL Statements .............................................................. 123 Exlusive Lockwaits ......................................................................................................................... 123 Unit 08 – Index Management and Optimization .................................................................................. 123 Index utilization .............................................................................................................................. 123 Creating an Index ............................................................................................................................ 124 Unit 09 – Cost Based Optimizer .......................................................................................................... 125 Update Statistics ............................................................................................................................. 125 Cost Evaluation ............................................................................................................................... 125 Unit 10 – Analysing Memory Configuration ....................................................................................... 126 Data Buffer Utilization ................................................................................................................... 126 Efficience Of Shared Pool .............................................................................................................. 126 Monitoring the Automatic Program Global Area ........................................................................... 126 Unit 11 Analyzing Physical and Logical Layout ................................................................................. 128 I/O contention ................................................................................................................................. 129 6 TADM10_1 Unit 1 – SAP Solutions mySAP Business Suite and mySAP ERP SAP NetWeaver: infra-estrutura tecnológica para todos os produtos SAP; mySAP Business Suíte: produtos para as indústrias, baseadas no NetWeaver; SAP Smart Business Solution: soluções para pequenas e médias empresas. SAP All-inone: comparado ao R/3. SAP Package Solution: pacotes de soluções do Business Suite que podem ser combinados para atender um cliente. SAP Business One é para micro empresas, compilado em C++, funciona em windows e possui funções como financeiro, customer management, etc. SAP xAPPS: Collaborative Cross Applications: integra soluções existentes, acessando datasets e funções. Industry Solutions: Add Ons para indústrias específicas. Instalado no R/3. mySAP Business Suíte mySAP ERP: baseado no SAP ECC System, mySAP HR e mySAP Financials; Formas de integração: Aplication Link Enabling (ALE), Eletronic Data Interchange (EDI), XML, Collaborative Cross Application (xAPPS) e Web Services. Definition of SAP NetWeaver Base técnica do mySAP Bussines Suíte, do xAPPS, do ESA (Enterprise Services Achitecture) e o conceito para Web Service. Níveis de integração: - People Integration: garante que os funcionários terão informações e funções necessárias ao trabalho. O Enterprise Portal é a peça chave; - Information Integration: provê informações da empresa. O SAP Business Information Warehouse é o core. Knowledge Management e Master Data Management são as funções centrais para o armazenamento de dados máster; - Process Integration: permite que processos possam correr entre sistemas. Peça chave é o Exchange Infraestructure (SAP XI); - Application Platform: SAP Web Application Server: J2EE e ABAP runtime. Suporta Web Applications e Web Services. SAP WEB AS: - ambiente de execução testado e confiável; - ambiente seguro para execução de complexos processos de negócio; - ambiente de desenvolvimento amigável e confiável; - suporta padrões abertos, como HTML, XML, etc.; - alta escalabilidade; - suporta vários SO e SGBDs. The SAP Release Strategy Ramp-up: - novos produtos ou novas releases a serem lançadas; - pode ser usado como sistema produtivo; - liberado apenas para alguns poucos clientes, que concordam em usá-lo; - serve para avaliação das funcionalidades antes do produto ser oficialmente lançado; - contato direto com o desenvolvimento da SAP e possuem suporte na implementação. 7 Manutenção do sistema SAP: - Usando Support Packages, Support Package Stack, Kernel Patches, etc. ou por novas versões do produto; - Upgrades são possíveis mesmo quando se muda o produto (de SAP R/3 para mySAP ERP). Estratégia de manutenção 5-1-2: - 5 anos de manutenção “oficial”; - 1 ano de manutenção com 2% de acréscimo; - 2 anos de manutenção com 4% de acréscimo; - Mais anos por conta do cliente. Unit 2 - Navigation Navigation in General Tipos de GUI: for windows, for java, for HTML. SAP GUI for HTML: - consiste no ITS pelo lado do servidor e o browser pelo lado do cliente; - ITS converte dados do WEB AS em HTML, enviando via WGate; - Não é necessário instalar nada no browser; - Nem todas funções estão disponíveis. Seqüência: SAP GUI SAP Logon (escolher os sistemas) Logon. Password pode ser trocado apenas 1x por dia. Parâmetro rdisp/max_alt_modes: quantidade de sessões que podem ser abertas (2 a 8). User Máster Record: dados de um usuário em um client. Imagem da página inicial é carregada no GUI toda vez que faz logon. Recomendadas imagens < 20Kb Itens da tela: - Command field: para ir diretamente a uma transação; - Menu Bar - Standard Toolbar: botões exibidos em todas as telas; - Title bar - Application Toolbar: botões referentes à tela local; - Status bar: status do sistema; /nend fecha todas as sessões perguntando, /nex fecha todas as sessões, sem perguntar. /i fecha apenas a atual. Advanced Navigation in the SAP GUI 2 tipos de menu: SAP Menu (original) e user menu (customizado via roles). Tabela USERS_SSM define usuários que podem acessar qual tipo de menu. Transações SEARCH_SAP_MENU e SEARCH_USER_MENU servem para procurar por texto as transações desejadas (não são abertas via duplo clique). Favoritos: salvos para um usuário em um sistema. F1 – explica o conteúdo de campos, menus, funções e mensagens F4 – mostra os últimos 15 comandos digitados naquele campo, ou os possíveis valores para aquele campo. F2 – ou edit select options permite busca avançada. 8 Unit 3 – The System Kernel Principal Architecture of the SAP Web Application Server ABAP (Advanced Business Application Programming). Web AS Java foi introduzido na versão 6.20. Enterprise Java Beans (EJB): empacotamento da lógica da aplicação. Representa componentes dos programas java. Três camadas de processamento: presentation (telas), application e database. Application server ABAP: - ABAP Dispacher distribui as requisições dos usuários entre os Work Process; - Dialog Work Process (D): processa os “dialog steps” disparadas pelo usuário. Mínimo de 2 por dispacher. Parâmetro rdisp/wp_no_dia; - Spool (S): gera as saídas para impressoras. Mínimo 1 por sistema, podem ter vários por dispacher. Parâmetros: rdisp/wp_no_spo; - Update (V): processa updates no banco. Mínimo 1 por sistema, podem ter vários por dispacher. Separado em V e V2: updates não tempo-críticos. Parâmetros rdisp/wp_no_vb e rdisp/wp_no_vb2; - Background (B): processos em background. Mínimo 2 por sistema, podem ter vários por dispacher. Parâmetro rdisp/wp_no_btc; - Enqueue (E): administra a lock table na shared Memory. Apenas 1 por sistema. Sistema: rdisp/wp_no_enq. Adicionalmente: - Message Server (MS): gerencia a fila de execução ABAP, entregando a vários dispachers. 1 por sistema; - Gateway (GW): gerencia comunicação entre sistemas SAP ou SAP com externos. 1 por dispacher; - Internet Communicator Manager (ICM): conversação entre SAP e a internet. Application Server Java: - Java Dispacher distribui as requisições para os Java server process; - Java Server Process: executa as aplicações em multi-threads; - Java Message Service: gerencia comunicação com os dispachers e server processes e com o JRE; - Java Enqueue Service: gerencia os locks lógicos; - SAP Java Conector (JCo): comunicação entre JAVA e ABAP. - SDM (Software Development Manager): realiza instalação dos componentes Java no sistema, e é sempre instalado como parte do central instance. Instância = AS = serviços juntos (sob junto, desce junto, configura junto...). Central Services: instância separada; possui o message service e o enqueue service. Representa a base de comunicação e sincronização do JRE. Dialog Processing in the SAP System Work Process: - task handler: coordena ações do work process; - Screen processor: executa a lógica da tela, dividido em PBO (process before output) que é o processamento antes da imagem ser enviada e PAI (process after input) que é o processamento após interação do usuário; - ABAP Interpreter: processa o código ABAP; 9 - Database interface: acessa o banco. Communication with the Database ABAP usa SAP Open SQL: AS verifica a sintaxe, transforma no SQL específico da base, otimizando os buffers. EXEC SQL executa a query direto no banco, sem buffers, etc. Appendix - The SAP Transaction Características (ACID): - Atomic: executou totalmente com sucesso ou não fez nada; - Consistent: obedece a regras de negócio; - Isolated: outras operações só enxergam esta após o commit; - Durable: no final das contas é gravada no banco. Appendix - Lock Management in SAP Systems Como uma transação lógica pode ser feita por vários dialogs (e cada um faz commit no banco quando termina de processar), o SAP tem seu próprio lock management. Tipos de lock: - X: Write locks: se não há lock, ele é consedido e ninguém mais efetua locks nessa entrada; - E: Extended Write Lock: só é consedido se não houve lock antes. Somente o owner do lock pode liberar futuros locks; - S: Shared Locks: locks futuros (não de escrita) podem ser requisitados; - O: Optimistic Lock: >= AS 6.40, dados foram abertos para edição, mas ela não começou efetivamente. O lock é resolvido no salvamento. Transação SM12 exibe os locks: em azul para os do update work process e preto para os do dialog work process. Appendix - Update Processing D/B Work process pede lock Enqueue WP faz o lock o programa grava alterações nas VB* tables user salva dados (COMMIT WORK), WP chama o V WP V WP lê das VB* Tables e grava no banco. V1: time critical e libera locks V2: updates não time critical (ex.: criar uma alteração de documento). Unit 4 –Software development in SAP systems Data Structure of an SAP System and Transports between SAP Systems (ABAP Stack) Client é uma unidade independente em termos de negócio, organização e dados. Customizing é o setup de dados por client. Cross-client customizing para todos os clients. Repository é o repositório ABAP. Objetos agrupados formam um package. As modificações podem ser de 3 tipos: - Customer Developments: adicionando objetos ao repositório; - Customer Echancements: melhorias adicionadas pelo desenvolvedor, chamadas a partir de user exits ou Business Add-Ins (BAdIs); - Modifications: modificação no objeto original. Three System Landscape. 10 Objetos do repositório são transportados e logados pelo Transport Organizer (SE09 e SE10). Customizações são tratadas também pelo Transport Organizer: - Workbench: alterações no repositório; - Customizing: customizações. Analista cria a request (transportável ou local) e associa a desenvolvedores TMS cria nome <SID>K9<nnnn> desenvolvedores associam objetos e liberam a task (o que transfere objetos da task para a change request) todas tasks liberadas, o analista pode liberar a request objetos são gravados no file system administrador importa no BD de destino. Cada desenvolvedor utiliza uma task. Accessing and Editing ABAP Repository Objects Características do ABAP: - Começa com um comando, termina com um ponto; - Possibilidade de desenvolvimento multi linguagem; - desenvolvimento de telas de forma simplificada; - permite programação orientada a objetos; - Independente de BD; - Acesso eficiente a estruturas de dados; Ferramentas de desenvolvimento (ABAP Workbench): - ABAP Editor (SE36); - ABAP Dictionary (SE11): tabelas, elementos de dados, lock objects, etc.; - Screen Painter (SE51); - Function Builder (SE37): desenvolvimento de funções; - Object Navigator (SE80): índice para demais itens. Usuário cria programa Especifica título e atributos associa a request trabalha no código ativa para poder usar (gerando nova versão). Packages: agrupamento de objetos relacionados. Transação SE80, abrir Web Application Builder para criar BSPs ABAP Dictionary: definições técnicas e de negócios do SAP data. Outros tools acessam essas informações. Dividido em: - Database definition objects (tables, views, ...); - type definitions (estrutura, tipos de tabela, ...); - service definitions (F1 para ajuda, lock objects, etc.). Appendix: Table Definition and the Two-Level Domain Concept Quando se ativa a tabela no dicionário de dados, ela é criada no BD. Data element: ex.: aeroporto de origem, aeroporto de destino. Domain: ex.: aeroporto (que é usado nos dois campos acima). Appendix: Modeling in the ABAP Dictionary Modelos permitem reduzir a complexidade do sistema em componentes essenciais. Documentam os relacionamentos orientados a negócio e os processos no dicionário ABAP. Introduction to the SAP NetWeaver Java Development Infrastructure JRE: - Class loader: lê as classes necessaries; - Bytecode Verifier: verifica se as classes são compatíveis com a JVM; - JVM. 11 J2EE (runtime environment): - JVM; - standard Java Interfaces; - outros componentes para executar aplicações Java e applets. SAP NetWeaver Developer Studio: ferramenta da SAP para desenvolvimento J2EE. Desenvolvido no Developer Studio, guardado no Design Time Repository (DTR – permite versionamento), build via Component Build Service (CBS – permite build centralizado, ativação sob demanda), transporte via Change Management Service (CMS). 4 System landscape: DEV CONS TEST PROD Unit 5 – Communication and Integration Tecnology Cross-System Business Processes Para aplicar Application Link Enabling (ALE): - Identificar os processos de negócio e os objetos; - Identificar informações a serem transmitidas; - Especificar o formato de dados; - Tipo de tecnologia usada; - Tipo de transferência; - Destino da transferência. BAPI: Bussines Application Programming Interfaces: interface que comunica com um objeto, através de métodos (ex.: alterar cadastro de algo). Transferência síncrona: na hora q acontece. Assíncrona: agendada. Remote Function Calls and BAPIs RFC (remote function call): interface (não programa) executa funções em sistemas remotos ou no próprio sistema. Baseado no CPI-C e TCP/IP controla o processo de comunicação, parâmetros de transferência e controle de erros. Usuário do destino pode ser configurado na RFC, ou digitado no código que usa a RFC. Quando vários usuários usam uma RFC, é chamada Trusted RFC. Web Services Web Service: serviço acessado via internet. Enterprise Service: conjunto de serviços que representam uma lógica de negócio. Desenvolvedor publica o Web Service no diretório (UDDI), descrito na linguagem WSDL. O cliente pode pesquisar nesse diretório via protocolo SOAP. SAP Business Workflow. Eventos do workflow chamam BAPIs. Unit6 - Tools for SAP System Administration Daily Tasks in System Management SM37: background Jobs; SM51: server ativos; SM04: usuários logados na instância; AL08: usuários logados em todas instânias; SM50: detalhes dos work process na instancia; 12 SM66: detalhes dos work process global; SM12: locks lógicos. SM13: update work process (V1 e V2). Não reprocessar V1. SM21: System log. Tamanho máximo especificado rslg/max_diskspace/local (192Kb por entrada no log). SM02: mensagens para usuários. SU01: perfis de usuários SU10: manutenção de profiles em massa. RZ20: monitoramento do ambiente. RZ21: configuração dos parâmetros da RZ20. pelo parâmetro SAP Service Marketplace Nenhum comentário. SAP Developer Network Nenhum comentário. Unit 7 - SAP NetWeaver and Enterprise Services Architecture SAP NetWeaver: An Overview Portal e collaboration Mobile Infraestructure: básico para “SAP Solution for Mobile Business”. Aplicativo que converte em HTTPS conversação com o NetWeaver com SAP Móbile Infraestructure server instalado. From SAP R/3 to mySAP ERP and the Enterprise Services Architecture Características da ESA: - geralmente implementada entre sistemas; - ABAP ou Java; - Não possui base própria; Unit 8 - Basics What is a SAP System? Um banco de dados e uma ou mais instâncias. O q é uma instância: unidade administrativa que provê serviços. Esses serviços são iniciados ou parados juntos, e configurados (ABAP) através de parâmetros. Possui um dispacher, 2 dialogs, etc... Process of a System Logon Saplogon passa uma série de informações para o SAPGui, que requer uma tela de logon dispacher devolve tela de logon GUI manda dados de logon para dispacher (pode ser outro) manda para um dialog vazio dialog verifica no banco se user e senha estão ok retorna para o user, que estará neste último dispacher até logoff. Work Process Multiplexing: uma transação pode usar vários Work Processes. Configuring SAP Logon Nenhum comentário 13 Analysis Transactions Idem unidade 6. Unit 9 – Starting and Stopping the SAP System System Start: Process BD SAPOSCOL Central Instance Outras instâncias. System Start: Logs Windows: - System Log: mensagens do SO e da aplicação - Application Log: lista de erros, warnings - Security Log: logins e acessos a arquivos. Logs no DIR_HOME: - STDERR1: startup do banco de dados; - STDERR2: startup do message server; - STDERR3: startup do dispatcher. Parâmetro rdisp/TRACE: granularidade do trace (de 0 a 3). Padrão 1. Logs de work process: - Dev_ms: message server; - Dev_rd: gateway; - Dev_disp: dispacher; - Dev_w<n>: work process System Shutdown: How and Why? Verificar usuários logados (SM04); Verificar batches (SM37) e batch input (SM35) Update (SM13); Conexões externas (RFC, SM50); Enviar mensagem (SM02). RZ03: control Stop SAP instance; Parar banco de dados. Appendix: Starting and Stopping Under Other Operating Systems Unix: startsap_host_instance ou startsap se só houver uma instância. Para parar stopsap. Appendix: Database Logs SAPDB: \sapdb\data\wrk\<SID>. MSSQL: …\MSSQL\LOG\ERRORLOG. Oracle: \oracle\<SID>\saptrace\background\alrt.log \oracle\<SID>\sa[trace\usertrace\Ora<n>.trc (erros em detalhes). DB2: \db2\<SID>\db2dump\. Unit 10 – Introduction to System Configuration How the System Evaluates its Parameters \usr\sap\<SID>\SYS\pofile Start Profile: processos que serão inicializados; Default Profile: parâmetros para todas as instâncias; 14 (error) ou Instance Profile: parâmetros para uma instância. Para exibir parâmeros: RZ11 ou relatório RSPFPAR. Via SO: sappfpar. How to Set System Parameters RZ10: Verifica consistência, versiona, centraliza. Setting up Operation Modes Criar operation mode (RZ04) atribuir instancias distribuir work process ajustar o calendário (SM63). Unit 11 – Fundamentals of Working with the Database Architeture of Database Systems Database process, fugger, data files e log files (dados alterados logados). Backing Up the Database Contents Recomendado: full diário, 28 dias, redo logs diários. Agendamento DB13, DB12 para ver mais detalhes. Overview: Monitoring the database Além de verificar se o backup executou, atualizar estatísticas, verificar erros, etc. Unit12 – Basics of User Administration User Administration Concept Tipos de users: - Dialog: efetua logon; - System: não efetua logon, não troca senha, usado para batch, RFC, ALE, Workflow, etc. - Communication: não efetua logon, setup de senha (validade, etc.), usado para comunicação entre sistemas - Service: usado para acesso anônimo via ITS, com baixas permissões, permitido múltiplos logons, etc. - Reference: referencia para criação de novos users. Autorization Concept Ações e acesso a dados são protegidos por authorization objects, que são formados por object classes, que permitem determinada ação. Quando se cria um menu com as transações em uma role, as autorizações vêm juntas. Necessário verificar manualmente. Ao associar user X role, não necessariamente começa a funcionar. Necessário fazer um “user máster comparison”, que pode ser feita na PFCG tab users user reconciliation ou via PFUD (defaul: 1x por dia). Login Parameters and User Info login/min_password_lng: tamanho mínimo da senha. De 3 (default) a 8 caracteres. login/min_password_digits: quantidade mínima de dígitos; login/min_password_letters: quantidade minima de letras; login/min_password_specials: quantidade minima de caracteres especiais. 15 login/password_expiration_time: 0 (default) a 999 dias. login/password/max_reset_valid: tempo em que a password alterada por administrador é válida. 0 a 24000 dias. login/password_max_new_valid: tempo em que a primeira senha é válida. 0 a 24000 dias. Passwords: - Não pode ser = últimas 5; - Não pode começar com ?, ! ou espaço; - Não pode ser “pass”; - Não pode começar com 3 caracteres iguais. login/fails_to_session_end: x vezes errado fecha sessão. 1 a 99. Padrão: 3. login/fails_to_user_lock: quantidade de vezes erradas para bloquear usuário. 1 a 99. Padrão: 12. login/failed_user_auto_unlock: se desbloqueia usuário na virada do dia: 0 ou 1 (default); login/disable_muilti_gui_login: usuário pode logar mais de 1 vez no mesmo client. 0 (default) ou 1. login/multi_login_users: lista de user separados por vírgula q são excluídos da regra acima. Transação SUIM: overview de user máster records, autorizações, profiles, roles, etc. SU53: mostras as autorizações que faltam para que o usuário possa completar a última ação. Appendix: Adcanced User Administration Topics CUA + LDAP Unit 13 – Setting Up Remote Connections Fundamentals and Types of RFC Tipos de RFC: Síncrona (sRFC): para comunicação entre sistemas diferentes e entre o Web AS e SAP Gui. Espera o retorno; Assíncrona (aRFC): entre sistemas diferentes e processamento paralelo; Transacional (tRFC): tipo de aRFC que garante o envio da interface; Queued (qRFC): tipo de tRFC executada em seqüência. Setting Up RFC Connections Nenhum comentário. Unit 14 – Working with the Transport System Data Structure of SAP Systems and System Landscapes Revisão de clients, customização e landscape de 3 sistemas. Performing and Checking Transports Goto Tp systemlog 16 Unit 15 – Support Packages, Plugins and Add-nos Term Definition: Support Packages SP: correção de erros ou novas funcionalidades. Componentes: - Extension Set: extensão de uma funcionalidade; - Industry Solution: software específico para uma indústria; - Plug-In: interface entre componentes; - Core Application (APPL): parte não HR de um ECC. Tipos de SP: - COP (Component Package): pacote dos componentes; - CRT (Conflict Resolution Transport): resolve conflitos entre SP e ADD-Nos; - PAT: novas funcionalidades para SPAM e SAINT Importing Support Packages SPAM: SPs; SAINT: Industry Solution: Installation + upgrade. Para aplicar um SP: - Client 000; - Atualizar última versão da SPAM/SAINT - TMS configurado; - Nenhum abort anterior. Updating the Tools Atualização da SPAM/SAINT via SPAM. Importing SAP Notes Nenhum comentário. Unit 16 – Scheduling Background Tasks Fundamentals of Background Processing rdisp/max_wprun_time: tempo máximo em que um WP processará uma requisição, antes de terminar o programa. 3 prioridades, com prioridade do especialmente configurado para rodar naquele servidor. Um job consiste de um ou mais steps (ABAP, comando externo, programa externo). Variants: entrada de dados de telas do programa executado no job. Iniciado agora, agendado ou iniciado após evento. SM36: criar novo job. SM36WIZ: wizard. SM37: monitorar jobs. Status: - Scheduled: mandou rodar, mas não definiu quando começa; - Released: mandou rodar, definindo quando começa; - Ready: está na hora de executar, mas está aguardando WP livre; - Active: executando; - Finished: sucesso; - Canceled: cancelado ou erro. 17 Time-Based Scheduling of Jobs Nenhum comentário. Event-Based Scheduling of Jobs rdisp/btcname: nome do background server que processa batches iniciados por evento. Background Processing: Other Topics Se tiver jobs classe A, alguns WP ficam livres, mesmo tendo jobs B e C para rodar. Configura-se isso na RZ04, recomendado 1. Caso execute programa externo, o job chama o programa sapxpg, que chama o programa. Não há como restringir se o usuário pode executar determinado programa no SO ou não. Job Scheduling: Extending the Standard Nenhum Comentário. Unit 17 – System Monitoring Monitoring Architecture A infra estrutura está instalada em todos componentes a partir de versões 4.x. Cada componente coleta seus dados e coloca na memória (monitoring segment). Recomendado ter um sistema independente para controle de transporte, CUA, monitoramento central, ou usar o SM para isso. Dividido em 3 níveis: - data collection: coletores em cada programa, salva dados na memória; - data storage: onde ficam os monitoring segments; e - administration level (exibe e permite avaliação de dados). Podem ser usados produtos de parceiros para o monitoramento, conectando no sistema através de interfaces. RZ20 mostra o monitoramento em formato de árvore, cada nó é chamado de Monitoring Tree Element (MTE), e os valores são chamados de atributos (monitoring attributes). Monitor sets são diferentes por produtos. Os nós podem se repetir em várias árvores. Ajustando em uma, automaticamente são alteradas nas demais. Alguns monitores não exibem dados. Podem-se usar monitores padrões ou customizálos. Ao abrir alertas, duas visões são possíveis: - Current Status: dados mais novos; - Open Alerts: dados históricos. Selecionar alerta Start Analysis Method (tool, URL, transação de ajuda...) F3 para voltar ao Alert Browser Complete Alerts. Show Alert History para ver histórico dos alertas (concluídos apresentados como Done). Including Remote Systems Para versões 3.x, usar programa SAPCM3X, para componentes não SAP SAPCCMSR. Criar 2 RFCs (tipo 3), para que uma acesse os dados do monitoramento (usuário communication), e outra para métodos de análise (current user). Acessar RZ21, Technical Infrastructure Configure Central System Create Remote Monitoring Entry. 18 Creating Your Own Monitors SAP recomenda a criação de monitores customizados. Originais não podem ser alterados. Monitores devem conter poucos dados (por causa do RFC). RZ20 Extras Activate maintenance function. Properties Variants and Threshold Values Threshold values determinam quando o status muda de cor (verde, amarelo, vermelho). Todos sistemas possuem valores padrões, porém a SAP recomenda configurar no sistema central e transportar via TMS para outros sistemas (desde que estejam em properties variants). Properties variants são containers que guardam uma série de thresholds. Podem ser criados vários, mas apenas um estará ativo por vez. Vantagens: - pode ser alterado de um variant para outro para testes. - pode ser linkado com o operation mode; - pode ser transportado usando o TMS. RZ21 Properties Variants. Podem ser organizadas hierarquicamente, onde os valores não especificados são obtidos pelo “pai”, até chegar ao padrão (SAP-DEFAULT). Link com operation mode: RZ04 Operation Mode Change Monitoring Properties Variant. Após criar um variant, selecionar o atributo na RZ20 e ir em propriedades. Para copiar via TMS: RZ21 Variant Transport. Concept of the SAP Solution Manager Plataforma de serviços e suporte para implementação e operação de sistemas SAP. Provê conteúdo, ferramentas e procedimentos para implementação, operação e suporte. Suporta durante o início do projeto, implementação funcional e técnica, durante o período em produção e durante a otimização dos landscapes. Centralizar no SM provê: distribuição e sincronização centralizada de customizações, gerenciamento de testes, monitoramento e gerenciamento de incidentes. Para monitoramento, podem ser criados Solution Landscapes, monitorado via Early Watch alerts (EWAs) ou via CCMS. Funcionalidades: - Serviços preventivos (Early Watch, GoingLive ...); - Continuous Improvement services; - Melhores práticas; - Monitoramento da aplicação e do sistema; - SAP Service Desk; - Remote support (NetMeeting ...); Suportes durante instalação: - Gerenciamento de projetos; - Repositório de processos de negócio; - Ferramentas para cenários integrados de negócio; - Integrated Implementation Guides; - Suporte ao monitoramento de processos de negócio; - Monitoramento centralizado; - Tarefas de administração centralizadas; - melhores práticas; 19 - Serviços remotos. SMSY: transação para apontar para o SM. Dados de monitoramento são coletados nos sistemas satélites, porém exibidos centralmente na RZ20 do SM. Pode-se usar o Service Desk para controlar mensagens de problemas. Change request management: - gerencia todas as requests; - classifica-as; - aprovação de workflow; - trace de status; - documentação de alterações. 20 TADM10_2 Unit 1 – Fundamentals Fundamentals Concepts of Java Propriedades: - Aplicativos: usado para programação como em outras linguagens: local, client/server, etc. - Applets: pequenas porções de código para execução em navegadores, obedecendo a regras de segurança; Java é mais lento que outras linguagens compiladas, devido ser interpretado no runtime. Isso é minimizado pelo JIT (just in time), que compila na linguagem nativa da maquina em memória. Continua mais lento que C, porém com pouca diferença. Java Development Kit (JDI) possui o Javac, JRE, applet viewer, java debugger, classes “padrões”, documentação, etc. JDK 1.2 = Java Plataform 2. Java 2 Software Development Kit (SDK): - Java 2 Standard Edition (J2SE): ambiente que define o SDK; - Java 2 Enterprise Edition (J2EE): add-ons para o J2SE que adiciona Enterprise Java Beans, Servlets, Java-Mail-API, ITS. - Java 2 Micro Edition (J2ME): small runtime para PDAs e telefones. Substitui o Personal Java e o Embedded java. .jar: classes compiladas compactadas, em formato unzip ou winzip. O compilador se encarrega de extrair. J2EE define a estrutura de desenvolvimento de aplicações em 3 camadas, banco, aplicativo e apresentação. Servlets: páginas JSP compiladas em código Java. The Architecture of SAP Web Application Server Nenhum Comentário. Java Cluster Architecture Server Process: infraestrutura para aplicações Java; Java Dispacher: distribui requisições dos clientes para server process da instância. Central service: comunicação e sincronização no java cluster. Connection request handler recebe solicitação do cliente inicializa um objeto de conexão (que é usado durante toda a sessão do user), usa o load balance para determinar um server process determina o tipo de serviço (ex.: http) via communication handler, contacta o server process. Central Service: - Message Service: - Notificação de eventos do cluster (serviço para, etc.); - Comunicação entre os serviços; - encaminhar mensagens e requisições entre os serviços; - prepara informações de logon para o SAP Web Dispacher; - Suporta o failover; - garante a transmissão da mensagem; - cuida das informações do cachê da instância. 21 - Enqueue Service: administra os locks lógicos e a sincronização do cluster. The Internal Structure of SAP Web AS Java Startup: runtime enviroment services application SAP Java Enterprise Runtime: Realiza as operações “core”, através de managers: - Log Manager: controla o processo de log; - Ports Manager: controla a criação de portas; - Application Thread Manager: controla as requests, associando à Threads ou enfileirando; - Thread Manager: controla as threads nas operações internas; - IP Verification Manager: controla a listas de hosts e a usa para controlar os acessos a elementos do cluster; - Connections Manipulator: controla as conexões dos clientes no cluster (executado no dispacher); - Locking Manager: interface entre o server process e enqueue server; - Configuration Manager: acessa banco de dados; - Classloading Manager: centralizador do registro e remoção de loaders e referências entre eles. - Cluster Manager: gerencia elementos do cluster (dispatcher e server process): - Join Port: entrada de conexões; - Open Port: conexões entre elementos do cluster; - Cluster Hosts: hosts que o dispatcher cria conexões. - Service Manager: contexto em que todos os serviços do cluster são executados. J2EE Components (services): Infraestrutura para executar aplicativos J2EE e SAP. Três componentes: - Interfaces: determina como os componentes trabalham em conjunto. Usadas pelos serviços; - Libraries: provê nomes, classes e objetos para o AS Java; - Services: usa funções do JRE através da API: - Security provider: administra usuários, grupos e autorizações; - Monitoring service: informações do sistema (memória, performance, etc); - Log Configurator Service: gerencia a configuração de log e trace; - Deploy service: gerencia os deploys; - EJB container service: gerencia os EJB; - HTTP Provider: analisa a requisição HTTP, envia para o serviço específico e retorna ao cliente. Application Layer: Terceiro nível dentro da arquitetura do AS Java. A comunicação entre a camada de aplicação e os componentes J2EE é feita através da API Java e de poucas APIs SAP. Tipos de aplicação: - Servlets: programa Java que responde requisições para um web server; - JSP: tecnologia para geração de HTML e XML de forma dinâmica. Através de compilador específico, é transformado em applets, e permite a separação da lógica de programação da apresentação. - EJB: usado para desenvolvimento de aplicações Java; - Java DataBase Connectivity (JDBC): conversação com o banco de dados. Web Container: Servlets + JSP; EJB Container: EJB; Persistência: JDBC. 22 Load Balancing in the SAP Web AS Java Environment Client Based Load Balance: cliente se conecta a um servidor, que devolve a informação do servidor “oficial” a ser usado. O cliente então direciona a comunicação para este servidor. Desvantagens: confusão devido muitas URLs, uso de favoritos, necessidade de vários certificados de segurança (1 por servidor), abertura no firewall. Stateless: um centralizador, que direciona comunicações para vários app servers, sem se preocupar em manter uma sessão. Stateful: um centralizador, que mantém o usuário sempre no mesmo app server, para manter os dados da sessão do usuário. O Java Web Dispacher se comunica apenas com o messager server, que informa quais os servidores e portas dos dispatchers, bem como a carga de cada um. Pode ser usado para Java, ABAP ou Java + ABAP. Unit 2 – Starting and Stopping a SAP Web AS Java Overview of the Process of Starting and Stopping a SAP Web AS Java Possível parar Java e não ABAP (via SMICM), mas não o contrário. No caso de apenas Java, o startup é feito de forma comum (startsap ou MMC), porém o comando é passado direto para o Startup and Control Framework. Java Startup and Control Framework Framework usado para iniciar, parar e monitorar as instâncias Java, exceto o Message Service. Processos: - JControl - Inicia, para e monitora processos da instância Java. SAP Signal Handling é implementado com o JLaunch para encaminhar comandos de inicio e parada para a instância; - reinicia processos parados, para serviços suspensos, e manda sinal de shutdown para instâncias; - lê o instance profile; - inicia o JLaunch; - cria a shared memory para controle dos processos JLaunch; - JLaunch - recebe comando do JControl para parar nós como dispatchers e servers; - para sozinho caso não detecte o JControl; - inicia a JVM em um processo separado. Startup: JControl é iniciado JControl inicia o SAP Signal Handler e cria um canal de comunicação com o Message Service JControl inicia o processo de boot da instância o processo de boot cria arquivo instance.properties no SO o processo lê a definição da instância no banco de dados JControl inicia o processo de boot dos nós java, que sincroniza todos os binários JControl inicia os nós, como os dispachers e servers como processos JLaunch. JCmon: monitora o JControl. Localizado em <instance_dir>/j2ee/os_lib e iniciado pelo comando JCmon pf=<instance_profile>. Starting under Microsoft Windows and UNIX Windows: MMC. Quando parar java sem parar ABAP, acessar SMICM. 23 Unix: Sistemas só com java: startsap JC<instance> (SCS) ou startsap J<instance> (dialog). startsap J2EE inicia Java E ABAP. Logs of the Start and Stop Processes of SAP Web AS Java - dev_jcontrol: trace do JControl; - dev_<node_name>: trace de processos JLaunch; - jvm_<node_name>.out: trace da JVM. Unit 3 – Installation in the SAP Web Application Server Java Enviroment Installing an SAP Web AS Java Master guide: descreve os cenários do NetWeaver e links para guias de instalação dos componentes. Installation of SAP NetWeaver Developer Studio NetWeaver Developer Workplace = Developer Studio + Web AS Java Unit 4 – Basic Configuration of SAP Web AS Java Administration and Configuration Tools for SAP Web AS Java Config Tools:Usado para configurar o Web AS Java no banco. - BD deve estar rodando - Configuração da JVM; - Configuração dos serviços e managers. - Necessário reinício do AS após setup; - não necessário user/senha; - executado localmente; - Chamado via configtool.bat, em /<instance_dir>/j2ee/configtool; Visual Administrator: usado para administrar e configurar o AS Java. - BD e Web AS devem estar rodando; - Configuração de serviços e managers; - configuração remota; - parar e ativar serviços; - parar uma instância java (se só java, quando java+ABAP, causa boot); - parâmetros alterados em runtime; - Chamado via go.bat, em /<instance_dir>/j2ee/admin; - Porta 50004. SAP Web AS Java Telnet: - DB e AS devem estar rodando; - Ativar e parar serviços; - parar uma instância java (ABAP + Java = reiniciar). - tool para emergências; - overview das informações importantes; - atividades simples de administração; - telnet <servidor> 50008. 24 General Configuration of the SAP Web AS Java Cluster with Config Tool Só pode usar o config tool para alterar parâmetros se todas as instâncias Java estiverem paradas. General Configuration of the SAP Web AS Java Cluster with Visual Administration 2 visões: global e cluster. Other Administration Tools System Information Acessar via browser, na pág. Principal escolher “System Information”. Mostra de forma geral a configuração do AS Java e informações de cada instância (host, portas, banco, SO, service pack, etc.). Telnet Comando “man” lista help. Principais: - lsc: lista os clusters ativos; - jump: trocar de nó; - shutdown. Selected Configurations Instance: 1 dispatcher e no máximo 16 server process. Config tool selecionar nó ou instância botão Add server p/ adicionar server process. Config tool é usado para alterar parâmetros do message server. Template Configuration Tool: fornece modelos fornecidos pela SAP. Iniciado em /usr/sap/<SID>/SYS/global/TemplateConfig. Unit 5 – User Administration in Java Environment Overview of User Administration in Java Tipos de armazenamento de usuários: - UME (User Management Engine): Default, serviço do Web AS Java, administração central de usuários. Administra usuários no banco de dados, serviço de diretório ou ABAP. - UDDI (Universal Description Discovery and Integration): iniciativa para descrever serviços e integrar negócios via internet. - Banco de dados, hard code, utilizado na versão 6.20 e não recomendado. User Management Engine (UME) Características: - console de administração, com facilidades de administração; - cenários de auto-atendimento: workflow de autorização, alterar os próprios dados, registrar-se como novo usuário, etc. - políticas de segurança para usuário (tamanho da senha, etc.); - logs de segurança. A UME é apenas uma interface para guardar dados de usuários. Utiliza vários data sources. 25 Interfaces: - persistence manager: permite guardar dados em fontes diferente. Define qual dado estará em qual data source; - replication manager: gera um XML e manda para um sistema externo. Tipos de particionamento: - Attribute-based: um campo (telefone, nome, etc.) é guardado em uma origem, outro campo em outra origem; - User-based: um tipo de usuário em um (ex.: terceiros) e outro tipo de usuários em outro; - Type-based: ex.: usuários no sistema e roles no LDAP. Particionamentos geram cenários, que possuem arquivos de configuração (XML) específicos. Durante a instalação podem ser ecolhidos 2 tipos de acessos: Java without ABAP: para centralização via java ou outro app server ABAP; ou ABAP + Java, onde o java acessa o repositório do ABAP. User Administration Tools Config Tool: apenas para alterar o data source. UME Console: site http://server:5xx00/useradmin. Administra usuários, roles, grupos, replicação manual e import/export de usuários, roles e grupos. Visual Administrator: administração caso os usuários sejam gravados no banco. ABAP User Management: caso integração ABAP x UME, permissões Java são consedidas via UME Console ou Visual Administrator. User Administration Administrator: ABAP + Java. J2EE_Admin: só Java. Usuário possui profile (nome, email, etc.). Usuário pode ser atribuído a grupos. Roles podem ser atribuídas a grupos e usuários. Se o ABAP user management é usado como data source, usuários devem ser mantidos na SU01. O usuário de comunicação ABAP/Java é o SAPJSF, que contém a role SAP_BC_JSF_COMMUNICATION_RO (recomendada). A role pode ser alterada para SAP_BC_JSF_COMMUNICATION para ter direito de escrita. A UME Console é sempre usada se a administração de usuários for no diretório ou banco de dados. Grupo de usuários é usado para atribuir roles para um grande número de usuários. Se o data source é ABAP, roles ABAP são vistas como grupos. The Java Authorization Concept Dois tipos: - J2EE security roles: administradas no Visual Administrator, parte do J2EE Standard, e se refere a um objeto; - UME roles: administradas via UME Console, uma extensão SAP que se refere à vários objetos. Na role UME: - permissions: definidos no código, e provê controle de acesso; - action: grupo de permissions especificadas em arquivo XML; - roles: grupo de ações de um ou mais objetos. SAP utiliza UME roles nas suas aplicações J2EE. 26 UME Parameters SAP recomenda que se use o Config Tool em modo offline (AS parado) para administrar os parâmetros (custer_Data Server cfg Services Propertysheet com.sap.security.core.ume.service). Proprieadades: - Security Policy: tamanho de senha, expiração, tamanho de login, etc.; - E-mail Notification: ao criar/remover/bloquear usuário, etc. - outras propriedades: histórico de alteração de usuário, criação de password automático, imagem apresentada no login. Special Users and UME Log/Trace Files Para alterar a senha do administrador, deve ser ajustado no secure store (Config Tool) e no UME Console. Existe um usuário “emergencial” (SAP*) que pode ser desbloqueado em casos de necessidade. O desbloqueio é via Config Tool e todos os demais usuários ficam bloqueados quando este está desbloqueado. Necessário reinicializar o Java cluster. Duas formas de ver log/trace: - via SO (security log (eventos de segurança) + trace files + log files (bibliotecas + UME provider)); - via log viewer. Unit 6 – Monitoring SAP Web AS Java Java Monitoring: Overview Junto ao CCMS, o monitoramento JAVA acumula dados, históricos e gera alertas. Podem ser exibidos localmente ou em um monitoramento central, usando o agente SPCCMSR. Funções para monitorar AS Java: - Monitoring Service; - Logging usando o Log Viewer; - Application Trace; - Single Activity Trace; - System Info; - SAP Application Statistics Monitoring Service Consiste de monitores de status e de configuração. Arquitetura baseada no padrão JMX. Monitora memória, threads, serviços e managers, conexão com o BD, transações do BD e sessões. Visualizado no Monitoring Service do dispatcher e do Server, via Visual Administrator. Logging Todos eventos importantes são gravados em log. Configuração via Log Configurator Service e exibido via Log Viewer. Application Trace Usado por desenvolvedores para Debug. Alguns marcadores mostram o tempo usado por métodos. Application Trace é integrado no Performance Tracing service no Visual Administrator. Single Activity Trace (SAT) Faz trace de requisições individuiais, que rodam em vários components. 27 Faz parte do Performance Tracing service no Visual Administrator e visto via Log Viewer. SAP Application Statistics Se existem problemas de performance, cada usuário individual pode ser adicionado na análise. Coleta tempo de resposta da aplicação, usuário que criou a requisição e a quantidade de dados transferidos. Visualizado no Visual Administrator, no Performance Tracing service. SQL Trace Trace de SQL pode ser ativado dinamicamente, e aponta o SQL, tempo, duração, resultados e parâmetros utilizados. System Info Mostra o status dos dispatchers, servidores, service pack... CCMS Os dados coletados pelo JMX podem ser enviados ao CCMS do sistema central via agente SAPCCMSR. Dados apresentados: - Dados de monitoramento; - Dados de disponibilidade; - Dados estatísticos: - ST03G: dados estatísticos relacionados à performance. AS Java usa distributed statistic records (DSRs). Para ativar, registrar o agente SAPCCMSR e agendar o job SAP_COLLETOR_FOR_NONE_R3_STAT. - STATTRACE: trace de performance. - Monitoramento de logs: monitora warnings, errors e fatal e dispara alertas. Resultados exibidos na RZ20. - Monitoramento do sistema operacional (coletados via SAPOSCOL e transferido via agente); Monitoring SAP Web AS Java O monitoramento é basedo no Java Management Extension (JMX). Através da API JMX é possível monitorar os recursos de todos componentes do servidor e de aplicações usando MBean (Manageable Bean). Tarefas da interface JMX e do Monitoring Service: - Monitorar o status atual; - Criar histórico; - Usar mecanismo de alertas para reagir em situações críticas; A infraestrutura JMX é provida pelo JMX Adapter Service. Os dados são coletados dos monitores JMX (passivo) ou os recursos mandam dados (ativo). JMX usa configurações em arquivos XMLs, e a SAP provê templates para serem usados. SAP recomenda monitoramento do Java via CCMS (ABAP) no PRD. Lá podem ser cofigurados sistemas de notificação e de auto-reação. Visual Administrator Server Services Monitoring: - Kernel; - Performance - Services - System: propriedades do sistema. - Applications: desenvolvedor utiliza funções no código, para monitoramento. Table buffer é exibido aqui, por default. 28 Alertas em branco: apenas informação (não há medida de desempenho) ou está com erro no monitor. History: histórico de valores. Cálculo dos valores/horas é configurado no monitorconfiguration.xml. A freqüência de coleta de dados pode ser alterada em Configuration General (do monitor). Configuration: configurar os valores de referência. General: freqüência e descrição. Performance: valores de referência. States: apenas em monitores estáticos. Important: cuidar dos monitores, que refletem informações de comunicação, processamento de requisições, conexão com banco, etc. Other Useful: utilizado para situações específicas; Info monitors: utilizado mais pela equipe de desenvolvimento. Appendix: Background Information About the Monitoring Service Seqüência: - Cliente manda HTTP para o dispatcher; - HTTP Provider abre um server socket na porta HTTP do ServerSocketListeners; - ServerSocketListener cria conexões entre o cliente e o dispacher. Default: 10 ServerSocketListner, para até 650 novas conexões por segundo. Se for maior que isso, fica no HTTP socket queue até o keepalive timeout; - após o ServerSocketListener, as requisições são direcionadas a thread do sistema, para processamento. Caso não possa iniciar o processo, é armazenada em WaitingTaskQueue do System Thread Pool do Thread Manager. - Cluster Manager transfere para o server. Uma session communication é criada diretamente entre o dispatcher e o server (requisições não provenientes de usuários são tratadas pelo message Server quando pequenas, ou pelo Lazy connection quando grandes). - o server inicia uma system thread e passa a requisição para uma application thread (ou aguarda na thread pool). 29 O System Thread Pool é responsável por atividades como backup e otimização em background dos dados: - ActiveThreadsCount: número de threads do Thread Pool que estão executando uma requisição; - CurrentThreadPoolSize: número de threads no Thread Pool; - InitialThreadPoolSize: tamanho inicial do Thread Pool; - MaximumThreadPoolSize: tamanho máximo do thread pool; - MinimumThreadPoolSize: tamanho mínimo do thread pool; - ThreadPoolIncrementStep: de quantas em quantas threads a Thread Pool crescerá; - ThreadPoolPercentageUsage: uso da Thread Pool em %. - WaitingTasksCount: número de requisições que estão aguardando uma thread livre na Thread Pool; - WaitingTasksQueueOverflow: número de threads que estão aguardando uma “vaga” na request queue; - WaitingTasksQueueSize: tamanho da request queue. O Application Thread Pool é responsável por executar o código. Possui o mesmo monitoramento que o System Thread Pool. O Cluster Manager é responsável pela comunicação entre elementos do cluster, seja via message server (poucos dados), seja via conexão direta (> lazy thresold parameter): - MessageContextCommunication: - TotalMSBytesReceived: quantidade de bytes recebidos por um serviço usando a camada de comunicação do server; - TotalMSBytesSent: quantidade de bytes enviados por um serviço usando a camada de comunicação do server; - AverageMSProcessTime: média de tempo em milisegundos em que uma mensagem é processada no message server. - LazyContextCommunication: - CurrentLazyPoolSize: tamanho atual do message object pool na lazy communication area; - CurrentMSPoolSize: tamanho atual do message object pool na message server area; - MaxLazyPoolSize: tamanho máximo do message object pool na lazy communication área; - MaxMSPoolSize: tamanho máximo da message object pool na message server area. - SessionContextCommunication: - CurrentSessionQueueSize: tamanho da message queue na session communication area; - TotalSessionBytesReceived: número de bytes utilizados por um serviço no session communication layer; - TotalSessionBytesSent: número de bytes enviados por um serviço usando a session communication layer; - AverageSessionProcessTime: média de tempo em milisegundos de uma mensagem na communication area; - MaxSessionQueueSize: tamanho máximo da message queue na session communication area. O Services Memory Service é usado para monitorar memória da JVM no cluster: - AvaliableMemory: memória total que pode ser usado pela JVM (-Xmx); - Allocated Memory: memória alocada; - Used Memory: memória em uso (dentro da alocada). Application Table Buffers são usados para diminuir acessos ao banco de dados e rede: - BufferSize: tamanho máximo dos buffers de tabela; 30 - FreeSize: memória livre, em bytes; - HitRate; - Number of displacements: número de deslocamento do buffer desde start do BD. Kernel Configuration Manager permite que módulos J2EE acessem dados no BD. Connecting to a Central Monitoring Service; Durante a instalação o agente SAPCCMSR cria um segmento na shared memory separado, onde os dados de monitoramento do AS Java são guardados. O agente manda dados para o CMS via RFC a cada 60 segundos. Para instalar e configurar o agente SAPCCMSR: - criar o usuário CSMREG no CMS (RZ21); - criar arquivo CSMCONF no CMS (RZ21); - registrar o agente com o SAP NetWeaver CCMS Agent Setup Tool. O arquivo CSMCONF é guardado no diretório do SAPCCMSR (/usr/sap/ccms/<SID>/sapccmsr). Este arquivo contém informações do usuário CSMREG e do administrador do ambiente. RZ20: SAP J2EE Monitor Templates: - Engines monitor: kernel, memória, serviços, performance... - Applications monitor: dados de aplicações. Para atualizar valores base de monitoramento: - Criar uma entrada na JCo RFC Provider service via Visual Administrator; - Criar uma coneão TCP/IP com o programa configurado (SM59); - Ajustar entrada do agente na RZ21. Após isto, a alteração pode ser feita dos dois lados. Log Viewer and Log Configuration O AS Java gera mais de 100 arquivos de logs, que podem ser acompanhados de duas formas: - via CCMS, caso esteja configurado; - via monitoramento da infraestrutura do WEB AS Java (log viewer, etc.). Todos os componentes java usam a mesma infraestrutura de log e trace, o que permite visualização central dos logs (Log Viewer). O log viewer é usado para ver arquivos de logs, independente de quem gerou (kernel, services, etc.). Pode ser usado para pesquisa de índice de severidade nos logs. Log viewer pode ser usado: - como um integrado log viewer; - como um central log viewer: visualização central de logs (de outros servers); - log viewer via linha de comando. Log Viewer Integrado Log Viewer roda como serviço no AS Java, disponível via Visual Administrator. Log Viewer é usado inicialmente para ler e para registrar arquivos de log. Cada aplicação fornece o log-configuration.xml, que é registrado manualmente ou automaticamente (diretório de logs ou via conexão de soquete). O registro de logs pode ser feito de forma manual (Log Viewer Service Runtime Add file) ou via log directory (importa do diretório tmp). Central Log Viewer 31 Permite visualização de logs mesmo quando o AS Java não está ativo, e visualização de logs ASCII, como do banco de dados. Central log viewer = log viewer + servidor remoto. Conecta no Web AS Java via porta P4 e no servidor remoto via porta RMI. Scritps para o Log Viewer central estão dentro de admin/logviewer_standalone. Deve ser executado o remoteserver.bat em cada AS a ser monitorado, e o logviewer.bat no que exibirá o log. File Connection to server para adicionar servidores a serem monitorados. Necessário registrar os logs para exibição. Command Line Log Viewer - via Standalone log viewer (lv.bat); - mostra apenas arquivos locais; - pode ser ativado durante deploys; - converte binários para formato legível. Logs significam: - eventos normais e excepcionais; - informações de runtime de uma aplicação ou sistema; - atividades durante operação normal; - dividido em categorias: sistema, aplicação e performance que apontam para um ou mais logs. Trace significa: - fluxo de processos de uma aplicação; - usado no desenvolvimento e para detecção de erros em produção; - todos os traces são guardados no trace default; - são estruturados em locations, que representam códigos de áreas, como classes ou packages. Logging/trace infraestructure: - SAP Logging API, Log Manager, Log Controller; - é configurado usando o Log Configurator Service; - é apresentado no Log Viewer. O Log manager lê o arquivo de configuração e informa ao Log Controller qual nível de log deve ser capturado. Este por sua vez cria o output dos dados de trace. Os arquivos de logs são salvos em <j2ee>/cluster/<server ou cluster>/log. Existem 7 níveis de log, sendo 3 para trace (ALL, DEBUG, PATH) e 4 para log (INFO, WARNING, ERROR, FATAL). O Log Configurator Service provê um ambiente para configuração de logs e traces. Use o log configurator via visual administrator para: - mudar o nível do trace; - adicionar, mudar ou remover destinos de logs; - adicionar, mudar ou remover formatos de log (diferentes de XML, como traces); - adicionar, mudar ou remover controladores de log; - arquivar arquivos de log. Log Formaters cuidam do tipo de formato de log (XML, trace, etc.), log destination é onde ficam guardados e log controllers são os objetos que podem escrever logs/traces. A mudança do nível de log pode ser feita via controllers (principal) ou no destino do log. Os logs são automaticamente (por default) arquivados em <j2ee>/cluster/<server ou cluster>/log/archive. Não são apagados automaticamente. O Log Configuration Tool é usado quando o AS não está disponível, e pode ser feito download a partir do SDN. 32 Via Log Manager é possível configurar o destino do log, se vai ser junto com os outros (padrão) ou separado. Availability Monitoring Ferramentas disponibilizadas para monitorar aplicações e o AS são baseadas no GRMG (Generic Request and Message Generator). GRMG é separado em duas partes: - Infraestructure: parte da arquitetura de monitoramento do CCMS. Manda um XML para a aplicação GRMG, recupera a resposta e encaminha-a para o CCMS; - Application: interface JSP ou BSP para monitoramento de disponibilidade. O monitoramento é conceituado como agente, sendo executado separadamente da aplicação monitorada. Cenários: - customização técnica para monitoramento: aplicação já existente, onde será habilitado o monitoramento; - instrumentação da aplicação: criar na aplicação um monitoramento GRMG. GRMG usa funções do CCMS para gerar o heartbeat (GRMG infrastructure manda XML para GRMG application GRMG application faz testes de disponibilidade e manda de volta para o GRMG infrastructure GRMG infrastructure manda resultado para o Alert Monitor). Para configurar monitor de disponibilidade: - alterar o grmg-customizing.xml via Visual Administrator; - upload do arquivo no CMS (automaticamente via SAPCCMSR ou manualmente via transação GRMG); - Iniciar cenários GRMG para monitoramento de disponibilidade. Para criar um monitoramento GRMG na aplicação: - Desenhar o cenário GRMG (aplicações, componentes, processos, etc.); - Criar mensagens que serão retornadas; - Criar um template do arquivo de customização; - Implementar a aplicação. Statistics and the Performance Trace Performance data = Performance statistics (overview = JARM + DSR) + performance trace (detalhes do fluxo de dados = Single Activity Trace (SAT) + Performance Trace + Application Trace + SQL Trace + Logging API Trace). Todos os traces de performance podem ser ativados juntos para monitorar uma sessão. Normalmente visualisados via: - DSR (área técnica) na ST03G (dados agregados para analise de performance) e STATTRACE (dados crus, para análise de problemas); - JARM (aplicação) no AS Java. Java Application Response Time (JARM) coleta dados de tempo de resposta de aplicações JAVA, que são disponibilizadas no Visual Administrator, serviço Performance Trace (Server Service Performance Tracing). Single Activity Trace (SAT) é usado para trace de ações de um usuário. Um trace é gerado para cada componente, e são interligados via passaportes. DSR coleta dados que são agrupados e enviados de hora em hora para o CCMS via agentes (iniciado pelo job SAP_COLLECTOR_FOR_NONE_R3_STAT). Esses dados agrupados são exibidos na ST03G. ST03G possui funções para parametrização e guardar dados DSR: - Exibir e deletar conteúdos de dados de performance; 33 - Reorganização (delete, etc.) de dados de performance (pelo job diário SAP_REORG_NONE_R3_STAT_DB); - Mostar logs de coletores; - Configurar parâmentros do coletor DSR - Configurar parâmetros de geração de estatísticas; - Exibir logs de aplicação; - Definir sistemas a serem monitorados. Ativar o trace de performance quando quiser detalhes maiores da operação executada. Para cada módulo, as informações de chamada de métodos e a sua duração são gravadas, e exibidas na STATTRACE. Para isso: - SAPCCMSR deve estar instalado; - CMS deve ser >= 6.40 - DSR service deve estar ativo. Para ativar o trace: Performance Tracing Runtime Control Trace Configuration. Application trace é direcionado apenas para desenvolvedores, que podem ativá-lo sem necessidade de boot do container, redeploy da aplicação ou colocar a VM em modo de debug. Neste caso, a aplicação é iniciada em bytecode-modified mode, e quando completado, volta para o normal mode. SQL Trace provê informações como tempo, duração, resultado, input... e é utilizado por desenvolvedores ou para análise de problemas de performance. Pode ser ativado e desativado via WEB (/OpenSQLTrace e /SQLTrace) ou Visual Administrator (Server services Log Configurator enable/disable SQL Trace). O peformance tracing pode ser ativado para uma sessão específica, em server Services Performance Tracing Runtime. Unit 7 – Change Management and Software Logistics in the SAP Web AS Java Environment Overview of the Standard J2EE Development Process Java é uma linguagem de programação orientada a objetos, similar a C ou C++. Toda codificação é feita através de classes, e os status através de métodos. Possui bibliotecas que facilita o trabalho com protocolos TCP/IP, como FTP, ou HTTP. Via RMI (Remote Method Invocation) é possível acessar métodos em outros servidores. A codificação (.java) é compilada em um formato independente de arquitetura, chamado bytecode (.class), que é interpretado e executado por uma Virtual Machine. JRE consiste de três elementos principais: - Class Loader que carrega as classes necessárias para execução do programa; - Bytecode Verifier que verificar se as classes são compatíveis com a VM; - JVM. Para execução de um programa, é necessário o JRE, que vem com a JVM, as interfaces padrões (ex.: RMI) e outros componentes necessários para aplicações e applets. J2SDK (software development kit) contém ferramentas para o desenvolvimento, como o compilador e debug. J2EE (enterprise edition) é um standard que permite desenvolvimento de aplicações multi-camadas e distribuídas usando componentes. A arquitetura do J2EE é dividido em 3 níveis: - presentation tier: web browser, aplicativo Java, etc. - middle tier: J2EE Server; - back-end tier: banco de dados, ERP, etc. 34 Componentes são unidades completas e funcionais do software, que quando combinada com outras classes formam uma aplicação J2EE. Componentes diferentes no J2EE: - Applets: componentes de apresentação que rodam no cliente; - Servlets e JSP: componentes de apresentação que rodam no servidor; - Enterprise Java Beans: lógica de negócio que roda no servidor. A comunicação entre o servidor Java e o cliente é via Web Standards, como HTTP, HTML e XML (criados via JSP ou Servlets). Container são objetos que proveem um runtime para outros objetos. Representam a interface entre o componente e a funcionalidade J2EE que suporta aquele componente. Antes de um componente poder ser usado, ele é juntando em uma aplicação J2EE (assembly) e deployed em um container. De acordo com o padrão J2EE, aplicação e apresentação são separadas durante o desenvolvimento. A configuração da aplicação é feita através do deployment descriptor (arquivo XML). Após a criação da aplicação, o desenvolvedor faz o build, que é a combinação de EJB, classes Java e o deployment descriptor (gerando um arquivo .jar). Também é gerado um web archive (.war) que contém a camada de apresentação e classes dependentes. O application assembler (administrador) reúne .jar + .war + outros enterprise archives + outro deployment descriptor para gerar um EAR (enterprise archive). Esta etapa é chamada de assembly. É feito um deployment deste EAR, que instala este arquivo em um J2EE Server. Introduction to the Infraestructure (JDI) SAP NetWeaver Java Development JDI transfere conceitos do ABAP para o Java, evitando sobreposição de arquivos em desenvolvimento e trabalhos em equipe. O JDI é baseado em padrões J2EE ou WebDav e DeltaV como repositório, para acesso e versionamento de objetos. O ambiente de desenvolvimento local é baseado no Eclipse. A ferramenta de desenvolvimento SAP NetWeaver Developer Studio é utilizada para desenvolvimento de aplicações Java multi-camadas. A vantagem é a integração com as ferramentas SAP, como o repositório central de objetos (DTR), processos de build automático (CBS), associado ao Change Management e transportável. Em comparação ao ABAP, no J2EE faz-se login no Development configuration do JDI, que contém uma lista de componentes de software requeridos para análise, construção e testes de um ou mais componentes no Developer Studio. As versões são baixadas na máquina do desenvolvedor, que as altera e, após testes locais, envia novamente ao servidor central. O servidor verifica novamente as versões (também de classes de bibliotecas) e, caso a nova versão seja ativada com sucesso, o desenvolvimento pode ser transportado. O Developer Studio conversa com o JDI, que consiste de um ambiente local para desenvolvimento (IDE) e serviços no servidor central, que provê um controle central do desenvolvimento e suporte para o desenvolvimento de softwares (DTS, CBS e Name Server do SLD). Para evitar conflitos de nomes, o System Landscape Directory (SLD) provê um serviço de reservas de nomes (Name Server). O DTR (Design Time Repository) provê versionamento, distribuição entre times de desenvolvimento e transporte e replicação dos sources. O CBS (Component Build Sercice) via developer Studio, permite build central do source code, em comunicação com o DTR. O CBS ainda conversa com o CMS para transporte. 35 CMS (Change Management System) é usado para configurar os landscapes de desenvolvimento e o transporte das modificações. Ele faz um link entre os componentes, criando uma unidade. O landscape é dividido em 4 ambientes: - DEV: usado por desenvolvedores para testes locais, sem interferência de alterações de outros desenvolvedores; - CONS: consolidar um determinado status do software; - TEST: teste final; - PROD. Configuring the SAP NetWeaver Java Development Infraestructure O WEB AS Java atua como runtime quando as aplicações sofrem deploy nele. O JDI suporta desenvolvimento em 3 cenários: - orientado a time: suporte para desenvolvimento de aplicações Java e J2EE, porém não para Web Dynpro; - componentes em uma track: usável apenas se um único componente for alterado, e a administração e ambiente de build sejam usados; - desenvolvimento em camadas: utilizado para desenvolvimento de múltiplos e interdependentes componentes. O cenário orientado a desenvolvimento em times é recomendado apenas para times pequenos, onde administração centralizada não é utilizada. Usado apenas o estúdio e o DTR. A compilação, assembly e deployment são feitos através do Studio. São criadas versões diferentes do software no DTR, para cada nível (desenvolvimento, testes, etc.). O cenário para desenvolvimento de componentes em uma track é recomendado para grandes grupos de desenvolvimento, mas sem administração centralizada. Todos os produtos do JDI são usados. A configuração do desenvolvimento representa o ponto central do processo. Esta configuração define a visão dos desenvolvedores do landscape JDI. O administrador usa o CMS para definir uma track, e o CMS automaticamente cria os workspaces e buildspaces necessários, e adiciona a configuração de desenvolvimento no SLD. Passos: instalar e configurar o DTR criar o client definition para os studios (opcional) implementar processo de change management. Como no primeiro cenário, os desenvolvedores têm o Developer Studio e um AS Java instalados na estação de trabalho, e usa o DTR como origem do código fonte. Usando componentes, os desenvolvedores podem quebrar o código em unidades menores e reusáveis. O build central é feito pelo CBS, e o processo de change management roda automaticamente. Passos: instalar o SLD instalar AS para CMS e DTR e outro (opcional) para CBS deployment do JDI no CBS, CMS e DTR instalação do Developer Studio e AS Java na estação de trabalho instalação de outro AS Java para testes centralizados. Após isto, o SDM (Software Deployment Manager) é usado para configurar o JDI: configurar o JDI database atribuir autorizações ao administrador preparar o SLD configurar o CBS. O SLD é um servidor cujos clientes comunicam via HTTP. Contém informações de componentes e descrição do landscape (versões, patches e dependências dos componentes). Quando o AS é instalado, ele é criado dentro de /SYS/global/sld, mas deve ser configurado e ativado: - Ativar o servidor SLD: via url HTTP://<sld-host>:<porta>/sld. O nome do object Server deve ser especificado, seja via SAP Marketplace ou com o nome do próprio servidor (que impossibilita o uso para reservas de nome no JDI); - download e import do SAP Master Component Information e updates; 36 - Configurar o SLD data bridge: converte dados de entrada no formato CIM; - Configurar o SLD data supplier: via ABAP são criadas RFCs, e via Java conexão HTTP, em cada cliente; - registrar o servidor SLD e o name service: no próprio AS do SLD e via DTR, respectivamente; - reservar namespace; - registrar o name service no DTR. Preparing for the Development of Java Applications Criar usuários e funções: - Desenvolvedores: trabalham no Developer Studio e no JDI. Requer acesso ao SLD e todos componentes no JDI; - Administrador: acesso a todos componentes do JDI não é requerido acesso ao SLD para tarefas no CMS; - CMS user: acesso full ao CMS, DTR e CBS. Acesso ao SLD é necessário para configurar o JDI e operar o CMS. Não é atribuído a uma pessoa real. Um development component (DC) é um container para uma série de objetos que fazem parte do software. Componentes possuem interfaces para comunicação com outros componentes, mas sua lógica interna é fechada em uma unidade. Development object (DO) é um objeto (classe, JSP, tabela) que faz parte de um componente e que pode ser alterado por si só. São guardados no repositório Software componets agrupam DCs para delivery e deployment em unidades maiores. Um produto consiste de um ou mais SCs, e representam um processo de negócio. Produtos e SC são criados no SLD (home Software Catalog). Um CMS domain representa a parte do landscape que é administrado pelo CMS. O domain name (3 caracteres) e o CMS name são criados e não podem mais ser alterados. O development configuration define os SCs que serão desenvolvidos e controla os acessos aos objetos no JDI. Uma track contém todos development configurations e todos os ambientes de runtime requeridos para desenvolver, testar, e produzir SC. Os componentes SAP-JEE, SAP_BUILDT e SAP_JTECHS são requeridos para um build central. O plug-in DTR Administrator facilita a administração do DTR. Deve ser ativado no Developer Studio do Administrador. Para isto, renomear arquivo plugin.xml.disabled. Para conectar o Developer Studio no JDI: - Ativar o Development Configuration Pool: Java Development Infraestructure Development Configuration Pool; - Configurar o local do runtime environment (AS Java), em SAP J2EE Engine; - Configurar o Proxy. Development configurations são criados e guardados no CMS. O SLD contém informação de onde (qual CMS) uma determinada configuração está. Developing Java Objects in SAP NetWeaver Developer Studio Development configurations são importados no Developer Studio, o que faz sincronizar as fontes no DTR e arquivos no CBS fontes são criados ou revisados build local: fontes e archives são carregadas e o build inicia testes locais sources são atualizados no DTR build central é iniciado pelo Studio sources e archives necessários são lidos do CBS, o build é realizado e a nova versão é ativada no DTR o deployment no sistema central é iniciado, usando software logistics testes gerais após release, as mudanças estarão no import do CONS. 37 O elemento central do developer Studio é o J2EE Explorer, ou J2EE DC Explorer, o que permite uma visão lógica do projeto e provê ponto de início para atividades de desenvolviemento (de JSPs, etc.). O DTR provê versionamento do código fonte no contexto do JDI, permite desenvolvimentos em times, transporte e replicação dos códigos fontes. O DTR é dividido em client (no developer Studio) e em Server (gerencia o versionamento dos arquivos). Arquivos alterados estarão sempre no workspace inativo no DTR. Para ativação, ocorre o build central. Após a ativação, a aplicação sofre deploy no sistema central de desenvolvimento da track usada. Transporting Java Developments Após o desenvolvimento, os desenvolvedores transferem as modificações para o CMS do ambiente de desenvolvimento central. DEV: desenvolvimento individual; CONS: consolidar testes de versões que não estão em desenvolvimento. TEST: teste final PROD: produção. Desenvolvedor transfere para o CBS CBS reinterpreta e disponibiliza resultado em forma de bibliotecas ou deployable archives desenvolvedor transfere as mudanças para o CMS CMS empacota atividades em uma change request e coloca na import queue da consolidação administrador importa: integra releases no DTR da consolidação e o CBS automaticamente compila os componentes alterados CMS cria uma nova versão da aplicação (assembly). Ao contrário do desenvolvimento no ABAP, onde o transporte utiliza sempre a mesma track (route), no Java uma track é usada apenas para um software component. Os sistemas envolvidos não estão relacionados apenas no runtime e banco de dados, mas nos workspaces do DTR e buildspace do CBS. O transporte entre desenvolvimento e consolidação é feito através de transport requests, porém a partir da consolidação, apenas componentes completos são transportados. Durante o export no desenvolvimento, é criado um arquivo pra (Propagation Request Archive), juntamente com um log. Como dev e cons usam o mesmo DTR, o arquivo pra contém apenas informações, e não código fonte. Após import, o CBS gera um arquivo SDA (Software Deploymet Archive), que é usado para deploy. Arquivos gerados no dir CMS: - CMS/logs: logs do export e import - CMS/archives: sca e pra files gerados no export - CMS/CBS: sda files gerados pelo CBS para deployment. Quando é liberado no sistema de consolidação, um processo de assembly é iniciado. Nele, as change requests são coletadas e uma versão do componente é criada, contendo todas as alterações das change requests. A versão do componente é disponibilizada no system landscape. As change requests não são usadas para futuras migrações no landscape. Os componentes gerados, além de archives e sources (dependendo da track), contêm informações sobre seus componentes e versões, mas não os componentes requeridos em si. Este componente de software é importado no TEST, onde ocorre um assembly. O desenvolvimento normalmente é feito em camadas, cada uma gerando sua track. Os componentes normalmente são independentes entre as tracks. 38 O Software Deployment Manager (SDM) é um software usado para gerenciar e fazer deploy de packages da SAP. A SAP disponibilisa SDAs e SCAs para serem importados. O software é cliente (para import)/servidor (embutido no AS Java). SDA: software deployment archive: aplicações SAP não ABAP. Contém um manifest, arquivos (jar/war). Representa a menor unidade de patches que podem ser disponibilizados. SCA: software component archive: representação física do status de um componente. Contém um número de SDAs, que prescreve um status de uma versão. A manutenção de software é feita em 3 níveis: - um produto: um ou mais SC que representam um processo de negócio; - support package: disponibilizados para manutenção de um produto; - patches: pequenas correções de erros. Unit 8 – Importing Corrections Installing Corrections for SAP Web AS Java SAP provê extensões, correções e updates via Service Packages. SAP Notes com patches são usados para pequenas correções. Para o AS Java, os seguintes arquivos são requeridos: - SAPINST<##>_<xx>.SAR: SAPInst; - CTRL<DB><##>_<xx>.SAR: arquivos de controle do SAPInst; - J2EERT<##>_<xx>.SAR: arquivos independentes de SO; - J2EERTOS<##>_<xx>.SAR: arquivos dependentes de SO. SPs para AS Java são importados via SAPInst. SPs para aplicações Java são importadas via SAPInst ou via Software Deployment Manager (SDM). Procedimento geral: - leitura da documentação do SP (ou SP Stack) + SAP Notes; - download no Service Marketplace; - descompactação dos arquivos (irá gerar diretórios SAPINST-CD e J2EE-RUNT-CD); - instalação na Central Instace; - instalação nas dialog instances. Para instalar um SP, entrar no diretório SAPINST-CD e iniciar o SAPInst. Primeiro ir em “Apply Support Package <#>” e depois em “Apply Support Package <#> for Dialog Instance”. Installing Corrections for a Java Application Lição usa JDI como exemplo. Arquivos do JDI: - SAPDEVINFF<##>_<xx>.SCA; - SAPDEVINF<##>_<xx>.SCA; - SAPBUILDT<##>_<xx>.SCA. São feitos deploys dos arquivos via SDM. Para alguns, deve ser offline, outros online. Offline Parar o AS Java, e para iniciar em modo StandAlone para o deploy, em /usr/SAP/<SID>/<central_instance>/SDM/program: - sdm.sh jstartup mode=standalone; - StartServer.sh - RemoteGui.sh (inicia o SDM GUI). Na guia Deploy, escolher ícone “Add SCA/DAS to Deployment List”. 39 Pressionar “Next” várias vezes e depois “Start”. Após o deploy, reiniciar o SDM em modo íntegro: - StopServer.sh; - sdm.sh jstartup mode=integrated; - iniciar o AS Java. Online Apenas iniciar o SDM e realizar o deploy. Unit 9 – Backing Up SAP Web AS Java Backing Up SAP Web AS Java Primeiro backup após instalação e upgrade: - file system backup: /usr/SAP/<SID>/<instance>; - Backup do SDM; - Backup do diretório home do banco de dados. O SDM deve ser parado para backup. Backup do dir /usr/SAP/<SID>/<CI>/SDM. O SDM contém a lista de todos os deployments instalados fora do banco de dados Unit 10 – Technology Components for Browser-Based User Dialogs Internet Schenarios with SAP Systems ITS é um software que age como gateway entre o web Server e o SAP. HTTP(s) e HTML de um lado e DIAG, RFC, screens de outro. Aplicativos desenvolvidos especialmente para ITS são chamados de Internet Application Components (IAC), como o self service. ITS ainda é requerido para SAP Gui for HTML e algumas aplicações. Devido a novas tecnologias usadas no AS 6.10, a SAP criou o ICM para processar HTTP diretamente da internet, e enviar a resposta de volta (sem web Server). J2EE Standard não descreve uma comunicação baseada em browser, mas sim um application Server completo. Web Dynpro é um modelo de programação preferido para interfaces Web de aplicações em sistemas SAP baseados no SAP Netweaver. Provê uma distinção entre interface e lógica de negócios. Inclui funções como verificar inputs, help, suporte a multilinguagem, etc. SAP Internet Transaction Server (Standalone) Um web Server é requerido. O ITS é dividido em AGate (application) e WGate (web). Usuário manda requisição HTTP Webserver identifica e direciona para o WGate WGate transfere para o AGate AGate determina a função que deve ser executada a transação é executada AGate transforma o output em HTML, usando templates Dados são mandados para o usuário através do WGate e do Web Server. A configuração do WGate é feita no arquivo Registry.xml, diretório config (para configurar o WGate e o IAC Object Receiver – IACOR). ITSRegistryWGATE.xml contém informações como a lista de ITS, AGate servers usados, parametrização. Necessário reinicializar o web Server após mudanças. Outra opção é usar o WGate configuration tool: - abrir ITSRegistryWGATE.xml e mudar ConfigMonitorEnabled para Yes; - acessar url HTTP://<server>:<SID ITS port>/scripts/wgate/wgate-restart; 40 - configurar na URL HTTP://<server>:<SID ITS port>/scripts/wgate/wgate-config; - retornar parâmetro para NO e reiniciar o WGate novamente. O ITS Configuration Tool permite a configuração do AGate. Inicialmente o usuário itsadmin é usado. Permite: - Administração de usuários, - Configuração dos parâmetros; - Iniciar e parar o AGate e o IACOR; - Verificar logs e traces; - Monitorar performance e tuning. Para desenvolvimento de objetos IAC: - Web Application Builder for ITS Sercives: SE80; - SAP@Web Studio (recomendado apenas para <= 4.6B). Watchdog: executado como serviço no Windows, no servidor do Web Server, permite monitoramento de todas instancias ITS via DCON, High-avaialability do WGate usando o MS WLNB, registro do ITS no LDAP. O monitoramento do ITS pode ser feito via CCMS, via agente SAPCCMSR. Internet Communication Manager Características: - Suporte a HTTP(S), SMTP, SOAP, WebDav; - Output em XML, HTML e XSLT; - integração completa com o SAP Funciona como Web Server e Web Client. Junto com o Work Process, o Internet Communication Framework (ICF) prove o ambiente para manipular requisições HTTP. ICF é a ponte entre o kernel do SAP e aplicações criadas em ABAP. O Work Process pode enviar uma resposta web via ICM. Para isto, as aplicações são desenvolvidas em BSPs (SE80). O ICM é um processo a parte (icman), baseado em threads, iniciado e monitorado pelo dispatcher ABAP. 41 Componentes: - Thread control: recebe a entrada TCP/IP e direciona ao thread pool; - Worker Thread: manipula as requisições e respostas. Contem I/O handler para input e output e plug-ins para cada protocolo (padrão: HTTP(S) e SMTP); - Watchdog: work thread espera por uma resposta do usuário. Caso dê timeout, o watchdog libera a thread para processar outra requisição; - Signal Handler: processa sinais enviados pelo SO ou outro processo; - Connection Info: informações sobre todas as conexões; - Memory Pipes: permite transmissão de dados entre ICM e ABAP work process. ISC: Internet Server cachê: - hierarquia em 2 níveis: cachê em memória e disco; - cachê dinâmico: cachê para BSPs e JSPs; - active caching: aplicação tem controle para verificar se o cachê está atualizado; - UFO cachê (UnFound) requisições inválidas são rejeitadas, evitando ataques; - cachê dependente de browser: usa cachê apenas para um tipo de navegador especificado no BSP. ISC é configurado via parâmetros icm/HTTP/server_cache* Parâmetro rdisp/start_icman determina qual instância terá o ICM. Para detalhes e monitoramento: SMICM. Em Administration ICM pode-se parar. Colocando Restart Yes/No indica se é para reiniciar (devido a erro) ou deixar parado (manutenção). SMICM: - monitora e reinicializa o ICM; - define o nivel de trace; - exibe o trace; - overview dos parâmetros; - mostra estatísticas; - monitora. 42 O programa icmon no SO exibe mais detalhes do ICM (icmon –h para help). Internet Communication Framework Permite a comunicação entre sistemas diferentes através de protocolos standard da internet. Nenhuma biblioteca adicional é requerida, exceto para HTTPS (sapcryptolib). O Task Handler recebe a requisição, executa alguns processos e responde a request. Caso a requisição deva ser direcionada a um Work Process, o Task Handler inicia um ICF controller. A partir daí, está no mundo ABAP. Usuário manda requisição HTTP ICM direciona para ABAP ou Java ICM guarda dados na memory pipe e avisa o ABAP dispatcher ABAP coloca a requisição no dispatcher queue, cria o contexto e seleciona um WP o task handler lê os dados do memory pipe e transfere para o ICF controller ICF controller transfere para o ICF Manager usuário autenticado a requisição HTTP é processada e o controle é devolvido para o ICF controller o task handler escreve o resultado na memory pipe e sinaliza ao ICM que a resposta está pronta ICM devolve a resposta. O ICF é uma classe ABAP por trás da requisição HTTP. A SAP disponibiliza algumas classes. Outras podem ser criadas no Class Builder (SE24). Todos os serviços são exibidos e mantidos na transação SICF. Serviços ativos são exibidos em preto, enquanto os inativos em cinza. Em azul os que são ativados/desativados de acordo com o serviço pai. A alteração das propriedades dos serviços é feita na forma de herança (mudou o pai, os filhos também são mudados), exceto quando o filho é alterado manualmente. O ICF cria links (ou alias) entre um serviço e outro. O ICF Recorder permite a desenvolvedores ou administradores a identificar e corrigir erros em solicitações HTTP. A request com problemas pode ser reexecutada várias vezes usando a entrada no banco de dados. Para acessar o ICF Recorder: SICF Edit Recorder Activate Recording/Deactivate Recording/Display recording, ou transação SICFRECORDER 43 para exibir o trace. Na hora de ativar o trace: determinar a URL, o tempo de duração e se uma ou mais requests serão gravadas. Até 6.20, o ITS era Standalone. A partir do 6.40, está imbutido no kernel (integrated). Na 6.40, o ITS é acessado via processo ICM, implementado como serviço ICF e usa o banco de dados como object store. Restrições: - o integrado não suporta o flow logic, WebRFC e WebReporting. Para isso necessário ITS 6.20; - um ITS standalone não pode sofrer upgrade para o integrated. Apenas via upgrade do Web AS. Para ativar o ITS integrated: - ICM deve estar rodando; - paramentro itsp/enable=1; - o serviço ITS deve estar publicado no site interno; - ITS service está ativo e o ICF e propriedade GUI Link=Y; - serviço ICM /SAP/public/BC/its/mimes está ativado e ICF e propriedade GUI link= “ ” (espaço). Outros parâmetros iniciam com itsp/*. Especial atenção para: - itsp/enable: ativa o ITS integrado; - em/global_area_MB: shared memory para todos Work Processes + integrado ITS. Além destes parâmetros, existem parâmetros de serviços, mantidos via SICF. Um desenvolvedor pode criar um novo serviço via Web Application Builder for ITS Service (SE80), e publicá-lo no site INTERNAL. Para usar o SAP GUI for HTML, é necessário ainda: - serviço system e webgui publicados no site INTERNAL; - serviço ICF /SAP/BR/gui/SAP/its/webgui ativado, com o GUI Link=Y. O monitoramento é feito via SM21, SM22, SMICM e SMICF, e os logs estão junto dos logs dos Work Process (dev_w*.trc). SAP Web Dispatcher O Web Dispatcher é usado como centralizador de conexões e como load balance. Age como um Web switch. 1) O Web Dispatcher identifica se a chamada é ABAP ou Java, e qual logon group a ser usado; 2) O load balancing é feito no grupo. É necessário um Web Dispatcher por sistema. O controle sobre sessão statefull é feita via cookie (usa sempre o mesmo AS). Se é stateless, é usado um logon group !DIAG ou !J2EE. Para usá-lo, copiar o executável (sapwebdisp.exe) para um host, junto com o profile. A configuração é feita basicamente em 3 parâmetros: - icm/server_port_<X>: porta do Web Dispatcher; - rdisp/mshost: host do message server; - ms/http_port: porta do message Server. Ativando em modo bootstrap (sapwebdisp –bootstrap): - se não existir o profile sapwebdisp.pfl, ele é criado; - se o arquivo de autorização icmauth.txt não existe, ele é criado e um usuário para administração é criado; - o Web Dispatcher é ativado com o profile criado. Outra forma de ativar: sapwebdisp pf=<profile>. Para desativar, executar o kill. 44 Monitorado via ICMON. A SAP disponibiliza uma interface de administração e monitoramento baseado em web. As entradas no icmauth.txt podem ser alteradas via icmon –a. 45 TADM12_1 Unit 1 – mySAP ERP Solution Architecture Introducing to mySAP ERP Solution ERP desenvolvido para levar para web processos para comunicação com clientes e fornecedores. Combina o core do ERP com colaboração baseada no portal. SAP Web AS componentes: SAP Kernel, SAP_BASIS, SAP_ABA e SAP_BW. SAP ECC componentes: SAP_APPL e SAP_HR 5 -1 2 release and maintenance strategy: 5 anos de suporte (Mainstream maintenance), 1 ano de supporte extendido com acréscimo de 2% e mais 2 anos de suporte extendido com acréscimo de 4%. Após isto, o cliente é responsável pelo suporte. ICM - Internet Communication Manager: adicionado na versão Web AS 6.10, possibilita a conversa via HTTP com web servers e via SMTP com mail servers. New Features of SAP ERP Central Component and SAPinst Linguagens: - SAP suporta mais de 30 linguagens diferentes; - Apenas linguagens com mesmo code page podem ser usadas juntas sem restrições; - suporta múltiplas linguagens com sistemas MDMP (multi-display-multi-processing). Unicode: - define um tipo de caracter que engloba virtualmente todos os caracteres usados no mundo; - suportado desde o Web AS 6.10; - aumenta consumo entre 30 e 35% de CPU, memória e rede; e de 36% (UTF8) ou 60% a 70% (UTF-16) no banco de dados. - o mesmo SAP GUI pode ser usado tanto em unicode quanto em não unicode. MCOD (Multiple Components One Database) - Não necessita de esforços adicionais, é integrado no processo de instalação. - Sap recomenda utilizar apenas em mesmo contexto (DES com DES, etc.) e não misturar OLTP com OLAP. 46 - Não é possível misturar produção com sistemas não produtivos. - Cada componente possui um usuário para base de dados. Directory Server Atua como repositório central de usuários. LDAP e CUA trabalham de forma independentes. SAPInst: System Landscape Implementation Manager Novidades: - GUI independente do SAPInst: você pode desconecta-la clicando em logoff, sem precisar cancelar a instalação; - Possível voltar steps sem precisar cancelar a instalação; - Erros não causam aborts; - Poucos arquivos de log; - SAPInst GUI permite monitorar toda a instalação e mostra todas as mensagens apresentadas pelo SAPInst; - Instalações canceladas podem ser continuadas; - SAPInst GUI pode ser iniciado em outro computador; - SAPInst GUI requer JDK e JRE. Unit 2 – Planning the Installation of SAP Central Component Planning the instalation Sugestão de separação dos discos em RAID: - Business Data e índices: RAID5; - Logs e arquivos de configuração do banco de dados: RAID1; RAID1 Dois discos espelhados. Caso um pare, o outro assume; RAID5 Vários discos trabalhando como em RAID0, porém gravando dados de paridade em todos eles. Caso um falhe, com informações de paridade e demais dados em outros HDs é possível reconstruir o arquivo. Unit 3 – Preparing for the Installation of SAP Central Component General Preparation for Instalation - Order or download installation DVDs; - Download install guide para SO e BD específicos; - Download de todas as notas espeficicadas no install guide; - Preparar os DVDs de instalação: - Não usar espaços nos nomes dos diretórios; - SAPInst precisa que todos os arquivos e diretórios estejam em maiúsculo. Futher preparation for Installation on Windows Pré-install - Precisa ser NTFS; - Utilizar um único domínio de rede; - Usuário com privilégio de Administrador; - Mapear (no arquivo hosts ou no DNS) o servidor SAPTRANSHOST apontando para o servidor que possui o diretório de transporte; Preparando a instalação - Instalar JDK em todos os servers que rodarão o SAPInst; 47 - Renomear arquivos em <java_home>\jre\lib\ext, tirando extensão .jar. Voltar após instalação; - Criar variável de ambiente JAVA_HOME; - Adicionar %JAVA_HOME\bin para a variável PATH Futher preparation for Installation on Unix - Criar FS ou RAW Device /usr/sap/<SID>, /usr/sap/trans e sapmnt/<SID>; Preparando a instalação - Instalar JDK em todos os servers que rodarão o SAPInst; - Renomear arquivos em <java_home>\jre\lib\ext, tirando extensão .jar. Voltar após instalação; - Criar variável de ambiente JAVA_HOME; - Criar variável DISPLAY apontando para o servidor que terá o GUI do SAPInst; - Caso utilize UNICODE, adicionar /sapmnt/<SID>/profile para o path do sistema. Unit 4 – Installing SAP GUI Installation of SAP GUI for Windows Três tipos de GUI: - for windows; - for java; - for HTML Instalar e aplicar patch. Admsetup.exe para gerar SAP GUI Installation Server. Para aplicar patch no installation Server, executar o SAPAdmin.exe. Installation of SAP GUI for Java Baixar do site da SAP a versão mais atual e consultar c:\program files\ SAPGUI for Java\<version>\doc\manual.html para maiores detalhes de configuração. Unit 5 – Installing the SAP ERP Central Component Introducing SAPInst Serviços que fazem parte do SAPInst: - Controller: controla todo o processo; - KeyDB: faz a persistência. Grava as ações completadas em XMLs; - GUI Engine: cuida da exibição de telas, do input de dados (o KeyDB grava nos arquivos XMLs), e valida input do usuário. Conversa com o SAPInst Java GUI, cuidando da comunicação via TCP/IP; - Message Lib: cria logs e traces durante a instalação; - SysLib: interface de comunicação com o SO, para atividades específicas dele (ex.: criar diretórios, etc.); - Registry: permite carregar bibliotecas dinâmicas durante a execução. Output files: - sapinst.log: progresso da instalação (diretório de instalação); - sapinst_dev.log: grava todas as mensagens de todos os passos, em detalhes (diretório de instalação); - instgui.log: mensagens referente ao GUI (máquina que possui o GUI). XML files: 48 - dialog.xml: contém todas as telas usadas na instalação; - keydb.xml: progresso da instalação e entrada dos usuários; - messages.xml: mensagens usadas na instalação; - control.xml: definição dos componentes utilizados no SAPInst; - packages.xml: para administração dos pacotes a serem instalados; SAPInst de forma remota: - Servidores devem estar na mesma rede e aceitar o ping entre si; - portas 21212 e 21213 devem estar liberadas; - Para instalar, utilizar startinstgui.bat; Installing and Patching Oracle Database Software Iniciar instalação via sapserver.cmd; Instalação sem criação de banco, com configurações típicas. Para aplicar patches e interim patches, parar o banco. OUI: Oracle Universal Instaler: para aplicar patches, apenas. OPatch: para aplicar e remover interim patches. Central Instance Installation No windows, não utilizar portas 25, 43, 60, 72 ou 89 devido a problemas conhecidos em serviços do windows (como terminal server). Memória: Database Instance Installation Recomendação: redo log archive não deve estar nos mesmos discos que sapreorg, sapbackup, sapdata<x>, etc. Número de jobs paralelos de import: número de processadores do servidor. Dialog Instance Installation SAP Web AS Java Central Instance Installation SAP Web Application Server Java = J2EE Engine = J2EE add-in. Criar um novo client antes de instalar?!?!?!?! SCS: SAP Central Services. Central Services Instance: serviço que gerencia todo o cluster J2EE. Formado pelo Message Service e Enqueue Service. Controla os dispachers e server processes e provê infra-estrutura para troca de comunicação entre os nós. Provê informações de load balance para o Web Dispacher. Gerencia lock lógico de dados e sincroniza dados pelo cluster. Usuários criados: - SAPJSF: comunicação via RFC entre ABAP e Java; - J2EE_ADMIN: administrador da instância java; - J2EE_GEST: usuário anônimo. SAP Web AS Java Dialog Instance Installation Mesmo dialog instance do ABAP. Appendix: SAP Gateway Installation Instance number: se na mesma máquina que a CI, usar número diferente; Memória: pode ser 128Mb. 49 Unit 6 – Performing Post-Installation Activities Installation of SAP License and Other Components Parando e voltando o SAP: - Parar e iniciar o sap; - Efetuar logon com user SAP* ou DDIC; - Verificar logs em \usr\sap\<SID>\DVEBMGS<XX>\work; - verificar transações SM50, SM51 e SM21; Instalar licença (ver procedimento). Instalar Documentação : - Um CD por cada linguagem; - PlainHtmlHttp requer web server; - Usar diretórios diferentes para cada linguagem, com dois caracteres (EN para inglês, etc.); - Não pode ser via SAP* e DDIC, pois vai gerar change request. Instalar SAPRouter - Necessário para conversação entre o SAPNet e o R3, para utilização do EarlyWatch e para consultoria remota; - Aumenta segurança e simplifica a configuração da rede. TMS and Basic Configuration - Transação SE06; - o TMS deve ser configurado após a instalação apenas em caso de cópia de um sistema já existente. Quando é nova instalação, a configuração é feita ao se configurar o transporte; - Importar os profiles após instalação: eles são escritos no banco e após isto nos arquivos; - Acessar tranzação RZ10 e importar os profiles (utilities import profiles of active servers); - Number of dialog work processes = RAM/256 (min 2, max 18); - Number of update work processes = RAM/768 (min 1, max 6); - Number of update2 work processes = RAM/1024 (min 1, max 3); - Number of batch work processes = RAM/1024 (min 2, max 3); - Number of enqueue work processes = 1; - Number of spool work processes = 1; - Realizar configuração de operation modes, transação RZ04; - Configurar usuários e funções na transação SU25; - Configurar logon groups (transação SMLG); - Instalar impressoras (SPAD); - Configurar System Log na transação SM21. Additional Tasks - Verificar inconsistências via transação SICK: - Verifica se a versão e o character set do kernel são as mesmas guardadas no BD; - Verificar se a estrutura de definições são iguais no Data Dictionary e no Kernel. - Ativar o SAP ERP Central Component Extension Set (SPRO); - Instalar nova linguagem; - Fazer backup do BD e FS; 50 - Verificar RFC SAPOSCOL_<hostname> (apenas se a instalação foi distribuída); - Verificar se user SAPJSF foi criado, e está com a role SAP_BC_JSF_COMMUNICATION_RO; - Executar o Load Generation (SGEN): carrega programas, grupos de funções, classes... Também gera BSPs. Appendix: Specific Post-Installation Activities - Windows: configurar usuários <SID>adm e SAPService<SID> para que o password nunca expire; - Verificar se o brtools está funcionando. Unit 7 – Implementing Patches Applying Patches - Support Packages Stack: conjunto otimizado de support packages e patches; - Possui toda documentação de o que contém como aplicar em determinados cenários, em determinados componentes, etc. - services.sap.com/patches, o wizard ajuda a escolher o que você precisa. Atualização de Kernel: - SAP System parado; - no windows, serviços parados. Aplicar no JAVA: via SAPInst. Unit 8 – Converting Non-Unicode to Unicode Procedure for Converting Non-Unicode to Unicode Exportar a base; Instalar nova base com Unicode; Importar a base antiga. Unit9 – Troubleshooting Installations Problems Solving Problems During SAP ERP Central Component Installation Verificar sapinst.log e procurar por mensagens de erro; Verificar o erro em notas informadas na instalação, no SAPInst Troubleshooting Guide (service.sap.com/sapinstfeedback) e no SAP Notes; Se não for um erro conhecido, executar o comando que deu erro na linha de comando e abrir um chamado na SAP, enviando keydb.xml e sapinst_dev.log via FTP. Implementar a solução e continuar com a instalação. Flow Trace provê mais informações sobre o progresso e sucesso da instalação. Unit 10 – Introduction to Software Logistics SAP System Landscape Revisão dos produtos, componentes, landscape. Client Concept Revisão da definição de client. 51 System and Client Change Options SE06 – System Change Option Define se os objetos de customização e de repositório são alteráveis globalmente e, se sim, se os componentes são. SCC4 – Changes And Transports for client-especific objects: - Changing without automatic records: permite alteração, porém a change request deve ser feita manualmente - Automatic record of change: alterações geram requests. Ex.: desenvolvimento; - No changes Allowed: sem modificações. Ex.: QAS, PRD; - Changes without automatic recording, no transports allowed: permite alterar, porém não pode transportar. Ex.: Sandbox. Client-independent object changes: - Changes to repository and cross-client customizing allowed: tudo liberado, adicionando em requests; - No changes to cross-client customizing objects: sem customização, mas pode desenvolver, adicionando em requests; - No changes to repository objects: permite customização, adicionando em requests, porém não pode desenvolver; - No changes to repository and cross-client customizing objects: tudo bloqueado. Current Settings: quando está tudo bloqueado, alguns valores podem ser alterados, por ex.: taxa de cambio, etc. Unit 11 – Setting Up an SAP System Landscape Setting Up the Transport Management System (TMS) Inicializar via SE06 e configurar o transporte via STMS. Configurar variável DIR_TRANS apontando para o diretório de transporte. Conceitos do TMS: - Configuração centralizada do Change and Transport System (CTS) para todos os sistemas SAP; - Gerenciamento centralizado de change requests e processo de importação; - estratégia de transporte baseada em rotas. Transport domain: todos os sistemas que usam o mesmo TMS. Devem ter SIDs diferentes e 1 deles é o domain controller. Transport domain controller: sistema onde toda a configuração do TMS é mantida. Alteram-se nele os parâmetros, que são direcionados às outras instâncias. System landscape: conjunto de ambientes que utilizam as mesmas customizações e change requests. Normalmente um landscape = domain, porém pode-se ter + de 1 landscape em 1 domain controler. Um transport domain possui pelo menos um transport group, que é um ou mais sistemas que compartilham o mesmo diretório. Configurar o TMS: - Configurar o domínio, que define quais sistemas estão inclusos no domínio; - configurar as rotas, que define sistemas e clients; - configurar o QAS com regras de aprovação (opcional). Configurar o domínio: - O primeiro sistema que é configurado é o domain controller (geralmente dev). Esta configuração é obrigatória no client 000. Depois, essa responsabilidade pode ser passada para outro ambiente (ex.: produção), por ser mais estável. - Ao se configurar um domínio: 52 - Um grupo de transporte é criado “GROUP_<SID>”; - Usuário TMSADM é criado no client 000; - RFCs são criadas para o TMS (TMSADM@<SID>.<DOMAINNAME> e TMSSUP@<SID>.<DOMAINNAME>); - Arquivo de configuração DOMAIN.CFG e arquivo de profile para o programa tp TP_<DOMAIN>.PFL são criados no diretório /bin. - Configura-se outro sistema, que pede permissão ao domain controller. Este deve aprovar. - Caso os sistemas ainda não estejam instalados, pode-se criar sistemas virtuais, que futuramente virarão sistemas físicos; - Recomendada a configuração de um backup domain controller, que irá funcionar caso o domain controller oficial esteja desativado. - A configuração do profile do programa tp deve ser feito via STMS, não via sistema operacional. Configurar rotas - rotas definem a regra de cada sistema e o fluxo das change requests. Ela define o system landscape; - Para configurar, deve-se modelar as rotas, usando os modelos existentes ou configurar manualmente. Após isto, distribuir e ativar as configurações nos outros sistemas. - As configurações das rotas são versionadas, e as versões mais antigas podem ser ativadas novamente. - As rotas podem ser de consolidação (export/import) ou de delivery (importação apenas); - Customizações e objetos são direcionados a uma rota de consolidação através de um transport layer. Os objetos são agrupados logicamente em pacotes, onde se define o transport layer. - Objetos originais usam o transport layer “SAP”. Os customizados a “Z<SID>”. - DEV = integration system (origem das change requests); - QAS = consolidation system (destino da rota de consolidação); - PRD = delivery system (destino da rota de delivery). - Para ativar a configuração, no domain controller clicar no botão de ativação, ou “Configuration Distribute and activate”. Configuração do procedimento de aprovação no QA: - Após liberação (release) de uma change request, no QAS terá uma lista de change requests para serem importadas (import buffer), marcadas como inativas. Apenas após a aprovação do responsável é que estará liberada para sistemas delivery. Verificar se a configuração do TMS está ok: - testar conexão RFC: STMS SAP System Check Connection Test; - testar diretório de transporte: STMS SAP System Check Transport directory; - testar programa tp: STMS SAP System Check transport tool. Extended Transport Control Originalmente não é possível configurar duas rotas em cima do mesmo transporte layer. Isto porque a package é apontada para um transport layer. A solução para este problema é criar um target group, que contém um ou mais sistemas. O TMS oferece o Extended Transport Control ( = CTC, client-dependent transport control), que automatiza os processos por: - cliente específico transport targets: transporte especifica <SID>.<client>; - cliente específico rotas de consolidação: destino pode ser um client em um sistema ou grupo de sistemas; 53 - cliente específico rotas de delivery. Transporte entre diferentes grupos de transporte (sistemas em um grupo de transporte usam mesmo diretório de transporte). Limitações: logs e transportes apresentados no CTO só aparecem no sistema de origem Transporte entre domínios de transporte diferentes Pode se usar link entre dois domínios ou sistemas externos. Domain link: conexão permanente via RFC, com funcionamento similar ao transporte convencional. Os logs são apresentados no sistema de destino. External system: utiliza-se outro diretório de transporte, comum aos dois domínios. Unit 12 – Customizing and Development in ABAP Customizing and Customizing Projects Implementation Guide (IMG): guia para customização em todo ambiente SAP. Provê documentação, e ferramentas para gerenciamento de projetos e documentação. Os projetos podem ser alterados, sobrepondo o projeto anterior, mas mantendo a documentação. Os projetos são cross-client, e podem ser acessados via transação SPRO_ADMIN. Centralização de projetos no Solution Manager permite: - Administração e definição do projeto; - Administração centralizada do landscape, o que permite aplicar modelos, centralizar configurações e testes; - Através do Business Process Repository, integrado ao SAP Knowledge Warehouse é possível acelerar a documentação do blueprint; - Permite controle central das modificações do projeto e customizações; - Criação de planos de testes que refletem em testes seqüenciais e integrados; Customizações afetam várias tabelas, que são vistas através de table view = tabela virtual, que apresenta dados de várias tabelas. Customizing Tools Ferramentas para customizing: - Implementation Guide (IMG): tool central para cuidar das customizações. - Transport Organizer: guarda as alterações em forma de requests. Transport Organizer é usado para criar, gerenciar, liberar e analizar requests. Acesso via SE09. Customizações alteram tabelas que são salvas em change requests do tipo customizing, que pertencem somente ao usuário que as criou. Tasks são unidades menores utilizadas pelos customizadores para guardar as mudanças. Recomendado pela SAP: Gerente do projeto cria uma change request os membros do projeto são adicionados na change request, através de tasks cada membro trabalha na sua request. Quando uma change request é salva, apenas as chaves da tabela são salvas. Quando acontece o export, há a leitura das demais linhas. Customizações podem ser logadas, o que é muito usado para documentação, através da transação SCU3. Caso a change request não seja associada a um projeto no início, é possível associar posteriormente, via CTS (Change and transport system). Quando se ativa funções de projeto CTS em um projeto IMG: - pode-se associar change requests ao projeto; - no overview da request pode se ver essa associação; 54 - quando se altera customizações no projeto IMG, elas são apenas associadas a requests do projeto IMG. A associação de projetos IMG à requests pode ser feita de 2 maneiras: - Através da SPRO_ADMIN; - Através da SE09, entrando em propriedades e associando o projeto IMG. Customizing Procedure Papéis: - Project manager: cria as change requests e associa os customizadores a ela (criando tasks). Após a customização estar ok, ele libera a change request. - Customizer: faz a customização e libera sua task. Tem permissão para copiar as modificações para o client de teste; - TMS Administrador: transporta as change requests para demais ambientes. Algumas transações são classificadas como transporte manual. Elas devem ser manualmente adicionadas à change requests. Antes de se fazer a release de uma change request, realizar testes unitários para testar a funcionalidade da change request e verificar se o conteúdo dela é completo. Criar um client para testes, que permite um teste unitário e testes sem risco de criar dados dependentes de customização. Transação SCC1 permite a copia de tasks, de change requests e de tasks + change requests para outro client. Ao copiar uma task para outro client, ela não deve ser liberada, para permitir recustomização caso necessário. Quando uma task é liberada, indica que a customização ou desenvolvimento foi terminado, o teste unitário está ok e a documentação está completa. Quando a change request é liberada, o conteúdo das tabelas é exportado para o SO e é criada em uma entrada na fila de import no QAS. É possível fazer o merge de change requests, através de utilities reorganize merge requests. Tipos de customização: - Client-dependent; - Client-independent; - Repository objects. É possível ver o tipo de customização (dependente/cross) em IMG View Additional information Technical data Client-dependence. Tipos de customização cross client: - objetos de customização, gerados pela demanda (objetos do repositório); - customizações em opções do sistema, cujas tabelas não contêm o número do client. Change requests: - customizing: setups client dependentes; - workbench: customização cross client e alterações em objetos do repositório. Managing Workbench Change Requests Áreas que devem ser documentadas para o gerenciamento de mudança: - Restringir alterações a objetos do repositório: - Criar 1 sistema para todo desenvolvimento; - certificar-se que as opções de sistema e client estão corretas; - colocar autorizações corretas aos usuários. - Definir padrões de desenvolvimento: usar pakages, padrões de documentação e manutenção de versões; 55 - definir times de projetos: treinar sobre os padrões e definir líderes. Recomendações da SAP: - desenvolvimento em um ambiente apenas; - usar packages para agrupar funções relacionadas. - após release da change request, documentar o propósito e o status das modificações. - usar autorizações para controlar perfis. Tools que ajudam na customização: IMG; e no desenvolvimento: ABAP Development Workbench. Características de customizing requests: Características de workbench requests: - documentação das mudanças; - documentação de mudanças - trabalho em equipe - trabalho em equipe - histórico de mudanças - SAP Software Change Registration - conectado ao Client Administration e ao (SSCR); TMS - Packages - Object lock - controle de versão - conectado ao TMS O Transport organizer (SE09 ou SE10) pode ser usado para customizing e workbench change requests: - exibe as change requests; - mostra informações globais sobre transport; - provê acesso a tools especiais. Prerequisites for development Desenvolvedores precisam ser registrados no SSCR para poder criar, modificar ou apagar objetos do repositório. Registrar objetos (originais) a serem alterados (apenas 1x, até upgrade), recebendo um número de licenças para alteração. Customizações começam com Z ou Y, e o nome pode ter um domínio (direcionado a uma package), registrado via view V_TRESN. Alterações em ambiente não padrão de desenvolvimento são chamadas REPAIRS. Objetos do repositório são organizados em packages, conhecidos como development class: - provê agrupamento lógico de objetos; - define qual transport layer será usado; - pode controlar nomenclatura de objetos. - Z ou Y demonstra que pode ser transportado - $ indica que tem objetos temporários, e não transportáveis; - TEST objetos locais, porém ligado ao transport organizer, para prover lock e versionamento. Características das classes: - Permite o agrupamento em hierarquias, garantindo a segurança; - Permite interfaces com outras classes, desde que elas sejam visíveis; - Definição de acesso de uso. Tipos de change requests: - Não-classificada: lista de objetos vazia - transportáveis: contém um transport layer definido (tipo development/correction ou repair); - local: não contém transport layer definido ou é inválido (tipo development/correction ou repair). 56 Repair: não permite modificações no QAS por desenvolvedores da primeira versão. É necessário criar uma nova repair e associar o(s) desenvolvedor(es). Handling Repairs and Modifications Modificações devem ser feitas apenas no sistema original (sistema onde foi desenvolvido). Quando copiado para outros sitemas, o objeto existe como uma cópia, e alterações lá são ditas “repair”. Objetos originais da SAP são cópias em todos os sistemas. Modificações são ditas “modifications”. Para tal, utilizar IMG, Business Add-nos, transação CMOD e o ABAP Workbench. Lista de objetos modificados: SE95. Durante o upgrade, modificações podem gerar necessidade de ajustes. Antes do upgrade, todas as modificações devem ser confirmadas e liberadas. Durante o upgrade, transação SPDD é utilizada para alterações no repositório. Para merge de outros objetos, utilizar SPAU. Tipos de lock durante a modificação de objetos do repositório: - Pelo programa editor, que permite que apenas um usuário utilize um objeto por vez; - Pela workbench change request, que assegura a modificação de objetos em tasks válidas, e apenas pelos desenvolvedores associados a ela. Objetos podem ser manualmente inseridos em uma lista de objetos em uma task ou request: SE09 Display Request/task Object list lock objects. Uma task liberada não pode mais ser alterada, porém outras tasks podem ser criadas na mesma change request para alterar os mesmos objetos. Quando uma change request é liberada, gera um controle de versionamento, que não é migrado para outros ambientes. Versionamento pode ser acessado por: - Repository Browser (SE80); - Transport organizer (SE09/SE10); - transações de exibição e manutenção para todos os objetos do repositório. Logs de transport: - 0: sucesso; - 4: warnings, porém transportou com sucesso; - 8: warnings, e pelo menos um objeto não foi transportado; - 12 ou maior: erro. Transport Organize tools (SE03) provê: - mostrar o erro de transporte ao logar no ambiente; - provê sistema de verificação de objetos antes de ser exportado ao SO. Autorizações/ Roles compostas: - super usuário (ex.: administrador): S_CTS_ALL/S_A.SYSTEM; - líder de projeto: S_CTS_PROJEC/S_A.CUSTOMIZ; - desenvolvedor: S_CTS_DEVELO/S_A.DEVELOP; - usuário final: S_CTS_SHOW/S_A.SHOW. Unit 13 – Transport Management in ABAP The Transport Process O TMS pode ser usado para importar toda a fila de change requests exportadas no desenvolvimento. Isto evita que ocorram erros de falta de objetos ao importar uma request (cuja dependente não foi importada) ou que objetos antigos sobreponham os novos. 57 As requests são exportadas para o diretório data e o arquivo de controle no diretório cofiles. No diretório buffer, existe o import buffer file para cada sistema no grupo de transporte (requests e ordem de importação = ordem de release das requests). Exporta do DEV importa no QAS fica inativa na PRD testa e aprova no QAS fica ativa na fila da PRD. Imports Using TMS Import queues (ABAP) = import buffer (SO) todas as change requests na ordem que foram liberadas. Podem ser visualisadas/importadas de qualquer sistema do domínio. Para ver a lista de import: STMS Overview Imports. Dados da fila são lidos do SO e jogados no banco, pela primeira vez. Para atualizar: - Edit refresh; - Overview Imports Extras Update all Import Queues; - Relatório RSTMSCOL (SAP recomenda agendar para rodar de hora em hora). Colocando um end mark (import queue) ou um stopmark (import buffer), significa que no import all apenas as requests até ali serão importadas. - Stopmark: Overview imports <system> Queue Close ou tp setstopmark; - Remove stopmark: Overview imports <system> Queue Open ou tp delstopmark; - Mover: via TMS ou tp mvstopmark. Import queue pode ser usada para: - Ver o status das requests; - Acessar lista de objetos, documentação e logs de transporte; - Abrir e fechar a queue, e mover a end mark; - Importar todas requests, um projeto inteiro, requests preliminares (apenas uma request) ou de acordo com seleção de filtro; - Adicionar, remover e passar adiante (outro sistema fora do domínio) requests. SAP recomenda um deadline para release de requests: após este horário, as requests são importadas, setando um end mark, e as seguintes serão importadas apenas no outro horário. Para copiar uma request em um sistema fora do domínio (forward): Request Forward System. Cuidado ao apagar requests para não gerar inconsistência de objetos. Melhor corrigir os objetos e gerar nova request. Import all: STMS Overview imports Queue Start Import. Importa todas requests na ordem que apareceram no buffer/queue. Asynchronously: import em background, sessão não fica presa no import. Se uma request de um projeto não for aprovada no QAS, o projeto não pode ser importado na PRD. Apenas as requests aprovadas. Pode-se desabilitar o import all utilizando o parâmetro NO_IMPORT_ALL. Antes de importar, SAP recomenda usar o end mark. Para evitar problemas quando se importa uma única request, esta fica na fila e pode ser importada novamente quando a import queue é processada. TMS verifica se uma request é dependente de outras. Dependendo do tipo de importação (simples, all, workflow, etc.), algums opções são apresentadas: - immediate; - at start time; 58 - after event: selecionando “execute import periodically”, será processado sempre após um evento, caso contrário só na primeira vez do evento. SAP recomenda uso do import all em períodos determinados. Importação freqüente não é recomendada. Inclusos no transporte: - versões de change requests; - import no mesmo sistema usando SCC1; - import em sistemas seguintes (QAS PRD). Tipos de estratégias de transporte: - Queue-controlled mass transports: recomendado quando se tem muitos transportes e se quer automatizar; - transportes simples: recomendado para transportes controlados (ex.: produção). - workflow: para comunicação entre desenvolvedores e administradores do TMS. Para selecionar estratégia: abrir rotas de transporte no STMS e efetuar um duplo clique no sistema. Mass transports: marcando “leave transport request in queue for later import” permite que importações simples sejam novamente importadas em import all. Utilizar “transport of copies” quando copiar objetos para outros sistemas, mantendo a versão do sistema de origem. Utilizar “relocations of objects w/o package change” para mover a localização original para outro sistema (ex.: de desenvolvimento temporário DEV). Utilizar “Relocations of objects with package change” copia os objetos movendo a origem para o sistema de destino, criando sistema de transporte. Utilizar “relocations of complete package” caso todo o package deverá ser mudado de origem. QA Approval Procedure and Transport Proposal Para ser QAS: - Deve ser destino de uma rota de consolidação; - Deve ser origem de uma rota de delivery. Enquanto todos os steps de aprovação não forem aprovados ou rejeitados, os já escolhidos podem ter sua posição mudada. Ex.: de recusado para aprovado. SAP recomenda não rejeitar requests. Recomenda desenvolver outra que corrija e migrar as duas. Goto QA History indica todas as requests para um período que não é apresentado no QA Worklist. Padrão até 30 dias. Para ver quem aprovou/recusou: Request Display QA Status. Para usar o Workflow, SAP recomenda que o sistema que esteja com o Workflow Engine tenha alta disponibilidade, mas baixa carga = QAS. Escolher “Special Transport Workflow” caso o transport seja urgente ou não siga a rota padrão: Utilities Create transport proposal. Se aprovado importa automaticamente e vai um e-mail pra quem solicitou. Se não, vai e-mail informando a recusa, que pode ser rebatido ou cancelado. Monitoring Tools Tools para monitoramento: - Import Monitor; - tp system log - Import queue consistency check; - Transport control program check; 59 - Transport directory check; - RCF connection test. STMS Overview Imports: - tp status: goto Import Monitor; - tp system log: - SLOG: Goto TP system log; - ALOG: Goto History Import History. - Import queue verificação de consistência: verifica se data files e control program da import queue estão no import buffer: Import queue Check Consistency. STMS Overview Systems: - verificar o tp: SAP System Check Transport tool; - verificar o diretório de transporte: SAP System Check Transport Directory; - verificar conexões RFC: SAP System Check Connection test. Existem dois momentos de se fazer a verificação por objetos críticos (somente do tipo R3TR): - Antes do import da change request no destino (manualmente: STMS overview imports Import Queue Check Critical objects); - Durante o export: automático se parâmetro CHK_CRIOBJ_AT_EXPORT for W (warning) ou E (error). Para manter lista de objetos críticos: STMS Overview Imports Extras Critical transport objects. SAP recomenda o congelamento de desenvolvimentos durante testes: - Liberar change requests com customizações; - Congelar o desenvolvimento no DEV; - Importar e verificar no QAS ; - “Assinar” as alterações no QAS. - Se necessário, liberar para outras customizações no DEV. Para isso: - parar as exportações: criar arquivo em <dir_trans>/bin/T_OFF.<SID> (primeira linha do arquivo uma mensagem); - parar as importações: criar arquivo em <dir_trans>/bin/NOIMPORT.<SID>. Transport Directory Structure and Files Devido o tp rodar em vários SOs, a nomenclatura é restrita: <DEV>K9<5 caracteres>. Subdiretórios do DIR_TRANS: - actlog: <DEV>Z<6 digitos>: grava ações na request (criação, modificação, release); - sapnames: <USER>: registro de ações de usuários; - buffer: <SID>: import buffer; - data: R9<5 digitos>.<SID>: objetos exportados; - cofiles: K9<5 digitos>.<SID>: passos para import; - log: ULOGs, ALOGs, SLOGs, <Source SID><action>9<5 digitos>.<action SID> (step executado) e <action><date>.<action SID> (steps coletivos). tp, The Transport Protocol Program tp é usado para controlar transports (export e import) entre sistemas, bem como fazer upgrade de releases. 60 tp é um programa que roda no SO, baseado em C, comandos SO e ABAP no sistema SAP. tp utiliza o R3trans para efetuar comunicação com o banco de dados. Não há mecanismos de import no target imediatamente após o export. Executar o tp via SO (diretório DIR_TRANS/bin com o <SID>adm) deve ser somente em casos especiais, como indisponibilidade do TMS. Para importar: - tp import all <SID> <CLIENT> pf=TP_<DOMAINNAME>.PFL; - tp import <REQUEST> <SID> <CLIENT> u0 pf=TP_<DOMAINNAME>.PFL; Uso do modo “uncondicional” para controle de erro. u0 significa que um transport individual não vai sobrepor objetos mais novos, mantendo ele na fila de imports: - 0: requests importadas não são removidas do buffer; - 1: ignorar já importadas; - 2: sobrepor original; - 6: sobrepor objetos em repairs não confirmados; - 8: ignorar restrições baseadas em tabela de restrições; - 9: ignorar que o sistema está lockado para esse tipo de transporte. Outros comandos: - tp showbuffer <SID>: buffer daquele SID; - tp addtobuffer <REQUEST> <SID>: adiciona request como última da fila; - tp delfrombuffer <REQUEST> <SID>: remove request do buffer; - tp cleambuffer <SID>: remove requests importadas com sucesso do buffer (intrinceco no inport all). Via STMS: Overview Imports Import Queue Display Extras Delete Imported Requests. - tp setstopmark <SID>: cria a stopmark no final do buffer; - tp movestopmark <REQUEST> <SID>: marca a request como última da fila; - tp delstopmark <SID>: remove a stopmark. Import Process R3trans é chamado eventualmente pelo tp e programa de controle de upgrade. A execução do R3trans não é suportada, mas pode ser usada em determinados casos, com pós-atividades necessários. No transporte, utilizar sempre via tp, que chamará o R3trans quando preciso e garantirá todas as atividades completas. Pode exportar em versão velha de R3trans e importar em novo. Pode exportar de um SO e importar em outro SO diferente. Pode exportar de um DB e importar em outro DB diferente. SAP não garante transporte entre releases diferentes de SAP. tp import all: tp setstopmark importa tp delstopmark tp cleanbuffer. Caso haja algum erro no import, após corrigi-lo, o tp recomeça de onde parou. Para cada passo do import: tp passa informações do buffer para o R3trans R3trans lê os data files e conecta no banco de dados, processando inserts e updates R3trans gera log no dir tmp e devolve um exit code para o tp tp move logs para dir log. tp chama job RDDIMPDP, comunicando via table TRBAT. tp escreve uma linha (header) para dizer ao RDDIMPDP que deve começar o processamento. Dependendo do tipo de atividade, apenas o header é escrito. RDDIMPDP lê a tabela TRBAT e seta a linha do header como “R” (run), inicia programa RDD* (que gera uma entrada na TRJOB) e se auto-agenda. Quando o header da TRBAT é “F” e a TRJOB está vazia, tp copia os logs dos steps concluídos do dir tmp para o dir log e remove entradas na TRBAT. 61 Se o tp detecta problemas nas tabelas TRBAT e TRJOB, inicia um sapevt para reprocessar o RDDIMPDP, que reconhece as entradas nas tabelas e reinicia de onde parou. Após a cópia de um client, o RDDIMPDP é agendado. Para verificar, SM37. Para agendar, o nome do dispatcher é RDDIMPDP_CLIENT_<###>. O evento é o SAP_TRIGGER_RDDIMPDP_CLIENT. O tp import all não necessariamente inicia uma request apenas quando terminou todos os steps da anterior. Steps de import: - DDIC I: ABAP dictionary import: de forma inativa, pelo R3trasns - ACTIV: ABAP dictionary activation: pelo RDDMASGL - ACTIV: ABAP dictionary distribution: ações para trazer o objeto ativado para o sistema em execução, pelo RDDGENBB; - Structure conversion: alterações em tabelas: RDDGENBB; - ACTIV: Move nametabs: objetos de runtime são colocados no ambiente ativo, pelo pgmvntab; - MAIN I: Main import: todos dados importados, pelo R3trans; - MCACT: ativação e conversão de enqueue objects: objetos não ativados antes são ativados e colocados em execução, pelo RDDGENBB; - ADO I: application-defined objects import: importação dos ADOs, como formulários, estilos, formatos de impressão, pelo RDDIC1L; - VERSF: versionamento, se vers_at_impotrt está ativado, pelo RDDVERSL; - XPRA: execução de atividades definidas pelo usuário (ex.: reports), pelo RDDEXECL; - GENERA: geração de programas ABAP e telas, pelo RDDIC03L. Troubleshooting transports Durante o import é usado o dir tmp, depois é movido para log. Os arquivos de log possuem nome <source SID><action><6 digitos>.<target SID>. Níveis de detalhes dos logs, visualizados no SAP: - ações e códigos de retorno; - mensagens de erro adicionais; - logs de usuário; - detalhes para desenvolvedores e hot-line. ULOG: cada linha representa um comando livre de erro; SLOG: monitora as atividades de transporte de um sistema; ALOG: todos os códigos de retorno de steps num mesmo diretório de transporte. Códigos de retorno: - 0 a 16: valor máximo todos códigos de retorno da ferramenta de transporte; - 17 a 99: calculado dos códigos de retorno das ferramentas de transporte e tp warnings; - 100 a 199: indica warnings. Até 149 são “normais”, após isto indica operação incorreta pelo usuário; - 200 ou mais: erro. Para verificar erro: 1 – STMS Monitor Alert viewer; 2 – Informações mais detalhadas no SLOG; 3 – ALOG apresenta steps cujos códigos de retorno estão no SLOG; 4 – Verificar se o job RDDIMPDP está agendado e se é iniciado por eventos. 5 – Comparar coteúdo das tabelas TRBAT e TRJOB com o import buffer (SM31). 62 Cleaning Up the Transport Directory Comandos - tp check all: procura por requests que não estão marcadas para import; - tp clearold all: usa o comando acima para ver requests que passaram da idade máxima. Parâmetros de idade máxima: datalifetime (move para dir olddata), olddatalifetime (apaga do dir olddata), cofilefiletime (apaga do dir cofiles), loglifetime (apaga do dir log). Unit 14 – Client tools Client Copy and Transport Tools Client Copy tools copia esses tipo de dados: - User máster data: só apaga dados no destino se um profile com user máster data é copiado; - customizing: todos profiles exceto SAP_USER. Tabelas classe C, G, E e S. - Cross-client customizing: para outro sistema; - máster/transacion (application) data: dados de aplicação. Tabelas classe A. Testes a serem feitos antes de liberar uma request: - testar funcionalidade; - verificar se o conteúdo é completo. Manter cliente separado para testes permite: - teste unitário verdadeiro; - teste sem risco de criar dados que dependam de customização; SCC1 permite copiar (a partir do destino): - uma task; - uma change request; - uma change request com suas tasks. Somente uma change request pode ser copiada por vez. As change requests podem ser agrupadas em outra, para migrar tudo de uma vez. Local client copy: no mesmo sistema: - SCC4 para criar novo client; - Setar login/no_automatic_user_sapstar=0 e logar no destino com SAP*/pass; - entrar na SCCL e importar dados; - setar login/no_automatic_user_sapstar=1. Acessando edit Expert settings pode-se tirar tabelas da cópia. Remote client copy: para outro sistema (SCC9): - Não precisa de espaço em disco, vai via RFC; - cross-client customizing objects podem ser migrados juntos; - tabelas devem ser iguais nos dois ambientes. Podem ser usados com vários processos paralelos, acelerando o processo: goto Parallel processes ou definindo grupos de RFC na SM59 RFC RFC Groups. Um processo paralelo monitora se o outro está rodando. Caso negativo o reinicia. Client transport: não usa RFC, mas gera arquivo no dir de transporte, via SCC8. Arquivos gerados: - RO<number>: cross client data; - RT<number>: dados específicos de client; - RX<number>: SAPsripts. Não é importada via import all, mas pode ser importada via TMS. Após: SCC7 para pósatividades. Para apagar um cliente: SCC5. 63 Atentar para: - não efetuar logon no client de destino enquanto importa os dados; - max online runtime (rdisp/max_wprun_time) deve ser grande o suficiente. Recomendado > 2000segs; - executar um teste de cópia antes, para ver se tem espaço no banco. Para monitoramento: SCC3: - estatísticas de tabelas; - controle de informação; - informações sobre cada tabela copiada. Verificar não só o log da cópia, mas também do sistema (RFC com problema, etc.). Re-execução recomeça de onde parou. Client Compare and Maintenance Tools A função de compare (SCU0) serve para ver diferenças de tabelas ou views entre clients diferentes, usando RFC. Usos: - comparar client com o client de referencia (000, por exemplo); - comparar clients durante um cenário de rollout. - comparar customizações cross-client antes de combinar clients (roll in). No compare, pode-se usar uma visão orientada a projeto, via IMG. A informação mais importante é o status (comparision status) que indica a existência e a natureza das diferenças. Process status indica os que já foram comparados ou não. Apenas um objeto pode ser alterado por vez, e aqueles que são alterados via SM30. Os demais apenas comparados. Via SCC4, configura-se o nível de proteção do cliente: - Protection level 1: no overwriting: não pode ser sobreposto, mas pode sofrer compare. - Protection level 1: no overwriting and no external availability: não sobrepõe e não aparece em compare (PRD). Unit 15 – Note Assistant, SAP Support Packages and Upgrades SAP Note Assistant Notas podem fornecer informações sobre produtos, parceiros e clientes da SAP, bem como correções. A nota inclui: - sintomas do erro; - causa do erro; - descrição de como corrigir o código; - a versão e support package necessários; - links para support packages que resolvem o problema. SNOTE: - implementa automaticamente notas que modificam códigos ABAP; - cuida da dependência com outras notas, support packages e modificações; - mostra todas as notas implementadas no sistema; - corrige apenas um bug, sem alterar ABAP Dictionay Objects, e não substitui SP. Pode-se aplicar uma nota diretamente via conexão com o SAP Net r/3 Frontend ou fazse o download da nova e aplica-se separadamente. Alterações no código original não requerem chave SSRC. Aplicar na DEV transportar para o QAS via TMS, não aplicar diretamente no QAS importar na PRD. 64 Acessando a SNOTE, é apresentada a worklist pessoal, diferente do Note Browser. Note Browser é um overview de todas as notas existentes no sistema. Note Assistant provê: - Exibição de informações de notas direcionadas para seu usuário, notas inconsistentes (todas) e notas novas; - Pesquisa por notas; - Download de notas; - Verificação de notas para verificar seu status; - definir o status de aplicação da nota. Notas podem ser implementadas/removidas (Cancel SAP Note Implementation). Para baixar direto via Note Assistant, é necessária conexão direta com a SAPNet. Pode-se classificar a nota, bem como direcionar a aplicação para outra pessoa. Para aplicar, selecionar “Implement SAP Note”. Será solicitado que salve as alterações em uma change request. Antes de importar, execute uma syntax check. Um log é gerado após a aplicação da nota. Caso seja necessário aplicar outras notas antes da escolhida, e havendo conexão direta com o SAPNet, serão apresentadas as outras notas não aplicadas. Caso haja necessidade de modificações, na aplicação da nota pode ser direcionado ao Modification Browser (SE95). SAP Support Packages Correções de erros e novas funcionalidades dos layers (SAP_BASIS, SAP_ABA, etc.) são implementados via support packages. Tipos: - COP: component package; - CRT: conflict resolution transport: resolve conflitos entre Support Packages e Add-ons. - PAT: novas funcionalidades para SPAM/SAINT SPAM é utilizado para importar SP tanto para o sistema standard SAP quanto para Addons: - Leitura de SAP SP; - Import de SP: - Restarting: reinicia de onde parou; - Exibe a situação atual do sistema; - Permite procedimentos especiais de importação, como o downtime-minimized; - Permite agendamento de início; - Permite processamento em background. Atualizações PAT são feitas apenas via SPAM: melhorias nas transações para os novos SPs. Apenas em Inglês e Alemão, linguagens recomendadas para se utilizar esta transação. Pré-requisitos: - SP requerido disponível; - espaço no FS; - import em período de baixo uso; - SPAM/SAINT mais novo; - TMS/CTS configurado; - nenhum SP abortado; - client 000; - usuário com autorização para a SPAM (administrador = S_A.SYSTEM = S_TRANSPRT + S_CTS_ADMIN). 65 Carregar o SP do site ou CD e descomprimir copiar para o servidor SPAM > Support Package > Load Package From Application Server. Se for < que 10MB, Support Package Load Packages From the Front End. Marcar “decompress”. Processo de import: - Preparation: fase de preparação e testes de import. Durante período produtivo; - Import1: import, ativação e modificações (se necessário) em objetos do dicionário. Durante período produtivo; - Import2: demais passos do import, como ativação dos objetos inativos. Durante período não produtivo; - Clean up: modificações no dicionário. Durante período não produtivo. Não transportar de preparation até import 2. SAP Support Package Manager garante que apenas SP relativos ao sistema serão importados. Pode ser criada uma fila selecionando “All Components”, que contém SP disponíveis para o sistema, CRTs e Industry Solutions. Regras: - os SP são colocados na fila na seqüência correta; - Caso um SP não esteja no meio, ele é adicionado automaticamente. Test Scenario ou Standard Scenario: Extras Settings: - Para verificar possíveis conflitos com modificações, prevendo o esforço e tempo a ser usado; - importa toda a fila. Se ocorrer erros, continua de onde estava. Pode ser ativada a opção “downtime minimized”. Modificações: - SPAM paraliza o serviço para a modificação (continua a partir do step RUN_SPAU ou RUN_SPDD); - Alterar o código, salvando em uma request, através da SPAU ou SPDD (SPAM Extras Adjust Modifications); - SPAM Support Package Import Queue. Será apresentada tela de customização, clicar em continue. Após importar, selecionar “Confirm queue”; Para atualizar em outros sistemas do landscape: - Devem ter sido importados com sucesso em um sistema; - Modificações devem ter sido feitas; - Sistemas devem ter o mesmo diretório de transporte; - No sistema seguinte, importar normalmente os SP; - Alterar o SPDD manualmente; - Importar a(s) request(s) que modificaram a SPAU. Para downtime minimized import, onde report sources e report texts são importados com o sistema ativo (reduz de 70 a 80% no ECC): - Importar report sources e report texts em modo inativo. Paralelamente a versão ativa estará no sistema; - Ativar os sources e texts que foram alterados e remover os obsoletos (down-time); - Inativar sources e textos ativos (down-time); - Remover sources e texts obsoletos. SPAM faz preparação e testes e importa objetos durante período ativo (customizações bloqueadas) SPAM apresenta uma tela solicitando a desativação do sistema Administrador para os batches e pede para todos usuários efetuarem logoff 66 Administrador pressiona “continue” SPAM ativa os objetos e informa conflitos em modifications modifica-se os objetos Import Queue novamente. Recomenda-se atualizar a SPAM/SAINST antes de usar. Updates na SPAM/SAINST só são feitos se não houverem SP abortados: - Aplica-se a fila de SPs; ou - Limpa a fila (Extras reset status queue) e aplica atualização da SPAM/SAINST. Support Package Stack possui a combinação otimizada de SPs e patches. Contém instruções de aplicação, componentes, requerimentos, etc. SAP System Upgrade Antes de realizar o upgrade, deve-se analisar o por quê: técnico, estratégico, etc: - qual o custo total do upgrade? - o upgrade trará vantagem financeira para mim (payback/ROI)? - Quais os benefícios do upgrade? - Quais os riscos envolvidos? Itens a serem pensados no planejamento do upgrade: - Release de customizações; - modifications; - adaptação e testes de melhorias de usuários; - adaptação e testes de interfaces; - adaptação e testes de formulários; - treinamento do usuário final; - testes e validação de novos releases. A maior parte do projeto de upgrade é adequar os processos do negócio às novas funcionalidades do sistema. Atividades técnicas a prever: - requerimento de hardware; - sizing e configuração; - planos de SO, DB, Kernel e upgrade de sistemas SAP; - testes e validação de backup da nova versão; - tecnical upgrade de todo o system landscape; - atividades pós-upgrade, incluindo acompanhamento de performance. Um upgrade técnico envolve: - tomar decisões sobre a estratégia de upgrade e a conversão de tabelas. Planejar as modificações para minimizar o downtime; - requerimentos de software, hardware, SO e BD devem ser vistos antes do upgrade; - após realizar as atividades de PREPARE, iniciar o upgrade; - PREPARE são atividades para verificar se o sistema pode receber o upgrade. Testes e ações manuais podem ser feitos antes do upgrade; - realizar o upgrade; - atividades pós-upgrade. Ferramentas para auxiliar o upgrade: - Prepare: faz verificações no sistema, como SP e Add-ons, e importa outros tools para o upgrade; - ICNV (incremental table conversion): tool importado pelo PREPARE responsável por trabalhar mudanças na estrutura de tabelas. - Upgrade Assistant: processa independentemente de um certo front-end; - Upgrade Monitor: monitora o upgrade e ajuda a identificar onde está parado. Estima quanto tempo falta. - SGEN: feito upgrade a cada versão. 67 Fases do upgrade: - PREPARE (prepare); - EU_IMPORT (import); - DIFFEXP (import); - START_SHDI (shadow); - ACT (shadow); - SHD_IMP (shadow); - SWITCH (switch); - PCON (switch); - TABIM (switch); - XPRA (switch); Durante a fase de switch, o sistema estará em período não produtivo. Alterações feitas na SPAU e SPDD devem ser incluídas (não importadas) no upgrade da próxima base. Todas as modifications são perdidas, sobrepostas em novos objetos. Elas devem ser refeitas nesses novos objetos. A lista de objetos que precisam ser ajustados é gerada na fase ADJUSTPRP, durante o PREPARE, As modifications devem ser feitas durante o downtime, antes da ativação de objetos do dicionário ABAP. São agrupadas em uma request, que não sofre release, mas é marcada como export na SPDD. Objetos não devem ser manualmente ativados. Eles serão ativados nas fases corretas. Após o upgrade, são concedidos 14 dias para execução da transação SPAU sem necessitar de SSCR em objetos modificados anteriormente. 68 TADM12_2 Unit 1 – Introduction to Workload Analysis Components of Dialog Step ST06 – detalhes do sistema operacional; ST04 – detalhes do banco de dados; SM04 – usuários no sistema; ST02 – buffers do SAP. Dialog Response Time: tempo entre recebimento da solicitação pelo dispacher e a resposta (não conta tempo do GUI). Wait Time (tempo na fila de espera por um WP livre) Roll-in Time (carga do contexto do usuário do roll buffer na roll memory do WP) Load And Generation Time (tempo para carregar o programa do buffer ou banco, e compila-lo, se necessário) Processing Time (dialog response time menos a soma de todos outros times) Buffer Access Time (tenta ver se tem o dado no buffer – 0ms) e Database Request Time (tempo para pegar o dado do banco, caso não tenha no buffer) Lock Time ou Enqueue Time (tempo para fazer um lock lógico) Roll Out Time (tempo para devolver o user context para o buffer na shared memory) em paralelo com o envio do resultado para o SAP GUI. CPU Time é diferente de Processing Time. Para análise de problemas: Alto Wait Time: falta work process; Alto roll-wait time: problemas de comunicação com o GUI, outro sistema ou muitos dados requeridos; Alto Load And Generation Times: buffers pequenos (CUA, Program ou Screen); Alto tempo de banco de dados: verificar problemas no banco de dados; Alto tempo de CPU: muito processamento ABAP (ex.: tabelas grandes), melhorar lógica de programação; Tempo de processamento maior que 2x CPU Time: gargalo na CPU. Statistical Records and the Workload Monitor ST03N: Workload Statistics Visões: - Workload: workload statistics; - Detailed Analysis: link para a STAD; - Load History and Distribution: dados de workload históricos e histórico de acesso de usuários; - BW System Load (BI Workload): histórico de acessos BW; - Collector and Performance DB: dados de performance do banco, acesso ao arquivo de log e configuração dos coletores. Analysis View: - Workload overview; - Transaction profile: standard (dialog data) e EarlyWatch (todos tipos de tasks); - Time Profile; - Ranking lists; - Memory Use Statistics; - RFC Profiles; - User and Settlement Statistics: estatísticas por usuários e clients; 69 - Front end Statistics; - Response Time distribution: tempo de resposta. Em %, deve ter + de 95% abaixo de 2 segs; ST03G: Global workload Monitor Idem ST03N, porém monitora todos os sistemas cadastrados. Os dados são armazenados localmente nos sistemas, e transferidos a cada hora para o central. A mais: Control: controla quantas records serão coletadas nas instâncias e quanto tempo ficará disponível; Settings and logs: sistemas monitorados e logs escritos. STAD: Business Transaction Analysis Monitora do início da transação até a chamada de update, ou quando o usuário abandona a transação. STATTRACE: Functional trace Análise de dados estatísticos de sistemas remotos (ou local). Cada dialog step gera dados coletados, que é colocado na shared memory, consultável via ST02 (buffer full, ou STAD/Last minute, ou a cada hora) passa para disco (parâmetro stat/file: <dir_instance>/data ), consultável via STAD e ST03N Last minute load Job SAP_COLLECTOR_FOR_PERFMONITOR roda relatório RSCOLL00 que agrupa informações do arquivo e joga no banco de dados. Unit 2 – Performance Analysis Monitors SAP Performance Monitors SM50: - No: número do WP; - Ty: tipo (dialog, etc.); - PID: PID no SO; - Status: waiting (IDLE), running, On hold (esperando o q está falado em “reason”), stopped (erro), shutdown, reservied (reservado); - Reasn: possível razão para o status; - Start: se será automaticamente reiniciado caso erro; - Err: número de reinícios; - Sem: semáforo usado para gerenciar recursos no SO; - CPU: tempo usado de CPU desde o startup; - Time: tempo de processamento, em segundos, fica vermelho quando maior que rdisp/max_wprun_time; - Report: report em execução; - CI: client; - User: usuário; - Action: ação executada; - Table: tabela acessada. SM66: global workprocess Overview: idem SM50, porém mostra a transação executada. Shift F6 ou F7 para navegar entre os modos de visão. SAPOSCOL: 1 por máquina, independente de quantas instâncias tiverem; Monitorar SO: ST06, OS06 e OS07. Mais importantes: - CPU Utilization: - User: deve estar entre 50% e 60%; - System: abaixo de 20%; 70 - Idle: acima de 20%. Abaixo disso pode causar gargalo - I/O Wait: CPU esperando resposta, deve estar abaixo de 10%; - Average CPU Load: separado por minutos, mostra processos em espera para entrar na CPU. Valor alto + consumo CPU alto = muitos processos no sistema. Valor alto + consumo CPU baixo = pouca memória. - Count: número de CPUs no sistema; - Memory: physical mem avail.: RAM do sistema; - Swap: - Maximum swap space: espaço de swap; - Commit Charge Limit (Windows): virtual memory (RAM + Swap); - Operating System Monitor: detalhes do SAPOSCOL; - Detail analysis Menu: informações detalhadas de CPU, memória, etc. ST02: The Buffer Monitor Mostra o status dos buffers do SAP, utilização de memória e buffer de tabela. Considerações: - Hit Ratio deve estar acima de 95%; - Swaps ocorrem devido não ter espaço livre no buffer ou os diretórios do buffer estão ocupados (diretório são divisões do buffer para cada objeto. Quanto maior, menos objetos cabem, quanto menor, o objeto pode não caber no diretório); - Não pode haver swap, nem telas em vermelho; Detalhes: - Nametab: Repository buffer ou ABAP Dictionary Buffer. Contém valores de definição de tabela e campos. Hit Ratio deve estar por volta de 99,5%. Dividido em: - Table Definitions (TTAB) - Field Descriptions (FTAB); - Initial Record Layouts (IREC): layout da record, dependendo do tipo de campo usado; - Short Nametab (SNTAB): sumário dos buffers TTAB e FTAB. - Program Buffer (PXA): ABAP Buffer. Programas carregados antes do processamento pelo WP. Caso não haja espaço no buffer, o algorítimo LRU tira o mais antigo para abrir espaço para o novo. A remoção é marcada como Swap. Para evitar queda de hit ratio durante boot, os programas no buffer são escritos em um arquivo, e recarregados após reinício. Swap de até 10.000 objetos por dia é considerado normal. - CUA Buffer: Menu Buffer. Guarda informações para o SAP GUI, como botões e menus. Não prejudica o desempenho. - Screen Buffer: Dynpro buffer. Guarda telas do sistema; - Calendar Buffer: feriádos públicos e da empresa. Não atrapalha o desempenho do sistema; - OTR Buffer: Online Text Repository: textos usados por BSPs, Exception Builder e serviços HTTP. Não atrapalha o desempenho do sistema; - Generic Table Buffer: generic buffer ou generic table key buffer. Guarda dados de tabelas, conforme definido no ABAP Dictionary; - Single Record Table Buffer: Single record buffer ou partial table buffer. Guarda apenas uma linha da tabela. Esperado Hit Ratio baixo, devido guardar poucos dados. Se não há muito swap, não influencia no desempenho; - Export/Import Buffer: dados carregados para vários WP; - Exp / Imp SHM (Shared Memory): usada por programa ABAP, através de commando. Se não há swap, está ok. 71 Analysing SAP Web AS Java Performance Via ST03G e STATTRACE. Trace de SQL pode ser iniciado http://<server>:<port>/SQLTrace. via Visual Administrator ou via Analysing ICM Performance SAP provê parâmetro para limitar quantidade de acessos nos WP pelo ICM. SAP Web Dispacher: dispacher para se usar vários ICMs. Monitoramento via SMICM ou via Web. SMICM: limpeza de cachê: goto http Server Cachê Invalidate Only Local Tuning: rdisp/start_icman: identifica se a instância tem ICM ou não; SAP Web Dispacher permite load distribution; UFO Cache: unfound object cache. Bloqueia requisição de serviços não existentes; ISC: Internet Server Cachê: cachê do ICM. Eficiência: goto HTTP Server Cachê Display Statistics. Work Threads: configurar nos parâmetros icm/min_threads e icm/max_threads o número mínimo e máximo, que pode ser maior que icm/max_conn (número máximo de conexões, pois conexões inativas não consomem threads). Cada thread ocupa 512Kb. Cota de acessos: através do parâmetro icm/HTTP/context_quota setar em % em relação ao parâmetro rdisp/tm_max_no. Performance Analysis on Integrated ITS ITS veio integrado no Web AS 6.40, chamado pelo ICM e monitorado via SICF. Parâmetro: itsp/enable = 1; SICF para configuração; Report SITSPMON mostra o status; Transações de logs (SM21 e ST11). 72 ITS: 10 Mb por linguagem, 10 Mb por tipo de browser + 3Mb por sessão, que usa a área da em/global_area_MB, que não deve ser maior que ¼ da Extended Memory. Unit 3 - SAP Memory Management Memory Areas Work processes trabalham na local memory e todos eles compartilham a shared memory. As duas memórias formam a virtual memory. A virtual memory pode estar na memória física ou no Swap, sendo gerido pelo sistema operacional. A local memory dos work processes é usada para: - ABAP load; - Data, stack; - Buffer for database transfer; - Local roll área; - Local paging área. A shared memory possui: - SAP Buffers: que contém programas, conteúdos de tabelas, etc; - Extended Memory: que contem dados e objetos de transações ainda não finalizadas. - Heap memory: contém dados da Extended Memory, caso esta esteja full. Aloca sob demanda no espaço da local memory. - Roll Buffer: parte inicial do contexto do usuário; - SAP Paging Buffer: possui objetos ABAP e objetos independentes de contexto; Problemas na configuração de memória (ST02): - Extended Memory: Max Use deve ser menor de 80% da In memory; - Roll Área: Max Use deve ser menor que 80% da In Memory. 73 SAP Memory Allocation User Context: dados que estão sendo usados para aquela sessão do usuário (autorizações, set/get parâmetros, tabelas internas, report lists). Roll-in: contexto do usuário da Roll Área para a local memory; Roll Buffer roll file: contexto de usuário Page buffer page file: memória para comandos específicos. Os dados das transações são guardados na memória estendida e acessadas via pointers, o que permite mudança de work process de forma rápida, sem precisar copiar dados de memória (apenas os ponteiros). Windows + Dialogs de outros SO: Processo ocupa na roll memory apenas o valor do parâmetro ztta/row_first começa a usar a memória estendida até estourá-la ou quando a cota por usuário é superada (ztta/roll_extension) o restante da Roll Memory (ztta/roll_area) é usada (para evitar usar a Heap Memory e PRIV mode) usa Heap Memory (abap/heap_area_dia), entrando em modo PRIV, sendo o WP dedicado àquele usuário. WP não dialogs em outros SO: Processo ocupa toda roll memory (ztta/roll_area) Usa Heap Memory (abap/heap_area_nondia ou até estourar) Usa extended memory (ztta/roll_extension). Após uso, a Heap Memory é liberada, exceto no Unix (e sistemas baseados), que quando o limite estipulado em “abap/heaplimit” for ultrapassado, ele é marcado para reiniciar, liberando a memória. Parâmetros ztta/roll_first: alocação inicial da roll área, antes de usar a extended; ztta/roll_area: roll área total, por WP; rdisp/roll_SHM: tamanho do roll buffer; rdisp/roll_MAXFS: tamanho do arquivo de roll buffer; em/initial_size_MB: tamanho inicial da memória estendida; ztta/roll_extention: cota de usuário para memória estendida; abap/heap_area_dia: tamanho ocupado na Heap Memory pelo dialog; abap/heap_area_nondia: define o limite de memória local para processos não dialogs; abap/heap_area_total: total de heap memory para todos os WP. 74 Implementation Of SAP Extended Memory O parâmetro em/initial_size_MB é limitado por SO, sendo 32 bits <= 4Gb e 64 bits espaço maior. SAP recomenda <= 2Gb no 32bits. O valor padrão de ztta/roll_extension é 2Gb, então é limitada pelo parâmetro em/adress_space_MB. Quando a instância é iniciada, a memória estendida é alocada pela variável em/initial_size_MB. No windows, será esticada até o valor de em/max_size_MB (ou limite de memória física = RAM + Swap). ST02 Detail Analysis Menu SAP Memory Mode list. Verificar user que estejam usando Heap Memory (PRIV mode). A terceira coluna (X), mostra WP que estejam processando. Os demais estão aguardando. Memory Usage for SAP Web AS Java JVM dividido em: - Young generation: objetos recentes; - Tenured generation: usados por um bom tempo; - Permanent generation: ex.: classes principais e métodos. Avaiable memory = memória alocada, não necessáriamente no máximo possível = reserved memory. Virtual memory = memória não alocada (total – alocada). 75 Recomendado colocar valor de início = valor máximo, para evitar mudanças de tamanho durante a operação. Unit 4 – Hardware Bottlenecks Hardware Bottlenecks CPU idle na transação ST06 deve estar por volta de 20%. Menos do que isso pode causar “CPU Wait”. Valor ótimo é em torno de 20%. Se a CPU estiver alta: - ST06 Detail analysis menu Top CPU processes: processo consumindo muita CPU; - Anotar o PID do processo acima e identificar na SM50; - Verificar na ST04 o porquê de tanto consumo, se pode ser feito tuning ou se é melhor deixar para horários com menos utilização da máquina. SOs baseados em Unix, toleram swap-out até 20% do tamanho da memória física por hora. Swap-in não influencia na performance. Windows tolera page-in até 25% da memória física por hora. Page-out não influencia na performance. Para verificar a atividade de Page/swap, ST06 Detail analysis menu Previous hours Memory. Alto swap/Page pode indicar gargalo de memória. Para reduzir o consumo: - Distribuir processos que não são específicos para este hardware para outra máquina; - se necessário, reduzir o tamanho do cachê de file system para menos de 10% da memória física total; - Identificar usuários/programas que consomem muita memória: ST02 Detail analysis menu SAP memory Mode list. Tuning de SQL ou ABAP pode ser necessário. Na transação ST03N podem ser verificados processos com grande média de wait time. Processo com processing time maior que duas vezes o tempo de CPU pode indicar gargalo. 76 Optimizing Hardware Utilization Dicas para configuração inicial de memória (ECC 5.0): - Banco de dados por volta de 20% da memória física de todos servers SAP; - Buffers em um total de 1Gb por instância; - Considerar por WP entre 50 e 60Mb de memória - de 15 a 20Mb por usuário; - Após primeiro startup, o consumo de memória virtual não pode exceder 2x RAM; - Swap no Unix: 3x RAM, mínimo de 5Gb. No 64bits, 20Gb; - Page size no Windows: 4x RAM. Verificar memória virtual: ST02 Detail Analysis Menu SAP Memory. Fatores para sizing de CPU: - distribuição de carga durante 24hs, 7 dias, 1 mês, 1 ano; - aplicações usadas; - Número de usuários concorrentes; - Tipo de hardware, SO, produto SAP e versões. Notas gerais de consumo de CPU: - BD entre 10% e 30% do total de CPU de todo sistema SAP; - Update process entre 10% e 20% do total de CPU de todo sistema SAP. Unit 5 – Expensive SQL Statements Detecting Expensive SQL Statements Expensive selects sao definidos como todos SQLs que fazem o banco ler muitos blocos (do disco ou buffer). Usualmente, comandos são considerados expensivos quando lêem mais de 5 blocos por Record encontrada. Algumas definições alteram esse limite para 30 blocos. No Workload Analysis (ST03N), podem-se somar os tempos de resposta para ver os comandos que demoram mais a responder ou transações mais demorada. Mas nem todo comando SQL expensivo será passível de melorias. Como usar o Work Process Overview (SM50): - Identificar ações longas (ex.: “Sequential Read”, “Insert” ou “Update”); - Verificar o nome do report e transação (SM66) para futuro detalhamento; - Verificar o nome da tabela; - Duplo clique na linha mostra o SQL que está executando (SM50). Como usar o Transaction Profile (ST03N): - Ordenar por Average DB time. Transações com alto tempo de resposta pode ser por causa de SQLs; - Ordernar por Total Database Time e somar. Transações com mais de 5% do total devem ser verificadas. Podem conter SQLs expensivos. - ordernar por Total Response Time e somar. Transações com mais de 5% do total devem ser verificadas. Podem necessitar tuning de ABAP. Como usar Statistical Records (STAD): - Selecione um tempo; - Task type D; - Escolher um valor relevante para DB request time (ex.: 1000ms). - Duplo clique nos resultados para análise. No Database Monitor (ST04): - Qualidade do data buffer > 95%; - devem haver menos recursive calls do que user calls; 77 - verificar “reads/user call”: não exceder 30 (blocos por user call). Isto é um forte indicador de comandos expensivos. Como usar o Database Process Monitor (ST04 Detailed Analysis Menu Oracle Session): - Identificar processos demorados, comparando o WP ID com o Client PID na SM50/SM66; - Verificar a ação no banco clicando em SQL Statement, no popup verá a informação do dicionário do objeto, o explain plan do SQL e a referência para a linha do programa ABAP. Analise o explain. Terminologia no monitoramento do banco de dados: - Reads: número de blocos lidos para o comando a partir do data buffer (encontrado diretamente no buffer ou lido do disco e jogado no buffer); - Buffer Gets: número de blocos lidos do data buffer; - Physical Reads/Disk Reads: blocos lidos do banco de dados (ST04 Detailed Analysis Menu SQL Request: Analysis of Shared Cursor Cache). SQLs: - ABAP: maúsculo e com aspas. Podem ser alterados; - Database administration tools: maiúsculo e não pode ser tunado; - SAP Basis tables: tabelas D*, não podem ser tunadas; - SQL Recursivos (Oracle): minúsculas, não pode ser tunado. Analysis and Tuning of Expensive SQL Statements Todas as tabelas SAP utilizam o otimizador bazeado em custo, que calcula o custo diferentes formas de acesso baseados em estatísticas. Estatísticas contém informações da tabela (ou índice) como número de entradas, distribuição nos blocos do BD, etc. Unit 6 – SAP Table Buffering Introduction to Table Buffering in SAP Systems O sistema pode acessar dados de tabelas em buffer, chamado table buffer. Via transações SE11 e SE13 podem ser definidos 3 níveis de buffer: - Fully Buffered: tabela inteiramente bufferizada; - Generic Area Buffered: dados são bufferizados seguindo regras de campos chaves definidos; - Single Record Buffered: cada linha acessada é bufferizada. Ambientes que possuem apenas um Central System, o buffer é sempre up to date, uma vez que dados alterados são invalidados no buffer. Porém, em ambientes com mais de uma instância, o parâmetro rdisp/bufrefmode deve ser setado para “sendon,exeauto”, para se segurar que: - o SAP logará cada alteração de buffer na tabela DDLOG (sendon); - as instâncias frequentemente acessarão a tabela DDLOG para verificar se os dados no buffer são válidos (exeauto). O tempo para invalidação do buffer é definido pelo parâmetro rdisp/bufreftime, usualmente setado para 60s ou 120s. Não ativar buffer em tabelas de dados de negócio, que devem ter garantia de não pegar dados antigos no buffer. Considerar opção de buffer “Buffering not allowed”. Comandos SQL que não utilizam o buffer: - Select ... bypassing buffer; - Select for update; 78 - Select distinct; - Order by (campos não chaves primárias); - Funções de agragação (min, Max, count, sum, avg); - Where com “is null”; - SQLs nativos. Não ativar buffer de tabelas para: - Tabelas originais SAP definidas como “buffering not allowed”; - Tabelas que não podem ter dados desatualizados; - Tabelas de transação. Recomendações: - Tabelas que são pouco alteradas; - Tabelas muito acessadas; - Somente em casos especiais para tabelas com mais de 1Mb; - São mais efetivos para tabelas acessadas pela chave primária; - Verificar se o buffer tem espaço suficiente para a nova tabela bufferizada; - Dados de customizações são geralmente bufferizados. Analyzing Table Buffering Acessar ST03N Transaction Profile e ordernar por “Response time total” transações com CPU time altos (> 40%) fazer trace de ABAP (SE30). Transações com database time alto (> 40%) selecionar a transação e pressionar “Single Records” Fazer trace de SQL (ST05) e analizar os buffers de dados (ST10). Perguntas a se analisar na ST10: - Tabelas sem bufferização com muitos “Total ABAP Processor Requests”: bufferizar? - Tabelas bufferizadas com grande número de invalidações: retirar bufferização? - Tabelas bufferizadas com grande número de “Rows affected”: retirar bufferização? - Tabelas com grande tamanho de buffer: retirar bufferização? Unit 7 – RFC Monitoring Remote Function Call Basics RFC é uma tecnologia para conectar sistemas SAP. RFC entre servidores SAP permite processamento automático de dados. SAP GUI utiliza RFC para se comunicar com o sistema SAP. Uso de RFC: - Comunicação entre sistemas SAP ou SAP e sistema externo; - Comunicação entre a aplicação SAP e o SAP GUI; - Inicializar processos em paralelo no SAP. Tipos de RFC: - Synchronous (sRFC): comunicação entre sistemas e SAP com o SAP GUI; - Asynchronous (aRFC): comunicação entre sistemas e processamento paralelo; - Transactional (tRFC): tipo especializado de aRFC, usado para comunicações seguras entre sistemas; - Queued (qRFC): tipo especializado de tRFC, para comunicação em ordem específica. Terminologias: - Client: quem estabelece a comunicação; - Server: quem recebe a comunicação; - Roll Wait Time: tempo de espera de retorno da chamada RFC; - RFC+CPIC time: 79 o Synchronous: tempo no cliente de estabelecer RFC + Roll out (envio) + Roll wait +Roll in; o Asynchronous: tempo de estabelecer RFC. AS envia informações em blocos ao GUI, chamados round trips. GUI Time: - Server: estabelecimento de RFC p/ cliente + Roll out + roll wait time; - Client: network transfer + screen build. Response time: wait, roll in & load time + processing time + database time + processing time + Gui time. GUI Time é acumulativo, ou seja, somado em cada dialog step. Na ST03N pode-se retirar o GUI time no Response Time Distribution. Monitoring RFC Load and Solving RFC Load Problems Records estatísticos contêm informações detalhadas de um step de uma transação. Existe uma Record principal por step, que pode conter várias sub-records, dependendo da parametrização. Parâmetros para coleta de dados estatísticos: - Kernell administration: stat/adrec: normalmente desligado, visto que engrandece o arquivo de estatísticas; - BTC: stat/btrrec: padrão 50 subrecords, cada uma corresponde a um step do job; - Database procedure: stat/dbprocrec: zero por default, tem relevância no APO; - Spool: stat/sporec: default 5; - Table Access: stat/tabrec: usado em combinação com o stat/tabrec_tcode_nr para restringir sub-records de acesso a tabelas para somente códigos de transações selecionadas; - HTTP client: stat/httprec: número de sub-records para salvar estatísticas de queries do AS para cada transaction step; - Remote function call: stat/rfcrec: default 5, que significa 5 RFCs sub-records são escritas por transaction step. 5 para top five response time e + 5 para top five destinations. No caso de transaction steps com RFCs, o SAP kernel escreve adicionais records estatísticas: as RFC Sub-records. ST03N Workload RFC Profiles: - RFC Client profile: agregado de individuais RFC Client sub-records para cada function module chamado; - RFC Server profile: agregado de individuais RFC Server sub-records para cada function module chamado; - RFC Client-destination profile: agrupamento de todas chamadas RFCs individuais por cliente; - RFC Server-destination profile: agrupamento de todas chamadas RFCs individuais por Server. As functions modules ARFC_DEST_CONFIRM, ARFC_DEST_SHIP, ARFC_RUN_NOWAIT e RFC_PING fazem parte do framework da tRFC e não devem ser analizadas. Na STAD, se RFC+CPIC time exceder em muito o roll-wait, pode haver problemas de comunicação. Roll wait time alto pode indicar expensive GUI round trips. Neste caso, tempo de GUI alto pode ser observado na ST03N. O Performance Trace (ST05) possui informações relevantes sobre SQL, enfileiramento e acesso a buffers, além de comunicação RFC. Quando o Trace é ativado, a primeira 80 entrada é a função SAPGUI_PROCESS_INDICATOR. O comando referindo a OLE_FLUSH_CALL indica o round trip para o GUI. O máximo de dados a ser transferido é 32Kb, caso ultrapasse, a função GUICORE_BLOB_DIAG_PARSER é chamada. Trace de autorizações pode ser iniciado via ST01, o trace indica o início de transações, chamadas RFCs e SQLs. sRFC: CALL FUNCTION ... DESTINATION aRFC: CALL FUNCTION … DESTINATION … STARTING NEW TASK tRFC: CALL FUNCTION … DESTINATION … IN BACKGROUND TASK tRFCs não são executadas imediatamente, são executadas no COMMIT WORK seguinte: chamadas são guardadas nas tabelas ARFCSSTATE e ARFCSDATA, onde cada logic unit of work (LUW) é identificada por um ID COMMIT WORK calls referentes aos IDs são executados no target system LUW executada no destino com sucesso? função ARFC_DEST_CONFIRM (no cliente) tabelas ARFCSSTATE E ARFCSDATA apagadas. Erros em tRFCs podem ser vistas na SM58. Caso o sistema de destino não seja encontrado, ex.: conexão não ativa, um report RSARFCSE é agendado com o ID. Para ver o intervalo padrão: SM58 Info System Settings. Se quiser alterar para uma determinada RFC, SM59 Destination tRFC options. Monitoramento de carga RFC: ST03N. Análise de RFC: - SM50: - reports SAPLARFC (aRFC) e SAPLERFC (tRFC); - Acessos a tabelas ARFCSSTATE ou ARFCSDATA (tRFC); - Workprocess com status “stopped”, com ação CMINIT, CMSEND ou CMRECEIVE por longo tempo indica problemas de comunicacao. - SM04: tipo RFC; - STAD: task type R; - SM58: monitorar tRFCs; - ST03N: RFC Profiles. Se for esperada uma grande carga de chamadas RFC entrantes, é recomendado configurar uma instância dedicada a essas RFCs. Unit 8 – Acess to Help Configuring the Online Documentation SAP Library = Online Documentation = help instalado. Usando o SAP Library, pode-se facilmente pesquisar, acessar o glossário e uma introdução de como usar o SAP (Getting Started). Tipos de help: - HtmlHelpFile: formato HTML compilado, disponibilizado em file server, exibidos no HelpViewer. Disponível apenas no windows, pode-se fazer pesquisa e imprimir várias documentações concorrentes, 10% do tamanho do HTML padrão; - PlainHtmlHttp: formato HTML padrão, disponibilizado em um web Server, permite fazer pesquisa e imprimir uma documentação individual; - PlainHtmlFile: formato HTML padrão, disponibilizado em file Server, aberto diretamente no Browser; - DynamicHelp: usado em todos front-ends, formato HTML padrão, acessível via Knowledge Warehouse Server. 81 IMG General Settings Setting Variants for help (SAP Library) ou SR13 é usado para configurar o help. A partir do R/3 4.6C, não é necessário alterar configurações no perfil. Na configuração das variáveis do help, o campo Area indica a área de conhecimento a que se refere o conteúdo. Ex.: EWBHELP (documentação para todos usuários), IWBTRAIN (treinamento), etc. Se forem instalados vários tipos de help, o usuário poderá optar em Help Settings Extended Help (via GUI). Configurações locais de front end são possíveis através do arquivo sapdoccd.ini, presente no windir, diretório do sapgui ou um nível acima deste. Este arquivo deve ter dados que estão na SR13, caso contrário não mostrará o help. Unit 9 – Introduction to System Security Security in the SAP Environment Mecanimos de criptografia, parâmetros de segurança de sistema e SAPRouter são alguns componentes que apóiam na implantação de conceitos de segurança. Usuários administradores padrões devem ter sua senha trocada. Sendo eles: SAP* em todos clientes e DDIC existe apenas no 000. O EarlyWatch no 066 não possui acessos administrativos, então não é necessário alterar a senha. O parâmetro login/no_automatic_user_sapstar só funciona se o usuário SAP* não existir no client. SNC é uma camada de software no SAP que fornece uma interface com produtos externos de segurança. A implementação de segurança é feita com produtos que não são diretamente fornecidos pela SAP. SNC provê segurança em nível de aplicação, isto quer dizer que a comunicação entre componentes estará segura. Níveis de proteção: - Authentication only: apenas a identidade do partner é verificada; - Integrity protection: o sistema identifica alterações na mensagem, feitas durante a transferência; - Confidentiality protection: mensagem é encriptada, inclui as duas anteriores. SNC criptograva protocolos DIAG e RFC. Para HTTP, é usado o SSL. Usos: - comunicação direta do AS com a internet, via ICM; - comunicação com internet via ITS, presente no WGate (web Server). Secure Store and Foward (SSF) assegura que dados e documentos são seguros durante transações dialog. É o caso de: - dados que deixam o sistema (eletronic orders, invoices, information); - dados que são gravados em mídias não seguras (disquetes, archive); - dados que são transferidos usando redes não seguras (internet); - dados individuais de pessoas (assinatura digital, dados pessoais). SAPRouter gerencia conexões através do firewall, mas não dispensa o uso deste. O SAPRouter pode ser usado para: - controlar e logar conexões; - criar conexões indiretas (ex.: regra da rede não permite acesso direto); - resolver conflitos de endereçamento quando não usa IPs registrados; - aumenta segurança: protege por senha, apenas acessos permitidos, SNC... - aumenta a performance e estabilidade reduzinho do workload do sistema com uma LAN durante comunicação com a WAN. 82 Unit 10 – Archiving Fundamentals of SAP Data Archiving Data Archiving significa a extração de objetos de dados do banco de dados, de forma consistente, onde todos dados extraídos são escritos em um arquivo fora do banco de dados. A consistência de regras de negócio é assegurada pelos programas de archiving da SAP. Os dados são archivados de forma online, ou seja, com o sistema no ar. Não é necessário fazer o shutdown. Razões para archiving: - melhorar ou assegurar tempos de resposta mais baixos; - reduzir custos de administração do banco de dados; - reduzir tempos de backup offline, recoveries, upgrades; Levar em consideração regras legais do país, como tempo de retenção, etc. Dados arquivados podem ser acessados a qualquer momento por queries. Dados arquivados são independentes de versões do SAP. Pode ser extraído em uma versão, o sistema sofrer upgrade, e serem lidos na nova versão. Processo de archiving: 1) Criando o arquivo de archive: o arquivo (ou mais) que conterá o archive é criado. Dados são lidos do banco e escritos nele(s); 2) Guardando os arquivos de archive: após completado a escrita dos archives, eles podem ser guardados; 3) Removendo os dados: o programa de remoção primeiro lê os arquivos de archive e então remove as records do banco de dados. Opções para guardar archives: - Hierarchical Storage Management (HSM): indicar caminho na transação FILE, o sistema gerencia onde guardar; - Optical archiving: CDs, etc. - Manual Storage: após deleção, podem ser manualmente movidos a uma fita, por exemplo. Performing Data Archiving O elemento central do arquivamento é o archiving object. Ele define a menor unidade que pode ser completamente arquivado e removido do banco de dados, e descreve qual database object deve ser acessado, e quando, para o archivamento completo do business object. O arquivamento consiste de 3 componentes: - Data declaration component: descreve todos os database objects que caracterizam um aplication object; - Customizing settings: paramentros do archiving object para a execução de um archive; - Programs: o programa de escrita (do archive em arquivos), de remoção (dos dados do banco) e o programa de exibição de dados após archive. Transação DB15 informa qual tabela está associada com qual archiving object e viceversa. Parâmetros: - General customizing (Basis customizing): logical path e nome dos arquivos gerados; - Cross-archiving object Customizing: grupo de servidores para processo background; - Archiving Object-Specific Customizing: tamanho dos arquivos e configurações para o programa de remoção dos dados arquivados. 83 O processo é agendado para execução em background seleciona objetos do banco de dados (levando em conta integridade) verifica se cada objeto de dados pode ser arquivado objetos são escritos no archive configurado para deleção automática? após término da escrita, programa de deleção é executado. A execução é agendada via transação SARA, clicando no botão “write”: 1) Crie um archive variant (seleciona archiving objects); 2) Especifique um usuário (tem q ter acesso S_ARCHIVE.S_ARCHIVE); 3) Especifique a hora de início; 4) Defina os parâmetros de spool. O monitoramento pode ser feito via background tools (SM37) ou via CCMS. Accessing Archived Data O Archive Development Kit quarda os dados de forma que possam ser lidos posteriormente, bastando para isso o programa de leitura que é disponibilizado pelo archiving object. O acesso é possível de duas formas: - Sequential (reading) Access: o programa primeiro abre o arquive, lê o conteúdo e lista os dados que correspondem ao critério de seleção. Ex.: mostrar documentos de um determinado período; - Direct Access: o objeto é primeiramente indexado utilizando critérios de pesquisa. Após isso, acessa diretamente o objeto via o índice criado. Forma mais custosa e não oferecida para todos archiving objects. A pesquisa pode ser feita acessando diretamente a transação SARA e escolhendo “Read”. O SAP Archive Information System é um utilitário para pesquisa em data archives, integrado no ambiente de archive. Oferece suporte para pesquisa e provê funções para exibição dos dados. Quando acessando dados arquivados, o usuário pode escolher entre diversar formas de exibição dos data objects. Exemplo são o tecnical view e o Business view. Unit 11 – Including Printers in SAP Systems Configuring Printers in SAP Systems O output em uma impresora é feita sempre da seguinte forma: uma spool request é criada (formato independente de impressora, com informações de autor, data, etc. e os dados a serem impressos) e após uma output request é criada (dados específicos para impressora). Isso permite visualização da spool antes da impressão. Uma spool pode ter vários output requests. O conteúdo de uma spool request é guardado na TemSe (para temporariamente seqüenciar os objetos) na localização definida pelo parâmetro rspo/store_location: - db = banco de dados (tabela TST03), com a vantagem de entrar em backup; - G = file system, com a vantagem de performance. Para definir uma localização individual para uma output device: SPAD Edit Data Storage. Se uma impressora não pode ser controlada pelo sistema operacional, ela não pode ser usada no SAP. Os principais métodos de impressão são: Local Printing, Remote Printing, e Front-end Printing. 84 O local printing caracteriza-se por o spool work process e o spool do sistema operacional estarem na mesma máquina, independente se a impressora está ou não. O WP passa dos dados de impressão na mesma máquina. É o método mais rápido para impressão. - no Unix, os dados são passados via método “L”, usando métodos do sistema operacional com linguagem específica sendo guardadas em profiles; - no Windows, o método de acesso é “C” e os dados são passados diretamente ao sistema operacional via API da impressora. O uso de vários SPO WP gera diferenças no seqüenciamento de outputs. No caso do remote printing o SPO WP e o spooler do sistema operacional estão em hosts separados. Cenários típicos: - a impressora é acessada diretamente via rede (Access method U); - uso do programa saplpd instalado em Windows (método “S” ou “U”). O front-end printing caracteriza-se por utilizar a impressora local do usuário. O administrador cria apenas uma impressora e associa ao método de acesso “F”. No Windows, o sapldp recebe a solicitação e encaminha ao Windows output controle. Nos outros SOs, os dados são direcionados diretamente ao spooler do sistema operacional. O número de SPO WP direcionados para front-end printing pode ser estipulado no parâmetro rdisp/wp_no_Fro_max. Para criar uma impressora, acessar SPAD, preencher em “devices/servers”: - Output device: nome longo, 30 caracteres; - Short Name: nome interno; - Device type: modelo da impressora. SWIN direciona para o formato Windows printer driver, que pode ser útil caso o usuário tenha várias impressoras diferentes; - Spool Server: AS com SPO ou logical Server; - Location: texto da localização da impressora; - Message: mensagem que substitui a localização (ex.: temporariamente fora do ar); - Lock print in SAP system: cria output, mas não manda para impressora; - Host spool Access method: como o SPO WP acessa o spooler do SO? - Host printer: nome da impressora no sistema operacional (case-sensitive); - Host: apenas para local printing, calculado pelo Spool Server. - Destination host: apenas para remote printing. Nome do servidor que tem o spooler do SO. Concept of Logical Spool Servers Um Spool Server é um AS com pelo menos um Spool WP. Cada output request é processado em um spool Server. Um output device pode ser colocado diretamente em um spool Server, mas existem vantagens de se usar um logical (spool) Server, como classificação (dev/PRD), load balancing, etc. A criação de um spool Server é feita na SPAD, guia Devices / Servers, escolhendo spool servers. Informações importantes: - Server Name: nome do spool Server, Max 20 caracteres; - Server class: classificação (ex.: mass printing); - Logical Server: para criar um logical Server; - Mapping: nome de um real ou logical Server que este logical aponta; Pode-se definir um spool Server apenas para front-end printing, através do parâmetro rspo/local_print/server, apontando para o nome do servidor. Caso contrário, será usado o servidor local (se tiver S WP) ou o com menor carga. 85 A classificação do output device pode ser feito via SPAD Output Devices Edit Classification). Vantagens do logical Spool Server: - Downtime security: utilizando um alternative Server, caso o normal não esteja disponível, as requisições são direcionadas. O servidor alternativo pode ser outro logical apontando para outros logicals, formando uma teia. - Load Balancing: calcula o número de spool work process, output requests e pages, entre o principal e o alternativo. Requisições seqüenciais têm prioridade sobre load balance. - Transporting the Print Landscape: os logical servers podem ser migrados entre ambientes, sendo necessário apenas mapear os logical servers para os spool servers no novo sistema. Managing Spool Requests Para manter spool e output devices, acessar transação SP01. Para apenas verificar o status da sua própria requisição de spool, SP02. É possível monitorar outros sistemas, colocando uma RFC válida no campo system name. Caso o monitoramento remoto via RZ20 esteja configurado, basta deixar esse campo vazio. Status de uma spool request: - : ainda não enviado ao sistema operacional; + : spool request sendo criada; Waiting: ainda não processada pelo pool do sistema; Proc.: Spool WP formatando a output request; Print: sendo impressa pelo spooler do sistema operacional; Compl.: output request impressa. <F5>: output requests com vários status; Problem: erro não sério, a requisição foi impressa; Error: indica erro grave; Time: um horário foi especificado para o output pelo seu criador. A remoção de spool requests antigas é trabalho de administração do sistema; Para remover spool requests antigas, agendar o programa ABAP RSPO1041 com uma variant apropriada. Para verificar a consistência do spool database, agendar o RSPO1043 com uma variant apropriada com freqüência diária. O SAP pode acessar um external Output Management System (OMS) via interface BCXOM, método de acesso “E”, interessante no caso de grande volume de processamento ou compartilhamento com outros sistemas. Desde a versão 4.0B, a saída de impressão pode ser enviada por e-mail (Acesso M). Web Printing é possível via device type PDF1, desde a versão 4.6B. Via ITS, é exibido um PDF para o usuário imprimir localmente. Unit 12 – Structured Troubleshooting Trace options Existem dois tipos de trace: performance trace e system trace. Pode ser usado ainda o developer trace e o system log para correção de problemas; - System log SM21: detectar e corrigir erros no sistema e ambiente; - Dump Analysis ST22: erros em runtime geram um short dump; 86 - System Trace ST01: atividades internas do SAP, como authorization check, acesso ao banco, kernet e RFC; - Performance Trace ST05: chamadas de: acesso ao banco, lock management, remote cals…; - Developer trace ST11: infomações técnicas sobre problemas internos. System log Se estiver usando sistema operacional UNIX, pode-se trabalhar com central logging. SM21 System log Choose All Remote System Logs ou System log Choose Central System Log. No Expert Mode (Edit Expert Mode) pode-se extender os critérios de pesquisa para um terminal apenas. Definição do path e nome de arquivo do log local e central: - rslg/local/file: local log (ex.: SLOG<SAP_SYSTEM_NUMBER>); - rslg/central/file: central log (ex.: SLOGJ). Dump Analysis Uma excessão não tratada gera um runtime error. Neste caso, o ABAP runtime finaliza a execução do programa, gerando um short dump. Situações de erros podem ser: - Internal Error: indentificado pelo error, contactar SAP; - Installation and Enviroment/Resource Error: instalação incorreta ou recurso faltando (ex.: shutdown); - Error in Application Program. Por default, short dumps são guardados por 14 dias. Short dumps podem ser removidos (goto Reorganize) ou salvos sem limite de tempo (Short Dump Keep/Release). SAP System Trace Primeiramente usado caso um authorization trace deve ser criado. SAP recomenda o uso de sytem log ou developer trace para analizar problemas. Usado para: - Authorization Checks: que permissões e quando são usadas; - Kernel functions; - Kernel Modules; - DB Accesses (SQL Trace): quando e com que parâmetros as Open SQL são transformandas em comandos SQL; - Table buffers; - Lock operations. Exibe quando chamadas RFCs são feitas e na instância que são executadas. Performance Trace - Gravar chamadas ao banco; - gravar gerenciamento de lock; - buffers de tabelas; - remote calls de reports e transações; - análize detalhada de trace records; - análize de comandos SQL. Os traces não são escritos diretamente em arquivos, mas guardados antes em um buffer. O parâmetro rstr/buffer_size_kB determina o tamanho deste buffer. O arquivo de buffer é criado com nome de acordo com o parâmetro rstr/filename; O arquivo de trace cresce até o tamanho de rstr/max_filesize_MB e então os mais antigos são renomeados, adicionando 00 até 99, ou quantidade definida pelo parâmetro rstr/max_files. Developer Trace 87 Contém informações técnicas e é usado em caso de erros. Utilizado para investigar problemas no SAP e servidor. O Acesso pode ser feito via SO, AL11 ou SM50 (Process Trace Display File). Unit 13 - Advanced User Administration Topics Introduction to CUA Usuários devem ser bloqueados, e não excluídos. Obs.: - Central deve ser 4.6C pra cima; - Cliente pode ser 4.5B pra cima. Logical System: sistema ligado um ao outro via ALE. No contexto do CUA, são os clients envolvidos. Setting UP a CUA Passos: Definir logical system na DB54; Acessar SCC4 e definir o logical system no client; No Server: Copiar funções “SAP_BC_USR_CUA_SETUP_CENTRAL”, “SAP_BC_USR_CUA_CENTRAL” e “SAP_BC_USR_CUA_CENTRAL_BDIST”, adicionando “Z_” na frente e regerar os profiles; Criar user “CUA_<SID>”. No Client: Copiar funções “SAP_BC_USR_CUA_SETUP_CLIENT” e “SAP_BC_USR_CUA_CLIENT”, adicionando “Z_” na frente e regerar os profiles; Criar user “CUA_<SID>_###”. Configurar RFCs via SM59, RFC do tipo 3, nome igual logical system; Na transação SCUA, criar nova e cadastrar todos os clientes (server); Na transação SCUM, alterar modo de replicação (server); Acertar company adress via SUCOMP, e replicar nos clients via SCUG; Sincronizar usuários via SCUG; User Administration with the CUA Após o CUA habilitado, algumas diferenças: - nova tab Systems: mostra os sistemas em que o usuário está cadastrado. Se removido desta tela, remove do ambiente; - Roles page: contém as roles do cliente. Executar o Text comparison para atualizar lista; - Profiles: idem roles; Introduction to Directory Services Directory Services age como um repositório central de usuários. As informações são gravadas de forma hierárquica (tree). Acesso normalmente via LDAP, X.500 DAP ou DSML. LDAP Utiliza pilhas TCP/IP; Contém entradas q são um ou mais atributos; atributos estão em Classes, que fazem parte de um Schema. 88 Entradas estão organizadas em árvores (chamada Directory Information Tree – DIT), e cada entrada possui um Distinguished Name (DN), que é criado descrevendo o caminho do root da árvore. SAP & LDAP Na versão 4.0A foi disponibilizado o LDAP Gateway, programa instalado a parte. Na versão 4.6A foi disponibilizado o LDAP Connector, integrado ao AS, interface entre o AS e o LDAP Server. Desde o Web AS 6.10 foram disponibilizadas funções para sincronização de dados. Technical Connection of Directory Services SAP usa RFC do tipo T (TCP/IP). Se só existe um ambiente no servidor, usar RFC com nome LDAP_<SERVIDOR>, caso tenha mais que um, utilizar LDAP_<SERVIDOR>-<SEQN>. Letras maiúsculas e sem espaço. Necessário registrar no gateway local (sapgw<instance number>). Transação LDAP ou SPRO SAP NetWeaver SAP Web Application Server System Administration Directory Integration. Quando o Status do servidor LDAP é determinado como ativo no SAP, o CCMS monitora frequentemente o status do LDAP. Necessário usuário para acessar o LDAP (ou acesso anônimo). Esse usuário não corresponde a usuário no SAP ou no Directory Server. O user pode estar cadastrado no SAP, porém aqui é salvado um user diferente. Após isto, configurar o Connection Data, com informações sobre o servidor LDAP. 89 TADM51 Unit 1 – Database Overview Database Architecture No sistema SAP, o único usuário que se conecta com o banco deve ser o administrador de banco. Terminologia: - database: coleção de dados, logicamente tratado como uma unidade. Fisicamente os dados são gravados em um ou mais datafiles em disco; - instance: combinação entre os processos do Oracle (background) e os buffers de memória. Uma database é associada a uma e somente uma instância; - SGA: system global área, dados e informações de controle para uma instância do Oracle; - processes: processos background; - system identifier (DBSID): cada banco de dados é identificado por um system identifier. No SAP são 3 dígitos, sendo o primeiro caracter maiúsculo e os outros dois caracteres maiúsculos ou números. Na inicialização de uma instância Oracle, um processo chamado Listener é carregado e abre um canal de comunicação pelo qual clientes podem se conectar com a instância. Em um ambiente SAP, a configuração de dedicated Server é usada, o que significa que para cada requisição de conexão do WP, o listener cria um Server process dedicado. Cada Server process criado para o WP é chamado de shadow process. Oracle Background processes realizam várias atividades para que o DBMS funcione corretamente. Dados são gravados em data files no disco. Para acelerar o acesso, os dados são gravados em cache, no database buffer, na SGA. O sistema trabalha as SQLs na Shared SQL área (ou chared cursor cachê), como parte do shared pool na SGA. A outra parte do shared pool é o row cachê, que contém informações sobre o dicionário do Oracle. Os dados primeiramente são copiados do banco para o database buffer pelo shadow process para depois ser usado pelo cliente. A menor unidade lógica do Oracle é chamada de data block (tanto em disco quanto em buffer): - Durante a instalação do Oracle pode-se escolher qual o tamanho do bloco. No SAP é sempre 8kb; - Por questões de performance, recomenda-se formatar os file systems com 8Kb. Alterações em dados são feitos sempre no buffer cache. O shadow process não copia blocos modificados (dirty blocks) do buffer cache para o disco. Este é o trabalho do database writer (DBW0), nas seguintes situações: - quando o shadow process procura por blocos livres no buffer, e este número está abaixo de um valor padrão, o shadow process inicializa o DBW0 que escreverá os dirty blocks na lista dos menos recentemente usados no disco e liberará os blocos; - em tempos específicos, o checkpoint process (CKPT) sinaliza ao database writer a gravar todos os dirty blocks em disco. Na maioria dos bancos, um processo DBW0 é suficiente, mas em alguns casos adicionais database writer processes podem ser criados (DBW1, etc.). Para garantir consistência nos dados e a leitura, Oracle mantém redo entries para executar comandos e undo entries para roll back, em caso de crashes. 90 Redo entries contém dados necessários para refazer as modificações feitas no banco de dados em uma transação efetivada. Redo entries contém novos valores, chamados after images. Em paralelo, shadow processes escrevem redo entries no redo log buffer, que contém todas as entradas (commitadas ou não). O processo log writer (LGWR) escreve porções do redo log buffer em online redo log files se: - a transação é efetivada (LGWR coloca uma informação específica no arquivo); - a cada 3 segundos; - quando o redo log está 1/3 cheio; - quando o DBW0 escrever dirty blocks no disco, mas esses ainda não foram para o online redo log. Quando uma transação sofre commit, é gerado um system change number (SCN), que é gravado no redo log. Undo entries contém informações para undo ou roll back, e suas entradas são chamadas before images. Essas entradas estão separadas do redo log, em undo tablespaces ou rollback segments. Durante um recovery, Oracle primeiramente aplica todas as modificações do redo log, para depois fazer o roll back das transações não efetivadas. Redo log files possuem um tamanho fixado (no SAP 50Mb), e quando começa a ficar cheio o LGWR fecha o arquivo e começa a escrever no arquivo seguinte, o que é chamado de log switch. Cada log recebe uma numeração log sequence number (LSN). Cada database possui um control file, que contém entradas que especificam a estrutura física e o estado da base, como tablespaces, nomes e localizações dos data files e redo logs, ou o LSN. Control file é apenas alterada pelo Oracle, deve estar disponível para escrita quando o banco é ativado e no SAP ele é espelhado em 3 lugares diferentes por segurança. O termo checkpoint tem dois significados: 1) Evento em que todos buffers no buffer cachê são escritos nos data files, pelo DBW0: O checkpoint process (CKPT) sinaliza o DBW0 copiar todos os dirty blocs para o disco. 2) Posição no log que indica a partir de onde é necessário fazer recovery, usando o redo log (dados anteriores já estão no data file). O Oracle lê a partir do control file o checkpoint para recorvery. O CKPT ainda atualiza os headers dos data files gravando os detalhes do checkpoint e escreve a posição do checkpoint no online redo log. Checkpoint ocorre a cada log switch e quando especificado em parâmetros do Oracle (no SAP esses parâmetros não são usados, e o checkpoint apenas no log switch). O recorvery na inicialização da base consiste de duas etapas: - inicia a partir do checkpoint, refazendo atividades do redo log, incluindo mudanças na undo space; - atividades que sofreram roll back explicitamente antes do crash são reprocessadas e o undo é garantido porque o Oracle não apaga entradas de transações abertas na undo space. Os redo logs devem ser espelhados, em duas ou mais cópias, e cada redo log deve estar em discos separados. O Oracle trás essa característica e é usada na instalação do SAP como default. Desta forma, não é necessário utilizar soluções externas. Como o online redo log é limitado em tamanho e não pode crescer automaticamente, Oracle deve sobrescrever redo logs antigos por novas entradas. 91 Para retornar uma situação antes do crash, normalmente é necessário além do backup aplicar os online redo logs posteriores. Para evitar perda de dados, os online redo log devem ser gravados em um local seguro, tarefa do archiver (ARC0). Archiving deve ser explicitamente ativado, via parâmetro LOG_ARCHIVE_START to TRUE. Em ambientes produtivos este parâmetro deve ser ativado, e os offline redo log devem ser guardados em discos espelhados (RAID). Caso haja perda de offline redo logs e data files, um recovery completo não é possível. System Monitor (SMON): - executa o recovery quando a instância é inicializada (se necessário); - escreve log de alertas se outro processo da instância falha; - limpa segmentos temporários que não estão em uso. Process Monitor (PMON): - monitora os shadow processes; - no caso de crash, faz roll back dos dados não comitados, para os shadow process e libera recursos que os processos estavam usando. A estrutura de diretórios no SAP é padrão (em todas instalações) e não deve ser alterada: - dbs (UNIX) ou database (Windows): profiles de configuração do Oracle (init<DBSID>.ora e spfile<DBSID>.ora e do BR*Tools (init<DBSID>.sap); - sapdata<n>: data files; - origlogA/B, mirrlogA/B: online redo logs 1 e 3 no A e 2 e 4 no B; - oraarch: offline redo log files, no formato <DBSID>arch1_<LSN>.dbf; - saptrace: usado para dump do Oracle. Oracle alert em saptrace/background e sadow processes in saptrace/usertrace; - saparch: logs do BRARCHIVE; - sapbackup: logs do BRBACKUP, BRRESTORE E BRRECOVER; - sapreorg: usado pelo BRSPACE para logs de diferentes atividades; 92 - sapcheck: usado pelo BRCONNECT para logs de diferentes atividades. Variáveis de ambiente para usuários <SAPSID>adm e no Unix também o ora<ORASID>: - ORACLE_SID: system ID para a instância; - ORACLE_HOME: diretório home do Oracle, que contém o Bin, DBS e network; - SAPDATA_HOME: contém arquivos do banco de dados; - no caso do Windows, se diretórios diferentes do SAPDATA_HOME são usados, SAPARCH, SAPBACKUP, SAPCHECK, SAPREORG. No Unix, ORA_NLS33 e LD_LIBRARY_PATH (ou LIBPATH no AIX, SHLIB_PATH no HPUNIX. Para melhoria de performance, aumento de carga e alta disponibilidade, o Oracle Real Application Clusters (RAC) pode ser usado, provendo: - processamento paralelo; - load balancing; - rápida e segura detecção de node ou network failure; - fast recovery. Para prover consistência de dados, o RAC coordena cada acesso da instância: - o TNS (Transport Network Service) listener prove um load balancing entre todos os nós; - se adicionar um novo nó no cluster, o Oracle atualiza todos os arquivos de listener. RAC requer que todos os nós acessem simultaneamente os discos compartilhados, e a escolha do tipo depende do SO escolhido, como em file system ou raw devices. Porém o uso de cluster file systems simplifica a instalação e administração dos RACs. RAC também controla os buffers cachês de múltiplas instâncias em diferentes nós. RAC também suporta as formas de backup e arquiving do Oracle single-instance. Connecting to the Database Para proteger o SAP, é necessário controlar usuários em três níveis: - Sistema Operacional; - Banco de Dados; - SAP. System privileges controla operações realizadas por um usuário em uma instância ou database. Object privileges controla operações em objetos, como select, update, etc. Special system privileges SYSDBA e SYSOPER são oferecidos durante as conexões, e de nenhuma outra maneira. Usuários do sistema operacional membros do grupo dba ou ORA_DBA (ou ORA_<SID>_DBA) podem conectar no banco com o privilégio SYSDBA. Membros do grupo oper ou ORA_<SID>_OPER como SYSOPER. System e objects privileges podem ser enfileirados em roles. A role mais importante é a DBA, que contém todos privilégios necessários para administração. Porém, para algumas atividades (como stop ou start), é necessário privilégio de SYSDBA ou SYSOPER. O SAP cria apenas a role SAPDBA, que provê acesso a certas tabelas para os SAP Tools, como DBSTATC, SDBAD, etc. Todas as instalações do Oracle contêm dois usuários administrativos: SYS e SYSTEM, que possuem a role DBA. SYS é o usuário mais poderoso no Oracle: 93 - todas as tabelas e views do data dictionary são guardadas no schema sys. Essas tabelas são críticas para o Oracle, não podem ser alteradas ou novas tabelas criadas nesse schema; - SYS garante adicionais privilégios que a role DBA, e pode alterar qualquer dado no banco. SYSTEM é usado pelo Oracle para criar tabelas internas e views adicionais para exibir informações administrativas. Não possui permissão para alterar tabelas do dicionário de dados. No SAP: - SYSTEM recebe função SAPDBA para que o BR*Tools possam acessar certas tabelas no schema SYS; - SYSTEM é o usuário default quando se usa SAP tools para administração do Oracle. Durante a instalação do SAP, é criado no banco um usuário SAP<SCHEMA-ID> (ou SAPR3 até Basis 4.6D). Todas as tabelas do SAP são guardadas neste schema, porém o usuário não possui direitos administrativos na database (não tem DBA ou SAPDBA). Outros usuários criados no Oracle fazem uso do operating system authentication. Se: - Usuário chamado OPS$<USERNAME> é criado na base, e <USERNAME> no sistema operacional; - parâmetro REMOTE_OS_AUTHENT=TRUE; - parâmetro OS_AUTHENT_PREFIX=OPS$; - usuário do SO só conseguirá se conectar no banco se for membro dos grupos dba ou oper no UNIX, ou ORA_DBA, ORA_<SID>_DBA ou ORA_<SID>_OPER no Windows. Conexões AS SYSDBA garante full administration na database e na instance, com o system privilege SYSDBA e os privilégios do usuário SYS. Processo de logon do WP: conecta-se no banco com o OPS$ user WP faz select na tabela SAPUSER e lê o password para SAP<SCHEMA-ID> WP disconecta do banco e conecta de novo com o usuário SAP<SCHEMA-ID>. Password do SAP<SCHEMA-ID> deve ser somente alterado via BRCONNECT. Na rede, a comunicação é via TCP/IP e no topo, no software layer, o OracleNet (Oracle Network Services). Na mesma máquina, o SAP usa o interprocess communication (IPC) protocol Named Pipes. OracleNet existe tanto no cliente quanto no servidor, e é responsável por estabelecer e manter a conexão entre os dois, bem como controlar as mensagens entre eles, usando protocolos padrões, como o TCP/IP. Um processo chamado listener (OracleNet Listener) se encarrega de ouvir novas conexões e ligá-las ao servidor. Após a conexão ser estabelecida, a comunicação passa ser diretamente entre cliente e servidor. Três arquivos são usados para essa configuração: - listener.ora: configura o listener e é usado apenas no servidor. Contém todas entradas dos sistemas Oracle que deverão aceitar conexões; - tnsnames.ora: contem a lista de services names que podem ser acessados via rede; - sqlnet.ora: pode conter informações do cliente, como domínio, traces, etc. O utilitário lsnrctl é usado para parar e ativar o listener, bem como ver seu status. No Unix é o processo tnslsnr, no Windows serviço Oracle<DBSID><Release>TNSListener. Se várias instâncias são usadas em um único host, geralmente há apenas um listener com todas entradas. O listener pode ser pingado via utilitário tnsping <DBSID>. 94 Database Administration Tools Administração do banco de dados Oracle pode ser feito via SAP administration tools, chamados de BR*Tools. Estão no diretório /usr/sap/<SID>/SYS/exe/run e podem ser usados em qualquer versão do SAP, a partir do Oracle 9i. BRTOOLS é disponibilizado como uma interface baseada em caracteres, para os programas BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE e BRCONNECT. Além do BRTOOLS, existe o BRGUI, baseado em Java, que usa as funções via BRTOOLS. Tools: - BRBACKUP: backup de data files, control files e online redo log files; - BRARCHIVE: backup dos offline redo log files; - BRRESTORE: restore de data files, control files, online e offline redo log files; - BRRECOVER: tools interativo para restore e recovery; - BRCONNECT: database administration: database check, update statistics, etc.; - BRSPACE: database administration: instance management, space management e reorganização; Os tools são separados em programas funcionais e de ajuda, bem como batch e interativos: - Funcionais: executam atividades no banco de dados: BRBACKUP, BRARCHIVE, BRRESTORE, BRRECORVER, BRSPACE e BRCONNECT; - Help: BRTOOLS que oferece menus para navegação e BRTOOLS E BRCONNECT são chamados por outros programas; - batch: BRBACKUP, BRARCHIVE, BRRESTORE e BRCONNECT não possuem menus próprios. - interativos: BRRECOVER e BRSPACE (além do BRTOOLS) possuem seus próprios menus, e podem ser chamados diretamente via prompt. Símbolos no menu do BR*Tools: Símbolo Usado em Significa + Control choise Ação está completada Control choise list Pode escolher ou executar essa opção agora * Control input Não pode escolher ou executar agora Exibição apenas, não é possível input Input Parâmetro pode ser alterado ~ Input Você pode alterar este parâmetro ou resetar seu valor Stop Todos Cancela o programa ativo Help Todos Help específico Back Todos Volta um menu Continue Yes Todos Continua pro próximo menu ou passo = Control list choise Valor automático se clicar em continue ? Input Um valor deve ser digitado # Control input Não pode ser executado ou não pode ser alterado. A função chpass do BRCONNECT deve ser usado para alterar a senha do SAP<SCHEMA-ID>. A customização do SQL*Plus pode ser feita via comando “set <variável> <valor>”. Se AUTOCOMMIT for OFF, o commit é realizado via comando “commit” ou quando é desconectado do Oracle. Transações para monitoramento e administração do banco: 95 - DB12: backup logs overview: resultado do backup e status do diretório de archives; - DB13: DBA Planing Calendar: agendamento de backups e outros Jobs administrativos. Caso use vários sistemas, pode-se usar a DB13C (central planning calendar); - DB14: DBA Operations Monitor: logs de backup, update statistics, database checks; - DB16: overview of database checks; - DB17: manter os valores usados durante system check; - DB20: manter estatísticas; - DB21: parâmetros de geração de estatísticas; - DB26: parâmetros do banco de dados; - DB02: table and indexes Monitor: monitora o tamanho do BD, e o status dos objetos do banco; - ST04: Database Performance Monitor: mostra os indicadores mais importantes (buffers, acessos de usuários, etc.) e a parametrização atual; - RZ20: database alert monitor. A DB13 é usada para agendar Jobs administrativos, como database check, backup, adapting next extents e update statistics. São executados os Jobs DBA:*, com base na tabela SDBAC. A DB14 é usada para monitoramento diário, clicar em “all activities”. Para limitar por data: Edit Selection Options. Administration of Oracle Instances Durante o startup do banco, passa-se por três fases: - NOMOUNT: o arquivo de parâmetros é lido, a instância é iniciada e os recursos alocados no sistema operacional. Usado para criar a database e recriar control files perdidos; - MOUNT: os control files são abertos, informações da estrutura física são lidas, parte do data dictionay é carregado. Usado para recovery, alteração do ARCHIVELOG, renomear data files, adicionar, remover ou renomear online redo log files; - OPEN: todos arquivos restantes são abertos, instance recovery é realizada (se necessário). Para inicializar via BRTOOLS: Instance Management Start up database, ou brspace – c force –f dbstart –s <state>. Para parar: Instance Management Shut down database, ou brspace –c force –f dbshut –m <mode>. Tipos de shutdown: - NORMAL: não aceita novas conexões, mas aguarda todos os usuários fazerem logout. Padrão do Oracle; - TRANSACTIONAL: não aceita novas conexões, aguarda transações atuais terminarem, mas não executa novas transações; - IMMEDIATE: não aceita novas conexões, não executa novas transações e faz roll back das transações atuais. Padrão do BRSPACE; - ABORT: não aceita novas conexões, não exeuta novas transações e cancela as transações atuais, sem roll back. Requer recovery (automaticamente executado) no próximo startup. O arquivo de parâmetros de inicialização tradicionalmente era em formato texto, com nome init<DBSID>.ora. a partir da versão 9i, pode-se manter em formato binário (SPFILE), com nome spfile<DBSID>.ora, ou spfile.ora. SPFILE é totalmente suportado a partir do BR*Tools 6.40 e a SAP recomenda usar SPFILE no upgrade para Oracle 9i. Quando um parâmetro é alterado no SPFILE, um init<DBSID>.ora é gerado automaticamente, permanecendo uma consistência entre eles. É recomendado criar e 96 guardar o SPFILE no local default do Oracle (ORACLE_HOME/dbs ou ORACLE_HOME\database). Quando uma instância é iniciada sem especificação de uma profile em particular, a ordem de pesquisa é: spfile<DBSID>.ora, spfile.ora, init<DBSID>.ora, init.ora. A inicialização com um spfile não padrão só é recomendado em casos emergenciais. Para modificar parâmetros do Oracle, via BRTOOLS acesse Instance Management Alter database parameters. Digite diretamente o parâmetro que quer alterar, ou “c” para continuar (pesquisa). Mensagens de informação, warnings ou erros são gravados em dump files. Os locais são definidos nos parâmetros: - BACKGROUND_DUMP_DEST (padrão: /saptrace/background): log de alerta (alert_<dbsid>.log), que loga eventos e mensagens de atividades, e traces em caso de erros; e - USER_DUMP_DEST (padrão: /saptrace/usertrace): traces escridos pelos shadow processes, quando ocorre problema com a conexão do cliente. Unit 2 – Backup, Restore & Recovery Backup Strategy A estratégia de backup deve ser adequada com as necessidades da empresa. Ela deve ser testada antes do GO Live e sempre após mudanças na mesma. O SAP oferece ferramentas para diferentes tipos de backup, como full online, incremental com RMAN, split-mirror. Devem-se manter pelo menos duas cópias dos offline redo logs em discos ou fitas. Ao se fazer point-in-time recovery, é necessário voltar toda a base, para manter consistência entre as tabelas. Desta forma, os dados entre o point-in-time e o momento em que a base foi desativada serão pedidos. Desta forma, point-in-time não deve ser a opção padrão para erros lógicos em produção. Pode-se ativar outra base com o backup e copiar os dados manualmente. O backup deve incluir verificação dos dados a sofrerem backup, bem como os dados nas fitas. Para verificar consistência no banco, um system check deve ser executado para descobrir data blocks corrompidos: - Corrupt Oracle blocks (erro ORA-1578) podem aparecer no banco devido erros de sistema operacional ou hardware; - Sem o check, os corrupt data blocks serão encontrados apenas no acesso aos mesmos; - base com corrupt data blocks sofre backup, porém o mesmo não pode ser usado. O check é recomendado uma vez por semana. Para verificar as fitas usadas pelo backup, executa-se o physical data check. Durante este check, as fitas são lidas e se a conexão com os dados é possível. No Offline backup, pode-se fazer um check para ver se os binários da fita são iguais aos do banco. Isto requer que a base fique desativada enquanto isso. No backup online, apenas verifica-se se os arquivos nas fitas podem ser lidos. Um cliclo de backup é o tempo em que o backup fica em fita. SAP recomenda o ciclo de backup de quatro semanas. O ciclo de backup do banco e dos offline redo logs deve ser o mesmo: - backup completo online todo dia útil; - backup completo offline uma vez no ciclo; - backup dos offline redo logs todo dia útil, bem como após backups online e offline. Gravar os offline redo logs em duas fitas diferentes antes de apagar do disco; 97 - fazer um logical check antes ou após o backup e pelo menos um physical check no ciclo (recomendado uma vez por semana); - retirar a fita do último backup offline do ciclo e guardar. Substituí-la por uma nova. A freqüência de backups completos se dá ao ponto de ter vários backups deste tipo disponível. Desta forma, evita-se perda de dados caso o último backup não esteja disponível. Executar backups adicionais após reorgs e upgrades, e guardar esses backups em longterm storage. O SAP usa dois programas para backup: BRBACKUP para backup e BRARCHIVE para offline redo logs. Desta forma, duas filas de fitas são necessárias e só poderão ser reusadas após o término do ciclo de backup. Se os dois backups forem feitos ao mesmo tempo, são necessárias duas fitas, ou seja, não é possível guardar na mesma fita duas execuções de backups. A quantidade de fitas necessárias é: - backup do banco: número de fitas necessárias para um backup completo e número de backups por ciclo; - backup de offline redo logs: média do número e tamanho dos offline redo logs e capacidade das fitas. Os backups padrões da DB13 (Whole database offline + redo log backup e Whole database online + redo log backup) faz o backup do banco e offline redo logs em uma execução. Desta forma, não é necessária duas filas de fitas, bem como os dois podem ir para uma fita apenas (se couber). É recomendado um acréscimo de 30% no número de fitas esperadas por ciclo, para caso de crescimento inesperado de banco ou offline redo logs. Tipos de backup: - Offline: o banco é parado antes do backup e os data files são copiados. Desta forma, não é necessário restaurar offline redo logs; - Online: o banco continua aberto durante o backup, então modificações podem ocorrer e é necessário aplicar offline redo logs após o mesmo. - Backup completo: - full (via RMAN): salva toda a base e o catálogo são salvos no control file, permitindo posterior backup incremental; - whole: toda base, porém não salva informações do catálogo. - Incremental Backup: backup somente dos data blocks modificados após último full. Todos os data blocks são lidos, então o tempo pode não ser reduzido: - só pode ser executado após um full; - controlado via RMAN; - via SAP tools, apenas acumulativo é suportado (é feito com base no último full); - via SAP tools, apenas o backup de todo banco é possível, não dá para selecionar apenas alguns data files; - Backup parcial: backup de apenas algumas partes do banco. A estratégia de backups pode conter backups incrementais ao invés de completos, economizando tempo de backup. Para recovery da base, é necessário o último full, restore do último parcial e os redo logs. Backup Tools and Tape Management O BRBACKUP faz backup dos data files, control file e online redo log, se necessário. É usado para backup do diretório do banco e do SAP. O BRARCHIVE faz o backup dos offline redo logs; 98 O BRRESTORE pode restaurar todos os arquivos do banco de dados: data files e offline redo log. O programa interativo BRRECOVERY verifica se arquivos do banco estão faltando, chama o BRRESTORE para restauração, executa o recovery e abre o banco. O BRBACKUP e o BRARCHIVE gravam as ações em arquivos de logs, que são analisados pelo BRRESTORE para restauração de arquivos inexistentes. O arquivo de configuração init<DBSID>.sap contém parâmetros para os BR*Tools. Itens mais importantes: - backup_mode: escopo do backup (all, full, incr...); - backup_type: offline ou online; - backup_dev_type: mídia do backup (tape, disk); - tape_copy_cmd: comando de cópia (cpio, dd recomendado, mais rápido que cpio); - disk_copy_cmd: comando de cópia para discos locais; - expir_period e tape_use_count: data de expiração da fita e quantidade de vezes que ela pode ser sobrescrita; - volume_backup e volume_archive: nome dos volumes para backup e archives; - tape_adress: endereço do drive de fitas. O Oracle Recovery Manager (RMAN) é o programa padrão para backup e restore. O BRBACKUP suporta o RMAN para backup de duas diferentes formas: - classificar um backup como completo (level 0) que servirá como base para um incremental (level 1); - dados podem ser escritos em fitas via RMAN, ao invés de comandos CPIO e DD. Se o backup é levado para fita via RMAN, este deve ser usado para restore e recovery, fato q é detectado pelo BRRECOVER. Caso este encontre algum problema, é necessário fazer o restore manualmente. Para copiar para a fita via BRBACKUP, escolha tape_copy_cmd como CPIO ou DD. Para deixar o controle com o RMAN, colocar valor rman. No caso do RMAN, na última etapa, o backup_mode é setado para full, RMAN escreve informações no control file e o CPIO copia o control file para a fita. O RMAN copia diretamente para disco, mas não para fita. Nete caso, ele necessita de uma biblioteca System Backup to tape (SBT), provida pela Oracle e que cada fabricante de fitas deve prover uma biblioteca. Antes de usar backup com RMAN, a biblioteca deve ser instalada: - caso não a tenha, o SAP instala automaticamente em /SYS/exe/run; - para usar um utilitário de backup externo, deve ser instalada a biblioteca SBT do mesmo. Oracle trás uma versão limitada single-server do Legato Networker. Para usar setar backup_dev_type para rman_disk ou rman_util. Vantagens de usar o RMAN: - todos blocks são verificados, procurando blocos corrompidos. Neste caso, o backup é consistente e futuros checks não são necessários; - apenas blocos usados são gravados (mesmo vazios, se já foram usados); - durante backups online, a tablespace é configurada para modo de backup, para evitar inconsistência. A partir do Web AS 6.10, RMAN também pode ser usado no BRARCHIVE, o que garante verificação interna de consistência nos offline redo logs. Quando se usa o RMAN, a biblioteca de backup SAP provê uma forma de otimizar o uso de fast tape drives, combinando vários data files em save sets. Neste caso, vários data files são lidos ao mesmo tempo, maximizando o fluxo de dados no modo streaming. Cada save set contém um header, um trailer e os blocos de pelo menos um data file. O parâmetro saveset_members, dentro do init<SAPSID>.sap permite os valores: 99 - 1,2,3,4: número de files que podem ser agrupados (default: 1); - tsp: um save set por table space; - all: um save set com todos data files. Usar save sets grandes ajuda a acelerar o backup, porém tem a desvantagem do restore/recovery se tornar mais lento. Todo o save set deve ser lido da fita. Backups para disco via RMAN (backup_dev_type = disk e disk_copy_cmd = rman), nenhum save set é formado. Data files são copiados diretamente para disco, como no uso dos comandos CP ou DD. Em outras palavras, uso de save sets só é possível quando uma SBT library é usada para backups incrementais. Se um backup via RMAN criará save sets com mais de um membro (saveset_members > 1) ou se usa tape stations com compressão e se quer levar em consideração a compressão para calcular o tamanho do save set, deve-se executar uma preparação para determinar a distribuição otimizada de tape sets. Esta preparação é executada via DB13 Prepare for RMAN Backup. Neste caso, o BRBACKUP inicializa o RMAN para backup dos data files. Nenhum backup é feito nesta etapa, o BRBACKUP apenas comprime os arquivos para estimar a taxa de compressão. O BRBACKUP determina quais data files são alocados nos save sets para cada valor possível do saveset_members, e calcula a taxa de compressão de cada save set. As informações de compressão e composição do save set são gravados no banco, para futuras utilizações. Essas informações não podem ser alteradas manualmente, apenas via uma nova preparação. Se durante um backup o RMAN identifica um data file não incluído na última preparação de execução, um novo save set é criado. É recomendado executar a preparação uma vez por ciclo, e após grandes modificações no banco. Um backup incremental é sempre um backup de todo o banco de dados, não de um individual data file. Ferramentas de sistema operacional não podem ser usados para cópia para fita, os parâmetros tape_copy_cmd ou disk_copy_cmd são ignorados e implicitamente alterados para rman. Após, completado o backup incremental, o control file é copiado para fita via CPIO. Apenas um save set “.INCR” é criado, uma vez que o parâmetro saveset_members é internamente setado para all. Desta forma, o backup pode ser feito em apenas uma fita. Se um data file foi criado entre o backup full e o incremental, um backup nível 0 é executado antes do início do backup nível 1. Todos novos data files são gravados em um novo file set “.FULL”. A volta de backup neste caso se dá em três passos: - volta os data files do backup nível 0; - os blocos alterados do backup de nível 1 podem ser importados no data file; - finalmente um recovery deve ser executado, do horário em que o backup nível 1 foi feito. Para facilitar a utilização de fitas para backup, o BRBACKUP e BRARCHIVE oferece um tape management system que: - ajuda a encontrar a fita correta para o backup; - ajuda a encontrar as fitas corretas para restore e recorver; - provê proteção às fitas contra sobrescrição acidental. Um pré-requisito é que se tenha duas filas de fitas: uma para BRBACKUP e outra para BRARCHIVE. 100 Durante a inicialização da fita, um arquivo é gravado primeiramente (.tape.hdr0), contendo o nome do volume. Pode ser especificada manualmente ou o BRBACKUP/BRARCHIVE seleciona da lista de nomes definidos no init<DBSID>.sap. Para inicializar tapes: BRTOOLS backup and database copy additional functions initialization of BRBACKUP (ou BRARCHIVE) tape volumes. Opções: - Initialize: rename (default) só pode ser inicializada após tempo de retenção; force inicializa mesmo assim; show exibe label; - Number: número de fitas a serem inicializadas (zero = todas); - Volume: nomes das fitas a serem inicializadas. Caso vazio, serão inicializadas as especificadas no init<DBSID>.sap. Após inicialização, a tape label contém o nome da fita, o nome da base que sofreu backup, o timestamp do último backup e o número de backups realizados por essa fita. Se o nome da fita está incorreto ou a fita está bloqueada, um erro é reportado. Se foi usada mais que o número de vezes especificado, um warning é gerado. No início do backup, o BRARCHIVE/BRBACKUP escreve o timestamp no header da fita. Adicionalmente, quando cada database file sofre backup com sucesso, informações sobre ele são escritas em um log (summary log e datailed log) e nas tabelas SDBAH e SDBAD. Desta forma, as ferramentas usam dois métodos de controle para verificar se a fita está bloqueada: - Physical lock: lê o tape label e verifica se o timestamp é maior que o expir_period (init<DBSID>.sap); - logical lock: lê o timestamp das tabelas SDBAH e SDBAD, a última fita usada e que não está no período de lock, é usada para o backup. Se o backup é finalizado antes que o primeiro arquivo possa ser gravado na fita, o volume é bloqueado fisicamente, mas não logicamente. Desta forma, deve-se fazer uma nova inicialização (force) da fita para cancelar o lock. Se um volume for reinicializado com force antes do período de expiração, o volume não está bloqueado fisicamente, mas logicamente. Desta forma, deve-se fazer o próximo backup com um volume chamado SCRATCH. Para permitir o BRBACKUP e BRARCHIVE escolherem a fita a ser usada de forma automática, os parâmetros volume_backup e volume_archive devem estar preenchidos. Além disto, não se deve especificar um volume na execução do backup (batch ou agendamento). Para verificar a próxima fita a ser usada, escolher um backup na DB13 e Goto Tapes needed. Via SO brbackup|bararchive –q|-query. Acrescentando parâmetro “check”, é realizado um physical tape check. Para executar um backup com qualquer fita, deixar o nome em branco. Executar um backup com um nome simbólico scratch desliga o gerenciamento automático de fitas. O BRBACKUP/BRARCHIVE faz apenas uma verificação de um physical lock. Pode ser usado, por exemplo, para criação de um backup mensal e não quer que ele seja gravado no pool de fitas. Executar um backup com um volume simbólico scratch, a próxima fita será renomeada para a requisitada. Lembrar: - volume = scratch: qualquer fita inicializada sem lock físico; - sem especificar volume name, mas uma fita com nome scratch, ela será renomeada para o próximo volume. 101 Para especificar uma fita a ser usada, especifique o nome na opção “volume” no BRTOOLS, ou opção –v|-volume <volume> no prompt. O physical tape check será realizado da mesma forma e fitas locadas são rejeitadas. Arquivos escritos pelo BRBACKUP e BRARCHIVE: - .tape.hdr0: tape label; - init<DBSID>.ora: arquivo de configuração do banco; - init<DBSID>.sap: arquivo de configuração do BR*Tools; - space<DBSID>.log: informação da criação, extensão ou reorganização de tablespaces ou tabelas (diretório sapreorg); - struc<DBSID>.log: histórico de mudanças estruturais no banco (diretório sapreorg); - <action_ID>.<function_ID>: log completo do BRBACKUP/BRARCHIVE; - back<DBSID>.log: sumário do BRBACKUP, lista de todos backups inicializados pelo BRBACKUP (diretório sapbackup); - arch<DBSID>.log: sumário do BRARCHIVE, lista de todos offline redo log files que sofreram backup pelo BRARCHIVE (diretório saparch). Os parâmetros tape_size e tape_size_arch especificam o tamanho da fita em GB, MB ou KB. Se o tape_size_arch estiver em branco, o valor é igual a tape_size. No início do backup, o BRBACKUP/BRARCHIVE verifica o tamanho total dos arquivos e planeja a distribuição nas fitas. Os arquivos nunca são quebrados, sempre são gravados em uma parte. Desta forma, o tamanho do maior arquivo (ex.: datafile) não pode ser maior que o especificado em tape_size. Os valores de tape_size e tape_size_arch devem ser menores que o valor da fita, uma vez que outros arquivos são copiados (ini files, logs, CPIO file headers). É recomendado deixar 10% do tamanho livre. Quando os arquivos são copiados para uma fita, não é verificado o espaço livre na mesma. O BRBACKUP chama outra fita e continua o backup. Já no BRARCHIVE, são copiados apenas os offline redo logs que cabem em uma fita. Caso o tamanho total exceda o parâmetro tape_size_arch, é necessária uma nova execução do BRARCHIVE. Com o parâmetro de inicialização “compress”, pode-se especificar quais arquivos serão comprimidos ou se compressão por hardware será levado em consideração quando planeja a distribuição dos arquivos em fitas: - compress=no: compressão por software não é usado. Compressão por hardware não é levado em conta; - compress=yes: junto com parâmetro compress_cmd e compress_dir, indica que haverá compressão por software; - compress=hardware: compressão por hardware deverá ser levado em conta (não ativa, apenas informa). Neste caso, tape_size contém o tamanho total de arquivos após compressão. No caso de compressão por hardware, BRBACKUP apenas estima a taxa de compressão. BRARCHIVE não usa compressão (1:1). Antes do backup com compressão por hardware, e uma vez por ciclo ou quando houver reorganização do banco, é necessário executar um copression run para determinar a taxa de compressão. Via DB13 compress database ou brbackup –k only. Como o valor de compressão pode variar e é apenas estimado, é recomendado usar o tape_size para um valor bem menor que o real, para evitar chegar ao final da fita. Para reduzir o risco na compressão por hardware, pode-se usar compress=no e tamanho da fita 2x o tamanho real, uma vez que a compressão geralmente é maior que 2:1. Os tools BRBACKUP, BRARCHIVE, BRRECOVER e BRRESTORE podem utilizar uma interface chamada BACKINT para acessar programas externos de backup. 102 Vantagens: - Pode-se usar mídias de backup específicas de um fabricante, como robôs e magnetoptical media; - pode-se fazer um backup consistente de file systems e banco de dados; - client/Server backup configuration permite uso de backup Server. De qualquer forma, o backup deve ser inicializado via SAP tools, para manter logs atualizados, monitoramento via CCMS e permitir restore/recover via BRRECOVER. Para configurar uma interface BACKINT, atribua ao parâmetro backup_dev_type para util_file ou util_file_online (coloca tablespace em backup mode) no init<DBSID>.sap e altere o parâmetro util_par_file para o arquivo de configuração do utilitário de backup. Para usar com RMAN, colocar backup_dev_type como rman_util, rman_disk ou rman_stage. Performing Backups O backup deve incluir todos objetos, como sistema operacional, arquivos do SAP e do software do Oracle. Geralmente sofrem backup via sistema operacional, uma vez por ciclo. Via RMAN as tablespaces não são colocadas no backup mode, uma vez que ele garante a integridade dos data blocs. Ordem de prioridade de parâmetros: command line/job/menu, depois arquivo init<DBSID>.sap, depois valores default. Não há transação SAP para alterar o init<DBSID>.sap. A forma recomendade de backup é via DB13, onde backups são agendados e executados na forma de Jobs (podem ser monitorados via SM37). Outra forma é agendamento via utilitário no sistema operacional (Cron/ task scheduler). Em casos excepcionais, pode ser executado via BRTOOLS. 103 Uma vez que o backup foi reportado como com sucesso, não quer dizer que ele está livre de erros. Para verificar: - Tape verification: verifica se o backup é passível de leitura, os arquivos são restaurados um a um e comparados com o original; - Databese block consistency: utilitário do Oracle DBVERIFY. Verifica bloco a bloco se estão consistentes. Caso contrário, deve-se voltar do backup. O offline redo log possui vários status durante a cópia para fita: - ARCHIVE: ainda não copiado; - SAVED: copiado para uma fita; - COPIED: copiado para segunda fita; - DELETED: após deleção. Durante cópia para disco: - DISK: ainda não copiado; - DISKSAV: savo em disco; - DISKDEL: deleção após salvo em disco. O parâmetro aconselhado para o BRARCHIVE (default na DB13) é –cds (copy_delete_save), que copia por uma segunda vez os redos com status SAVED e então apaga do disco. Redo com status ARCHIVE são sempre copiados para fita. Para definir “one-run strategy” de backup, escolha a opção –a|-archive do BRBACKUP. Depois dessa seleção, opções do BRARCHIVE serão apresentadas. Consistent online backups é executado via comando brbackup –t online_cons, e é inteiramente regido pelo BRBACKUP. Após a cópia de todos data files, é executado um log switch e o offline redo log gerado é copiado para a mesma fita, sem intervenção do BRARCHIVE. Ao término, summary e detail log são copiados. Normalmente é executado para salvar em long term tapes e recomendado antes de upgrades. Para verificar os logs dos backups: - DB14: DBA operations: logs de todas atividades de DBA; - DB13: DBA Planning Calendar: de acordo com a cor da execução: - DB12: apenas logs de backups, relatório de recover, status do diretório de archive e overview dos archived redo logs. Restore and Recovery Oracle cria sincronização usando timestamps. Timestamps são inteiros incrementados por certos eventos, como logwriter e checkpoint. Ex.: log sequence number (LSN) a cada log switch e system change number (SCN) a cada commit e checkpoint. Para analisar problemas no banco, verificar o alert log e trace files no diretório /saptrace/background. Faça um backup completo offline do banco corrompido antes de restaurar o backup. Isto é recomendado principalmente em point-in-time recovery ou database reset, que envolve perdas de dados. Da mesma forma, fazer um backup dos offline redo logs. Para testar a realidade da estratégia de backup, execute o Recovery report na transação DB12. Ele contém informações que podem ser usadas em caso de recovery. O report informa o último backup com sucesso, incluindo o tipo de backup e o nome da fita, qual backup deve ser usado para recovery e quais redo log files estão disponívels. O report também ajuda a detectar gaps nos backups: - redo log files que estão faltando; - se a lista de redo logs está grande, o tempo de recovery pode se tornar muito longo. Complete Database Recovery: usado para restaurar data files que estão faltando, e para restaurar a base até o status imediatamente anterior ao erro ocorrido. 104 Para sincronização, o Oracle utiliza informações salvas nos cabeçalhos dos arquivos. O banco requer todos os offline redo log files desde o último database file. Com o complete database recovery, todas as alterações são feitas novamente, desde que todos os arquivos tenham o mesmo SCN. Este procedimento é chamado de media recovery. Para realizar um Complete Database Recovery com o Brtools, acesse Restore and recovery complete database recovery. Fases: 1) Check the status of database files: verifica o status de todos os arquivos do banco, com ajuda das views V$, e escreve os logs no diretório sapbackup; 2) Select database backup: BRRECOVER determina os backups utilizáveis (código de retorno 0 ou 1) via log back<DBSID>.log. Data files ausentes podem ser recuperados de vários backups. Um backup incremental pode ser escolhido antes de aplicar os offline redo log files. Neste caso, o BRRECOVER escolhe o backup full correspondente. 3) Restore data files: BRRECOVER chama o BRRESTORE para restaurar os arquivos para o local de origem (o diretório sapdata não é criado automaticamente, mas os sub-diretórios sim); 4) Restore and apply incremental backup: se existir backup incremental, é aplicado nesse ponto; 5) Restore and apply archive logs: com base no arch<DBSID>.log, a lista de offline redo log files é montada. BRRECOVER chama BRRESTORE para restaurar os archivos da fita para o diretório oraarch. Finalmente o BRRECOVER chama o SQL*Plus para aplicar os offline redo log files. Eles são aplicados em grupos de 100. 6) Open database: BRRECOVER ativa a base e verifica o status dos arquivos e tabespaces. Point-in-time Recovery: usado para restaurar a base a em certo horário, com a ajuda de um backup completo. Point-in-time recovery sempre resulta em perda de dados. Quando a base é ativada, é usado o comando ALTER DATABASE OPEN RESETLOGS, o que reinicia os contadores de LSN. Desta forma, deve-se fazer um backup full antes de liberar para uso. O point-in-time pode ser usado para toda base ou só para umas tablespaces específicas (ex.: usando MCOD). Para executar via BRTOOLS, acessar Restore and recovery Database point-in-time recovery. Fases: 1) Set point-in-time for recovery: LSN, SCN ou horário específico; 2) Select database backup: BRRECOVER determina os backups utilizáveis (código de retorno 0 ou 1) via log back<DBSID>.log. Data files ausentes podem ser recuperados de vários backups. Um backup incremental pode ser escolhido antes de aplicar os offline redo log files. Neste caso, o BRRECOVER escolhe o backup full correspondente. 3) Check the status of database file: BRRECOVER verifica status de todos os arquivos e determina quais serão sobrescritos; 4) Restore control file: se necessário; 5) Restore data files; 6) Restore and apply incremental backup: se selecionado anteriormente; 7) Restore and apply archivelog files: BRRECOVER verifica no arch<DBSID>.log os offline redo log files necessário, chama o BRRESTORE para copiar da fita para o oraarch e chama o SQL*Plus para importar no banco. 105 8) Open database: abre o banco com opção RESETLOGS, cria arquivos temporários que estão faltando, verifica o status dos data files e tablespaces e remove arquivos desnecessários. Whole Database Reset: usado para restaurar a base para o momento imediatamente após o backup completo. Como o point-in-time recovery, database reset resulta em perda de dados. Para executar via BRTOOLS, acessar Restore and recovery Whole database reset. Passos: 1) Select consistent database backup: BRRECOVER determina backups que podem ser usados, com base no back<DBSID>.log. Se escolher um backup incremental, o backup full correspondente é escolhido para restaurar todos data files; 2) Restore control files and redolog files: sempre restaurados se um backup online é escolhido; 3) Restore data files; 4) Apply incremental backup: se escolhido; 5) Apply archivelog files: se escolhido online backup; 6) Open database: ativa o banco (se necessário com RESETLOGS), cria arquivos temporários que possam estar faltando, verifica o status dos data files e tablespaces, deleta aquivos desnecessários Disaster Recovery: usado quando não houver arquivos de controle e profiles de configuração. Pré requisitos: SAP e Oracle instalados, file system sapdata existe e configurado como antes do disaster. O disaster recovery é apenas um step anterior. O recovery é feito via point-in-time ou whole database reset. Para realizar o disaster database recovery, via BRTOOLS Restore and recovery Disaster recovery. Após restaurar o init<DBSID>.sap, o back<DBSID>.log é restaurado e o sistema conhece através de quais backups fará o restore. Outros profiles e logs podem ser restaurados através de uma lista. Na maioria dos casos, não é necessário mudar a seleção default, uma vez que o BRRECOVERY já determina quais arquivos devem ser restaurados. Na próxima seleção, Restore of BRBACKUP detail logs, a lista de backup detail logs é exibida para restore. Outras funções do BRRECOVER, não tratadas aqui são: - Restore of individual backup files: restaurar um arquivo de backup para restauração manual; - Restore and application of archivelog files: para recovery manual. Advanced Backup Techniques Algumas técnicas podem melhorar a estratégia de backup, mas em compensação exige esforços como: - Hardware; - Treinamento dos administradores; - Aumento na administração do ambiente. Split-mirror Disk Backup: algumas alterações são necessárias no init<DBSID>.sap e o BRBACKUP do servidor espelho deve enchergar o servidor de produção. Online: tablespaces em backup mode quebra do espelhamento produção sai do modo backup online backup no espelho resincronização. Offline: shutdown do banco quebra do espelhamento inicialização da base de produção offline backup no espelho resincronização do espelho. 106 SAP Tools and the Oracle Standby Database: o banco de dados de produção fica aberto, porém o standby em “mount” e frequentemente recebe os offline redo log files do de produção. No caso de falha do Server, este pode ser usado como produção. O backup é feito na base standby via BRBACKUP, backup_type = offline_standby, com ações registradas na SDBAH e SDBAD do servidor de produção, além do diretório sapbackup (devem estar acessíveis do standby Server). O BRARCHIVE roda nos dois servidores, sendo no Server colocando os archives em disco, e no standby lendo do oraarch e jogando em fita. Os redo são aplicados com a opção “-m | -modify <delay>”, onde delay é o tempo para atualização. Structure Retaining Database Copy: usado para criar uma base com outro DBSID no mesmo servidor, ou outra base com mesmo ou diferente DBSID em outro Server. Unit 3 – Monitors and Tools Introduction to Oracle Data Management Segment contém dados de uma tablespace. Existem 4 tipos de segumento: - Data; - Index: usado para acelerar o acesso e forçar unique constraint; - Temporary: usado para sorts e criação de índices; - rollback/undo: prover consistência, roll back ou undo e para recovery. Qualquer seguimento é guardado em uma tablespace, mas pode estar em vários data files. Para atender a demanda de bancos grandes, as tabelas e índices podem ser particionados, o que permite que dados possam ser quebrados em pedaços menores e mais maleáveis. Cada partição é guardada em seu próprio segmento, e gerenciada manualmente. SAP recomenda utilizar a mesma tablespace original. No SAP, um segmento possui todos os dados de uma tabela ou todos dados de uma partição de uma tabela particionada. Até a versão 4.6C, as tablespaceses eram divididas em system, rollback, temporária, dados por tipo de tabela (dados, máster data, pool, logs, etc.) e índices por tipo de tabela. As vantagens eram: data files poderiam ser guardados em discos diferentes (dependendo do uso) e a reorganização poderia ser feita em unidades menores. As desvantagens eram o aumento do trabalho de organização e baixa efetividade do armazenamento. A partir do AS 6.10: - SYSTEM: Oracle Data Dictionary; - PSAPROLL ou PSAPUNDO: rollback/undo; - PSAPTEMP: segmentos temporários; - PSAP<SCHEMA-ID>: objetos ABAP; - PSAP<SCHEMA-ID>USR: customer objects; - PSAP<SCHEMA-ID><REL>: dados dependents da release; - PSAP<SCHEMA-ID>DB: objetos do AS Java (AS 6.40 e mais novos). Através deste desenho, é possível utilizar o MCOD, pois além do desenho da tabela, a substituição do usuário SAPR3 por SAP<SCHEMA-ID> foi incorporada. Definições: - SAP SID: identificador do SAP System; - Database SID: identificador do banco de dados, pode ser diferente do SAPSID; - Schema ID: usado como identificador de parte de tablespace e do user SAP. Se MCOD não é usado, todos IDs devem ser iguais. Se é usado, o segundo SAP System deve ter um SCHEMA-ID diferente do DBSID. 107 O MCOD pode ser usado a partir do 4.6C SR2, e o BR*Tools pode ser usado em qualquer tipo de layout de tablespace (e sempre suportará). Convensões para os data files: - criado no diretório sapdata<n>, onde <n> é número da divisão da tablespace; - possui o nome da tablespace, sem PSAP e com final .data<n>. Se uma tablespace está cheia, três saídas podem ser adotadas: - criar um novo datafile; - data file pode ser aumentado; - o data file pode ser alterado para autoextensible. Ele crescerá até MAXBYTES em intervalos de INCREMENT_BY. Como o tamanho da base não é importante (salvo sistemas 32 bits), o número de data files deve ser em torno de 100, quando a base está no tamanho esperado. Neste caso, será múltiplos de 2Gb, sendo tamanho máximo/100: - Até 200Gb de banco: 2Gb por data file; - De 200 a 400Gb: 4Gb por data file... RAW devices são somente suportados em UNIX, e nesse caso o Oracle vai gerenciar o uso do disco. No uso de RAC, deve-se usar um cluster file system ou um RAW device, uma vez que existem várias instâncias acessando o mesmo datafile. Vantagens do RAW: I/O mais rápido, um pouco menos de espaço requerido, recovery mais rápido. Desvantagens do RAW: deve ser bem documentado, apenas um data file por raw device, backup somente via RMAN ou dd (ambos suportados pelo BR*Tools). Data-dictionary tablespaces eram usados no formato antigo de tablespaces, mas a SAP recomenta a conversão para gerenciada localmente (possível via reorganization). Cada segmento é formado por um ou mais extents (coleção de blocos alocados sequencialmente). O Oracle verifica e atualiza o dicionário de dados sempre que precisar alocar um novo extent. O tamanho do extent e outros parâmetros são chamados de storage parameters, e são guardados do dicionário de dados. Esses parâmetros são configurados na criação da tablespace, e podem ser sobrepostos na criação de uma tabela ou alterado via BR*Tools para as tabelas existentes: - MINEXTENTS: quatidade de extents alocados na criação da tabela; - INITIAL: tamanho do extent inicial; - NEXT: tamanho dos extents criados quando os anteriores estão cheios; - PCTINCREASE: não usado no SAP. Porcentagem maior do anterior a ser criado; - MAXEXTENTS: quantidade máxima de extents que podem ser criados. Desvantagens deste tipo de alocação de espaço: - deve haver área livre contínua maior que o NEXT. Pequenas áreas livres não são usadas neste caso; - quando um segmento é dropado, ele pode ser usado. Porém áreas livres subseqüentes não são aproveitadas como uma área grande livre, até execução do coalesce; - o administrador deve verificar se está perto de MAXEXTENTS. Para evitar erro (ORA-01553 maxextents reached), aumentar o tamanho de NEXT; - o parâmetro NEXT deve ser verificado freqüêntemente para evitar que cresça mais queo necessário para o período. O BRCONNECT pode ser usado para adaptar o NEXT extents. O BRSPACE pode ser usado para coalesce manual, e o brconnect –f ceck para coalesce de forma automática. 108 Locally Managed Tablespaces são usadas no novo layout MCOD. Cada data file tem um bitmap listando blocos usados e livres. O Oracle procura em cada data file se há espaço contínuo para alocar um novo extent. O tamanho do extent não é mais definido por parâmetro. Ele pode ser idêntico para todos extents (UNIFORM) ou escolhido de acordo com o tamanho do segmento (AUTOALLOCATE), escolhidos na criação da tablespace e não mais alterado posteriormente. SAP usa locally managed tablespace, com automatic extent allocation, exceto: - PSAPTEMP: UNIFORM; - PSAPROLL: dictionary-managed (substituída pela PSAPUNDO: UNIFORM); - Em sistemas SAP BW, tablespaces que contém tabelas de fatos ou agregamentos, devem ser criadas com uniform extent size de 1Mb. Vantagens: - adaptação de NETX ou MAXEXTENTS não é mais necessário; - devido ao tamanho máximo do extent ser 64Mb, menos fragmentação é causado e o espaço no data file é melhor gerenciado; - melhor performance em dropps ou criação de tabelas em paralelo, uma vez que não é necessário atualizar o dicionário de dados. Desvantagem: a busca por blocos usados e livres consome recurso. Além de guardar dados, o banco de dados Oracle deve prover: - consistência de transação; - consistência de leitura: outras transações devem ler dados ainda não alterados (antes de commit ou deletes). Para prover esse tipo de consistência, Oracle provê rollback segments em uma tablespace de rollback, ou, a partir do Oracle 9i, undo segments em undo tablespace. Quando um dado é alterado, antes ele é levado para um segmento de rollback (ou undo). Se for feito rollback, os blocos voltam do segmento de rollback (ou undo) para o local de origem. Se antes do commit ou rollback outro comando selecionar esses dados, eles são lidos do segmento de rollback (ou undo). SAP utiliza tablespace de rollback até a versão 6.20. É recomendado mudar para undo tablespace quando usando Oracle 9i, pela facilidade e novos recursos. Rollback tablespace: o gerenciamento de extents é similar ao da dictionary-managed tablespace, porém com a adição do parâmetro OPTIMAL. Quando uma transação sofre commit, o extent é marcado para sobreescrito. Em certos casos, o Oracle redimensiona a tablespace para seu tamanho OPTIMAL. Desvantagens: - parâmetros devem ser experimentados até chegar a um bom valor, pois depende do tamanho e uso do sistema; - como o Oracle pode escolher qualquer segmento de rollback, os parâmetros devem ser alterados para todos os segmentos de rollback; - em caso de grande movimentação de dados, a SAP recomenda criar outra tablespace de rollback. Undo Tablespace: a partir da versão 9i a Oracle introduziu o automatic undo management (AUM). Vantagens: - gerenciados automaticamente; - uma transação pode usar mais de um undo segment; - o tempo em que um segmento pode ser sobreposto não é mais o commit, e sim o tempo definido em undo_retention, evitando o erro ORA-01555; 109 - alterar para undo tablespaces grandes, para grande movimentação de dados, é mais fácil. Parâmetros adicionados: - undo_management: MANUAL ou AUTO (para ativar); - undo_tablespace: comando CREATE UNDO TABLESPACE „PSAPUNDO‟; - undo retention: tempo de retenção em segundos, antes que o dado possa ser sobreposto; - undo_supress_errors: suprime os erros ao tentar mudar manualmente. Passos para alterar de rollback para undo: 1) Criar tablespace PSAPUNDO; 2) Alterar ou inserir os 4 parâmetros; 3) Drop em todos os segmentos de rollback (exceto no SYSTEM); 4) Remover ou comentar o parâmetro rollback_segments; 5) Remover a tablespace de rollback Database System Check O BRCONNECT é usado para verificar o banco de dados, adaptar NEXT extents, criar estatísticas e apagar DBA logs. Checking the Database Para fazer o check do banco de dados, o BRCONNECT verifica as condições na tabela DBCHECKORA. O log é criado /sapcheck/c<encoded_timestamp>.chk, e pode ser visto via editor de textos, BRTOOLS ou DB14. Erros e warnings podem ser vistos ainda na DB16 e CCMS. Pode ser executado via BRTOOLS Check and verification Database system check ou comando brconnect –f check. Para atualizar os parâmetros, acessar DB17: - adicionar novas condições DBO, ORA ou PROF; - excluir condições do check; - especificar valores padrão; - criar condições para serem excluídas do check; - criar condições para definir valores padrões; - especificar ações de correção; - manter descrições das condições. Tipos de verificação na tabela DBCHECKORA: - Database administration (DBAs): operações de administração, como configuração, gerenciamento de espaço. Não podem ser adicionados. Para excluir, usar parâmetro check_exclude do init<DBSID>.sap; - Database operation (DBO): verificações de operação, como backup e falhas; - Oracle messages: o arquivo e log é verificado em busca de erros. - Oracle profile parameters (PROF): verificação de parâmetros do profile. Adapting the NEXT Extent Size Brconnect –f next deve ser executado regularmente para adaptar o parâmetro NEXT de todas as tablespaces gerenciadas por dicionário para evitar: - ter vários pequenos segmentos (degrada performance, perto do limite de MAXEXTENTS); - ter segmentos muito grandes (perda de espaço em disco, fragmentação, tablespace overflow). Objetos em tablespaces localmente gerenciadas são automaticamente excluídos. Comando normalmente utilizado: brconnect –u / -c –f next –t all 110 O algorítimo utilizado para determinar o valor otimizado para NEXT garante que NEXT é: - não é valor menor que o valor atual e como especificado no SAP data dictionary para este tipo de tabela ou índice; - em torno de 10% do tamanho total da tabela ou índice, se o tamanho é maior que o esperado; - menor que a maior área livre contínua da tablespace, se esta não é auto-extensível. O log é guardado em /sapcheck, com extensão .nxt e pode ser visto da mesma forma que o log da database system check. Checking and Updating Database Statistics Oracle usa otimizador baseado em custo para encontrar o melhor caminho quando selecionando tabelas. No SAP, o parâmetro optimizer_mode é configurado para CHOOSE, o que indica que o Oracle usará o otimizador baseado em custo quando estatísticas estão disponíveis. Isto porque algumas tabelas sofrem alterações de dados frequentemente, e não devem ter estatísticas geradas. Para fazer o update statistics, executar brconnect –f stats, que verificará se as estatísticas estão desatualizadas e atualizará as necessárias. SAP recomenda a execução de brconnect –u / -c –f stats –t all semanalmente. Pode ser agendada via DB13. Para atualizar apenas as tabelas que não possuem estatísticas (ex.: recém criadas): brconnect –f stats –t missing, ou DB20 Global statistics Create missing. O log é gerado em sapcheck, com a extensão .sta, e pode ser visualizado como no database system check. Cleaning Up Old Logs and Traces Para limpar logs e arquivos intermediários (como backups), execute brconnect –f cleanup, que limpará: - Logs detalhados do BR*Tools; - Backups em disco; - Export dumps e scripts criados pelo BRSPACE; - log records e check results nas tabelas SDBAH, SDBAD, DBA*, e DBMSGORA; - Oracle trace e audit files. Comando normalmente executado: brconnect –u / -c –f cleanup Por padrão, arquivos anteriores a 30 dias e database log records anteriores a 100 dias são removidos. Esses valores podem ser alterados via parâmetros específicos no init<DBSID>.sap. Checking Database Growth Os dados estatísticos sobre o crescimento do banco podem ser visualizados via DB02. A tela de entrada mostra um sumário das informações do tamanho do banco de dados e espaço livre. Para mais detalhes, selecionar os botões: - Space statistics: estatísticas do espaço de toda a base; - Current sizes: tamanho e status de tablespaces e tabelas; - Space statistics: estatísticas de espaço por tablespace; - Freespace Statistics: informações detalhadas do espaço livre nas tablespaces, incluindo fragmentação; - Space critical obects: todos os segmentos que o next extent é maior que a maior área livre. 111 Para coletar estatísticas do banco de dados, SO e SAP, e guardar os dados em tabelas, o job COLLECTOR_FOR_PERFORMANCE_MONITOR deve estar agendado em freqüência horária, executando o ABAP report RSCOLL00. O report RSCOLL00 lê a tabela TCOLL para ver o que será verificado e em que horário. O report coleta as informações e guarda nas tabelas MONI (dados estatísticos) e PAHI (parâmetros). CCMS Alert Monitor O CCMS pode ser usado para monitorar e verificar as seguintes funções: - Space Management: tablespaces e segments; - Performance: otimizador de estatísticas, buffers, logs e checkpoints; - Backup or restore; - Consistency: entre objetos ABAP e dicionários do Oracle; - Health: system checks do BRCONNECT. O principal coletor de informações sobre o banco é o BRCONNECT, que escreve os resultados na DBMSGORA, lida pelo CCMS. Os MTEs na RZ20 podem ser removidos, após alteração de parâmetros na DB17. Após remoção, executar programa RSDBMON0 para recriá-los, com as novas configurações. Para evitar acessos excessivos à view DBA_SEGMENTS, é necessário executar o brconnect –f check uma vez por dia. Caso os dados sejam mais antigos que um dia na DBMSGORA, os dados serão exibidos da DBA_SEGMENTS. Unit 4 – Storage Management Tablespace Administration Em operação “normal”, a criação de uma nova tablespace ou a remoção de uma existente não é necessária. Este é ocaso de upgrade e preparação de uma reorganização online. Para criar uma nova tablespace, acessar BRTOOLS Space management Create tablespace. Opções: - tablespace: nome da tablespace, seguindo padrão SAP (PSAP<SCHEMA-ID><unique name>; - contents: data (dados + índices), temp ou undo; - space: auto (gerenciamento de espaços de segmento automático) ou manual. Sempre é criado locally managed tablespaces; - owner: só em casos de MCOD; - data: table, índex ou both (recomendado para facilitar administração); - joint: se escolheu table ou índex acima, especificar a tablespace de índice ou tabelas correspondente. Após o continue, um novo menu é apresentado: - file: o nome do novo data file para a tablespace; - size: em MB; - autoextend: Yes (cresce automaticamente) ou no; - maxsize; - incrsize. Antes e a pós a criação, um backup do control file é criado em /sapreorg, além de log da operação em /sapreorg/struc<DBSID>.log. Para remover, BRTOOLS Space management Drop tablespace. Por padrão, uma tablespace não é apaga se não estiver vazia. O parâmetro force = Yes altera isso. O BRSPACE vai: 112 - criar um backup do control file antes de após a remoção; - verificar se a tablespace está vazia; - torná-la offline; - removê-la, inclusive seus data files; - remover todos os subdiretórios; - criar uma entrada no log struc<DBSID>.log. Para aumentar uma tablespace, três opções são possíveis: - adicionar novo data file; - as propriedades do data file pode ser mudada para “autoextensible”; - o data file pode ser aumentado. Para adicionar um novo datafile, BRTOOLS Space managment Extend tablespace. O menu é similar ao de criar uma tablespace nova. Para alterar um data file para autoextensible, acessar BRTOOLS Space management Alter data file Maintain autoextend. É possível alterar maxsize e incrsize nessa função. Para alterar o tamanho de data file, BRTOOLS Space management Alter data file Resize data file. Para mover ou renomear um data file, o BRSPACE o faz somente com padrão de nomenclatura SAP. BRTOOLS Space management Move data file. Opções: - Destination; - parallel: se foi selecionado mais de um data file; - force: força o shutdown do banco mesmo que o SAP esteja ativo. Para exibir informações de uma tablespace: BRTOOLS Space management Additional space functions. Para alterar uma tablespace: BRTOOLS Space management Alter tablespace: - Set tablespaces offline ou online; - Set ou reset the backup status: quando o BRBACKUP apresenta erro, uma ou mais tablespaces podem ficar em status backup mode. Neste caso, um shutdown não funciona e se for um shutdown abort, é necessário recovery manual. - Coalesce free extents Reorganization of Tables Reorganização é normalmente utilizada para retirar a fragmentação de objetos do banco. Executando ela, melhora-se a performance e recupera-se espaços fragmentados. O modelo clássico é: - export das tabelas; - drop das tabelas (e tablespace); - recriação da tablespace (se foi removida); - import das tabelas. Nas versões de Oracle 8 e 9i, junto com a evolução de discos e RAID, novas características foram introduzidas, diminuindo a necessidade de reorganizações: - locally managed tablespaces possuem alocações mais eficientes; - usando automatic segment space allocation, a fragmentação de blocos é significadamente reduzida e a performance de queries em paralelo melhorada; - discos grandes com RAID e buffers maiores e mais seguros diminuem o I/O. Usando as facilidades de redefinição online do Oracle, a reorganização (online table redefinition) ocorre de forma mais fácil. Vantagens e características: - pode ser feita online; - pode ser paralelizado; - pode ser usado para mover tabelas para outras tablespaces; 113 - pode ser usado para recriar uma tabela, reduzindo fragmentação; - diminui o risco, onde verificações são feitas antes do processo e a remoção do objeto apenas após a criação do mesmo. Razões para desfragmentação no Oracle 9i: - tabelas fragmentadas e índices fragmentados ou degenerados; - transformar dictionary-managed em locally managed tablespaces; - mover tabelas para novas tablespaces. BRSPACE suporta online table redefinition e métods tradicionais de reorganização. BRTOOLS Segment Management. Opções: - Reorganize Tables: redefinição online, usado para diminuir fragmentação, transformar dictionary-managed tablespaces em locally managed, transformar tablespaces do layout tradicional em layout do MCOD, mover tabelas grandes para uma tablespace separada. - Rebuild indexes: recriar índices; - Export e Import tables: método tradicional de reorganização. Usado em Oracle 9i em tabelas com campos LONG ; - Alter tables e indexes: algumas funções de performance, como “switch on table monitoring”, onde o Oracle controlará se a tabela foi alterada (acelerando consulta para update statistics) e “set parallel degree”, para prover performance em INSERTs (com o aval da SAP, não usado em produção). Passos do online table redefinition: - BRSPACE usa o PL/SQL DBMS_REDEFINITION; - tabelas são verificadas se podem ser redefinidas online; - cria uma tabela temporária, com nome <ORIGINAL>#$; - copia os dados para a temporária, pode ser paralelizado; - cria índices, contraints, triggers, etc.; - termina o processo com o pacote DBMS_REDEFINITION; - objetos criados são renomeados; - BRSPACE apaga a tabela temporária. Em caso de erros, a tabela original permanece intacta, e o BRSPACE apaga a tabela temporária. Antes de iniciar a reorganização usando online table redefinition, verifique: - se vai mover para nova tablespace, ela existe? - tablespace é locally managed? - há espaço na tablespace/disco? Para reorganização, BRTOOLS Segment management Reorganize tables. Pode-se usar caracteres para tabelas ([<owner>].<prefix>* ou *), especificar a tablespace (todas tabelas sem LONG sofrerão reorg) ou deixar em branco (serão apresentadas as tabelas). O parâmetro reorg_table no init<DBSID>.sap pode ser usado para informar quais tabelas sofrerão reorg. Os parâmetros para reorganização são: - newts: nova tablespace ou vazio para atual; - indts: tablespace de índice (se diferente da de tabelas); - parallel: paralelismo; - degree: paralelismo de cópia para as tabelas temporárias; - ddl: NO (comando DDL gerado apenas internamente, não recomendado), YES (gera ddl.sql em /sapreorg), FIRST (gera o ddl.sql e aguarda confirmação antes de executar). Para recriar índices, acessar BRTOOLS Segment management Rebuild indexes. As opções são similares à de reorganização, porém não é Criado DDL (é usado o comando ALTER INDEX REBUILD ONLINE), especificando a tabela, todos índices dela serão recriados e uma nova tablespace para os índices pode ser informada. 114 O BRSPACE suporta o método tradicional EXP/IMP, porém só é recomendado para tabelas que não podem sofrer redefinição online. Além do utilitário, vários passos devem ser feitos manualmente. Para transformar uma tablespace gerenciada pelo dicionário de dados em localmente gerenciada, faz-se a online reorganization em uma nova tablespace, com os passos adicionais: 1) Criar uma tablespace localmente gerenciada, que conterá dados e índices. Recomenda-se que seja auto-extensível; 2) BRTOOLS Segment management Reorganize tables, escolha a tablespace e coloque “*” para as tabelas; 3) Continue e confirm; 4) Em “Options for reorganization of tables, defina o nome da nova tablespace. Tabelas que não podem ser reorganizadas online permanecerão na tablespace antiga. Neste caso: - utilizar export / import após a reorganização; - assim que possível, usar o BRSPACE para converter LONG em LOB antes da reorganização. Housekeeping and Troubleshooting Revisão das atividades: - Database System check deve rodar diariamente, agendada via DB13. DB14 deve ser verificada para warnings/erros. Warnings e erros devem ser solucionados; - Check and adapt NEXT extents: executar semanalmente, agendada via DB13. Verificar logs na DB14; - Update optimizer statistics: deve rodar semanalmente, agendada via DB13. Verificar logs na DB14; - Clean up old logs and traces: deve rodar semanalmente, agendada via DB13. Verificar logs na DB14. Archiver stuck ocorre quando não é possível copiar o online redo log e o LGWR necessita sobrepor este arquivo. Isto normalmente ocorre quando o disco do diretório de archive está cheio. Para evitar, recomenda-se: - ter bastante espaço no diretório de archives, pelo menos 3x o tamanho diário esperado; - criar um arquivo dummy 10x maior que um archive. Assim ele pode ser apagado, o sistema volta a funcionar e rotinas como backup de offline redo log files podem ser executadas; - usar o diretório de archive em uma unidade diferente de onde o BRARCHIVE guarda os logs. Quando ocorre erro durante o backup online, algumas tablespaces podem ficar em estado de backup. Para verificar, executar brspace –c force –f dbshow –t tslist. Neste caso: - Verificar no sistema operacional se o BRBACKUP está em execução; - BRTOOLS Space management alter tablespace Reset backup status; - coloque 0 para selecionar todas tablespaces; - remover arquivo /sapbackup/.lock.brb; - executar um teste de backup para ver se está OK. Caso o banco tenha caído durante o backup, o erro ORA – 01113: file N needs media recovery. Um recovery pode ser necessário: - brrecover –c force –t complete; ou 115 - via SQL*Plus: ALTER DATABASE END BACKUP, em que o recovery não é executado (somente se um data file não precisou ser restaurado). Unit 5 – Introduction to Oracle cache management Oracle System Global Area Em sistemas SAP, o único usuário que deve acessar o banco é o administrador do banco. Terminologia: - database: coleção de dados, logicalmente formam uma unidade, fisicamente um ou mais datafiles. Um objeto do banco de dados (ex.: tabela) está em uma tablespace (unidade lógica), que pode ter um ou mais datafile. - Instance = memory + processes: - memory: shared memory = system global area (SGA). Cada instância possui sua própria SGA, que não é compartilhada com outras instances. - processes: processos background. No Unix se vê processo a processo, no NT apenas um “Oracle” (usa threads). - DBSID: identificador do banco de dados, nome único, no caso da SAP com 3 caracteres (upercase, sendo primeiro obrigatóriamente letra, os outros 2, letras ou número). Listerner não faz parte da instância, faz parte de processos de rede. Cada work process se comunica com um shadow process. O work process se conecta automaticamente após queda/startup do banco. O gerenciamento de memória separa área de memória que pode ser usada por todos os processos (SGA) ou para cada processo individualmente (PGA) – parâmetros em bytes: - SGA (System Global Area ou shared memory): - Buffer Pool (Data Buffer ou Buffer Cache): buffer para data blocks (DB_BLOCK_BUFFERS em blocos ou DB_CACHE_SIZE usando dynamic SGA); 116 - Shared Pool: buffer para comandos SQL (Shared SQL Area, Shared Cursor Cache ou Library Cache) e informações do dicionário de dados (Dictionary Cache ou Row cache). Parâmetro SHARED_POOL_SIZE; - Java Pool: cache para java (JAVA_POOL_SIZE); - Large Pool: buffer para dados especiais (multi-thread, RMAN com vários I/O, PL/SQL, etc.). Parâmetro LARGE_POOL_SIZE; - Redo Buffer: buffer para redo log (LOG_BUFFER). - PGA (Program Global Area ou process-local memory): buffer para sorting, hash joing e outras atividades temporárias (PGA_AGGREGATE_TARGET quando usa automatic PGA administration). Parametrização do SAP: - Buffer pool: grande o suficiente para a qualidade ser maior que 95%; - Shared pool: pelo menos 400Mb; - Java Pool: se não usado, valor 0; - Large Pool: não necessita configuração, pois usa pouca memória; - Redo buffer: bom valor: 1Mb, não deve ser excedido; - PGA: valor máximo que conseguir. Até oracle 8.1.7.* as áreas de memórias não eram mudadas dinamicamente. A partir da versão 9, com a opção Dynamic SGA, o boot não é requerido. Multiple Block Sizes para tablespaces não são recomentadas pela SAP. Parâmetros para Dynamic SGA: - SGA_MAX_SIZE: tamanho máximo em que a SGA pode crescer automaticamente (soma dos parâmetros das subáreas da SGA); - DB_CACHE_SIZE: tamanho do buffer cache, e que ativa o Dynamic SGA. Não usar junto com DB_BLOCK_BUFFERS (Oracle 8i e menores); Parâmetros que podem ser alterados dinamicamente quando ativo o Dynamic SGA: - DB_CACHE_SIZE: buffer cache; - SHARED_POOL_SIZE: shared pool; - LARGE_POOL_SIZE: large pool. Parâmetros não alterados dinamicamente: - SGA_MAX_SIZE: tamanho máximo da SGA; - LOG_BUFFER: tamanho do redo log; - JAVA_POOL_SIZE: java pool. Shared Pool - shared SQL area: SQLs parsed, com o plano de execução. Quando já existe o comando na shared SQL area: soft parse. Quando não existe, e precisa consultar o dicionário de dados: hard parse. SQL executado tem na shared? Se não parse e salva na shared recupera dados e armazena na shared pool. - Data Dictionary cache (nomes, definições, acessos, segurança...). Execução do SQL: 1) Declare: substitui o SQL por variáveis: select * from mara where mandt=:A0 and matnr=:A1. Shadow Process allocates memory areas from PGA; 2) Prepare: determina o plano de execução; 3) Open: substitui variáveis pelos valores: select * from mara where mandt=‟100‟ and matnr=‟4711‟ 4) Fetch: retorna os dados da consulta. 117 Oracle Program Global Area Program Global Area = Process Global Area = work area. Optimun: comando feito sort na PGA. Ideal > 90% (OLTP); One-pass: acessa tabela temporária para fazer 1 nível de sort (separa em “blocos” de sort e depois junta tudo no banco). Ideal < 10% (OLTP); Multi-pass: necessita criar vários níveis de sort até chegar no resultado esperado. Não deve ocorrer. No Oracle 8i: SORT_AREA_SIZE HASH_AREA_SIZE BITMAP_MERGE_AREA_SIZE BITMAP_CREATE_AREA_SIZE Parâmetros estáticos. No Oracle 9i: WORKAREA_SIZE_POLICY = AUTO PGA_AGGREGATE_TARGET = 100MB Define-se o tamanho total da PGA da instância, e o Oracle gerencia de forma automática como deve ser. O parâmetro é dinâmico, ou seja, pode ser alterado em runtime. O Oracle avalia toda a memória disponível na PGA, a quantidade que o comando precisa e aloca a memória necessária. O Oracle calcula, em regra geral (9i): - máximo 5% para Shadow Process; - máximo 30% para processo paralelos da Shadow Process; - máximo 200Mb para Shadow Process. Cálculo estimado para a PGA: PGA_AGGREGATE_TARGET = <memória física > * 20% (OLTP); PGA_AGGREGATE_TARGET = <memória física > * 40% (OLAP); PGA_AGGREGATE_TARGET = (SORT_AREA_SIZE + HASH_AREA_SIZE + ...) * (#Shadow process / 10). Unit 6 – Monitoring of the database instance The New Oracle Database Monitor provided by SAP A nova transação ST04N pode ser usada para monitoramento do Oracle, seja ele single ou RAC. Ela substitui a antiga ST04 e busca informações das views V$, GV$ (existe apenas no RAC) e DBA. A nova transação é apenas para Oracle 9i+. Para utilizar a funcionalidade da nova transação, é requirido: - parallel_min_servers pelo menos 10; - executar alguns scripts para criar tabelas de históricos, views e sinônimos utilizados; - para ter dados históricos, o report “RSORAHCL” deve estar agendado. Main monitor: - data buffer quality: proporção das leituras físicas em relação ao total de leituras. Deve estar acima de 94% em um total de 15 milhões de leituras; - ratio of user and recursive calls: uma boa performance indica proporção maior que 2; - number of reads per user call: se exceder de 30, pode indicar expensive SQL; - Time/User Call: valores acima de 15 ms indicam necessidade de otimização; - Busy wait tine X CPU time: valores em torno de 60:40 indicam um sistema estável. Valores muito acima indicam necessidades de melhoria; - DD-cache quality: deve estar acima de 80%. Além dos menus, a ST04N povê submonitores para informações detalhadas: 118 - Overall Activity: - Buffer busy waits: indica que há buffers em que vários processos tentam acessar de forma simultânea; - File system requests (GV$FILESTAT): data files mais utilizados; - System/wait events (GV$SYSTEM_EVENT): wait events; - Undo statistics (GV$UNDOSTAT); - Automatic segment space management: verifica o ASSM do banco; - Online redefinition tables; - Resumable space allocation; - Parallel query (V$PQ*): ocorrência de queries em paralelo, que são úteis em caso de full table scans, etc. - Resource Consumptions: - Oracle Session Monitor: lista as sessões do oracle, pode-se ver o plano de execução de um SQL; - SQL request: acesso a SQLs processadas no banco de dados; - Top SQL statements: informações da instância e dados históricos; - Table Access monitor: shared cursor cachê pelo ponto de vista das tabelas acessadas; - Latch monitor: atividades de uso exclusivo de recurso; - PGA monitor: monitora a PGA; - SGA monitor: monitora a SGA. - Exceptional Conditions: - enqueue monitor: monitoramento das filas; - Lock monitor: monitora os locks ativos; - Database message log. - Additional Functions: - Display V$/GV$ views and values: acesso a views de performance; - Parameter configuration: parâmetros do SPFILE ou init<sid>.ora; - arbitrary monitoring; - System statistics for CBO; - Checkpoints; - Data guard: monitora a funcionalidade de data guard do Oracle; - State on disk: chama DB02. As novas funcionalidades do Oracle 9i suportadas pela SAP são: - uso do SPFILE; - Automatic Undo Management (AUM); - Automatic segment space management (ASSM), que provê um uso melhor de espaço, reduzindo buffer busy waits; - Dynamic System Global Area: permite alterar parâmetros de buffers online; - Automatic Program Global Area memory management; - Online reorganization of tables: também possível no 8i; - Defaul temporary tablespace: a partir do AS 6.40, tablespace PSAPTEMP é a tablespace temporária padrão, não usando a SYSTEM para isso; - Locally managed SYSTEM tablespace; - Suporte ao RAC. Snapshots = dados históricos. Dados históricos do SAP são guardados na tabela MONI; Dados históricos do banco são gravados em tabelas GVD*, atualizadas via report RSORAHCL (ou RSORAHIST). 119 Oracle Wait Interface Determinando o Wait Event, é possível saber o que a sessão está fazendo, ou o que está esperando. Se um processo demora muito tempo, analisando os wait events é possível saber quanto desse tempo é perdido com full table scans, leitura de discos causadas por idex lookups, etc. A análise detalhada é muito usual, uma vez que o tempo de resposta geralmente é determinado pelo tempo de espera no framework de wait events e o consumo de CPU. Em sistemas otimizados, wait events consome na faixa de 60% do tempo de resposta. Analisando os wait events acumulados desde o startup do banco, é possível saber o nível de otimização possível e onde é necessário focar. Total wait time = idle wait time (não há o que fazer) + busy wait time (espera por um recurso). Busy wait mais comuns: - dB file sequential read: aguardando blocos paralelos serem lidos do disco; - dB file parallel read: esperando por blocos a serem lidos paralelamente do disco; - dB file scattered read: aguardando por vários blocos serem lidos do disco; - log file sync: aguarda enquanto LGWR escreve dados do redo buffer, após commit ou rollback; - log buffer space: aguardando espaço livre no redo buffer; - log file switch: aguardando switch do relo log file; - log file parallel write: LGWR aguarda por blocos a serem escritos no disco; - Buffer busy waits: aguardando um bloco que está sendo carregado ou alterado por outra sessão; - write complete waits: aguardando o DBWR escrever um bloco no disco; - enqueue: aguardando um lock do Oracle; - library cachê pin / library cache lock: aguardando acesso exclusivo a dados no library cachê (Shared SQL Area); - row cachê lock: aguardando por um acesso exclusivo no row cachê; - db file parallel write: espera do DBWR, enquanto blocos são escritos no disco; - direct path read: aguardando enquanto está lendo buffers do disco para o PGA; - direct path write: aguardando enquanto escreve buffers da PGA pro disco; - free buffer waits: procurando por buffer blocks livres. Quando um processo está busy, não há informações no wait event interface. A wait event information provida pelo Oracle provê informações detalhadas de quanto tempo e quantas vezes foi necessário esperar por um determinado evento. Não são gravadas informações de uso de CPU, desta forma não é possível saber o tempo de espera por uma CPU, o tempo de uso de uma CPU e o tempo da memória sofrer swap de volta à memória física. Quando o acesso a um data block é feito diretamente ao buffer cachê, uma leitura lógica ocorre sem leitura física. Desta forma, o processo consegue ler o bloco sem wait event. A interface do Oracle para wait events, consiste de 4 views: - V$SYSTEM_EVENT: wait events acumulados no sistema desde que a base foi inicializada: uma linha para cada evento, o número de vezes que um processo esperou por esse evento, o numero de timeouts, o tempo total esperado e a média de tempo; - V$SESSION_EVENT: wait events acomulados por sessão desde que a base foi iniciada: dados semelhantes à V$SYSTEM_EVENT, porém por sessão; - V$SESSION_WAIT: wait events atuais: processo, quantas vezes entrou em wait e o estado atual (se STATE for Waiting, espera por evento, caso contrário está processando); 120 - V$EVENT_NAME: nome e parâmetro dos wait events, exibe uma linha para cada wait event conhecido pelo banco de dados Oracle. Para evitar acesso direto ao banco, ST04N Detail analysis menu Additional Functions display V$/VG$ views and values. Se a proporção é 60% Wait time para 40% CPU Time e o sistema está lento, expensive SQLs devem ser monitorados. Se é mais de 60%, os wait events devem ser tunados. Se é menos, a CPU deve ser tunada. Os wait events mais importantes podem ser monitorados no SAP/Oracle Database Monitor, no submonitor “System / Wait Events”: - Busy waits summary: mostra um resumo dos busy waits dependendo do tipo de processo (Background / user); - Wait event details: mostra detalhes de cada wait event. Apenas eventos de processos non-idle são listados; - GV$SYSTEM_EVENT: mostra os dados da view no banco, interessante somente em RAC. Para achar eventos com alto potencial de otimização, escolha o TOP 5 non idle events que mais influenciam na performance. DB file sequential read, significa que está aguardando parallel blocks serem lidos do banco. De regra geral, não deve exceder 20ms na V$SYSTEM_EVENT (ou 15ms para read-write-cache-memory). Usando a V$FILESTAT, verificar quais data files possuem pior acesso e movê-los. Usar tempos anteriores para comparação de queda de desempenho. Além do tempo, a quantidade é importante, demonstrando baixo hit rate do buffer pool, expensives SQLs e necessidade de aumento do DB_CACHE_SIZE. DB file scattered read, significa esperar que vários blocos sejam lidos do disco. É causado por full table scans e mais raramente por índex fast full scans, que devem ser evitados em sistemas R/3. Buffer busy waits, significa que está aguardando um bloco ser importado ou alterado por outra sessão. Esse valor não deve exceder 40ms na V$SYSTEM_EVENT (ou 15ms para read-write-cache memory). Normalmente ocorre por problemas na I/O area, e deve ser tratado como descrito em db file sequential read. Free buffer waits, significa que deve aguardar o DBWR escrever dirty blocks no disco, para ter blocos livres. Não deve estar no top 10 da V$SYSTEM_EVENT. Verificar se o I/O subsystem deve ser melhorado, como aumentar o DB_CACHE_SIZE ou colocar mais processos DBWR. Write complete waits, significa que está esperando enquanto o DBWR está escrevendo blocos necessários para o disco. Não deve estar no top 10 da V#SYSTEM_EVENT, e I/O subsystem deve ser melhorado nesse caso. Log file sync, significa que o LGWR está escrevendo todos dados do redo buffer para o online redolog, durante commit ou rollback. Não deve exceder 40ms no V$SYSTEM_EVENT (ou 15ms para read-write-cache memory). Verificar se o sistema de I/O está configurado e otimizado. RAID5 não deve ser usado para online redologs. Log file parallel write, significa que LGWR está esperando por blocos serem escritos no disco. Deve ser otimizado como no log file sync. Log file switch, significa que está aguardando por um log switch. Verificar Archiver Stuck (log file switch (archiving needed)) ou necessário melhorar o DBWR (log file switch (checkpoint incomplete)). Log buffer space, significa que está esperando por espaço livre no redo buffer. Colocar LOG_BUFFER = 1MB. Se continuar, pode ser problema de I/O, verificar procedimento de log file sync. 121 Latch free, que significa que uma área deve ser liberada. Latch é um mecanismo de serialização que é usado para evitar que estrutura de dados sejam acessadas simultaneamente na SGA. Para otimizar, ver nota 767414. Enqueue significa esperando por um Oracle-Lock. Ver nota 745639. Se um número de um wait event está inexplicavelmente alto, pode ser gargalo de CPU. Acessar ST06/OS07 e verificar o consumo de CPU (deve ter pelo menos 30% em idle/hora). Para evitar a exibição de parâmetros incorretos, um reset deve ser feito em várias telas do SAP. Unit 7 – Analysing Application Design Consequences of Expesive SQL Statements Resumo de lição anterior Using SM50/SM66 to Find Expensive SQL Statements Como identificar: - Identificar atividades longas relacionadas ao banco (ex.: sequential read, insert, update); - Anotar o nome do report e da transação (SM66) para análise detalhada; - Anotar o nome da tabela em que a ação é executada; - Anotar o nome do usuário para possíveis futuras assistências; - Na SM50, é possível ver o SQL atual. Using ST03N/STAD to Find Expensive SQL Statements Usando a ST03N, é possível identificar transações que usam uma parte significativa do tempo total de resposta, bem como transações com tempo de banco de dados grande. Escolha “Standard Transaction Profile” e restrinja por Dialog e ordene por Total Database Time: acima de 5% do tempo todal deve ser avaliada; Acessar a STAD e escolher: - um período de tempo; - Task Type D; - Valor relevante do DB Request Time. Using ST04N to Find Expensive SQL Statements A ST04N oferece uma visão diretamente nos processos atuais do banco de dados. Isto é útil para identificar queries em execução e prover maiores detalhes do quê está acontecendo. Acessar Detailed Analyses Resource Consumption Oracle Session Monitor: - Identificar o work process ID (proveniente da SM50/SM66); - Verificar a ação em SQL text; - Analizar o explain plan da query. Informações de Buffer gets podem ser obtidas em Detailed Analyses Resource Consumption SQL Request. Obtendo expensives SQL usando o shared cursor cachê: - ST04N Detailed Analyses Resource Consumption SQL Request: Analysis of Shared Cursor Cache; - Selecionar em buffer gets, um numero igual a 5% dos logical reads da ST04N; - Verificar as SQLs que causam esse consumo; - Analisar o explain plan (com link para o call point no programa ABAP); 122 Critérios de seleção: - Buffer gets/execution: considerar os raramente chamados, mas muito expensivos (normalmente batches); - Disk reads: comandos que atrapalham a performance de I/O; - Buffer gets/Record: comandos expensivos para banco e AS; - Records/execution: ex.: muitos buffer gets para várias records, mas muito utilizado. Using the SQL Trace to Find Expensive SQL Statements ST05 é uma ferramenta para analisar acessos ao banco de dados. Grava tempos de acessos em diferentes passos executados no banco. Também faz trace de enqueue, RFC e buffer. O tamanho máximo é definido pelo parâmetro rsrt/Max_filesize_MB, que normalmente é 16MB no ECC. Exlusive Lockwaits Os locks podem ser divididos em “Database Locks”/”Database enqueues” e “SAP Enqueues. Tipos de lock Oracle: - Usuário: - TX (Tansaction enqueue); - TM (DML Enqueue): quando o objeto todo está em lock (ex.: rebuild, VALIDATE STRUCTURE); - Sistema: - ST (space transaction): em tablespaces dictionary-managed em alocação ou liberação de extents; - CI (Cross Instance Invocation enqueue call): em truncates, drops, etc. O monitoramento de database locks pode ser feito via análise do wait event “enqueue”, via V$LOCK ou ST04N. A duração pode ser acompanhada na V$ENQUEUE_STAT ou ST04N Detailed Analyses Exceptional Conditions Enqueue Monitor. Quando um processo aguarda um lock para utilizar um recurso, é chamado Exclusive Lockwaits. Lockwaits podem ser enfileirados de forma que ocupem todos os WP disponíveis, sendo necessária a eliminação do processo via sistema operacional. O Oracle Lock Montor pode ser acessado via DB01 ou ST04N Detailed Analysis Exceptional Conditions Lock monitor, que indica o causador do lock, os bloqueados e a chave bloqueada. Para evitar exclusive lockwaits, o lock deve ser requisitado pelo programa o mais tarde prossível. Unit 08 – Index Management and Optimization Index utilization Index serve apenas para acelerar o acesso ao dado, apontando diretamente para onde ele está. A criação de índices não necessita alteração de códigos SQL. Um índice é composto de um ou mais campos de tabelas. Cada linha de uma tabela é identificada por um ROWID, que é o datafile number + data block + row number. No índice, as colunas são ordenadas para facilitar o acesso. Quanto menos campos em um índice, a reusabilidade aumenta e a decisão do otimizador melhora. Index scheme: - B-Tree: um bloco “root”, com pointers para outros blocos; 123 - Bitmap: bom para vários valores repetidos, aponta para uma range de valores na tabela. Tipos de índices: - primário: define normalmente o unique da tabela; - secundário: para acelerar pesquisas sem ser pelos campos chaves; - unique secondary: índice secundário, com unique constraint. Acesso a índices: - Fast Full Index: campos requeridos estão no índice. - Index Unique Scan: quando a cláusula where tem os mesmos campos que no índice; - Index Range Scan: quando a cláusula where tem menos campos que o índice. Nesse caso, a ordem é importante para acelerar o processo; - Unselective Index Range Scan: quando um campo da cláusula where está no índice, o outro não. Todos os dados são lidos do índice, onde é feito um sort do outro campo. Muita carga é gerada, e pode ser interessante o full table scan neste caso; - Index Skip Scan: até Oracle 8i, só podia usar índices compostos (mais de um campo) caso o where contivesse todos os campos necessários. A partir do Oracle 9i, caso apenas dois campos estejam na query, um índice com 3 campos não na mesma sequência pode ser usado. As vantagens são: aceleração de algumas queries e obtenção de uma boa performance com menos índices (ocupa menos espaço, acelera manutenções e DMLs). - Full Table Scan: são verificados todos os blocos da tabela, sem índice. Pode ser eficiente se vários dados são requisitados. Creating an Index Antes de sair criando indices: - se o SQL for original, procurar por notas ou abrir chamados; - se o SQL for customizado, tentar usar técnicas como “matched tables” e “SAP business índex tables”, reescrever o código para usar índices já existentes ou adaptar um índice já existente. Índices secundários crescem junto com a tabela, o que torna a pesquisa cada vez mais lenta. Regras gerais: - colocar apenas campos selecionáveis na query; - usar poucos campos como possível (máximo de 4); - posição dos campos no índice: campos geralmente não utilizados colocar no final; - índices devem ser disjunct: não se parecer com outros índices; - usar poucos índices em uma tabela: geralmente até 5, exceto quando tabelas que sofrem muita leitura, como máster data; - não alterar índices originais da SAP. Antes de criar um índice, deve-se ver quão seletivo ele será. Para isso, acessar a DB05, ou via SQL*Plus (having count(*) > 100, para ver se retornará mais de 100 linhas diferentes). Na DB05, se adicionado um campo para o índice e o número de valores únicos não aumentar, este campo não deve entrar no índice. Os índices são criados e mantidos no ABAP Dictionary, via SE11. Para verificar índices criados no ABAP, mas que faltam no banco, acessar DB02 Missing Indexes. Caso um índice primário esteja faltando: SE11 nome da tabela Utilities Database Utility selecionar o índice e clicar em “Choose” Create Database Index. Caso um índice secundário: DB02 missing indexes selecionar o índice Create in DB. 124 Unit 09 – Cost Based Optimizer Update Statistics O otimizador baseado em custo procura o caminho (access path) com menor custo esperado de I/O. Casos em que estatísticas não são necessárias: - quando se usa Rule Based Optimizer (RBO) ou usando o comando RULE; - tabelas de pools e clusters; - exceções de acordo com a DBSTATC; - Oracle DDIC Objects; - para comandos Insert. Tipos de estatísticas: - table statistics: informações como número de linhas, número de blocos usados, exatidão (sample_size) e data das últimas estatísticas; - índex statistics: tamanho da árvore do índice, número de chaves diferentes, etc; - column statistics: número de valores diferentes, o menor e o maior valor, exatidão e data da última criação de estatísticas. Informações de histograma são gravados na DBA_TAB_HISTOGRAMS, que descreve a distribuição dos valores das colunas no menor e no maior valor. Para atualizar: - SQL ANALYSE TALE: deve cair em desuso; - Oracle DBMS_STATS package: forma mais recente. Para mudar de tipo de estatísticas, deve-se deletar a anterior; - BR*TOOLS ou BRCONNECT: método recomendado e deve ser agendado via DB13. Utiliza o ANALYSE TABLE, mas pode ser alterado para DBMS_STATs no init<sid>.sap; - DB20: para tabelas especificadas manualmente; - Report RSANAORA: pode gerar novas estatísticas para tabelas ou índices. A criação de estatísticas pelo BRCONNECT é feita baseando se a tabela foi alterada em 50% (para mais ou para menos). A partir do BRCONNECT 6.10, uma opção chamada table-monitoring pode ser ativada e é recomendado pela SAP. Esse monitor acelera a fase de check das estatísticas, pois se baseia em mudanças na tabela. Cost Evaluation Parâmetros que influenciam: - OPTIMIZER_MODE: deve ser “CHOOSE”, para ativar o CBO; - OPTIMIZER_INDEX_COST_ADJ: fator de multiplicação do custo de acesso por índice. Ex.: valor 10 significa 10% do custo; - OPTIMIZER_INDEX_CACHING: porcentagem de blocos do índice que irão para cachê. - DB_FILE_MULTBLOCK_READ_COUNT: quantidade de blocos lidos por vez. - HASH_AREA_SIZE / PGA_AGGREGATE_TARGET: quanto maior, menor o custo de hash join; - SORT_AREA_SIZE / PGA_AGGREGATE_TARGET: usada para sort. Quanto maior, menor custo. O custo de um full table scan pode ser estimado pelo número de blocos lidos, além do parâmetro DB_FILE_MULTIBLOCK_READ_COUNT. Para bases SAP R/3, o acesso deve ser feito via índice, então este parâmetro deve estar configurado para evitar o full table scan. A experiência mostra que o valor deve ser 8. 125 “Oracle hints” são comandos para forçar o CBO a ir a uma direção estabelecida. Além de manual hints, também existem generated hints, que podem ser controlados via parâmetro dbs/ora/use_hints. Valor padrão é -1 (ativado). Unit 10 – Analysing Memory Configuration Data Buffer Utilization ST04N Data Buffer Quality > 95% ST04 calcula determinando as leituras físicas dividido pelas leituras em buffer, enquanto a ST04N calcula retirando as leituras diretas na tabela (através de comandos que forçam isso). Parâmetros para o cálculo: - session logical reads: total de requisições para acessar um bloco, em memória ou em disco; - phisical reads: total de requisições para acessar um bloco em disco; - phisical reads direct: número de blocos lidos em disco, através de bypass do buffer, exceto LOBs; - phisical reads direct (LOB): idem acima, porém para large objects. Um Buffer Quality alto não quer dizer que o sistema esteja com tamanho de buffer ok. SQLs consumidores que estão com muitos dados em buffer, aumentam o hit ratio, porém consome espaço para outros SQLs. Um tuning desse SQL pode levar a abaixar o hit ratio. Se log reads/user calls > 15, esse marcador é inválido. A performance view V$DB_CACHE_ADVICE provê uma simulação do I/O quando se altera o tamanho do buffer, pode ser ligado/desligado pelo parâmetro dinâmico DB_CACHE_ADVICE. Os dados são coletados desde o startup da base, e em máquinas com consumo de até 60% de CPU não degride a performance. Também pode ser obtido via ST04N Detailed Analyses Resource consumption SGA Monitor Cachê Advisory Stat. Size for estimation. Efficience Of Shared Pool Componentes do shared pool: - Shared SQL Área: SQLs executados armazenados para todos os processos; - Data Dictionary Cache: dicionário de dados, incluindo otimizador baseado em custo. Uso: - User Calls: acesso dos shadow process à Shared SQL Area; - Recursive Calls: leituras físicas do dicionário de dados da tablespace do sistema. Monitoramento (ST04N): - Shared SQL Area: - reloads/pins < 0,04. - pin/ratio >= 95%. - Dictionary Cachê - User/recursive calls: > 2; - DD-cache quality: > 80%. Shared Pool Advisory: ferramenta do Oracle de simulação de alteração da SGA e possíveis resultados. View: V$SHARED_POOL_ADVICE. não há parâmetros para alterar o tamanho da shared e/ou dictionary. Aumentando a SGA aumenta os dois. Monitoring the Automatic Program Global Area Views para monitorar: 126 - V$PGASTAT: estatística de uso da PGA da instância; - V$SQL_WORKAREA: informações sobre work areas utilizadas por cursores de SQL; - V$SQL_WORKAREA_HISTOGRAM: mostra dados estatísticos sobre execuções por work areas, separadas por execuções otimizadas, one pass ou multi-pass. - V$SQL_WORKAREA_ACTIVE: visão atual de quais work areas estão alocadas, quais estão em disco, etc; - V$PROCESS: mostra a PGA usada por processo Oracle. Importante saber a utilização das views abaixo para tuning: - V$SYSSTAT: estatísticas do sistema. Concatenar “STATISTICS#” com a view “V$STATNAME”; - V$SESSTAT: estatística dos usuários. Concatenar “STATISTICS#” com a view “V$STATNAME”. No SAP: ST04N Detailed Analysis Resource Consumption PGA Monitor Guia Status: configuração da PGA, baseado na view V$PGASTAT: - PGA Status Aggregate PGA Target parameter: valor do parâmetro PGA_AGGREGATE_TARGET: tamanho da PGA; - Aggregate PGA Auto Target: área que o Oracle reserva para work areas. - Over Allocation Count: valor acima do PGA_AGGREGATE_TARGET necessário. Deve ser 0, caso contrário aumentar valor deste parâmetro. - Cachê hit percentage: valor ideal de 100% mostra que todas os work areas trabalham de forma otimizada, e não one-pass ou multi-pass. - SQL workarea - View SQL Workarea: view V$SQL_WORKAREA, tamanho em bytes, tempo em segundos; - Top 10 mem. Cachê con: top 10 consumidores de memory cache. Informação da V$SQL_WORKAREA; - One-multipass workarea: SQLs, tipo de execução (otimizada, one ou multipas) e percentuais de execução. Baseada na V$SQL e V$SQL_WORKAREA. - SQL workarea histogram: - Histogram: visão baseada na V$SQL_WORKAREA_HISTOGRAM - Percent optimal: percentagem de work areas que executaram em modo otimizado, one-pass ou multi-pass. - Work area executions: mostra quais work areas foram executadas em modos diferentes. Baseado na V$SYSSTAT. Guia Snapshot: dados atuais - Current Operations: atividades correntes com suas work areas. Baseada na V$SQL_WORKAREA_ACTIVE. - PGA Memory Usage: operações em execução, com processo no SO, a instância, informações de memória e se possível o SQL. Baseada na V$PROCESS. Memória em bytes. Guia PGA Advice - Target Advice Size: simulação do hit ratio do cache para diferentes configurações do parâmetro PGA_AGGREGATE_TARGET, baseado na view V$PGA_TARGET_ADVICE. 127 - Advice Histogram: baseado na view V$SQL_WORKAREA_HISTOGRAM, simula o comportamento dos work areas de acordo com um fator digitado. Para tuning, avaliar as views V$PGA_TARGET_ADVICE (simulação de hit percentage em referência ao tamanho da PGA) e V$PGA_TARGET_ADVICE_HISTOGRAM (simulação baseada na V$SQL_WORKAREA_HISTOGRAM). Valores de hit ratio em 90% p/ BW e 60% para OLTP são válidos e suficientes. Unit 11 Analyzing Physical and Logical Layout Se uma query está consumindo recursos e o uso do índice está apropriado e o código ABAP está otimizado, pode ser problema de índice fragmentado. Para desfragmentá-lo, é necessário reorganizá-lo. Um índice fragmentado consiste de blocos vazios ou páginas vazias ou com poucos registros, sendo necessária a leitura de vários blocos para poucas informações. Um exemplo de índices que precisam de reorganização são índices de tabelas de RFC. Índices se tornam fragmentados: - após archive de dados; - após várias records serem removidas; - tabelas dinâmicas. Existem duas formas de se medir a fragmentação de índices: - índex storage quality, que compara espaço livre e usado; - deleted Leaf rows: compara número de leaf rows removidas com todas leaf rows. Índex storage quality compara o espaço disponível com o espaço usado, onde os dados são levantados como: - espaço disponível: número de blocos de índices usados multiplicados pelo tamanho do bloco, menos cabeçalho dos blocos; - espaço usado: número de entradas no índice multiplicadas pela média de tamanho de uma entrada mais 6 bytes para o ROWID e o cabeçalho para os blocos root e branch. Devido à imprecisão da análise dos dois métodos, eles são apenas indicadores do nível de fragmentação do índice, mas não podem dizer o quanto influencia na performance. Para estimar a qualidade de storage, o report RSORATAD pode ser executado diretamente na SE38 ou a funcionalidade pode ser acessada via DB02. A percentagem exibida não é precisa, mas em índices abaixo de 70% a desfragmentação é recomendada. Para índices pequenos, a percentagem pode ser baixa mesmo quando o índice foi reorganizado. Para índices abaixo de 10 blocos, outro método é recomendado. Vantagens: - lock não é necessário; - mostra informação exata sobre a fragmentação do índice; Desvantagens: - um índice por vez; - execução demorada; - aumenta a carga do sistema. Estimar a proporção de leaf rows e deleted leaf rows pode ser feita via ANALYZE INDEX VALIDATE STRUCTURE diretamente no Oracle ou via DB02. A relação entre deleted/entries deve ser menor que 25%. No Oracle 9, a adição de “online” permite a diminuição do lock, porém estatísticas não são criadas. Vantagens: - diretamente no Oracle, todos índices podem ser analizados (via script); - fornece informações exatas sobre fragmentação do índice. Desvantagens: 128 - a tabela é bloqueada para comandos DML; - execução demorada; - aumenta carga no sistema. Nos logs de execução de estatísticas do BRCONNECT, entradas informando que o índice “is unbalanced” indicam que o índice está fragmentado. Razões para esta entrada no log podem ser: - índice não balanceado; - parâmetro STATS_CHANGE_THRESHOLD no init<DBSID>.sap está com valor baixo (padrão: 50%); - a precisão do cálculo do índice está baixa, devido aos valores definidos na DBSTATC. Vantagens: - não é necessário lock; - não é necessário aumento de carga no sistema; Desvantagens: - não há garantia que todos índices fragmentados sejam reconhecidos. Para desfragmentar, 3 formas são possíveis: - Drop and create view; - Rebuild: - vantagens: pode-se mudar de tablespace, cria nova árvore do índice, possível mudar parâmetros sem necessidade de remover o índice, lock na tabela pode ser evitado via parâmetro “online”. - desvantagens: requer espaço em disco ou em memória. Pode ser feito via BRSPACE, report RSANAORA e via DB02 (tables and indexes monitor). - Coalesce índex: para liberar espaço livre interno. Pode ser feito online. - vantagens: não requer espaço adicional, solução rápida, libera blocos para uso futuro, não causa lock; - desvantagens: não pode mudar de tablespace, não resolve todos problemas de storage quality baixa. I/O contention Contenção em I/O refere-se à altos tempos de I/O, por processos acessando o banco de dados. Quando vários shadow proesses e o DBWR acessam o mesmo disco ao mesmo tempo, contenção de I/O pode ocorrer. Contenção de I/O pode ocorrer: - design de aplicação não é eficiente; - I/O não distribuído em vários discos; - acessos pesados a tabelas ou índices não distribuídos em vários discos; - configuração incorreta de hardware, file system e sistema operacional. Contenção de I/O normalmente é causado por problemas de design da aplicação, então este item deve ser verificado primeiro. Para identificar, usar o submonitor “Filesystem requests” na ST04N, que exibe informações baseadas na V$FILESTAT: - I/O per File (data file); - Total per devices; - I/O per Path. Verificar se a média de escritas e leituras está alta, acima de 20ms. Verificar existência de eventos como “write complete waits”, “free buffer waits” e “log file switch” (checkpoint not complete). Para resolver problemas de contenção de disco: 129 - distribuir o I/O nos discos disponívels; - distribuir o I/O em mais discos; - usar discos mais rápidos; - mover tabelas ou índices muito acessados para discos próprios. 130