Basis 2.0.pdf

8/19/2019 Basis 2.0.pdf

1/234

BASISAdministrando o SAP R/3

Cópia Controlada Consystem Informática – (31) 3281-8864 Page 1 of 234

Revisado por: Daniel Tomaz Matos

WORKSHOP SAP BASIS

8/19/2019 Basis 2.0.pdf

2/234




Instance R/3........................................................................................................................................... página 1

Start/Stop R/3..........................................................................................................................................página 4

Clients R/3..............................................................................................................................................página 11

CCMS – Visão geral............................................................................................................................. página 16

Oracle – visão geral..............................................................................................................................página 22

Criando novo usuário.......................................................................................................................... página 37

Manutenção nos usuário do sistema..................................................................................................página 43

Bloqueando e desbloqueando usuários.............................................................................................página 45

Manutenção de usuários em massa (Transaction SU10).................................................................página 52

Deletando sessão de usuários (Transaction SM04)..........................................................................página 52

Impressão/Spool System.....................................................................................................................página 54

TMS Authorization Concept.................................................................................................................página 61Registering Developers in SSCR.........................................................................................................página 66

System Change Option.........................................................................................................................página 68

Development Class...............................................................................................................................página 69

R/3 Repository Object Locking............................................................................................................página 70

Implementation Guide..........................................................................................................................página 78

Client Change Options.........................................................................................................................página 80

8/19/2019 Basis 2.0.pdf

3/234




Client Tools...........................................................................................................................................página 92

R/3 Upgrade and UPDATE SAP SUPPORT PACKAGE....................................................................página 103

Administrando o Banco de Dados....................................................................................................página 107

Shutdown do Sistema SAP R/3..........................................................................................................página 114

Estrutura de diretórios do Sistema SAP...........................................................................................página 115

BRTOOLS Backup Tasks...................................................................................................................página 135

Backup database.................................................................................................................................página 141

INTRODUCTION SOFTWARE LOGISTICS.........................................................................................página 151

Performance do Banco de Dados.....................................................................................................página 156

Checklists Diário.................................................................................................................................página 162

Checking for Tables nearing their Maximum Extents.....................................................................página 195

Checking File System Space Usage..................................................................................................página 196

Planing the system Clients................................................................................................................página 198

Logon Balancing.................................................................................................................................página 202

Operation Mode...................................................................................................................................página 206

INTRODUÇÃO aos perfis de acesso................................................................................................página 215

OBJETO DE AUTORIZAÇÃO.............................................................................................................página 217

CRIAÇÃO DE USUÁRIOS...................................................................................................................página 221

CRIAÇÃO DE FUNÇÕES.....................................................................................................................página 226

8/19/2019 Basis 2.0.pdf

4/234




Instance R/3

Mandantes R/3 (ou clients R/3) são organizados independentemente. Cada um tem seu próprio ambiente dedados, com seus dados mestres e dados transacionais, dados de usuário e também seus próprios parâmetrosde customização.

Usuários em diferentes mandantes coexistem em um mesmo sistema R/3, mas seus dados são isolados e nãopodem ser acessados de outro mandante. Somente usuários com as autorizações necessárias podemvisualizar ou processar dados em um mandante específico. Esse conceito de isolamento se reflete nas estruturas das tabelas, tanto em nível de aplicação quanto de customização, que é um nível de adaptaçãodependente de cada implementação.

O mandante 000 é definido como o padrão SAP e não pode ser modificado. Ele serve como um modelo para acriação de outros mandantes.

O número máximo de mandantes em um sistema R/3 é de 997, número dificilmente atingido.

Uma instância (instance) é um grupo de serviços do R/3 que são iniciados e finalizados em conjunto.Normalmente, o termo é associado a um dispatcher e seus wp´s correspondentes, mas também pode serconsiderado uma instância um servidor executando somente o serviço de gateway do SAP.

Central instance (instância central) é a combinação de um dispatcher com todos os processos do R/3, ou seja,a combinação DVEBMGS. Como exemplo disso, temos a instância C na figura acima, que mostra todos osprocessos do R/3 sendo executados, com a exceção do G (gateway), mas que também deve estar presenteem uma central instance.

Um servidor R/3 de aplicação consiste principalmente de um dispatcher, seus wp´s associados e seu bancode memória.Em um ambiente R/3, os conceitos “cliente” e “servidor” são geralmente abordados como software, dessemodo vários servidores de aplicação podem ser executados em um só computador.

Do ponto de vista de hardware, entretanto, um servidor de aplicação pode ser definido como um computadorcom pelo menos um dispatcher, configuração que também é chamada de instância de dialog.

As seguintes restrições se aplicam ao número permitido para cada tipo de work process:- Dialog: cada dispatcher precisa de, pelo menos, dois wp´s de dialog.- Spool: pelo menos um por sistema R/3, e os dispatchers podem ter mais de um spool.- Update: pelo menos um por sistema R/3, e os dispatchers podem ter mais de um update.- Background: pelo menos dois um por sistema R/3, e os dispatchers podem ter mais backgrounds.- Enqueue: somente um wp de enqueue pode existir em um sistema R/3.

8/19/2019 Basis 2.0.pdf

5/234




Uma vez estabelecida a conexão com um dispatcher através do SAPGUI, um sessão no sistema R/3 éiniciada para o usuário.

Os dados são passados do SAPGUI para o dispatcher usando o protocolo padrão do SAPGUI, que étransmitido sobre TCP/IP, e o seguinte processo é iniciado:

- O dispatcher classifica o pedido e coloca-o na fila de pedidos apropriada.- Os pedidos são passados por ordem de ch agada (FIFO) para um wp de dialog que estiver livre.- O subprocesso taskhandler restaura o contexto do usuário num passo chamado “roll-in”. Esse

contexto contém os dados principais das transações a serem executadas por esse usuário etambém as autorizações específicas do usuário.

- O taskhandler chama, então, o processador dynpro para a conversão da tela em variáveis ABAP.- O processador ABAP executa o código referente ao módulo “process after input” (PAI) da tela

precedente seguido do módulo “process before output” (PBO) da tela subsequente. Caso sejanecessário, ele também se comunica com o banco de dados.

- O processador dynpro então converte as variáveis ABAP novamente em campos de tela. Quandoo dynpro é finalizado, o taskhandler assume novamente o processamento.

- O contexto do usuário é novamente armazenado na memória compartilhada dos WP´s.- Por fim, o resultado do processamento é retornado ao SAPGUI através do dispatcher e o WP´s

que tratou do pedido pode ser liberado novamente.

8/19/2019 Basis 2.0.pdf

6/234




Se a transação envolver mais de uma tela, a sequência de passos de dialog descrita anteriormente é,geralmente, processada por diversos WP´s de dialog diferentes. Essa característica é conhecida comomultiplexação de work process.

Cada pedido de dialog é primeiro colocado pelo dispatcher na fila de pedidos de dialog, de onde ele poderáser assumido por um WP de dialog disponível.O WP não realiza operações no banco de dados. Em vez disso, ele repassa comandos para os processos debanco de dados através da interface de programação do próprio banco.

8/19/2019 Basis 2.0.pdf

7/234




Start/Stop R/3

Um usuário do sistema operacional loga usando o usuário adm Para iniciar o R/3, execute o script de inicializaçãostartsap__instance_no> a partir do home directorydo usuário adm . O script startsap__instance_no> tem um alias “startsap ” startsap inicia o processo sopsocol, que é o coletor de estatísticas de dados do sistema operacional, caso omesmo não esteja sendo executado.startsap, então, chama o satrtdb, que inicia o banco de dados, caso o mesmo ainda não est aeja sendoexecutado.Depois disso, o startsap inicia a central instance.O administrador pode iniciar instâncias adicionais e servidores de aplicação. Para iniciar instâncias

independentes do banco de dados, use o startsap:- startsap r3: verifica se o banco está no ar: se estiver, só a instancia é iniciada.- startsap db: só o banco de dados.- startsap all: default, inicia o banco e a instância.

8/19/2019 Basis 2.0.pdf

8/234




O gráfico acima mostra a inicialização do R/3 em maior detalhe.

Passos para a inicialização:

O script startsap chama o programa SAPSTART.

O programa SAPSTART lê o perfil de inicialização da instância e inicia os componentes do R/3 listados eoutros serviços.

Em uma central instance, SAPSTART inicia os serviços message server, dispatcher, collector e sender. Emuma instância de dialog, somente o sender e o dispatcher são iniciados. O collector e o sender são usadospara implementar os serviços centrais do log do sistema R/3.

