When an ASM database crashed for one of our clients and the database repair options failed, TAC recommended a full ASM DB reset on the lines of K6992

The KB article doesn’t really explain the full behavior.

As per the TAC, the policy name remains as it is, think of it as a “container”. This is because the virtual servers are referring to these policies hence the script keeps them intact but deletes all the “insides” of the policies, stuff like parameters, URLs and so on.

You then need to do a simple config sync from the peer unit to get all of that back.

However, once you run the script, the behavior is a bit tricky.

The policies all disappeared and over the next few minutes those policies keep coming up and the count goes up one by one and slooowwly

This looks a bit weird when you first see it, so just relax it all should be fine.

Our peer device had a count of 50 policies and the one on which I did the reset went up to 45 and stopped.

At this stage, I just synced from the peer unit, and again the policy count started going up one at a time and eventually reached 49. I am guessing it deleted some of the policies which were not assigned to a virtual server.

The F5 kb article indeed is very wanting on the expected behavior.