844-NOGALIS (844-664-2547)
Nogalis, Inc.
  • Link to Facebook
  • Link to X
  • Link to LinkedIn
  • Link to Mail
  • Company
    • News, Events and Articles
    • About Us
  • Products
    • Infor Lawson Data Archive
    • PeopleSoft Data Archive
    • Oracle Data Archive
  • Services
    • Infor Lawson Support
    • Infor Lawson / CloudSuite Consulting
  • Education & Training
  • Support
  • Contact Us
  • Click to open the search input field Click to open the search input field Search
  • Menu Menu

AWS Schema Conversion Tool Error 602

Articles, Frontpage Article, News

When migrating schemas to MySQL using the AWS Schema Conversion Tool (SCT), you may encounter the error:

“602: Converted tables might exceed the row-size limit in MySQL.”

This warning means that one or more tables being converted could exceed MySQL’s row-size limit. For the InnoDB storage engine (default in MySQL and Amazon Aurora MySQL), the maximum row length is 65,535 bytes. If your converted table design goes beyond this, MySQL will reject it.


Why This Happens

  • Large VARCHAR or TEXT columns
  • Too many columns in a single table
  • Wide columns that, when combined, exceed the 64KB limit
  • Non-optimized data types during schema conversion

Fixing the Issue

  1. Review and Optimize Column Data Types
  • Reduce overly large VARCHAR lengths. For example:
    • VARCHAR(1000) → VARCHAR(255) if values never exceed that length.
  • Replace TEXT with smaller types (TINYTEXT, MEDIUMTEXT) where possible.
  • Use integers (INT, SMALLINT, TINYINT) instead of BIGINT if values fit.
  1. Normalize the Table

If your schema has too many wide columns:

  • Split them into multiple related tables
  • Use foreign keys to maintain relationships
  • Store large blobs of data separately
  1. Drop Unnecessary Columns

Remove unused or redundant columns before migration to shrink the row size.

  1. Consider Storage Engine Options
  • InnoDB enforces the row-size limit but stores large TEXT/BLOB columns off-page (only a 20-byte pointer remains in the row).
  • If you only need full-text lookups, splitting those into reference tables may help.
  1. Change InnoDB Page Size (Advanced)

By default, InnoDB uses a 16KB page size. MySQL allows compilation with different page sizes (4KB, 8KB, 16KB, 32KB, 64KB).
⚠️ Important: This cannot be changed dynamically. You must recompile MySQL from source with a custom setting.

  • Download MySQL source
  • Modify the UNIV_PAGE_SIZE definition
  • Rebuild and reinstall MySQL
  • Re-import your schema and data

This approach is rarely used in practice because it complicates upgrades and maintenance, and is not supported on managed services like Amazon RDS or Aurora MySQL.


Best Practice in AWS Context

Since you’re working with AWS SCT and likely using Aurora MySQL or RDS, you cannot change InnoDB page size. Instead, the best fix is to:

  • Normalize your schema
  • Adjust column definitions
  • Split oversized tables

Takeaway

The 602 error in AWS SCT isn’t a hard failure—it’s a warning that your schema design may hit MySQL’s row-size limits. While increasing InnoDB page size is technically possible in self-managed MySQL builds, on AWS-managed databases the right solution is schema redesign and column optimization.


✅ Rule of thumb: If you’re migrating from Oracle, SQL Server, or DB2 into MySQL, review the largest tables carefully. Wide schemas that were fine in those engines may not fit in MySQL’s stricter row limits.

 

Retiring Lawson, PeopleSoft, or Oracle? APIX archives the entire application — every table, every year, attachments and security included — into your own AWS account in about 30 days, so you can decommission the legacy system and keep full access to the history.

See how the APIX ERP archive works →

03/27/2026
Share this entry
  • Share on Facebook
  • Share on X
  • Share on WhatsApp
  • Share on LinkedIn
  • Share on Reddit
  • Share by Mail
https://www.nogalis.com/wp-content/uploads/2026/03/AWS-Schema-Conversion-Tool-Error-602.jpg 470 470 Angeli Menta https://www.nogalis.com/wp-content/uploads/2013/04/logo-with-slogan-good.png Angeli Menta2026-03-27 08:02:422026-03-19 16:08:43AWS Schema Conversion Tool Error 602

LEGACY ERP DATA ARCHIVE SOLUTION



Discover how our clients are leveraging AWS services to archive their Legacy ERP data and provide ubiquitous access to users via a light-weight, secure, and read-only web interface. Secure, Fast, Reliable, and Cost Effective. That is the promise of APIX. Follow the link below to find out more and book a discovery call with our data archive specialist.

BOOK DEMO

© Copyright - Nogalis, Inc. 2026
  • Legal
  • Privacy
  • Contact Us
Link to: Why ERP Ecosystems Are A Strategic Architecture Decision Link to: Why ERP Ecosystems Are A Strategic Architecture Decision Why ERP Ecosystems Are A Strategic Architecture Decision Link to: Weekly Patch Notification: March 28, 2026 Link to: Weekly Patch Notification: March 28, 2026 Weekly Patch Notification: March 28, 2026
Scroll to top Scroll to top Scroll to top