O dispatcher, então, assume o papel de pai dos processos a serem criados. Para isso, ele cria processosfilhos como o gateway e os work processes, de acordo com os perfis de inicialização correspondentes.

Os work processes, então, se conectam ao banco de dados, que, nesse momento, já deve ter sidoinicializado.

8/19/2019 Basis 2.0.pdf

9/234




Os ID´s de vários processos do R/3 na figura acima mostram a ordem de execução na inicialização.- Sapstart cria o dispatcher, o collector e o sender.- Saposcol é iniciado diretamente do script startsap.- O processo init do UNIX tem o ID 1.

De modo a construir um procedimento de inicialização, a sequência de leitura dos parâmetros (também

conhecida como sequência de substituição de parâmetros) é definida como:- O R/3 processa os parâmetros como definido em seu código fonte no kernel R/3 (disp+work).- O perfil default é lido, e os parâmetros já definidos através do código fonte do kernel são

substituídos pelos correspondentes encontrados no perfil default.- O perfil da instância é lido e, do mesmo modo, sobreescreve os valores anteriores.

Esse procedimento garante que os parâmetros de sistema vão refletir as configurações das três fontes.

8/19/2019 Basis 2.0.pdf

10/234




Durante a inicialização da base de dados, o startsap chama o script startdb, o qual acessa um arquivo de logpara armazenar o processo de inicialização do banco.

Todos os eventos importantes no processo, como inicialização e parada do banco de dados e qualquer errona base, são anotados no arquivo de alerta do Oracle. Maiores detalhes são anotados no arquivo de trace.

Visão Geral dos Trace Logs

8/19/2019 Basis 2.0.pdf

11/234




O gráfico acima mostra os possíveis pontos de falha durante o processo de inicialização do R/3.

Se ocorrer algum erro, a informação correta deve ser encontrada para se diagnosticar o problema. Abaixocomentamos algumas das possibilidades de erro:

Se o acesso a recursos como os scripts startsap ou startdb, a causa pode ser, por exemplo:- As permissões de sistema de arquivo não estão corretas.- O usuário adm não foi criado corretamente.

Se o banco de dados não foi iniciado ou o WP não pode se conectar ao banco, o R/3 não pode serinicializado. Algumas das causas que podem levar a base de dados a falhar na inicialização são:- As variáveis de ambiente não foram configuradas corretamente.- A base de dados está sendo executada no modo DBA.- Os arquivos da base estão corrompidos.- Os arquivos de dados foram renomeados no banco, mas não no sistema operacional.

Se o R/3 não inicia, podemos verificar se:- O kernel do UNIX não foi configurado corretamente.- Existem erros no sistema de gerenciamento de memória.- Os perfis do R/3 não estão acessíveis.

Existem duas razões principais para parar um sistema R/3:

8/19/2019 Basis 2.0.pdf

12/234




Parada planejada:- Para alterar os parâmetros dos perfis.- Para realizar uma atualização do R/3.- Para manutenção do sistema operacional ou do hardware.

Paradas não planejadas podem ocorrer por diversos fatores (por exemplo, um problema físico nos discos).

Antes de parar o R/3, o administrador deve verificar:- Visão geral dos jobs.- Verificar se nenhum job de background de qualquer servidor de aplicação está ativo ou sendo

inicializado por processo externo.- Visão dos processos.- Verificar se o processo BTC está sendo executado nos servidores de aplicação.- Verificar a execução de processos de batch input.- Verificar se alguma atualização está pendente no banco de dados.

O administrador deverá decidir se interrompe ou não os processos que estiverem pendentes. Um avisoatravés de uma mensagem de sistema também pode ser útil.

Para parar um sistema R/3, o administrador deve:

8/19/2019 Basis 2.0.pdf

13/234




- Parar os servidores de aplicação (instâncias de dialog e também a central), o que pode ser feito dedois modos: através do CCMS ou usando o script stopsap__ ou tambématravés do alias: stopsap r3.

- Parar a base de dados usando o stopsap all , o stopdb , pelo Oracle Manager ou pelo SAPDBA.

Se a reconexão à base de dados (databese reconnect) estiver configurada no R/3, não é necessário parar umservidor de aplicação antes de um backup offline. Os buffers do R/3 não são esvaziados, e os work processconfiguram o status “reconnect” até que a base de dados seja reinicializada .

Durante um backup offline, a execução do banco de dados deve ser interrompida (shut down), e os WP´sreceberão da base de dados uma mensagem com código de erro “reconnect” .

Cada vez que um pedido acontecer ou que o tempo de espera expire, o WP tentará se reconectar ao banco,por isso, antes da cada backup offline, o administrador deverá mandar uma mensagem avisando aos usuários.

Se a base de dados não puder ser finalizado, a casa pode ser por:

8/19/2019 Basis 2.0.pdf

14/234




- O banco de dados está fazendo um rollback de transações abortadas pela finalização do R/3.Dependendo da última atualização do banco de dados em disco, esse processo pode levar muitotempo.

- Um backup online está sendo executado, e deve-se esperar que o mesmo termine.

Se não existir nenhuma razão natural para a demora, uma análise mais detalhada deve ser efetuada para sedecidir o que fazer.

Clients R/3

Mandantes R/3 (ou clients R/3) são organizados independentemente. Cada um tem seu próprio ambiente dedados, com seus dados mestres e dados transacionais, dados de usuário e também seus próprios parâmetrosde customização.

Usuários em diferentes mandantes coexistem em um mesmo sistema R/3, mas seus dados são isolados e nãopodem ser acessados de outro mandante. Somente usuários com as autorizações necessárias podemvisualizar ou processar dados em um mandante específico. Esse conceito de isolamento se reflete naestruturas das tabelas, tanto em nível de aplicação quanto de customização, que é um nível de adaptaçãodependente de cada implementação.

O mandante 000 é definido como o padrão SAP e não pode ser modificado. Ele serve como um modelo para acriação de outros mandantes.

O número máximo de mandantes em um sistema R/3 é de 997, número dificilmente atingido.

8/19/2019 Basis 2.0.pdf

15/234




Quando um processo SAPGUI é iniciado em uma estação, um comando é enviado indicando uma dasseguintes ações:

- Um dispatcher específico deve ser acessado diretamente.- Um logon no message server deve ser efetuado para se usar o balanceamento de carga.

Quando do uso do logon balance, o message server retorna o endereço IP e o número da instancia (instance)de um dispatcher especít f ico. O número de dispatchers disponíveis é configurado no sistema. Obalanceamento de carga (logon balance) é útil para associar certos usuários a servidores específicos.

O message server retorna o endereço IP do dispatcher escolhido, tipicamente aquele que estiver com melhortempo de resposta nos últimos cinco minutos, estatística que é armazenada no workload data (dados deutilização do servidor).

O processo de front-end (SAPGUI) se conecta, então, ao dispatcher designado, que escolhe um work process(wp) de dialog para atender o logon do usuário, comparando os dados da chamada com as informaçõescontidas nos dados do usuário no sistema.

Se as informações são compatíveis com os dados do usuário no sistema, o logon é permitido, e esse

dispatcher e seus wp´s serão usados durante toda a sessão.Se o usuário deslogar e logar novamente, o logon balance pode fazer com que o message server selecioneoutro dispatcher para o usuário.

8/19/2019 Basis 2.0.pdf

16/234

8/19/2019 Basis 2.0.pdf

17/234




Uma vez estabelecida a conexão com um dispatcher através do SAPGUI, um sessão no sistema R/3 éiniciada para o usuário.

Os dados são passados do SAPGUI para o dispatcher usando o protocolo padrão do SAPGUI, que étransmitido sobre TCP/IP, e o seguinte processo é iniciado:

- O dispatcher classifica o pedido e coloca-o na fila de pedidos apropriada.- Os pedidos são passados por ordem de chegada (FIFO) para um wp de dialog que estiver livre.- O subprocesso taskhandler restau ra o contexto do usuário num passo chamado “roll-in”. Esse

contexto contém os dados principais das transações a serem executadas por esse usuário etambém as autorizações específicas do usuário.

- O taskhandler chama, então, o processador dynpro para a conversão da tela em variáveis ABAP.- O processador ABAP executa o código referente ao módulo “process after input” (PAI) da tela

precedente seguido do módulo “process before output” (PBO) da tela subsequente. Caso sejanecessário, ele também se comunica com o banco de dados.

