The current encoding of oracle instance is WE8ISO8859P1 and needs to be moved to UTF-8. I have found some challenges in my database instance due to its current setup and requirements of my business.
This instance in question has 100+ schema users with number of tables created under each schema. We can say logically each schema exists for application or specific system within the enterprise. The requirement is to move only certain schema and their table objects to new character set of UTF-8.
Also, remember the reason for this migration right now is compliance with Restful POST calls that will perform CRUD operations in UTF format.
NLS_NCHAR_CHARACTERSET- AL16UTF16
NLS_CHARACTERSET- WE8ISO8859P1
I did do some research earlier and here are my findings.
• Oracle doesn’t support character encoding at the tablespace , table or column level. Therefore options start reducing for any charset migration strategy at schema level only.
• We have CRUD calls by other enterprise legacy systems to this schema. Therefore should not have a any wider impact. Off course, other schema's in this instance doesn't have any requirements of UTF-8.
The only way I see a solution is
OPTION 1 - Move the target schema and thier objects into new database instance with NLS_LANGUAGE to be UTF-8.
OPTION 2 - Converting all the relevant columns to NCHAR and NVARCHAR but with loss of length and truncation.
Both the approaches lead to big impact and not able to conclude what is best. Any suggestions are welcome that solves my charset migration without impact and changes to other schema in the instance.
Related
In oracle what's the differences between a database and a table space?
A little terminology:
Oracle defines a database as the set of files that you find on your Oracle system. This means all data in your Oracle system is in these database files, commonly known as "data files". There are other files in the database such as parameter files and redo logs.
On the other hand, an instance consists of the processes and memory areas that Oracle database uses. Together, a database and an instance make up a database system. (For more information, see the Oracle Concept guide)
Logically, you will want to define different spaces within that database. This is done via tablespaces (see Oracle Concept guide). A tablespace usually consists of one or more data files. When you define a table with CREATE TABLE, you can specify in which tablespace the table should be created. This allows you to seperate different applications on the same database system, for example.
The Oracle Concepts guide is an excellent source of information for questions like these. See this picture on how data files and tablespaces are composed.
Let's consider an example of an Ocean consist of lots of water. Now you want that water. For this what you do is collect water in barrel for better usage and better storage purpose. Same here Ocean is database having lots of Data files here data file means water and for better usage and handling you put that into barrel you can relate barrel as Tablespace
An Oracle database consists of one or more logical storage units
called tablespaces, which collectively store all of the database's
data.
Databases, tablespaces, and datafiles are closely related, but they have important differences:
Each tablespace in an Oracle database consists of one or more files
called datafiles, which are physical structures that conform to the
operating system in which Oracle is running.
A database's data is collectively stored in the datafiles that
constitute each tablespace of the database. For example, the simplest
Oracle database would have one tablespace and one datafile. Another
database can have three tablespaces, each consisting of two datafiles
(for a total of six datafiles).
reference link
DATABASES's data are stored in logical storage units called TABLESPACES. A database may contain "one or more" tablespaces. A tablespace may contain one or more datafiles.
A database's data is collectively stored in the datafiles that constitute each tablespace of the database.
Example: the simplest database may have one tablespace and one datafile. On the other hande another database can have 5 tablespaces which may contain two datafiles each (On a total of 10 files)
This question is quite dated. IBM Db2 also has Table spaces. I think there is some commonality between Db2 table spaces and Oracle database table spaces. In that respect this link offers more insight into why table spaces, as storage structures, are needed and how are they distinct from databases. Two benefits are easy recoverability of the database and better storage management.
I will be deploying an application database on an existing Oracle Server. I need to store English characters on this database, but my client asked me if this would be a problem, since his Oracle database is using a “KS5601” character map, with “ANSI” encoding. My question is, if I create a new database on an existing Oracle Server instance, would this database have its own encoding, or it will have to follow the current encoding of the server?
If I have to use the KS5601 (Korean Character Map), would I be able to store English alphanumeric characters?
KS5601 is not a database character set. What is the existing database's character set
SELECT *
FROM v$nls_parameters
WHERE parameter LIKE '%CHARACTERSET'
What do you mean when you say "create a new database on an existing Oracle Server Instance"? If you mean that you are creating a new database and a new instance on the same physical server (so you'll have a completely separate SGA & PGA and completely separate set of background processes), you can create the new database with whatever character set you'd like. If you mean that you are creating a new schema in an existing database, you would need to use whatever character set the database uses.
I am getting the following error:
Microsoft OLE DB Provider for Oracle: Data type is not supported.
Could somebody help me figure out this please...
Situation:
Recently migrated database from SQL Server 2005 to Oracle 11g. One of the table has some columns of the data type ntext in SQL Server, which were converted to NCLOB during migration to Oracle. Client is Classic ASP page (VBScript) accessing the Oracle Database through OLEDB connection.
When the execution reaches the query (Select query) that reads the column of type NCLOB it is throwing the Microsoft OLE DB Provider for Oracle: Data type is not supported error. When I take out that particular column then the query is running fine...
QUESTION: How to read NCLOB, CLOB data values from Classic ASP pages?
Plz let me know if you need more information.....
Thank You..
I know that Microsoft's ODBC Driver for Oracle didn't support any of the LOB types-- I would wager that its OLE DB Provider didn't either given the error. Can you upgrade to the Oracle OLE DB Provider?
As an aside, since you are migrating from SQL Server to Oracle, do you really need to use the NCLOB data type? Since Oracle allows the database character set to be Unicode, you normally don't need (and don't want) to use the NVARCHAR2 or NCLOB data types unless you're stuck supporting an old database that requires a non-Unicode character set. For data that is English or Western Eurpoean in nature, storing data in a CLOB has substantial benefits in terms of storage space since the CLOB would store the data in UTF-8 rather than UTF-16 in an NCLOB (assuming that you picked a Unicode character set for the database). Eliminating the NVARCHAR2 and NCLOB columns also tends to make it much easier for front-end tools to handle the data.
I'm trying to figure out where our project went wrong.
A long time ago, our database administrator created a user and a schema for the project we were working on.
We gave that user to a contractor who created the tables and installed the application.
Today I discovered that our database doesn't support UTF-8 characters and we need it to.
select value from nls_database_parameters
where parameter='NLS_CHARACTERSET'
The result is : WE8ISO8859P1
My question is, was the mistake made when the user was created, or was the mistake done by the contractor who created the tables?
Thanks
The character set is an attribute of the database. So whoever created the database presumably chose the wrong character set. There are no character set related settings when you create a user or create a table (other than determining whether to use the database character set (CHAR/ VARCHAR2) or the national character set (NCHAR/ NVARCHAR2) data types).
Changing the character set of an existing database may take a bit of effort. The Globalization Guide has a section on character set migration. Depending on the Oracle version (the procedure is different in 10g and 11g) and what data already exists, doing an export & import to a new database may be the easiest option.
I should add that the order of operations you specified in your post doesn't make sense. The database has to be created before the user or the schema can be created. So it doesn't make sense that the DBA could have created the user and the schema a long time ago and the contractor created the database more recently. Are you possibly using the terms "database" and "schema" in a non-Oracle context?
I have Oracle database with following settings
NLS_CHARACTERSET EE8MSWIN1250
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_LANGUAGE AMERICAN
I've created test table with one column of type NVARCHAR2, where I'm going to store cyrillic.
I use SQL Developer to connect DB.
The problem is when I put a cyrillic chain into DB using SQL Developer cell, the data is stored correctly. But when I use INSERT query with the same data using N'' or not the data is stored as question marks.
Interesting thing is that query generated by SQL Developer, and written by me is identical.
I solved this problem by changing NLS_CHARACTERSET to UTF8, but on production server I can't do such a thing.
IMO it must be some way to store cyrillic into that DB in proper way using query if SQL Developer can do that.
Regards
Depending on the ODBC/JDBC in use, localization settings on your computer may override any config values in the database. Try using ALTER SESSION and set the proper NLS parameters before executing your query, and see if that helps. SQL developer might do this behind the scenes when you edit the data cell.