character set confusion
- From: Robyn <robyn.sands@xxxxxxxxx>
- To: oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 13 Jul 2007 19:49:36 -0400
Hello all,
What are the limitations of materialized views across character sets? We
will be upgrading the source database for many, many materialized views to
Oracle 10.2.0.2 in a few months. We will also be converting the database to
UTF8 although that will probably occur a few months later. The target
database is, at the moment, 9.2.0.8 and USASCII7. It too will be upgraded
eventually but I need to determine if there is a reason to perform the
upgrade simultaneously with the upgrade and/or the UTF8 conversion. Both
databases have been around for many years; about a third of the objects in
question still use the SNAP$ convention.
It seems logical to me that there would be the potential for the target to
be unable to hold some of the data stored in the UTF8 source database, but
every test I've run has worked. I did manage to hit the bug with the big
endian/little endian issue but once that patch was in, no problems. I've
opened a case with Oracle, but their answer was brief and not very
reassuring. Supposedly, if I upgrade both databases to 10g, I won't have
to worry about any differences in character sets. Somehow, that's not
making sense to me and no logic was offered with the answer.
So is there some kind of conversion that occurs in the materialized view
process? Or would I eventually hit some bit of data that could not be
stored in the target database if it remains USASCII7? Would it make more
sense to convert both to UTF8? I've got time to plan for this and I'd like
to do it right, short of having to convert to completely new form of
replication overnight.
Suggestions appreciated, including any test cases that might conclusively
prove the possibility of failure. I'd rather find out now than at 3:00 am
on Feb 23rd 2009.
tia ... Robyn
Other related posts:
