as some of you may have experienced, BDLS has changed in releases from NW640 upwards. the 'new' BDLS cannot be run in parallel any longer, every attempt of doing so leads to the jobs aborting or getting 'stuck'. apart from this news the absurdly long runtimes of BDLS are grating on the nerves of every basis person who has to do a lot of system copies.
i met my challenge last week and i think i have found a way out of this dead end.
Step 1. Since the new BDLS refuses parallel runs, don't use it
the 'old' BDLS is still around and - SAP reassured me - can be used as of old without any damage being done. so i did it. in order to get a report generated which you can use for your parallelization, rund RBDLS2LS using tx. SE38 in background for a couple of minutes, then abort it. by then it should have generated a report with the name RBDLSXXX (where XXX = the number of the client). that's the one you want.
Step 2. Help the database work, create temporary indexes
after the report RBDLSXXX has been generated, have a look at the coding and search - for example - for table GLPCA. you will recognize that this report will scan GLPCA twice, first for field LOGSYS, second time for field AWSYS. other tables contain up to 3 fields that match the scan criteria and each scan run will only operate on one of the fields. i'm not perfectly sure why, but i think all of those fields may (in certain setups) contain different information and not necessarily the same information in all of the fields, so that might be the reason for several scans on the same table.
identify all of the tables that need scanning and conversion. the most easy way to do so is to run the new BDLS in test mode and have a look at the tables BDLSHDR and BDLSPOS afterwards. you need not do this every time, but every now and then - just to be sure you have even the newly created (custom or otherwise) tables.
create an index for every field that identifies for the scan. in our example, create:
Index Z01 on GLPCA for field LOGSYS / if operating on a MaxDB, avoid fields indicating the client, in this case RSCLT
Index Z02 on GLPCA for field AWSYS / ...
continue to do so for the largest tables that will be converted, like CE1ZZZZ, VBAP, GLPCA, VBUK, COEP ... and several others. if using an IS or add-on there might be several more ...
some databases do not take kindly to the attempt of indexes created in parallel, like in our example: creating Z01 and Z02 at the same time might not work - switch to sequential processing in such a case.
Step 3. Create Variants
create variants for your report RBDLSXXX and try to make packages that make sense regarding the size of the tables per package. select the tables to be converted like: A* to D* (caution: if on MaxDB this will proceed all tables the names of which begin with A, B and C - it will not proceed on tables starting with a D, so in this case, make your variants either overlapping, like A* to D* and the next from D* to G* or simply add single values for the selection). for tables the names of which start with '/' and such ... there is note telling to create a variant with the selection: exclude A* to Z* ... again: for MaxDB this does not work. MaxDB interprets such a statement as: proceed all tables the names of which begin with a Z and then it stops. i ended up, naming the tables in such namespaces singularly.
try to exclude as many of the biggest tables as possible by naming them in your variants. for example: if table CE1ZZZZ does not have any values in the fields LOGSYS, there is no need to scan/convert the table. excluding them will shorten the runtime. you can check on such tables using tx. TAANA, grouping by the fields to be scanned.
with the 'old' BDLS there is no obligation to do a testrun before doing a conversion. so you might want to de-flag the testrun option.
de-flag the 'check for every entry' also.
SAP sometimes advises to enlarge the commit-counter up to 10.000.000 - i was none to happy with that and after several experiments i let it be on the default value of 100.000
Step 4. Adjust Operation Modes and/or Process Setup
depending on the number of variants you will want for as many batch-processes as there are variants. your hardware setup allowing for such, try to create operation modes (RZ12) that will switch dialogue-processes to batch during runtime. make sure, you leave some dialogue-processes for logins etc.
Step 5. Run your jobs and Clean Up
run as many jobs in parallel as you are able to, split if necessary. do not forget to drop the indexes you created in step 2. as they might badly influence the overall system performance for "normal" tasks and are no longer needed. frees the space used, also.
Statistics
all the figures given now were taken on a NW640/22 ERP 5.0 / MaxDB 7.6 / Linux 2.6 / size of DB: 1 TB / mode: conversion run / DB-cache empty (directly after startup).
GLPCA without any indexes: 32 hours
GLPCA with one index on both fields LOGSYS and AWSYS: 15 hours
GLPCA with two indexes, one for each of the fields LOGSYS and AWSYS: 7 seconds
complete run of new BDLS without variants, exclusion of tables, and indexes: 108 hours
complete run of old BDLS with improvements of step 1 - 5: 3 hours
hope this helps
