Informix

 View Only
  • 1.  GL_COLLATE & GL_CTYPE

    Posted Mon November 30, 2020 05:01 PM
    Hi,

    Currently we used default setting for GL_COLLATE & GL_CTYPE en_US.819. We plan to convert this database to GL_COLLATE & GL_CTYPE to en_US.57372, How to do this? Right now, look like we need to used dbexport data and dbimport back data using environment setting export DB_LOCALE=en_US.57372 before run dbimport. It will take longer time because our data size is too big & that process will need more than 2 days downtime. Any method can we used to change GL_COLLATE & GL_CTYPE to en_US.57372? 

    Our Informix version is 14.10 FC3 (HP ITANIUM)

    Please advice.

    Thank You

    ------------------------------
    MOHD FADZIL JUSOH
    ------------------------------

    #Informix


  • 2.  RE: GL_COLLATE & GL_CTYPE

    IBM Champion
    Posted Tue December 01, 2020 04:15 AM
    Hello,

    so what you want is for your database to be converted from (default) en_us.819 standard asci codeset to utf8 - which indeed cannot be done in place.
    Traditional - and disruptive - method, as you said, is export and re-import using target DB_LOCALE.

    An alternative, non-disruptive approach is offered by Enterprise Replication (ER) since this now supports codeset conversion between databases being replicated, through its --UTF8 option.
    For this you'd have to create a UTF8 copy of your database and replicate each and every table (that is important to you) between original and new database, probably as a two-way "update-anywhere" replication, with your applications connected to the old one until you feel the new one is fully in sync with the old one, at which point you could start bringing applications over to the new database.

    Zero downtime if all goes well - yet you've got to invite ER into your life ;-)
    For more convenience, all this even is pre-packaged in 14.10's "cdr migrate server" feature (which actually is more a "migrate database").  To take advantage of codeset conversion/migration, though, you'd have to rely on the 'scripted' variant and manually modify the target database's DB_LOCALE, and you had to rely on data being moved through replication (rather than remote inserts).

    BR,
     Andreas

    ------------------------------
    Andreas Legner
    ------------------------------