- O processador dynpro então converte as variáveis ABAP novamente em campos de tela. Quandoo dynpro é finalizado, o taskhandler assume novamente o processamento.

- O contexto do usuário é novamente armazenado na memória compartilhada dos WP´s.- Por fim, o resultado do processamento é retornado ao SAPGUI através do dispatcher e o WP´s

que tratou do pedido pode ser liberado novamente.

8/19/2019 Basis 2.0.pdf

18/234




Se a transação envolver mais de uma tela, a sequência de passos de dialog descrita anteriormente é,geralmente, processada por diversos WP´s de dialog diferentes. Essa característica é conhecida comomultiplexação de work process.

Cada pedido de dialog é primeiro colocado pelo dispatcher na fila de pedidos de dialog, de onde ele poderáser assumido por um WP de dialog disponível.O WP não realiza operações no banco de dados. Em vez disso, ele repassa comandos para os processos debanco de dados através da interface de programação do próprio banco.

8/19/2019 Basis 2.0.pdf

19/234




CCMS – Visão geral

O CCMS (Computing Center Management System) é uma parte do sistema de administração basis do R/3 quefornece ferramentas para administração de:

- Performance do sistema R/3- Banco de dados e backups- Carga de trabalho do sistema- Velocidade de resposta- Segurança dos dados

Ele pode ser usado para analisar e distribuir a carga de utilização dos usuários e criar relatórios de consumo

de recursos pelo sistema. O CCMS também fornece ferramentas gráficas para monitoramento egerenciamento.

O CCMS também fornece os meios para configurar o gerenciamento 24h por dia do controle dos modos deoperação e das instâncias.

Antes de ser usado, o CCMS deve ser configurado corretamente.

Antes de ser possível trabalhar com o CCMS, seu ambiente deve ser organizado corretamente. A consistênciae a precisão do funcionamento do CCMS dependem de como ele é configurado inicialmente pelo usuário.

A configuração do CCMS envolve os seguintes passos:

- Manutenção correta dos perfis.- Definição de, pelo menos, um modo de operação.- Designação das definições das instâncias na instalação.- Designação das definições das instâncias para cada modo de operação.- Definição da tabela de agendamento para os modos de operação.

8/19/2019 Basis 2.0.pdf

20/234




Se as instâncias, os modos de operação ou as tabelas de agendamento não estiverem configuradascorretamente, o CCMS não irá fornecer informações precisas.

Para a definição das propriedades das instâncias, o R/3 usa os arquivos de perfil (profile), que armazenam asconfigurações a serem utilizadas pelo sistema quando da inicialização.

Os parâmetros nos perfis estão associados a recursos, como memória principal, perfil da inicialização (startup)e da instância, que são configurados automaticamente no perfil default durante a instalação do R/3.

Quando a primeira instância do R/3 é criada, os três perfis (default, startup e da instância) são gerados. Nainstalação de instâncias subsequêntes, o perfil default existente é atualizado.

Em um sistema distribuído formado por servidores de aplicação de uma mesma plataforma, um diretóriocompartilhado para os perfis pode ser criado.

Para se alterar perfis de diferentes servidores de aplicação, os perfis devem ser armazenados na base dedados. Entretanto, depois da instalçação, os perfis são armazenados no sistema de arquivos. Então, os perfisdevem se importados para que possam ser gerenciados de dentro do R/3.

Depois que os perfis são importados, uma verificação dos parâmetros é efetuada. Os perfis, então, sãoarmazenados automaticamente na base de dados e sua ativação é feita através do armazenamento tambémno sistema de arquivos.

Diferentes versões de um perfil podem ser armazenados na base de dados com o mesmo nome, alterando-sesomente o número da versão do arquivo. Cada vez que uma alteração for salva, um novo número de versãoserá criado. A base de dados, então, conterá diferentes cópias de um mesmo perfil, assim como o históricodocumentado de modificação dos parâmetros.

Apesar de estar armazenado no banco de dados, o perfil usado na inicialização de um servidor R/3 é o queestá armazenado no sistema de arquivos. As alterações dos perfis em sistema de arquivos são monitoradaspelo R/3, e um histórico de modificação (quem, quando, o quê) é documentado pelo próprio sistema.

8/19/2019 Basis 2.0.pdf

21/234




Normalmente, os parâmetros default sugeridos pelo sistema são válidos e só devem ser alterados sobsugestão da SAP ou de um parceiro SAP, o que pode ser necessário em situações do tipo mudança do bancode dados, modificação no número de work process etc.

As mudanças nos perfis são verificadas automaticamente, e erros simples ou inconsistência são verificados,mas as modificações só devem ser feitas com segurança e conhecimento de suas consequências, casocontrário o sistema pode ser colocado em risco. A maioria dos parâmetros só terá mudanças ativadas após a próxima inicialização do sistema, com exceçãode alguns parâmetros de gerenciamento de memória da instância, que podem ser ativados dinamicamente.

Operation Mode

Normalmente, os sistemas R/3 precisam de mais WP´s dialog durante o dia e mais WP´s background durantea noite.

Existem dois modos de se ajustar o sistema para se adequar às necessidades diferentes dependendo doperíodo do dia e do tipo de utilização principal. Isso pode ser feito alternado-se os perfis da instância ouusando o processo de modo de operação (operation mode).O uso de modo de operação maximiza a utilização dos recursos nas diferentes fases de atividade do sistema. A mudança do modo de operação reconfigura o R/3 dinamicamente, o que substitui a alteração dos perfis e areinicialização do sistema. A utilização das mudanças de modo de operação se baseia nos seguintes fatores:

- Os serviços ou os tipos de work processes needed.- O intervalo de tempo escolhido.

8/19/2019 Basis 2.0.pdf

22/234




Durante o dia, normalmente o modo de operação requer mais processos de dialog, o que permite melhortempo de respostas para transações de entrada de dados, por exemplo.O processamento de dialog é responsável por:

- Processamento interativo, como criação de documentos ou de ordens de venda.- Envio de um volume limitado de dados para inserção na base de dados.- Atividades de usuário com um limite de transações.- Processos urgentes.

A operação usual do período noturno requer mais processos de background, que devem estar disponíveispara jobs de alta prioridade e/ou de execução programada.

8/19/2019 Basis 2.0.pdf

23/234




O processamento de background é usado para tarefas que requerem alta atividade do banco de dados e queconsumiriam muito tempo em um dialog, como, por exemplo:

- Processos de balanço e pagamentos.- Processamento de listas.- Alguns processamentos periódicos.- Inserção e atualização de um grande volume de dados.

Instâncias são criadas durante a instalação do R/3.Para cada instância, os perfis são criados automaticamente.Depois da definição do primeiro modo de operação, as definições da instância devem ser criadas.Não há modo para se criar as definições de instâncias manualmente, elas devem ser criadas através dageração ou da cópia das definições usando o CCMS.Quando da geração das definições de uma instância, o sistema importa os dados correntes da instância decada servidor de aplicação que estiver ativo.

Se você escolher obter as configurações correntes de uma das instâncias ativas quando for gerar asdefinições, cada modo de operação produtivo que foi criado previamente será associado com a disposição donúmero corrente de work processes para cada nova definição de instância.

8/19/2019 Basis 2.0.pdf

24/234




Se nova definição de instância for criada sem se basear em uma instância já ativa, o modo de operação teráque ser designado manualmente.

Para cada modo de operação associado, é possível adaptar a distribuição dos work processescorrespondentes. Apesar de ser possível mudar o tipo dos work processes, o número total deles devepermanecer o mesmo e só poderá ser alterado no perfil da instância.O número mínimo de work processes tanto para dialog quanto para background é 2. O total de WP´s de dialogé sempre o número total de WP´s menos a quantidade de todos os outros WP´s.É possível reservar um ou mais WP´s de background para processamento de jogs de alta prioridade, ou seja, jobs classe A.

Durante a mudança de modo de operação, os work processes são redistribuídos automaticamente, sem que ainstância tenha que ser reiniciada. Não há tempo de parada nesse processo, e somente o tipo dos workprocesses é que é mudado e não o número de work processes disponíveis.Se algum dos WP´s a ser alterado estiver processando um job, ele será modificado após o término da tarefaem andamento. Nenhum processo é interrompido, a performance do sistema é mantida, e os buffers do R/3(ABAP e table buffers) não são ressetados. A mudança do modo de operação é registrada no log do sistema. Apesar de excepcional, caso o processo demudança no modo de operação não seja completado automaticamente, a mudança poderá ser feitamanualmente.

