Active IQ Unified Manager Discussions

OCUM 7.2 Upgrade - Performance Data Migration failed - SQLException !

sanadmin_stadtdo
11,789 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
11,569 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
11,570 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
11,451 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
11,245 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
11,241 Views

Hi PaulF,

 

I suggest to open a case.

This should be investigated and documented.

 

regards, Niels

PaulF
11,221 Views

Hi

 

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

sanadmin_stadtdo
11,153 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
8,805 Views

Where do you insert or add that value? 

TMADOCTHOMAS
8,782 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
8,746 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
11,218 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
10,993 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
10,871 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
9,221 Views

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

niels
9,206 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
9,189 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