cancel
Showing results for 
Search instead for 
Did you mean: 

SQL query to change backupcomplete to 1

juggernaut1
Level 5
Partner Accredited Certified

anyone have a sql statement to update the journalarchive table where backupcomplete = 0 to one on a specifig archiveid..

trying to work around the movearchive task as it is waiting for backup at destination.. 

i tried to attrib and ignorearchive bit and they haven't workedt yet..

 

Thanks in advance.....

1 ACCEPTED SOLUTION

Accepted Solutions

JesusWept3
Level 6
Partner Accredited Certified

Please please please don't run that query, it will just flood your event logs with errors because each item with a backupComplete = 0 means that it relies on an item in the watchfile table, so when it attempts to delete the record from the Journal table, you will get a 1336x error saying that theres a foreign key constraint because of the item in the watch file table.

You should probably look at IgnoreArchiveBitTrigger.txt instead for the easiest way to get out of it.
However because of the way that OSIS works, you may find that if you have multiple vault stores in the Vault Store Group, it may be awaiting the backup of a shared part in another vault store partition and not the one you are concentrating on.

 

https://www.linkedin.com/in/alex-allen-turl-07370146

View solution in original post

5 REPLIES 5

AndrewB
Moderator
Moderator
Partner    VIP    Accredited

this should do the trick. substitute your vault store db and the vaultID that you need to set this for.

use VaultStoreDB
update JournalArchive
set BackupComplete=1
where VaultID='VaultID'

JesusWept3
Level 6
Partner Accredited Certified

Please please please don't run that query, it will just flood your event logs with errors because each item with a backupComplete = 0 means that it relies on an item in the watchfile table, so when it attempts to delete the record from the Journal table, you will get a 1336x error saying that theres a foreign key constraint because of the item in the watch file table.

You should probably look at IgnoreArchiveBitTrigger.txt instead for the easiest way to get out of it.
However because of the way that OSIS works, you may find that if you have multiple vault stores in the Vault Store Group, it may be awaiting the backup of a shared part in another vault store partition and not the one you are concentrating on.

 

https://www.linkedin.com/in/alex-allen-turl-07370146

juggernaut1
Level 5
Partner Accredited Certified

i tried the ignorearchiebit as well..    the issue is that move archive is stuck at waiting for backup destination etc..    trying to move the process a long. I think what  could be causing this is the partition is set up for collections and the config for that is 10 days and 25 megs..   I tried the movearchive config setting to not check for backup but that seems to not be working...

JesusWept3
Level 6
Partner Accredited Certified

Well the thing is with collections is that an item will not go in to a CAB file until it has been backed up and secured, so if the item is awaiting backup, the item will not be in a CAB file and will remain in the watchfile table.

So really what I would suggest is dtrace the StorageFileWatch and then restart the Storage Service and see what its doing and why items arent being marked as secured.

Heres a question though, I don't suppose you have your JournalArchive table set to a SQL 2000 compatibility level do you?

https://www.linkedin.com/in/alex-allen-turl-07370146

LCT
Level 6
Accredited Certified

What version of EV are you running? It's not 9.0.3 or 10.0.0 for the destination environment is it? There is currently a bug with a backup issue ie.e. with the post-processing processes.

http://www.symantec.com/business/support/index?page=content&id=TECH180841

You should check and confirm that you have the same issue before applying the hotfix (and if you are running the affected EV version).

I am running 9.0.3 and I had this issue and I had to apply it last week to get the post-processing working properly.

It is believed that this issue has been fixed with 10.0.1 and also in 10.0.2 when it is released. If you have the same problem I would suggest you report it to SYMC tech support too.