No caso de falha na mudança do modo de operação, o administrador deverá investigar as causas da falha,

que, geralmente, está relacionada com inconsistências do sistema como, por exemplo, se houver umadiscrepância entre os diferentes locais de configuração do número de work processes:

8/19/2019 Basis 2.0.pdf

25/234




- No perfil da instância no sistema de arquivos.- Na base de dados.

- Ou na definição do modo de operação.Se os perfis forem modificados, e o sistema for reiniciado, os modos de operação assim como as definiçõesda instância devem ser reconfiguradas.

Oracle – visão geral

8/19/2019 Basis 2.0.pdf

26/234




Quando um banco de dados Oracle é iniciado, diversos processos são criados:- O processo listener é responsável pela comunicação do Oracle com a rede.

- Um processo shadow dedicado é criado para cada sessão da base de dados.- Alguns processos compartilhados, que trabalham para o gerenciamento do banco de dados.

A base de dados é armazenada em blocos de 8KB em arquivos de dados no disco.Para acelerar o acesso de leitura e gravação, esses blocos de dados são armazenados no pool de buffer dememória principal.Modificações na base de dados são armazenadas nos arquivos de redo log online. Esse processo garante aintegridade e a segurança dos dados. Para garantir a tolerância a falhas na operação sobre a base de dados,os arquivos de controle (control files) e os arquivos de redo log online do sistema devem ser espelhados.O sistema de gerenciamento do Oracle mantém os comandos SQL executáveis em uma área de SALcompartilhado (SQL shared area), que é faz parte do pool de memória compartilhada e disponível para todosos processos.Cada work processes do R/3:

- Se conecta a base de dados como o usuário SAPR3 do banco de dados.- Trata requisições de diferentes usuários do R/3.- Se comunica com o shadow process correspondente na base de dados.

Usuários do R/3 não possuem um usuário correspondente no banco de dados.

8/19/2019 Basis 2.0.pdf

27/234




O banco de dados Oracle é iniciado em três fases:- Na fase No Mount , a instanciação da base de dados é construída. Recursos do sistema

operacional são alocados usando a configuração armazenada no arquivo de perfil do Oracle.- Na fase Mount, os arquivos de controle do banco de dados são avaliados. Então, o sistema lê as

informações da estrutura de arquivos da base de dados. Nenhum arquivo ainda foi aberto.- Na fase Open, todos os arquivos da base de dados são abertos. Caso necessário, uma

recuperação de instância é imediatamente iniciada. Transações pendentes na base de dados sãofinalizadas de acordo com a lógica transacional.

O administrador pode derrubar o banco de dados usando um dos três modos a seguir:- SHUTDOWN NORMAL: Todos os usuários devem deslogar. A base de dados é fechada

sistematicamente, todos os arquivos são fechados, a base é desmontada, e a instância do bancoé derrubada. A base de dados termina o shutdown com consistência.

- SHUTDOWN IMMEDIATE: Somente os comandos correntes são finalizados. PMON finaliza todasas sessões e faz um rollback das transações abertas. A base de dados é fechadasistematicamente (como num shutdown normal) e termina o shutdown consistente.

- SHUTDOWN ABORT: usado somente em emergências. Usuários não são deslogados, e orollback das transações abertas não é efetuado. A base de dados não termina o shutdown deforma consistente, e uma recuperação da instância da base de dados é realizada na próximainicialização da base de dados.

Um sistema de banco de dados Oracle tem três processos que gravam informação da Shared Global Area(SGA) para os arquivos apropriados:

- Durante um chackpoint, oDatabase Writer (DBWR) grava de maneira assíncrona os blocos de

dados que foram modificados da SGA para os arquivos de dados.- Para aumentar a velocidade da gravação, o processo Checkpoint (CKPT) é executado.- O Logwriter (LGWR) grava sincronamente as mudanças no buffer de redolog do SGA para o

arquivo de redolog online corrente.Em um sistema de produção, a base de dados deve sempre ser executada no modo ARCHIVELOG e ter oprocesso Archiver (ARCH) inicializado. O ARCH armazena uma cópia completa do arquivo de redolog onlineno arquivo de redolog offline dentro do diretório de archive da base de dados.Uma vez que o arquivo de redolog offline é criado, o arquivo correspondente de redolog online é liberado epode ser sobreescrito com novos dados de log pelo sistema.Se não houver mais espaço disponível no diretório de archive, o ARCH não irá armazenar o próximo arquivo.Nesse momento, a base de dados “trava”, depois de um número de mudanças no arquivo de redolog. Novasmodificações na base de dados não podem ser salvas enquanto o travamento do ARCH persistir.

8/19/2019 Basis 2.0.pdf

28/234




O banco de dados Oracle usa tablespaces . Do ponto de vista lógico, uma tablespace é um container paraobjetos da base de dados, como tabelas e índices. No disco, uma tablespace consiste de um ou maisarquivos. A capacidade de uma tablespace pode aumentar adicionando-se mais arquivos à estrutura.Os objetos criados na SYSTEM (tablespace principal do Oracle), PSAPROLL (rollback da base) e PSAPTEMP

(temporário da base) devem ser exclusivos dos usuários SYSTEM e SYS do Oracle.

Os diretórios e arquivos também são criados de acordo com uma convenção de nomes e de localização. Porexemplo, os arquivos de tablespaces residem no diretório sapdata , e os arquivos de alerta do Oracle são

armazenados no diretório saptrace\background.

8/19/2019 Basis 2.0.pdf

29/234




As tarefas de manutenção diárias do banco de dados incluem:- Backup de toda a base de dados.- Backup dos arquivos de redo log offline.- Monitoração do sucesso dos backups.

Fatores externos, erros físicos e lógicos podem levar a perda de dados e parada do sistema.Uma estratégia de backup efetiva e um plano de recuperação de dados são essenciais para minimizar tempode parada e perda de dados.Para garantir a disponibilidade do R/3, uma estratégia de backup deve ser desenvolvida pelo administrador dabase de dados e testada com precisão.

8/19/2019 Basis 2.0.pdf

30/234




Cada sistema de gerenciamento de base de dados armazena seus dados em estruturas adequadas para agravação em disco e grava as modificações nos dados no log da base de dados. No caso do Oracle:- Os dados são armazenados nos arquivos das tablespaces.- O log é anotado no arquivo de redo log online corrente.- Dados de administração são armazenados nos arquivos de controle e de parâmetros.

Durante um backup da base de dados, os arquivos de dados, do redo log online, os perfis e os arquivos decontrole são armazenados.Quando o arquivo de redo log online corrente é preenchido completamente, automaticamente o Oracle passaa gravar no próximo arquivo de redo logo online. O Oracle archiver, então, copia o arquivo de redo log onlinepreenchido para o diretório de archive. Esse novo arquivo é chamando de arquivo de redo log offline.

Os backps dos arquivos da base de dados quanto do redo log offline são necessários para garantir arecuperação da base de dados em um ponto de tempo o mais próximo possível de quando os dados foramperdidos. Para realizar a restauração, o backup dos dados deve ser restaurado desde o início.

Uma estratégia de backup deve incluir a verificação dos dados e dos backups de dados.Use a verificação lógica dos dados para verificar a consistência da base de dados Oracle:

- Blocos corrompidos (erro ORA-1578) podem aparecer na base de dados R/3 como resultado de

um erro de sistema operacional ou de hardware. Blocos corrompidos podem inutilizar um backup.

8/19/2019 Basis 2.0.pdf

31/234




- A existência desses blocos só se torna evidente durante a próxima tentativa de leitura da tabeladentro do bloco afetado. Como esse particular acesso podem não ocorrer frequentemente, eblocos não validados durante o backup, esses blocos corrompidos podem permanecer escondidosno sistema por um longo tempo.

- Por isso, uma verificação lógica é necessária de tempos em tempos. Por questões deperformance, a verificação deverá ser efetuada em horários de baixa atividade do sistema.

Uma verificação física dos dados nas fitas usadas para o backup também é importante. Para isso, as fitasdevem ser lidas para verificação após o backup.Quando um backup offline é efetuado, a base de dados deve ser descarregada e permanecer indisponíveldurante o backup. Como os arquivos do Oracle permanecem intactos durante o backup, a consistência dosdados é mantida.Os seguintes arquivos são copiados durante um backup offline:

