Active IQ Unified Manager Discussions

OCUM 7.2 Upgrade - Performance Data Migration failed - SQLException !

sanadmin_stadtdo
10,106 Views

Hello,

we have updated our OCUM (vmware appliance) from 7.1 to 7.2. The performance data must be migrated for 4 clusters with a total of 10 nodes.
While this has worked smoothly with 3 clusters, a cluster with 4 nodes breaks again and again with 'Failed':

 

Wed Aug 23 08:12:50 CEST 2017 - Data migration completed for Optional[summary_wafl]
Wed Aug 23 08:12:50 CEST 2017 - Data migration completed for Optional[summary_networklifVserver]
Wed Aug 23 08:12:50 CEST 2017 - Data migration completed for Optional[summary_nfsv3]
Wed Aug 23 08:12:50 CEST 2017 - Data migration completed for Optional[summary_aggregate_1]
Wed Aug 23 08:12:50 CEST 2017 - Data migration completed for Optional[summary_cifsvserver]
Wed Aug 23 08:12:51 CEST 2017 - Data migration completed for Optional[summary_quos_workload_queue_dblade_1]
Wed Aug 23 08:12:51 CEST 2017 - Data migration completed for Optional[summary_quos_workload_queue_nblade_1]
Wed Aug 23 08:12:51 CEST 2017 - Data migration completed for Optional[summary_disk_1]
Wed Aug 23 08:12:52 CEST 2017 - Data migration completed for Optional[summary_quos_workload_detail_1]
Wed Aug 23 08:12:52 CEST 2017 - Data migration completed for netapp_performance database
Wed Aug 23 08:19:26 CEST 2017 - Error Message: PreparedStatementCallback: uncategorized SQLException for SQL [SELECT Cause : java.io.EOFException: unexpected end of stream, read 31 bytes from 80

Do you want to retry the data mirgation from cluster FAS80402 (failed) Y/N ?

 

 

It is always the SQLException above.

Once at "read 31 bytes from 80", then "read 57 bytes from 76" or even "read 61 bytes from 77"

 

 

Any idea?

Many Thanks

Michael

1 ACCEPTED SOLUTION

niels
9,886 Views

Hi Michael,

 

this looks familiar and unfortunately you are not alone. This could be a known problem which is logged under BURT 1102280.

Please open a case and refer to that BURT. Support should be able to provide you parameters to tweak some MySQL settings.

Basically the migration wizard runs into a timeout because of a large number of objects that need to be retrieved from old OPM DB.

 

regards, Niels

 

----

If this post resolved your issue, please help others by selecting ACCEPT AS SOLUTION or adding a KUDO or both.

View solution in original post

15 REPLIES 15

niels
9,887 Views

Hi Michael,

 

this looks familiar and unfortunately you are not alone. This could be a known problem which is logged under BURT 1102280.

Please open a case and refer to that BURT. Support should be able to provide you parameters to tweak some MySQL settings.

Basically the migration wizard runs into a timeout because of a large number of objects that need to be retrieved from old OPM DB.

 

regards, Niels

 

----

If this post resolved your issue, please help others by selecting ACCEPT AS SOLUTION or adding a KUDO or both.

sanadmin_stadtdo
9,801 Views

Hello Niels,

Thank you very much. You were right - there were runtime problems.

After I had opened a case, I got a tutorial from the support, how I had to adjust the timeout-parameter (net_write_timeout) in the my.cnf-file of the MySQL at the Performance Manager.

After that the transfer of the performance data worked.

Best regards

Michael

PaulF
9,595 Views

@sanadmin_stadtdoI have the same issue, out of interest what value did you add to net_write_timeout, whatever i try the migration keeps failing.

 

Thanks

 

 

niels
9,591 Views

Hi PaulF,

 

I suggest to open a case.

This should be investigated and documented.

 

regards, Niels

PaulF
9,571 Views

Hi

 

I have a case open already just curious as to what value worked as it continues to fail for me.

sanadmin_stadtdo
9,503 Views

Hello Paul,

 

sorry I didn't answer until now, I was on vacation.

 

I've tried different values. With net_write_timeout=4800 it finally worked.

 

Best regards

 

Michael

 

kman2123
7,155 Views

Where do you insert or add that value? 

TMADOCTHOMAS
7,132 Views

If you mean the option in 7.2 to import up to 13 months of data from the OCPM 7.1 database, it's option #8 on the main OCUM console menu.

kman2123
7,096 Views

No the mysql update change. I have a ticket open with NetApp. He told me what values I need to change a little bit ago.

colsen
9,568 Views

Shoot - wish I had seen this earlier.  We ran into the same issue with our OCPM 7.1->7.2 migration - frankly we decided we'd just start with a clean slate (more out of the need to move on to other pressing matters than anything) so we just deleted the old OCPM 7.1 vApp...

 

Oh well - thanks for the posting though!

 

Chris

TETRAHEDRON
9,343 Views

We started with a parallel install of the OCUM 7.2 appliance, to evaluate it.  This ran fine, but failed to migrate the historic OCPM data, showing the error you described.  I discovered that an in-place upgrade of our OCUM 7.1 appliance successfully migrated the OCPM performance data, even though it also showed the same migration errors.

 

In two different instances, an in-place upgrade of our OCUM 7.1 appliances successfully migrated historic OCPM performance data, even in the presence of these data migration errors.

MratyunjayMudgal
9,221 Views

Anybody observed that after migrating Data from OCPM 7.1 to OCUM 7.2p1, last 15 days data (Performance Data) is missing even after successfull data migration.

 

We face java exception issue Wed Aug 23 08:19:26 CEST 2017 - Error Message: PreparedStatementCallback: uncategorized SQLException for SQL [SELECT Cause : java.io.EOFException: unexpected end of stream, read 31 bytes from 80 and resolved successfully but last 15 days performance data still missing. 

TMADOCTHOMAS
7,571 Views

I had the same issue. Opening a case and working through MySQL changes resolved the issue for me as well.

niels
7,556 Views

That looks to be working as designed.

OCUM will poll the last 15 days directly from the Performance Archiver Files of ONTAP, so the migration from the old OPM instance only takes data from the past up until now-15 days.

So this should resolve itself.

If not, you may need to open a case to have this investigated further.

 

regards, Niels

TMADOCTHOMAS
7,539 Views

We're actually referring to something beyond the 15 days ... there's an option in 7.2 to import up to 13 months of data from the OCPM 7.1 database.

Public