Unsecured SIS parts in other partitions.
Hi All,
The EV Operations Manager site shows me that “Number of Saveset files awaiting backup or replication” is 163. I know it’s not a very big number compared to some that I have seen described here but it has been static for quite a while which made me start looking into it.
All partitions are set to “Check for trigger file”, EV enters backup mode successfully, backups have completed successfully, trigger files have been created in all open and closed partitions and then EV is taken out of backup mode. After this, all the trigger files are automatically renamed to IgnoreArchiveBitTrigger.old by EV. The Status section on the Backup tab of each partition has a very recent date under “Last item secured”.
I have 3 partitions with "Unsecured SIS parts in other partitions". I could be wrong but logically I would expect there to be a similar number in "Unsecured SIS parts in local partition" on other partitions.
There are 163 items in the WatchFile table all with ItemSecured set to 1 and 163 items in the JournalArchive table with BackupComplete set to 0. There are 193 items in the WatchSISPartFile table. I’m guessing more than one SISPart for some of the items in the WatchFile as there are 163 distinct SavesetIdentity’s.
Can anyone offer any suggestions to take this further?
Thanks,
Mark.
Hi Rob,
Sorry, I forgot to come back and update this. I had a call open with Symantec and they used some internal SQL scripts to update the Secured flag of the SIS parts in question in the Fingerprint database. I was a bit uncomfortable with what felt like a hack but after providing DTrace's and deployment scanner logs a root cause wasn't found. I haven't had a chance (or a need) to revisit the issues I was having trying to use EVSVR though.
From memory the basic stages we went through are below in case anyone reads this thread in years to come.
If you have any thoughts on this process (positive or otherwise), I'd appreciate hearing them.
Thanks,
Mark.--
We went through the following article (again):
Why items may get 'stuck' in a Pending State - Enterprise Vault (EV) Basic Archive Process: http://www.symantec.com/business/support/index?page=content&id=TECH66202Once that was done, the engineer changed focus to a particular Saveset ... which explained the link between the vault store database and the fingerprint database member tables that previously stumped me. Here's the instructions from that conversation:
<<
1. Logon to SQL and change focus to the Vault Store database
2. Run the following SQL query to check that the DVS item is secured
SELECT SavesetIdentity,ItemSecured FROM WatchFile WHERE SavesetIdentity = 'SaveSetIdentity'
This will return the SaveSetIdentity and if it is secured (which it should be)
3. As the SIS parts are referenced in the fingerprint database, we need to locate which table in the database holds the SIS part reference
SELECT SavesetIdentity,FPDistinctionByte,ParentTransactionId FROM WatchSISPartFile WHERE SavesetIdentity = 'SaveSetIdentity'
This will return the SaveSetIdentity with the finger print MemberTable (FPDistinctionByte) and the item's ParentTransactionID
4. Knowing this information we can check that the SIS part has been secured.
Change focus to the fingerprint database
SELECT ParentTransactionId,Secured FROM MemberTable_FPDistinctionByte WHERE ParentTransactionId = 'ParentTransactionId'
>>Following that he used evsvr with the dumpsaveset switch to confirm that the saveset and all its sisparts could be recombined successfully (I was concerned that if the Sisparts weren't "Secured" in the fingerprint database it may not even exist on disk).
Once my arm was twisted that the cause was probably due to a glitch during an upgrade at some point and no data was missing, we went ahead and updated the Secured flag on the SISPart.
The manual process was: UPDATE MemberTable_FPDistinctionByte SET Secured = 1 WHERE ParentTransactionId = 'ParentTransactionId'
The Engineer needed to get approval from backline support before he could use a bulk approach to perform this task and mentioned that this should NEVER be done without Symantec support supervision so I won't repeat all the details but the basics were:
Ran ‘CreateSPFindUnsecuredSISParts.sql’ script to create the stored procedure.
Ran ‘Select unsecured sis parts.sql’ script and took the count of unsecured SISparts.
Ran ‘Reset sis parts unsecured status.sql’ script and now all the SISparts are secured.
--