- Os arquivos de todas as tablespaces pertencentes a uma base de dados.- Os arquivos de redo log online.- Os arquivos de controle.- Os arqivos de perfil.

Depois que o backup offline termina, é necessário armazenar também os arquivos do redo log offline. Apesar de o R/3 poder continuar disponível durante um backup, os usuários não podem acessar a base nesseperíodo.

Durante um backup online, o Oracle e o R/3 permanecem disponíveis. O online backup causa uma pequenaredução de performance do sistema.Os seguintes arquivos são armazenados durante um backup online:

- Arquivos de dados de todas as tablespaces da base de dados.- Arquivos de controle.- Perfis.

Atenção:

- Backups online por si só não são consistentes, pois os arquivos de dados estão sendo atualizadosconcorrentemente ao armazenamento. Um backup online só será consistente em conjunto com as

8/19/2019 Basis 2.0.pdf

32/234




informações de log gravadas durante o processo do backup. Depois do final do backup, aferramenta SAP pode ser usada para mudar a utilização do redo log online para outro arquivo, oque faz com que o Oracle copie o arquivo anterior para o diretório dos arquivos de redo log offline,que também deverão ser incluídos no backup para garantir a consistência da cópia.

Não é necessário fazer o backup do redo log online depois que um backup online é finalizado.

Os arquivos de redo log offline são copias dos arquivos de redo log online que são gravadas pelo archiver doOracle no diretório saparch. Os arquivos de redo log online são sobrescritos ciclicamente.Registros de log são constantemente gerados durante modificação dos dados na base. Assim, espaço emdisco para o diretório de archive dos logs deve sempre estar disponível. Quando o archiver não tiver espaçodisponível para gravar, o Oracle irá retornar o erro 257: Archiver is stuck ou o erro 255: Error archiving log, e obanco de dados para. Uma mensagem de erro também é gravada nos arquivos de trace do Oracle.Se, no caso de uma restauração, um dos arquivos do redo log offline não detém um backup válido, podeocorrer perda de dados. Os arquivos de redo log offline devem ser armazenados em fita antes de seremapagados do diretório de archive. Por questões de segurança, faça duas cópias em fitas separadas dosarquivos de redo log offline.No caso de uma falha no banco de dados, pode acontecer uma situação na qual não será possível recuperaras atualizações mais recentes que não estiverem sido armazenadas no redo log offline. Também é importantelembrar que um backup online não é útil sem uma cópia dos arquivos de log gerados durante a execução dobackup.

8/19/2019 Basis 2.0.pdf

33/234




A SAP recomenda um ciclo de backup de quatro semanas.Grupos de fitas para a base de dados e para o redo log offline são necessários, e eles devem cobrir todo operíodo de backup. As fitas podem ser reusadas depois do término do ciclo.Realize um backup online completo todos os dias. Pelo menos uma vez no ciclo de backup, realize um backupcompleto.

Os arquivos de redo log offline devem ser armazenados (em duas cópias em fitas separadas) ao final de cadadia de trabalho e também depois de cada backup, seja online ou offline.Para se validar um backup, deve-se verificar a base de dados à procura de erro lógicos e os backups,principalmente verificando os erros físicos. Essa verificação deve ser realizada pelo menos uma vez durante ociclo de backup A última cópia completa offline de cada ciclo deve ser removida do grupo de fitas e armazenada em localseguro.

Backups da base de dados são realizados usando a ferramente BRBACKUP fornecida pela SAP, enquanto osbackups de arquivos de redo log offline são comandados pela ferramenta BRARCHIVE.

8/19/2019 Basis 2.0.pdf

34/234




Existem três modos de execução do precesso:- Usando o BRTOOLS.

- Diretamente através do sistema operacional.- E usando o DBA planning Calendar do R/3.

A SAP recomenda o seguinte procedimento:- Programar todos os backups regulares usando o DBA planning Calendar.- Realizar backups adicionais através do DB13.

Todos os passos do backup são armazenados em arquivos e em tabelas da base de dados.

Para determinar a estratégia de backup devem ser considerados:

- Requisitos operacionais.- Requisitos de segurança.- Componentes de hardware.- Disponibilidade do sistema.

A implementação deve se preocupar com:- Definição das fitas e locais de armazenamento.- Agendamento do processo.- Definição de responsabilidades.- Configuração das autorizações necessárias.

- Criação do plano de emergência e responsáveis. Além do plano de emergência, deve ser criado um manual que contenha as informações de cada passo dobackup e que deve estar disponível a todos os responsáveis pelo backup.

Monitoring DB

O R/3 pode configurar o processo de backup para usar compressão de dados.Para avaliar a taxa de compressão a ser obtida no backup, o administrador pode usar a transação DB02. Essaverificação deve ser realizada a cada ciclo de backup.

O Backup Log Monitor (transação DB12) mostra informações sobre:- Backups da base de dados e dos arquivos de redo log offline.- Logs gravados pelo BRBACKUP e pelo BRARCHIVE.- O último backup que falhou.- O último backup com sucesso.- O estado do diretório de archive.- Como que os backups de base de dados e de redo log offline podem ser usados em uma

recuperação de base. A transação DB13 mostra informações sobre todos os backups comandados.

8/19/2019 Basis 2.0.pdf

35/234




Para melhorar a performance e minimizar o tempo de parada do sistema, o Oracle deve ser monitorado

diariamente. Para uma visão geral de indicadores de performance, o CCMS fornece os seguintes monitores:- Database System Check Monitor (DB16) mostra uma visão geral das funções principais do banco

e seu estado geral.- Backup Log Monitor (DB12) mostra informações de status dos backups de base de dados e de

redo log offline- Tables Index Monitor (DB02) mostra uma visão geral da base de dados e seus objetos.- Database Performance Monitor (ST04) mostra uma visão geral da carga de utilização do banco de

dados. A verificação dessas estatísticas é necessária para previnir:

- Informação desatualizada para o Cost-Based Optmizer.- Criação de um grande número de extents.- Problemas de espaço.

O otimizador do Oracle pode ser usado para determinar uma estratégia efetiva de acesso aos dados.Ele analisa várias estatégias de acesso a tabelas e escolhe qual é a mais adequada para uma determinadasituação.

8/19/2019 Basis 2.0.pdf

36/234




Cada tabela e índice são associados e armazenados em uma tablespace, que consiste de um ou maisarquivos.O Oracle armazena as tabelas e índices em blocos individuais de 8KB de tamanho. Diversos blocos de umatabela ou índice são agrupados, o que forma um extent. Esses objetos de dados do Oracle possuem diversosparâmetros de armazenamento que influenciam seu crescimento.O primeiro extent (initial extent) deve ser grande o bastante para suportar o tamanho esperado da tabela ouíndice. Se um extent é completado durante uma inserção ou atualização de dados, outro extent será alocadopara a tabela dentro do tablespace.

Um objeto pode alocar extents até o máximo definido pelo sistema. No R/3, o default para o máximo é 300. Seo número máximo de extents de um objeto é atingido, o Oracle retornará a mensagem de erro ORA-1631(para uma tabela) ou ORA-1632 (para um índice).O processo de alocação de extents garante que um objeto só pedirá mais espaço quando necessário. Se nãohouver condições para que o Oracle consiga espaço livre contínuo, o sistema retornará a menssagem de erroORA-1653 (para tabelas) ou ORA-1654 (para índice). As mensagens de erro são gravadas nos logs do Oracle e no log de sistema do R/3 (transação SM21).

8/19/2019 Basis 2.0.pdf

37/234




Use o SAPDBA para verificar o seguinte:

- Fragmenteção de tabelas e índices.- Preenchimento de uma tablespace.- Consistência da base de dados.- Log de mensagens críticas de erro.- Parâmetros do Oracle.- Problemas de base de dados específicos do R/3.

Programe a execução semanal do SAPDBA usando o DBA Planning Check ou o comando sapdba – check.O resultado da verificação pode ser observado através da transação DB16.

Para evitar problemas com extents, o BRTOOLS possui um ajuste automático de extents (-next). A transação DB12 pode ser usada para verificar uma lista de tabelas e índices que alocaram mais de umextent nas últimas quatro semanas.O Database system Check Monitor (transação DB16) pode ser usado para informar quais objetos estãoexcedendo um limite de extents (default de 80) ou se aproximando do limite máximo de extents.O Monitor de tabelas e índices (transação DB02) pode ser usado para:

- Analisar as tablespaces que frequentemente apresentam problemas de espaço.

