SAP ILM (IQ back end) after system refresh - missing ZILMSTORRD* objects in IQ

[Oldskoolskater]

Hi,

We have SAP ILM connected to IQ databases across our landscape (Dev/QA/Prd) and all have been archiving to their respective IQ databases successfully. We have recently refreshed the QA NW stack from Prd and I am having issues getting ILM in QA working again.

Previous archive information was not required as part of the refresh so I have dropped the existing QA IQ database and provisioned a new one to avoid issues with broken logical links, etc.

Archive objects in NW have been deactivated, corresponding infostructures deleted, then reactivated. This did not generate the ZILMSTORRD* objects in IQ as I expected it would.

As a result archive jobs are failing at the store stage due to the objects being missing (a quick sp_iqdbspaceinfo shows there to be no object_names present)

I feel I'm very close to resolving but missing that last piece of the puzzle i.e. how are the ZILMSTORR* objects created and the required steps to resolve this.

I've been through all the Neenu Susan George and Roland Kramer blogs that I'm aware of but can't find this particular piece of information.

Could anybody please advise on what I'm missing?

thanks

[NeenuSGeorge]

Hello Steve,

Could you give more details on the exact error shown in the store job. Are you getting a "Table does not exist" error? You can also check transaction SLG1 for object ILM_STOR for the error logs.

Also, I understand that you now want to store new archive files into the IQ database, and do not want to access any older stored files. Is this understanding correct?

Best Regards,

Neenu

[Oldskoolskater]

Hi Neenu,

This is the output from the store job

And the corresponding SLG1 output

In terms of landscape and usage, you are correct.

QA and PRD are as you would expect completely independent of one another so each has its own respective IQ server back end, table structure, licence, SID, system users, etc.

When planning the system refresh I'd reached agreement with our functional teams that previously archived information does not need to be accessible. If this had been a requirement I would have copied the PRD IQ files back to the QA IQ server but that presumably also brings with it complications at the IQ DB level when reconnecting everything.

The functional teams requirement is that they can test the archiving process in QA with new data from the refresh, rather than access data prior to the refresh.

[Oldskoolskater]

Just spotted an ST22 dump for this highlighting the failure due to absence of the ZILMSTORRD* tables

[andreas_baldauf]

Hello Steve,

SAP ILM Store stores information about the IQ tables in field TABLE_INSTANCE_NAME of tables TILM_STOR and TILM_STOR_POOL. Information about the archive files and paths are stored in additional tables (e.g. ADMI_FILES, DAS_COLLECTIONS). So there are complex relationships between several table that should be understood before deleting IQ tables.

I suggest that you restore the SAP IQ database (or at least the ZILMSTORRD* tables.

Best regards,
Andreas

[Oldskoolskater]

Thanks Andreas,

When you say restore the IQ database, do you mean:

1. Restore the source PRD IQ DB over the target QA IQ DB
2. Restore the original QA IQ DB over the newly created QA IQ DB

If option 1, then this would be possible, noting that there will now be more archiving information in there as the refresh happened a couple of weeks ago (not a big deal). All references would need to be changed from PRD to QA also.

If option 2, then this would also be possible though presumably the logical links, table structures, etc. would not be aware of the refreshed NW stack.

Thanks

Steve

[andreas_baldauf]

Hello Steve,

If I understand you correctly, you have refreshed your QA ERP system (S/4HANA or ECC 6.0) with the data from your Prd ERP system (including the tables ADMI_RUN, ADMI_FILES, TILM_STOR_POOL, TILM_STOR, DAS_COLLECTIONS, etc.). At the same time you have dropped the existing QA IQ database and set up a new one.

Is that correct?

If yes, in my opinion you should also refresh the QA IQ system with the data from the Prd IQ system. For this purpose, you should use the backup of the Prd IQ database that was created exactly on the same time as the backup of the Prd ERP database that was used as the basis for refreshing the QA ERP system.

According to the dump, table ZILMSTORRDD940DB is missing. So there should be an entry in the table TILM_STOR_POOL where the column TABLE_INSTANCE_NAME has the value D940DB. Could you please check and provide a screenshot of the table?

Best regards,
Andreas

Attention: No liability is assumed for any damage.

[Oldskoolskater]

Hi Andreas,

That is correct (ECC 6.0)

That said, I don't think all the tables you mention were perhaps refreshed, as I can see that TILM_STOR_POOL has 7 entries in Prd but it has 65 in QA. I will check with the team that performed the refresh for further detail.

Our backup & recovery team are looking into such a restore for me at present, though in the meantime a check in the table TILM_STOR_POOL shows an entry for D940DB

D940DB also exists as a table

Indeed, the only place I cannot find it is at the IQ database level, hence why it is dumping out.

Thanks

Steve

[andreas_baldauf]

Hello Steve,

There are several ways to solve the problem. Before you change anything (e.g. restore a backup of the Prd IQ database or the QA IQ database; create empty ZILMSTORRD* tables in the QA IQ database, ...), you should

- understand how your QA ERP system was renewed,
- understand the relationships between the involved tables (e.g. ADMI_RUN, ADMI_FILES, TILM_STOR_POOL, TILM_STOR, DAS_COLLECTIONS), the data dictionary and the IQ System,
- understand in advance the effects of your action.

From my point of view, it makes sense to renew the QA IQ system as well when renewing the QA ERP system, so that transactions that read archived data can also be tested on the QA ERP system.

Best regards,
Andreas