What are teh 3196 errors?

I saw something similar where EV wouldn't do anything for a task because it had mailboxes that no longer existed lingering in the A3 queue, as from an archiving stand point that would be the highest priroity, so anything in A3 should take presedence over anything else.

So once i found out the user didn't exist, purged the queue and then it ran, but in that instance (EV9 SP1) it would actually fail the task, the task wouldn't remain running.

What i would suggest if you can is just to Dtrace the Archive Task for 30 minutes and upload it if you can.

But you may have bigger issues than this, you may want to check your SQL Server for any locking or blocking, as if SQL gets bottlenecked, then EV will remain unresponsive, and theres an olidish issue that still lingers regarding the ArchiveFolder table, and if it meets a ceterain looping condition then it brings EV to its knees

I'll check with my sql engineer. maybe he can run some diags o the sql server. I'll be back with I find. thanks.

Can you post the event's related to the 3196 event ID?

It was just 2 events and it was for two mailboxes that were removed. The events are not related as I've been having this probem for about two weeks wthout those events.

hmm okay.

I rescheduled mailbox synchronization to run at 9 am, once a day only. The A7 queue was empty last night, yet the Items Archived per Hour report shows only 12 archives processed between midnight and 8 am. EV archives 1000 items in a mailbox before moving on to the next one. it have processed well over 1000 mailboxes alst night. i used to process that many when i was archivign 5000 items per mailbox.

Not only are there no errors in the Symantec Enterprise Vault event log, but there are no entries period between midnight, info event 3156 (Start to process the Exchange system) and 9:05 am, warning event 41261

It is more than 2 days since backup or replication was detected for one or more open partitions.
Open partitions not scanned: 1
Total open partitions: 1
List of partitions:

but, the a5 queue has over 2000 entries in it.

I meant to say EV should have processed at least 1000 archives last night, but did not..

I would suggest logging a case with Support as there are a lot of things that need looking at, something that cannot easily been done via forum posts.

I've been working with Symantec Support since last week. We still can't figure out what is wrong. Have check EV in and out and it all looks ok. So far the only possible problem is the hard drives on the sql server. Tney are heavily fragmented. some was suppsoed to defrag them this past weekend. Still waiting for an update on that. Other than the we can't figure out why EV is archiving and synchronzing so slowly.

Well, after spending a little over a week working with symantec it turns out that the performance issues must be related to hardware. We are going to defrag the 900+ GB Index drive this weekend as well as the 1 TB drive that contains the active partition. Hopefully this will increase performance until we can move the EV partitions to something faster than a sata drive.

If anyone can think of anything else I can do to increase performance, please let me know.

Thank you all for you help.

If you're talking about doing defrags on the SQL drives, then great, be sure to do all your maintenance plans too (rebuilding SQL indexes and the like) however defrag of your EV indexes and EV vault store data wouldn't cause any issues or slow downs with synchronizations.

We've already defragged the sql drives and the sql databases are properly maintained,  but that did not increase performance. Tthe symantec tech I spoke too said defragging the drives that the vault index and partition is on might help. What else can I do. There are no errors in EV. We ran dtaces, recreated the archive task and even ran a DBCC SHOWCONTIG command in sql and all looked ok.

The case was closed today but can be reopened within 10 days.
I have an SQL "expert" and he tells me that SQL is ok, but I will ask him the same question you asked me.
We did dtrace the archivetask and I sent it to Symantec. They told me everything looked normal.
CPU and memory of SQL was confirmed ok by my SQL engineer.
I've checked the exchange server logs and there are no errors.
One of my server engineers ran a performance monitor during my midnight to 8am schedueld archive run and thaere were high disk drive i/o rates
I've checked Exchange inside and out and its ok.
I have gone through all the logs on the ev server and there are no errors. As a matter of fact no events are registered in the EV log between midnight and 8am, which I find strange to begin with.

Access to archvied email is just fine.

Everything in Exchange and Enterprise vaylt works fine, except that archiving has slowed down tremendously.

Dont suppose you have Moved Items enabled in your Archiving Policy do you?

I am attching a screenshot of our SQL sentry screen showing sql activity. My sql engineer says all the wait time is from the front end, meaning the EV server.