- Verificar o nível de preenchimento para determinar quais tabelas estão próximas de problemas.Use o Database System Check Monitor (transação DB16) para analisar problemas de espaço no banco.

8/19/2019 Basis 2.0.pdf

38/234




Para monitorar o processo de execução dos backups, o R/3 disponibiliza o Backup Log Monitor (transaçãoDB12), que fornece informações sobre:

- Backups de base de dados e de arquivos de redo log offline- Arquivos de log gravados pela execução do BRBACKUP e do BRARCHIVE.- O último backup que falhou.- O último backup com sucesso.- O estado do diretório de archive- Como que os backups de base de dados e de redo log offline podem ser usados em uma

recuperação de base.

8/19/2019 Basis 2.0.pdf

39/234




Uma parada no archiver pode acontecer quando:

- A base de dados está no modo ativo, mas o archiver do Oracle não está funcionando. Se issoacontecer, o SAPDBA retorna uma mensagem de erro. Nesse caso há uma chance de se reiniciaro archiver.

- O diretório de archive atinge seu limite máximo de tamanho devido às atualizações do banco.Nesse caso, mais espaço deverá ser disponibilizado no diretório de archive.

Se uma parada do archiver acontecer, o banco de dados ficará impedido de:- Gravar nos arquivos de redo log online.- Realizar qualquer modificação na base de dados.

- O SAPDBA não poderá se conectar ao banco.

Em uma parada do archiver, o monitor da base de dados salva uma entrada de erro nos arquivos de log.Para liberar mais espaço no diretório de archive, uma das soluções é armazenar em fita os arquivos de redolog offline e apagá-los. Confiar em uma só fita é sob essa circunstância é uma situação arriscada.Se houver espaço disponível, arquivos ‘temporários” podem ser criados manualmente para ocupar espaço aser liberado no caso de uma parada do archiver por falta de espaço.

8/19/2019 Basis 2.0.pdf

40/234




Criando novo usuárioPara os procedimentos de verificação de todos os documentos e autorizações, o usuário deve estar criado.

Existem 2 meios de criar um usuário : Copiando um existente ou criando um novo.

Quando criar um usuário por cópia, verifique se o perfil de segurança é válido para o usuário criado.

Entre com a transação SU01: 1

2

1. Digite ouser id (por exemplo, basis ) que será o modelo para o novo usuário.

2. Selecione Copy .

8/19/2019 Basis 2.0.pdf

41/234




3. Na janela do Copy Users , entre com o nome do novo usuário.

4. Selecione Copy ..5. Digite a password inicial (por exemplo,init ). Re-entre a mesma no segundo campo.

6. No User group , entre o grupo que este usuário irá pertencer. (por exemplo, ACCT ).

7. Você pode usar o combo box para verificar quais grupos existem.3

8/19/2019 Basis 2.0.pdf

42/234




4

8. Digite a data limite que o usuário terá acesso ao sistema.

9. Selecione a pasta Address para alterar o endereço do novo usuário.

8/19/2019 Basis 2.0.pdf

43/234




16. Selecione Defaults .1213

8/19/2019 Basis 2.0.pdf

44/234




17. Verifique qual a linguagem que o usuário irá trabalhar. O default é Inglês.

18. Sobre o Output Controller , selecione Output immediately e Delete after output . (indica que a impressãosairá imediatamente e será deletada após).

19. Verifique em qual time zone o usuário irá trabalhar.

20. Sobre o Decimal notation , selecione o sinal decimal que o usuário irá trabalhar.

21. Sobre o formato da data, selecione (por exemplo, MM/DD/YYYY).

8/19/2019 Basis 2.0.pdf

45/234




22. Clique no Save .1718Crian

Criando ddCriando novos usuários

Algumas vezes é necessário criar um usuário novo do nada “scratch”. 1. Digite a transação SU01.

2. Digite o user ID (por exemplo,gary ) que você quer criar.

3. Selecione Create.

4.,5,6,7,8,9. Entre os dados do usuário.

10. Selecione a pasta Logon data .2

8/19/2019 Basis 2.0.pdf

46/234




3 11. Digite apassword inicial (por exemplo,init ). Re-entre a mesma no segundo campo.

12. No User group , entre o grupo que este usuário irá pertencer. (por exemplo, ACCT ).

13. Entre com a data limite para o usuário ter acesso ao sistema.

14. Selecione Defaults.1112

8/19/2019 Basis 2.0.pdf

47/234




13

15. Verifique qual a linguagem que o usuário irá trabalhar. O default é Inglês.

16. Sobre o Output Controller , selecione Output immediately e Delete after output . (indica que a impressãosairá imediatamente e será deletada após).

17. Verifique em qual time zone o usuário irá trabalhar.

18. Sobre o Decimal notation , selecione o sinal decimal que o usuário irá trabalhar.

19. Sobre o formato da data, selecione (por exemplo, MM/DD/YYYY).

20. Clique no Save .

8/19/2019 Basis 2.0.pdf

48/234




21. Entre no Profile Generator (PFCG) para criar ou assinalar um perfil de acesso para este usuário.(Veja Authorizations Made Easy Guidebook).15

1618Manutenção nos usuário do sistema Antes de fazer uma manutenção no usuário, verifique com a sua auditoria se as mudanças são permitidas.

1. Digite a transação SU01 e tecle Enter.

2. Entre com o user id (por exemplo, basis ).

3. Selecione Change . (Lápis).

8/19/2019 Basis 2.0.pdf

49/234




A tela de Maintain User permite que você altere: endereço, data de logon, password, grupo do usuário, eoutros.

4. Quando terminar as alterações clique em Save .

Resetting a Password

A maior razão para zerar um usuário (reset) é com relação a sua password.Quando o usuário esquece sua password e tenta por um número de vezes entrar no sistema o usuário éautomáticamente bloqueado. Reveja na profile do SAP (RZ10) os seguintes parâmetros para controle de login .

Login/ext_security = Acesso ao sistema com segurança externa.

Login/failed_user_auto_unlock = se 1, sistema automaticamente desbloqueia usuários que estejamsuspensos por logons inválidos às 24h e 1min.

Login/fails_to_session_end = número de logons inválidos permitidos por umUser Master record até que oprocedimento de logon seja interrompido.

8/19/2019 Basis 2.0.pdf

50/234




Login/fails_to_user_lock = número de logons inválidos permitidos por umUser Master record até que ologon seja rejeitado para esse usuário. Uma entrada é registrada em System Log e ( Audit Log a partir daverão 4.0) O Bloqueio é liberado a meia-noite - (Veja parâmetro acima)

Login/min_password_lng = comprimento mínimo de senha.

Login/password_expiration_time = valor 0 significa que usuários não são forçados a mudar suas senhas.Valor maior que 0 especifica o número de dias que os usuários têm para mudar sua senha de logon .

Login/system_client = Client padrão do sistema.

Rdisp/gui_auto_logout = número de segundos após o qual a seção do usuário é interrompida porinatividade.

1. Digite a transação SU01 e Enter.

2. Entre o user ID (por exemplo,GARYN).

3. Selecione Change password .

4. Na janela do Change Password , digite a password temporária.

8/19/2019 Basis 2.0.pdf

51/234




5. Selecione Copy .

Para uma maior segurança, você deve setar a password do usuário com o valor inicial, e deixar parao usuário alterar a sua própria password.

Bloqueando e desbloqueando usuários

Locking

Se um usuário sair da empresa, ou é designado para um grupo diferente, os acessos no R/3 devem serremovidos. A funçãolock permite que o usuário e suas autorizações fiquem no sistema R/3, mas bloqueadopara uso.

UnlockingO usuário é desbloqueado, verifique antes se a requisição para esta tarefa é autorizada pela auditoria.4

5

1. Digite a transação SU01 e Enter2. Entre com o user ID (por exemplo, basis ).

3. Selecione Lock/unlock (desenho do cadeado).

4. Na próxima janela marque o usuário que será bloqueado.

5. Selecione Lock/Unlock (desenho do cadeado).

8/19/2019 Basis 2.0.pdf

52/234




23 6. Aparecerá a mensagem que o usuário foi bloqueado/ desbloqueado.

Manutenção de usuários em massa (Transaction SU10) A transação SU10 oferece a opção de manutenção em massa de usuários, inserimos a lista de usuários natransação e podemos alterar informações, incluir perfis, e realizar o bloqueio e desbloqueio de usuários emmassa.

Deletando sessão de usuários (Transaction SM04)

