Como verificar o progresso da execução do BDLS e evitar que ele fique 'travado'

John,

Gosto das possibilidades desta publicação e o timing é perfeito. Tenho uma atualização de 6TB na próxima semana e é o nosso processo mais lento para a conversão de BDLS. Existe uma nova transação BDLSS que consiste em dois passos. O primeiro passo escaneia todas as suas tabelas que contêm LOGSYS para verificar se alguma linha possui dados no campo. O segundo passo atualiza apenas as tabelas relevantes (a parte de atualização real é rápida). Portanto, sob este processo, consigo ver como alguns podem dizer que excluir tabelas é irrelevante porque a fase de escaneamento inicial está identificando as únicas tabelas relevantes.

No entanto, o escaneamento para verificar quais tabelas precisam de atualização leva uma eternidade se você for como nós e tiver milhões de linhas em algumas tabelas. A boa notícia é que posso pegar os resultados da última execução e identificar muitas dessas tabelas monstruosas que não estão usando seu LOGSYS de forma alguma e tentar excluí-las do passo de escaneamento inicial. Isso tem a possibilidade de me economizar muito tempo.

Atualmente, meu BDLS levará vários DIAS se simplesmente deixar escanear tudo. Vou testar sua abordagem em nosso sistema ECC 6.0 (Basis 7.0 SP19) e ver quanto consigo reduzir meus tempos. Da última vez, levou mais de 3 dias apenas para encontrar 9 tabelas que precisam de algumas milhares de linhas atualizadas. Foi uma grande perda de tempo.

Obrigado,

Richard

Georgia-Pacific

Se este tópico ainda estiver ativo... tenho algumas informações para adicionar, bem como uma pergunta para o grupo.

Costumava usar o código BDLSC para excluir várias tabelas da execução do BDLS. BDLSC é uma transação simples que atualiza a tabela BDLSEXZ. A única opção que usávamos no BDLSC era a opção "Tabela excluída". Inseríamos tabelas que sabíamos que não era necessário atualizar.

Como sabíamos quais tabelas não precisavam de atualização?... observávamos o BDLS em SM50 - esperávamos que ele 'travasse' por muito tempo em uma tabela. Então verificávamos essa tabela através do SE16 - contávamos o número de registros onde LOGSYS (ou AWSYS, etc.) não estava vazio. Se nenhum registro fosse retornado, não havia nada para atualizar no BDLS. Cancelávamos o trabalho, adicionávamos a tabela à lista de exclusão através do BDLSC e começávamos de novo. Com o tempo, adicionamos as tabelas conhecidas ao BDLSC no sistema de produção, deixamos que fossem copiadas de volta para Q durante a atualização e estávamos prontos para continuar.

A outra forma como aceleramos as coisas foi através de um programa ABAP personalizado que fazia atualizações diretas em algumas tabelas grandes onde realmente precisávamos atualizar o LOGSYS. Tenho certeza de que haverá pessoas que considerarão isso um grande erro. Tudo bem - entendo... mas suponho que muitos clientes SAP tenham feito isso.

Minha pergunta aqui se refere ao uso do BDLSC. Disseram-me que não é necessário. Que o BDLS só dedicará tempo a atualizar tabelas que tenham dados no LOGSYS. Se todas as entradas estiverem vazias, ele irá pular a tabela. Tentarei verificar no código, mas alguém poderia comentar se isso é verdade?

Obrigado,

-john

Olá,

1. Execute o relatório RBDLSMAP_RESET para limpar execuções antigas ou travadas do BDLS.

2. Crie o Índice temporário para as tabelas identificadas como enormes e que contêm os campos (AWSYS, LOGSYS, SNDSYSTEM, RCVSYSTEM, etc.) - isso pode ser identificado se você realizar uma execução de teste ou escrever um trecho de código para identificar tais tabelas.

3. Após a criação dos Índices - execute o relatório RBDLS2LS (através do SE38).

4. Aparece a tela normal do BDLS - aqui, insira o intervalo de tabelas.

5. Após executar o relatório RBDLS2LS pela primeira vez no sistema, crie um novo relatório RBDLS<client.no.>.

6. Agora, use o relatório RBDLS<client No> para programar o BDLS mais tarde (isso permite execuções em paralelo também).

Estamos testando isso agora e houve uma melhoria significativa no tempo de execução do BDLS. Esta abordagem é essencial para sistemas de tamanho TB.