Forum Discussion

Rob_dos_Ramos's avatar
Rob_dos_Ramos
Level 6
14 years ago

Storage Queue disappeared

Hi All

 

The strangest thing happened when trying to upgrade EV 9 to EV 9.0.1

 

Installation went through fine and the upgrade went through fine on most of the DB's. Except for the  journal database. 

After all of this we restarted the EV server as is our procedure. But when the server came backup the storage queue was no longer there. 

Tried reinstalling MSMQ, Installing Reinstalling EV redoing the upgrade but nothing. 

The system details:

Windows 2003 Standard edition 64 bit SP2

VMware server

Currently looking after 12 exchange servers (new another EV server being implemented Early next year) 

Any ideas how to recreate the Storage Queue? 

 

The errors we are getting are as follows,

 

Event Type: Error
Event Source: Enterprise Vault 
Event Category: Storage Online 
Event ID: 8390
Date: 12/20/2010
Time: 12:24:01 PM
User: N/A
Computer: ***
Description:
The EnterpriseVault.DirectoryConnection object reported an error.
 
One or more arguments are invalid
 
Internal references:
Error 0x80070057
CDirectoryConnectionObject::GetSyncSlotInfo .\DirectoryConnectionObject.cpp [lines {10426,10430}], built Nov 24 00:04:09 2010 
 
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp
 
Event Type: Error
Event Source: Enterprise Vault 
Event Category: Storage Server 
Event ID: 13360
Date: 12/20/2010
Time: 12:26:08 PM
User: N/A
Computer: ***
Description:
An error was detected while accessing the Vault Database '' (Internal reference: CADODataAccess::ExecuteSQLCommand .\ADODataAccess.cpp [lines {1393,1395,1410,1447}], built Nov 24 00:04:01 2010): 
 
Description:  
 
[Microsoft][ODBC SQL Server Driver][SQL Server]Could not find any index named 'IX_Vault_ArchivePointIdentity' for table 'dbo.Vault'.
 
 
SQL Command: 
 
IF NOT EXISTS (select * from dbo.sysindexes where name = 'IX_Vault_ArchivePointIdentity' and origfillfactor = 80)
BEGIN
CREATE INDEX [IX_Vault_ArchivePointIdentity] ON [dbo].[Vault]([ArchivePointIdentity]) WITH FILLFACTOR = 80, PAD_INDEX, DROP_EXISTING ON [PRIMARY]
END
 
 
Additional Microsoft supplied information:
 
Source:       Microsoft OLE DB Provider for ODBC Drivers 
Number:       0x80040e14 
SQL State:    37000 
Native Error: 00007999 
HRESULT 0x80040e14
 
 
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp
 
Event Type: Error
Event Source: Enterprise Vault 
Event Category: Journal Task 
Event ID: 6531
Date: 12/20/2010
Time: 9:47:26 AM
User: N/A
Computer: ***
Description:
Failed to open Queue: Enterprise Vault Storage Archive Queue
Queue FormatName: \Enterprise Vault Storage Archive
The queue does not exist or you do not have sufficient permissions to perform the operation.  [0xc00e0003] 
 
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp
 
SQL server is located on the same server (Planning to move it soon)
 
 
Any ideas would be great. 
Configuring
Enterprise Vault
Information Governance
Recovering
Troubleshooting
Upgrade
  • Rob_dos_Ramos's avatar
    Rob_dos_Ramos
    14 years ago

    Well Symantec was unable to help me as it would require pro services to get involved. 

     

    So I decided to play around a little and found that because EV could not complete the upgrade of the journal database it would not recreate the queues, so I it follows procedures and if one is not met then the whole thing crashes. 

     

    I removed the Journal database from the directory records and then detached the Journal database. 

     

    Once that was done all queues came back on line. So I restore the directory database and now I need to work out how to upgrade the journal database. 

     

    Thanks for all the help

8 Replies

Sort By
  • GertjanA's avatar
    GertjanA
    Moderator
    14 years ago

    Hi Rob,

    I've heard (through the grapvine as the saying is I believe) there are some weird things happening. As you write your upgrade of the Vault Store database failed, that might be the culprit.

    Normally speaking, queues should be (re-)created when the services start, and the queue is not there. However, the errors you list indicate problems with either the directory database, and/or the store database.

    I strongly suggest you stop archiving, and call support (with a system-down priority)

     

    To quick verify, you do have a storage service (yes service) on the machine?

    If not, manually create it. Make sure VSA is local admin, and does have rights to the MSMQ location.

  • Rob_dos_Ramos's avatar
    Rob_dos_Ramos
    Level 6
    14 years ago

    Thanks for the reply, 

     

    I do have a storage service, do you know of a way to delete the service and recreate it? I have logged a call but they have not gotten back to me. 

  • Rob_dos_Ramos's avatar
    Rob_dos_Ramos
    Level 6
    14 years ago

    Tried to delete the store service but with no luck. EV states that data is associated to data and can't be deleted.

     

    Still waiting for support to get back to me. Listed it as system down.

  • Rob_dos_Ramos's avatar
    Rob_dos_Ramos
    Level 6
    14 years ago

    Well Symantec was unable to help me as it would require pro services to get involved. 

     

    So I decided to play around a little and found that because EV could not complete the upgrade of the journal database it would not recreate the queues, so I it follows procedures and if one is not met then the whole thing crashes. 

     

    I removed the Journal database from the directory records and then detached the Journal database. 

     

    Once that was done all queues came back on line. So I restore the directory database and now I need to work out how to upgrade the journal database. 

     

    Thanks for all the help

  • GertjanA's avatar
    GertjanA
    Moderator
    14 years ago

    Hello Rob,

    There are some SQL-scripts in the EV installation folder that are run in a specific order to upgrade the database(s).

    There called something like:

    VaultStoredb_9_updates.sql, updates2.sql, programmability.sql and main.sql

    I'm not sure about the order they are run in, but if you can figure that out, or get it from support, you should be able to run them manually on your journaldb, and see where they crash, and (if you are good, or if you have a good dba) you should be able to fix any issues with either the script or the db.

     

    Good luck...