RepoScan guide question ( run -repair with back-up )

[former_member422662]

Bellow is the reposcan guide:

https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=143065487

In the "Business Intelligence Platform Repository Diagnostic Tool User Guide" there is the following statement:

It is recommended that you back up your CMS database and FRS filestore, and run the RDT against the backed-up version while your SAP BusinessObjects Business Intelligence platform services are down. If this is not possible, RDT can be run on an active database.

However there are no clear steps for this best practice.

Can someone provide a feedback on this process ?

This is how I see it:

1. Stop BO (completely)

2. Run back-up on DB and FRS

3. Run reposcan with -repair ( against DB and FRS )

4. Start BO

Recovery: If something goes wrong, stop BO restore DB and FRS and start BO

[amitrathi239 · Accepted solution]

Reposcan is run against of CMS DB.So you can stop the BO services.All your steps looks correct for me.

One question but why you want to run the reposcan command?

[former_member422662 · Accepted solution]

Hello Amit,

There were some complains regarding the performances issue.

Running the reposcan without the -repair flag we found out that we have 2000 file on the FRS and 30 objects in the DB that are invalid. ( please let me know if you have any suggestions )

Thank you for the answer.

[amitrathi239 · Accepted solution]

then yes reposcan.

[former_member422662 · Accepted solution]

Hello Amit,

I am still confused about the first bullet point statement:

What should be taken special care when running RDT Be careful with the parameter "-repair" which tells the RDT to repair all inconsistencies. Repair actions that the RDT takes while users are accessing your deployment can create further inconsistencies.

• So do not to run the RDT against a live CMS database and FRS.
• Or at least not to use the "-repair" option against live CMS.

( https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=143065487#HowtouseRepositoryDiagnosticToo... )

Run them against the back-up? what would be the testing process to see that nothing went wrong ?

I couldn't find any articles that advice on what tests to perform after the -repair or "what could go wrong"

[ivanyin · Accepted solution]

In most cases, "Repair" actually means "Delete" in this scenario. RDT will delete all the inconsistencies either from CMS DB or from Filestore.

It is always dangerous to delete something and it is always a good idea to do a double confirm and make a bake up before really deleting something.

[Joe_Peters · Accepted solution]

reposcan can screw up your environment -- taking a backup beforehand is a good idea.

It deleted a bunch of valid instances in our environment. I haven't run a -repair since. What I've done instead is run it without -repair, and then manually make changes based on the output.

[denis_konovalov · Accepted solution]

"live CMS" in this scenario means CMS that is being accessed by users.
When you run reposcan -repair, make sure you have backup of CMS DB/FRS and no users are using the system.

[former_member422662 · Accepted solution]

We'll perform a full back-up.

Joe, I would fix them manually as we only have 20 "Inconsistent Objects".

Attached an example but I don't know how I can fix those ( all are similar ).

inc-objects.png

I've tried to find more details on the internet but without any results.

Then we have have 2000 inconsistent files on the FRS. We'll remove those using the -repair flag.

[denis_konovalov · Accepted solution]

User9122 object is pointing to a user or a group or a folder or a report that is no longer exist.
So, you need to find this object and see what it is, what it does, what properties it has and where it points/who it references

[Joe_Peters · Accepted solution]

The specific error in your screenshot appears to be caused by a universe overload that includes a user or group who no longer exists. You might be able to correct it by editing and saving the overload.

Joe