cancel
Showing results for 
Search instead for 
Did you mean: 

NTFSCENTERAMIGRATOR.exe - Centera Collection partition fills without moving to ATMOS.

robinhollins
Level 3

I have recently added an EMC ATMOS device as a Centera Partition to our Enterprise vault configuration.  I have begun migrating all our closed partitions to the device and am having intermittant problems.

Sometimes the collection partition fills without moving savesets to the centera target and sometimes it works fine.  I seem to have to create the job, restart the storage service then leave it for an hour or so then restart the storage service again.  Sometimes even this doesnt work and it just fills the 30Gb partition I have created and crashes the Service anyway.  I have around 7TB to move.

I can progress the jobs by fudging it but have concerns about future performance.

I found the following : Article: TECH144758http://www.symantec.com/business/support/index?page=content&id=TECH144758 http://www.symantec.com/business/support/index?page=content&id=TECH144758  

I am unsure if this applies to our environment as it seems to only refer to v8.0 upgraded to v9.0 with no mention of later revisions?  Does this mean it is included in v9.02?

Current config :

EV 9.02 upgraded from v8 - Hotfix not applied before upgrade.

I should also mention that connectivity tests using EV and JcenterVerify come back succesfull everytime.

Any comments / help welcome.

1 ACCEPTED SOLUTION

Accepted Solutions

John_Chisari
Level 6
Partner Accredited

That hotfix is already in EV9 SP2 it's what makes the upgrade to large VS databases take so long :)

What you are describing with having to restart the storage service for collections to go down I think has been fixed in EV9 SP3.

Unreplicated Centera clip could block further post processing [Ref 9039594, E1992210] - detailed in this technote http://www.symantec.com/docs/TECH126043

also the changes made around here

Improvements to Storage File Watch [Ref 9030269, 90310412, E2523803, E2069020]

There have been some improvements to the Storage File Watch process.

  • Storage File Watch failed to scan Centera partitions that had not been replicated. The Storage service had to be restarted periodically. This has been fixed.
  • Storage File Watch failed to process items when several million items were waiting to be processed. This has been fixed

View solution in original post

6 REPLIES 6

JesusWept3
Level 6
Partner Accredited Certified

you're going to have to get traces of SFW and the migrator exe to really see whats going on as well as any errors showing in the event logs or other log files the utility produces

 

best bet may be to call support as intermittent issues doesnt sound like its going to be an easy quick fix

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

JesusWept3
Level 6
Partner Accredited Certified

oh and definitely put the sql index in there, cant make it any worse, and in some circumstances can really help

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

Percy_Vere
Level 6
Employee Accredited

Perhaps the fact that it is an EMC Atmos and not mentioned in the EV compatability guide is the problem.

http://clientui-kb.symantec.com/kb/index?page=content&id=TECH38537&key=50996

I suggest you do what JesusWept2 advised and call support, that way you should find out for definite.

 

AndrewB
Moderator
Moderator
Partner    VIP    Accredited

percy has a good point about the atmos not mentioned in the compatibility guide but when i had issues with centera collections, implementing this reg tweak really helped

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

John_Chisari
Level 6
Partner Accredited

That hotfix is already in EV9 SP2 it's what makes the upgrade to large VS databases take so long :)

What you are describing with having to restart the storage service for collections to go down I think has been fixed in EV9 SP3.

Unreplicated Centera clip could block further post processing [Ref 9039594, E1992210] - detailed in this technote http://www.symantec.com/docs/TECH126043

also the changes made around here

Improvements to Storage File Watch [Ref 9030269, 90310412, E2523803, E2069020]

There have been some improvements to the Storage File Watch process.

  • Storage File Watch failed to scan Centera partitions that had not been replicated. The Storage service had to be restarted periodically. This has been fixed.
  • Storage File Watch failed to process items when several million items were waiting to be processed. This has been fixed

robinhollins
Level 3

Thanks John,

it certainly seems to be very very similar to the issue I am experiencing.  Ill check out SP3 later today and apply out of hours later in the week to see if it resolves the issues. 

I had guessed the fix was already in SP2 but it seemed unclear that if the DB had been upgraded from 8 to 9 weather the fix needed reapplying.

Anyway fingers crossed,

Many Thanks

Rob