Use a transação SM04 para terminar uma sessão do usuário, ela mostra quais usuários estão ativos para oR/3.

Um usuário pode ter sua sessão terminada quando: sua transação está travada, seu programa está emlooping, ter um deadlock de transação, etc.

1. Verifique se o usuário não está logado no R/3, verifique ligações físicas.

8/19/2019 Basis 2.0.pdf

53/234




2. Digite a transação SM04.

6

8/19/2019 Basis 2.0.pdf

54/234




3. Selecione o user ID que será deletado. (Verifique bem, pois é muito comum clicar no usuário errado).

4. Selecione Sessions .

5. Selecione a sesão que será deletada.

6. Selecione End session .

7. Repita os passos 5 e 6 até que a sessão seja totalmente deletada.6

Impressão/Spool System

Existem dois tipos básicos de ligação entre o R/3 e as impressoras que ele poderá utilizar, são eles:Impressoras com ligação direta na rede (impressora remota).Impressoras ligadas através de um micro na rede.

Impressoras com ligação direta na rede

Neste caso o procedimento será o seguinte:

1. Indentifique o endereço IP que esta impressora possuirá na sua rede e o endereço IP do micro que estáadministrando a mesma.2. Cadastre-os no arquivo hosts no servidor R/3 (/etc/hosts).3. Crie esta impressora no sistema operacional (UNIX) do servidor R/3.4. Teste-a com enviando algum documento para impressão através do sistema operacional (UNIX) do

servidor R/3.5. Concluido a instalação da mesma no sistema operacional, vamos agora criar esta impressora no R/3

através da transação SPAD.

8/19/2019 Basis 2.0.pdf

55/234

8/19/2019 Basis 2.0.pdf

56/234




8. Na tela de criação do dispositivo você terá as seguintes informações: Dispositivo de saída: nome que este dispositivo será chamado no R/3. Nome Breve: abreviação do nome do dispositivo de saída no R/3. Ctg. de dispositivo: selecione o driver que seja compatível com o dispositivo de saída. Servidor de edição: selecione o servidor R/3 que irá administrar este dispositivo. Impressora host: informe o nome que este dispositivo possui no sistema operacional (obedecendo letras

maiúsculas e minúsculas). Classe aparelho: selecione o tipo de dispositivo que está sendo instalado, no nosso caso Impressora

normal. Tipo acoplam. p/spool host: informe o modo que o R/3 se comunicará com o dispositivo, no nosso caso

nós utilizaremos a opção L - Impressão local via LP/LPR. Modelo: informe o modelo da impressora (Opcional). Localização: informe onde a impressora está localizada (Opcional).

8/19/2019 Basis 2.0.pdf

57/234




Mensagem: informe uma mensagem que o usuário visualizará impressão. Bloquear impressora pág SAP: se selecionado bloqueia a utilização deste dispositivo.

Folha de rosto SAP: se selecionado emitirá uma folha de rosto para cada trabalho a ser impresso.

8/19/2019 Basis 2.0.pdf

58/234




9. Preenchido estas informações, salve-as e a partir deste momento este dispositivo estará disponível paraos usuários do R/3. Observe o exemplo abaixo.

8/19/2019 Basis 2.0.pdf

59/234




Impressoras ligadas através de um micro na rede

Segue abaixo o procedimento para instalar impressoras com esta característica no sistema R/3.

1. A impressora a ser utilizada pelo R/3 deve estar instalada no sistema operacional do micro que possuiacesso ao R/3.

2. Deverá ser acionado um aplicativo chamado SAPLPD que é instalado junto com o front end. Vocêobservará que ao acioná-lo ele exibirá o endereço IP que este micro está utilizando na rede e o nome domesmo, como no exemplo abaixo.

3. Estes dois dados deverão constar no arquivo hosts (/etc/hosts ) do servidor R/3, viabilizando acomunicação do servidor (UNIX) com este micro (Windows ). Note que este micro deverá possuir umendereço IP fixo na rede, pois se o mesmo está configurado para receber o seu endereçoautomaticamente através do DHCP ele poderá ter o seu endereço IP trocado tornando a comunicaçãocom o servidor R/3 (UNIX) inviável, pois o mesmo não será atualizado pelo DHCP.

8/19/2019 Basis 2.0.pdf

60/234




4. No R/3 você acessará a transação SPAD.

5. Selecione o botão dispositivos de saída, esta tela exibirá todos os dispositivos de saída configurados parao R/3.

6. Selecione o botão modificar e para criar um novo dispositivo acesse selecione o botão criar.

7. Na tela de criação do dispositivo você terá as seguintes informações:

Dispositivo de saída: nome que este dispositivo será chamado no R/3. Nome Breve: abreviação do nome do dispositivo de saída no R/3. Ctg. de dispositivo: selecione o driver que seja compatível com o dispositivo de saída (Neste caso,

independente da impressora que estamos utilizando, será selecionado a opção SAPWIN - Rel

4.x/SAPLPD 4.x ONLY!). Servidor de edição: selecione o servidor R/3 que irá administrar este dispositivo. Host de comutação: informe o nome do micro que possui a impressora que será instalada. Opções...: ele exibirá três campos de configuração, são eles: Tmp.estr.conex (tempo de timeout para

conexão em segundos, padrão 60s), Tempo resposta (especifica o tempo limite para receber umaresposta do dispositivo, o valor padrão está definido no parâmetro rspo/tcp_timeout_connect no profile dainstance) e Número de porta (número da porta disponível para comunicação com o dispositivo).

Impressora host: informe o nome que este dispositivo possui no sistema operacional (obedecendo letrasmaiúsculas e minúsculas).

Classe aparelho: selecione o tipo de dispositivo que está sendo instalado, no nosso caso Impressoranormal.

Tipo acoplam.p/spool host: informe o modo que o R/3 se comunicará com o dispositivo, no nosso caso nósutilizaremos a opção L - Impressão local via LP/LPR.

Modelo: informe o modelo da impressora (Opcional). Localização: informe onde a impressora está localizada (Opcional). Mensagem: informe uma mensagem que o usuário visualizará impressão. Bloquear impressora págSAP: se selecionado bloqueia a utilização deste dispositivo. Folha de rosto SAP: se selecionado emitirá uma folha de rosto para cada trabalho a ser impresso.

8/19/2019 Basis 2.0.pdf

61/234




TMS Authorization Concept

O usuário que irá configurar oTMS deverá estar logado no client 000 e possuir autorização S_CTS_ADMIN.

Para evitar um acesso indevido no R/3 através do TMS:O TMS sempre verifica a autorização no sistema destino.O RFC do sistema destino são gerados durante a configuração e não podem ser modificados.O Transport Domain do R/3 externo não pode acessar o Trasnport Domain do meu R/3.

Selecione :

Overview > system > R/3 system > check > connection test para verificar a conexão com o RFC.

Overview > system > R/3 system > check > trasnport directory para verificar a disponibilidade do sistema detransporte.

Overview > system > R/3 system > check > transport tool para verificar o programa TP.

Overview > system > configuration > distribute para distribuir a configuração do Domain Controler para osoutros sistemas R/3.

Overview > system > configuration > activate > in all domain para ativar todos os Transport Domain.

Overview > system > configuration > activate > local para ativar o Transport Domain local.

8/19/2019 Basis 2.0.pdf

62/234




Change Management for Development

O sistema R/3 pode ser ajustado de acordo com o negócio da empresa que estiver implementando-o dasseguintes formas :

Customizing : Ajusta os processos do negócio da empresa ao R/3 de acordo com as funcionalidades do IMG.

Personalization : Alterar algumas telas, campos, pré-determina valores do existente no R/3.

Modification : Alterar os objetos repositórios existentes.

Enhancement : Altera os objetos repositórios utilizando de user exit.

Customer Development : Cria novos programas ABAP.

8/19/2019 Basis 2.0.pdf

63/234




Todos os objetos repositório que são alterados e criados através do ABAP WORKBENCH são registradosnuma Change Request.

A transção SE09 , mostra as Change Requests, informações dos transportes , e provê acesso de suasferramentas.

8/19/2019 Basis 2.0.pdf

64/234




A Change Request registra as mudanças nos objetos repositórios ou nas entradas de tabelas.

O conteúdo da Change Request é armazenado nas TASKS correspondentes ao desenvolvedor específico.

Com a SE09 , podemos criar, alterar, liberar e deletar request, adicionar usuário para uma request existente,adicionar tasks a uma request.

