One feature we’ve been anxiously awaiting when VisualWorks 7.5 was in development is support for Unicode ODBC.
(self connection getSession)
unicodeEncoding: #’UCS-2′;
unicode: true;
yourself.
Naturally as soon as it became available my inclination was to turn it on and over time migrate our database schema from varchar() to nvarchar() and from char() to nchar() etcetera. Sounds reasonable? I thought so myself, but it took about a month of running this small change in production to prove me wrong. Take a look at the server CPU graph below (Hint: Unicode was enabled late August and disabled late October),
Looking back, it all kind of makes sense. I suspect ODBC layer is encoding everything on the way out, so running a query against a plain old varchar() column with a Unicode parameter SQL ended up having to encode all row values on the fly, essentially resulting in endless table scans and lots of CPU wastage for most basic scenarios. Turning off Unicode or changing the offending column to n*char() fixes the problem.
What this means, however, is that you can’t conceivably go the Unicode route without converting all *char() columns to n*char() columns at the same time. You can certainly afford to have a small performance impacting window to ensure availability, but it would most certainly be unreasonable to stretch this transition period. So much for piecemeal approach, sigh.
Categories:
