Csscan tool would do the inventory activity and present the results in three files about the consequences of such a conversion. Of course still needed to do a proper analyses about the data present in the database before starting such conversion, plan a scenario in pre-production to do the conversion, do a lot of analyses of the results, run the same scenario ( run inventory do an impact analyses first on production, making a backup, do the conversion and do a lot of post checks ones that conversion has completed).īefore Oracle 12 two tools would need to be used to do the conversion. If the new character-set is a super set ( if it is holding the same characters ( and at the same location in the character table)) then a conversion will be possible. There is one exception to the above scenario where you always will have to recreate the database to get to the desired (new) character-set. Of course only to be done after testing such a scenario on a pre-production environment and only after careful analyses of the results in the reports to check the data before moving such scenario to the production environment. As a rule of thumb one could even say if the character set is wrong the data present in the database needs to be extracted (with tools like datapump), the database would need to be recreated in the new character-set after which the data can be added (inserted) again. Plain and simple if the Character-set is not chosen correctly there might be an issue converting the character set (if possible at all ) if you want to set it to the one desired at a later point and time. When setting up a new database there is of course a lot to be considered as in sizing of the database ( sizing during start and lets say after 12 Months ), the users and their privileges but there is one extra very important topic to think of well ( think of twice would even be better ) and that is the character set.
#ORACLE DATABASE CHARACTER SET SOFTWARE#
Oracle software is trying to protect you by keeping a max of 7 days between analyses and conversion and of course that makes sense given the fact that the data of course will continue to grow during and after the first analyses. Oh and of course ( test test test test ) and have a backup in place before doing this on your live production boxes. With the knowledge gained from those reports they (application – datamodel) aware people will then have to fix issues if any in the Source database before running another analyses ( scan ) before doing a conversion.
But this can only be achieved after careful checking first and if checks show actions are needed then you will Need a team with application – datamodel knowledge look into the reports that will be generated during the inventory part of the scenario. Below are some thoughts, things to remember if you are really heading in such direction.Ī management summary of this article would be: Yes it is technically possible to move the character set of a database from we8iso8859p15 to al32utf8. Goal would be to move from we8iso8859p15 to al32utf8. Recently a request came in to investigate options to change the character set for a number of core databases. Mission Critical system with Oracle Rac.Oci clone and create Pdbs in Same Container.Cloning a Pdb with Different Character set into your CDB.There may also be performance implications if you are running an additional database running basically the same workload on the same machine- that's obviously going to put additional load on your I/O subsystem, your CPU, RAM, etc.
But configuring Streams and testing the failover process in lower environments can be somewhat challenging, particularly if the old and new databases are going to be on the same server.
That would allow you to switch over to the UTF8 database in a matter of seconds. If you're willing to invest a fair amount of time and effort, you could set up the UTF8 database, configure Streams to replicate data between the systems, and then have the UTF8 database be a few seconds behind the primary. How much effort are you willing to expend to shorten the downtime window?Īssuming your estimates that it would take 10 hours to export and 10 hours to import the database are correct (and assuming that you're benchmarking the DataPump versions of these tools if you're using 10.1 or later), that would require a 20 hour downtime window (or 10 hours if you're willing to lose all changes made while you're taking the export which seems unlikely). What version of Oracle are we talking about?
0 kommentar(er)