8/19/2019 Basis 2.0.pdf

65/234

8/19/2019 Basis 2.0.pdf

66/234




S_A.SYSTEM = usada por um superusuário com todos os direitos no CTS.

S_A.CUSTOMIZ = usado pelo Líder de projeto acesso total as Requests.

S_A.DEVELOP = usada por desenvolvedores e customizadores, acesso total as Tasks.

S_A.SHOW = usada por Basis visualização do CTS.

8/19/2019 Basis 2.0.pdf

67/234




Registering Developers in SSCR

Todo desenvolvedor ABAP deve ter o seu código no SSCR (Sap Software Change Registration) na qual éobtida através do OSS.

Somente um desenvolvedor registrado pode criar e modificar objetos no repositório.

Para prevenir conflitos com os nomes de objetos, quando criamos nossos objetos, existe uma convenção paraos nomes.

Os programas desenvolvidos por terceiros fora a SAP, devem começar com Z ou Y – veja nota 16466.

8/19/2019 Basis 2.0.pdf

68/234

8/19/2019 Basis 2.0.pdf

69/234




Development Class

Todos os objetos são assinalados a uma classe de desenvolvimento.

A classe de desenvolvimento são objetos de ABAP Workbench e podem ser criados pelo Browser dorepositório.

As classes de desenvolvimento que não são standard começam com:

Z ou Y – classe de desenvolvimento que o objeto pode ser transportado.

S - classe de desenvolvimento com objetos temporários e não serão transportados.

T - classe de desenvolvimento para objetos locais que estão ligados ao workbench Organizer.

STMP – é usado quando o objeto é salvo no repositório local e não é registrado numa classe dedesenvolviemnto.

Criar uma classe de desenvolvimento – selecione a transação SE80 – marque o nome da classe e clique nodisplay.

8/19/2019 Basis 2.0.pdf

70/234




R/3 Repository Object Locking

Os objetos originais podem ser modificados por desenvolvedores que estejam assinalados no Workbenchchange request.

Existem 2 meios de bloquear objetos que serão modificados:

O editor de programa trabalha com enfileiramento de work process e isto assegura que somente umdesenvolvedor por vez pode modificar um objeto.

O workbench change request assegura que o objeto do desenvolvedor seja assinalado para uma task numarequest e que quando este objeto for sofrer uma alteração, só poderá ser feito pelo desenvolvedor assinaladona request.

Os objetos também podem ser manualmente inseridos na request, mas esses objetos não sãoautomáticamente bloqueados; Para isso temos que bloqueá-lo manualmente através do caminho:Request task > object list > lock objects.

8/19/2019 Basis 2.0.pdf

71/234




Quando liberamos uma request :

Grava-se a versão mais nova do objeto no banco de dados.Desbloqueia os objetos.Exporta os dados contidos na request quando a mesma é transportada.

A versão do objeto no repositório pode ser comparada e restaurada.

O Development DB contém as versões ativas e temporárias.

O Version DB contém todas as versões gravadas através de uma liberação de request.

8/19/2019 Basis 2.0.pdf

72/234




Para acessar o Repository Browse, use a transação SE80 .

Para acessar o Workbench Organizer, use a transação SE09 .

Os return codes válidos são:

00 – o export foi executado com sucesso.04 – Existem warning, porém o export foi executado.08 – Um dos objetos contidos no request não foi transportado.12 – Erro crítico.

8/19/2019 Basis 2.0.pdf

73/234




Na SE09 , visualizamos os transportes e repair. O semáforo indica o resultado do transporte.

Execução OK.

Execução com Warning.

Execução com erros.Quando um erro é identificado, o atributo da request pode ser alterado pressionando o ícone Error Corrected Na tela da SE09 .

8/19/2019 Basis 2.0.pdf

74/234




Os tipos de objetos são :

PROG – Programa ABAPDEVC – Classe de desenvolvimento.VIEW – Visão de tabela.FORM – Form ABAPCOMM – Arquivos com comandosCHD0 – Mudança de documentos

Somente o usuário DDIC poderá alterar os atributos dos objetos, exceto o Original Language .

O caminho é SE09 > tools > abap workbench > overview > workbench organizer > goto > tools > objectdirectory.

Repair Flag – são todos os objetos modificados, sendo standard ou não .

Generation Flag – são objetos gerados automáticamente por customizing.

Os objetos são originais somente num sistema, nos outros são tidos como cópia.

8/19/2019 Basis 2.0.pdf

75/234




Antes de um Upgrade todas as Repairs devem ser confirmadas e liberadas através da ferramenta PREPARE.

Para ajustar o dicionário de Dados durante o Upgrade use a transação SPDD .

A transação SPAU consolida todos os objetos do repositório.

8/19/2019 Basis 2.0.pdf

76/234




Para ativar o Transport Erros global , selecione: Tools > abap workbench > overview > workbench organizer> goto > tools > administration > global customizing workbench e marque a opção Globally Activated .Para um usuário específico marque a opção Can be set for specific user .

8/19/2019 Basis 2.0.pdf

77/234




Change Management for Customizing

Customização típica, cria e altera entrada de várias tabelas através de visões (View) e de client dependent.

8/19/2019 Basis 2.0.pdf

78/234




A SAP provê várias ferramentas para suportar a implementação:

Customizing:

Implementation Guide (IMG) – é a principal ferramenta de customização.

Customizing Organizer (CO) – SE10 grava as alterações de customizações na Change request com o tipoCUST.

Development:

Abap Development Workbench – desenvolvimento abap.

Workbench Organizer (SE09) – grava o desenvolvimento abap na Change request de tipo SYST.

Implementation Guide

Um projeto noIMG pode ser gerado para cada sistema R/3.

As funções selecionadas podem ser alteradas e regeradas, a transação utilizada para acessar o IMG é SPRO .

8/19/2019 Basis 2.0.pdf

79/234




O IMG provê todas as transações de customização para o projeto.

Oferece acesso online de todas as informações requeridas na customização e ferramenta de gerenciamentoDo projeto

Para visualizar os itens do IMG que são Client Dependence, selecione: tools > business engineer >customizing > enterprise IMG > information > title and IMG info > client dependence .

Para visualizar os itens do IMG que são transport Dependence, selecione: tools > business engineer >customizing > enterprise IMG > information > title and IMG info > transport dependence .

8/19/2019 Basis 2.0.pdf

80/234




Client Change Options

Para acessar o Client change Option use a transação SCC4 .

Change without automatic recording permite que se altere as tabelas, mas não inclui automaticamente essasmudanças na request.

Pode se incluir as alterações manualmente na request, da seguinte maneira:1- Entre na transação de customização.2- Use a opção Table/View Transport .3- Preencha as informações da request.4- Selecione as entradas que serão incluidas na request aberta.5- Clique na opção Include in transport .6- Salve.

Automatic Recording of Changes permite que se altere as tabelas e esta alteração é incluida automáticamenteNa request.

No Changes Allowed não permite alteração nas tabelas.

No Transport Allowed permite que as tabelas sejam alteradas, mas não permite que sejam transportadas.

8/19/2019 Basis 2.0.pdf

81/234




Por causa do dinâmismo de acesso as tabelas durante a customização, ambos clients (dependente eindependente) não estão protegidos contra regravação. As tabelas são bloqueadas enquanto as transaçõesde customizações estão sendo usadas, mas são desbloqueadas quando as alterações são completadas esalvas na request.

Para ativar o LOGIN para Changes to Customizing Tables , selecione a transação OY18 .

Geralmente todos os objetos são transportados para o sistema Destino na qual eles existem no sistema Fonte,os objetos transportados do sistema fonte regravam os objetos no sistema destino que tem o mesmo nome,estes objetos são deletados do sistema destino se eles não existirem no sistema fonte.

8/19/2019 Basis 2.0.pdf

82/234




Release and Export – copia as entradas das tabelas do banco de dados para um arquivo do sistemaoperacional (no sistema fonte).

Release to Request – libera e copia a change request de customização para change requst transportável.

Após liberar a change request customizing , lembre-se de verificar a execução do EXPORT pela transaçãoSE10 .

8/19/2019 Basis 2.0.pdf

83/234




Transport Management

Quando é feito o EXPORT, os arquivos de dados são armazenados no diretório usr/sap/tr

Date post:	08-Jul-2018
Category:	Documents
Upload:	ary-j-b-almeida
View:	219 times
Download:	0 times

Basis 2.0.pdf

Documents