Inserting vietnamese characterset into nvarchar2/varchar without Prefix 'N' from client - oracle

I am having a database(Oracle 11g) on windows whose NLS_CHARACTERSET value is WE8MSWIN1252, while the NLS_NCHAR_CHARACTERSET value is AL16UTF16.
Now, I have a table 'TEST_NOTE' whose column type is NVARCHAR2. While running the following insert statement:
insert into test_note values (n'Chào thế giới!')
The data gets inserted fine and I am able to fetch it properly.
Since I have to insert the data from a different client software(company's proprietary software), I am not able to append 'n' to the value the user enters.
Also, can I make do with VARCHAR2 instead of NVARCHAR, as I don't want to change the existing schema of the database in production?
My ideal solution will be using VARCHAR2 and inserting Vietnamese Characters without using 'n' as prefix.
EDIT:
I Tried the following on Windows 10:
C:\WINDOWS\system32>chcp
Active code page: 437
C:\WINDOWS\system32>set NLS_LANG =.AL32UTF8
C:\WINDOWS\system32>sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 22 11:15:11 2017
Copyright (c) 1982, 2010, Oracle. All rights reserved.
SQL> connect system as sysdba
Enter password:
Connected.
SQL> insert into ss_repo.test_note values ('abcs','Chào thế giới!');
1 row created.
SQL> commit;
Commit complete.
SQL> select * from SS_REPO.TEST_NOTE;
SOEID NOTE
-------------------- --------------------
ID17836 Chào th? gi?i!
s Chào th? gi?i!
abcs Chào th? gi?i!
ABCD Chαo th┐ gi┐i!
Or Can I do the same from SQL Developer? Will it be easy using that?
The client which will be used in production will be using JDBC JAR file OJDBC6.JAR
But for the time being I am trying to do using SQL Plus or SQL Developer.

Codepage 437 does not support any Vietnamese characters.
When you set set NLS_LANG =.AL32UTF8 then you have to execute chcp 65001 beforehand in order to change your codepage (and thus also character set of SQL*Plus) to UTF-8
However, using UTF-8 on Windows command line has some issues, see this discussion: https://community.oracle.com/thread/600575
You can also try Codepage 1258 which should work for Vietnamese:
C:\>chcp 1258
Active code page: 1258
C:\>set NLS_LANG =.VN8MSWIN1258
C:\>sqlplus ...

Related

Oracle SQL: Running insert statements from a large text file

I have a large text file (around 50mb). This text file has thousands of insert statements. I tried to open the text file in Oracle SQL Developer, but it is too large. How do I insert the data into my tables without opening the file in SQL Developer?
I tried to loop through the insert statements one by one and insert them into my table like this:
DECLARE
V1 VARCHAR2(32767);
fileVariable UTL_FILE.FILE_TYPE;
BEGIN
fileVariable := UTL_FILE.FOPEN('h:/Documents',
'clob_export.sql',
'R',
32760);
UTL_FILE.GET_LINE(fileVariable,V1,32767);
UTL_FILE.FCLOSE(fileVariable);
END;
But this doesn't seem to work. I can't create directories on the machine, and anyways, the text file is on the computer where I am running SQL Developer and SQL Developer is connected remotely to the database.
The simplest way - from my point of view - is to run it from SQL*Plus, such as:
c:\Temp>sqlplus scott/tiger
SQL*Plus: Release 11.2.0.2.0 Production on Uto Sij 26 22:20:18 2021
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
SQL> #insert_data.sql
1 row created.
1 row created.
<snip>
presuming that insert_data.sql contains something like
insert into dept values (1, 'Dept 1', 'NY');
insert into dept values (2, 'Dept 2', 'London');
...
Use sqlplus and if where are too much text use options to log only in the file not on screen
SET TERMOUT OFF;
spool M:\Documents\test.log;
Call the file with # instead of trying to open the file. You may also want to disable feedback to avoid many thousands of "1 row inserted" messages.
set feedback off;
#c:\users\jon\Desktop\test.sql
The above commands are SQL*Plus syntax, but Oracle SQL Developer worksheets understand basic SQL*Plus commands. If you need to frequently run large scripts then you might want to learn the command line SQL*Plus, but if this is just a one-time task then stick with SQL Developer.

Cannot type Japanase kanji from windows IME into oracle 12c database sqlplus in windows 10

my column,"ideograph", is of varchar2(1000) datatype. I inserted one character into the column with Microsoft IME, 寺, Oracle sqlplus just gives me a "?".
I checked v$nls_parameters.
nls_characterset= AL32UTF8
nls_nchar_characterset= AL16UTF16
Now,based on what i've read in other questions here, if I'm using varchar2 datatype, then based on the v$nls_parameters query, the db is using AL32UTF8, but this is a " national characterset", I think, I have no idea what is the " database" character set is.
I also used the dump function with the dual table.
select dump('寺',1016) from dual;
I got typ=96 len=1 characterset=AL32UTF8: 3F
I did the same thing in livesql.oracle.com, which uses apex on a cloud, and I got this:
typ=96 len=3 characterset=AL32UTF8: e5,af,ba
why the hexadecimal codes are different if it says is the same character set?
I have no idea what encoding microsoft IME is using, maybe that is the problem.
How can I fix this? I can create another database, because I don't have any data in the one I'm doing this, is just for training purposes. but I want to see if I can fix it without having to do that.
General solution is learning NLS_LANG setting in Oracle and understanding that you may have different NLS_LANG settings on Windows because Windows command line mode does not work the same way as Windows graphical user interface as far as character set settings are concerned.

Unable to alter Oracle Parameters

I am unable to add more than 200 datafiles in my database because of these parameters:
select records_total from v$controlfile_record_section where type = 'DATAFILE';
select value from v$parameter where name = 'db_files';
Both of these give me an output of 200. I need to increase this to 400 so I have tried:
alter system set records_total = 400 where name = 'db_files';
alter system set value= 400 where type = 'DATAFILE';
but I am getting
S
QL Error: ORA-02065: illegal option for ALTER SYSTEM
02065. 00000 - "illegal option for ALTER SYSTEM"
*Cause: The option specified for ALTER SYSTEM is not supported
*Action: refer to the user manual for option supported
Am I able to change these parameters and how?
You probably want to use commands like this:
C:\Users\jonearles>sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Fri Jul 10 13:07:16 2015
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL> show parameter db_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_files integer 200
SQL> alter system set db_files=400 scope=spfile;
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 1048576000 bytes
Fixed Size 3053584 bytes
Variable Size 662702064 bytes
Database Buffers 377487360 bytes
Redo Buffers 5332992 bytes
Database mounted.
Database opened.
SQL> show parameter db_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_files integer 400
SQL>
This assumes you are using an SPFILE (or else you will need to manually edit the init.ora file and restart) and you are not using RAC (or else you will need to use a command like srvctl stop database -d my_sid).
As ditto mentioned, it can help to look at the ALTER syntax. It may also help to look at the Oracle Database Reference, which will tell you if the command is dynamic (meaning it can be run without restarting the database).

Oracle 12c extended to support varchar2 > 4000 bytes doesn't work for user who is not sysdba

On oracle 12c compatible 12.0.0, changed to extended with sysdba privileges.
I can create a table with varchar2(16000) as column now and insert a string > 4000 bytes; but only when connected as sysdba.
When connected as a normal user rather than sysdba, I cannot play with varchar2 >4000 bytes, an error ORA-60019 is thrown. Can anyone explain why?
the param max_string_size= extended and compatible=12.0.0 when logged in as a user who is not a sysdba.
Do following steps and let me know if the issue is resolved. I am asking to set the parameter again just to make sure
everything is in order.
1) Back up your spfile ( get location of spfile)
sqlplus / as sysdba
show parameter spfile;
2) Shut down the database.
sqlplus / as sysdba
shutdown immediate
3) Restart the database in UPGRADE mode.
startup upgrade
4) Change the setting of MAX_STRING_SIZE to EXTENDED.
alter system set MAX_STRING_SIZE ='EXTENDED' scope=spfile;
5)
sqlplus / as sysdba
#%ORACLE_HOME%\RDBMS\ADMIN\utl32k.sql
#%ORACLE_HOME%\RDBMS\ADMIN\utlrp.sql
Note: The utl32k.sql script increases the maximum size of the
VARCHAR2, NVARCHAR2, and RAW columns for the views where this is
required. The script does not increase the maximum size of the
VARCHAR2, NVARCHAR2, and RAW columns in some views because of the way
the SQL for those views is written.
rdbms/admin/utlrp.sql script helps to recompile invalid objects. You
must be connected AS SYSDBA to run the script.
6) Restart the database in NORMAL mode.
sqlplus / as sysdba
shutdown immediate
startup;
show parameter MAX_STRING_SIZE;
7) create new table with column datatype varchar2 having more than 4000 size.
You must change your file "TNSNAMES.ORA" to connect by PDB.
I was with the same problem.
I have solved with the information of link bellow.
https://dba.stackexchange.com/questions/240761/in-oracle-12c-tryiyng-to-create-table-with-columns-greater-than-4000
The reason for that behaviour is that you are in a multi-tenant environment, i.e. a master container called the CDB ("Container Database"), and any number of PDBs ("Pluggable Databases").
The CDB ("container") is a kind of "system" database that is there to contain the actual customer databases ("pluggable databases" or PDBs). The CDB is not intended to receive any customer data whatsoever. Everything goes into one or more PDBs.
When you connect without specifying any service, you are automatically placed in the CDB. The extended strings parameter is ignored for the CDB: the limit remains 4000 bytes. The following connects to the CDB. Creating a table with a long string is rejected, just like in your case:

How can I tell if my Oracle system is set to support Unicode or multibyte characters?

I understand that Oracle supports multiple character sets, but how can determine if the current 11g system where I work has that functionality enabled?
SELECT *
FROM v$nls_parameters
WHERE parameter LIKE '%CHARACTERSET';
will show you the database and national character set. The database character set controls the encoding of data in CHAR and VARCHAR2 columns. If the database supports Unicode in those columns, the database character set should be AL32UTF8 (or UTF8 in some rare cases). The national character set controls the encoding of data in NCHAR and NVARCHAR2 columns. If the database character set does not support Unicode, you may be able to store Unicode data in columns with these data types but that generally adds complexity to the system-- applications may have to change to support the national character set.
Unicode is a character encoding system that defines every character in most of the spoken languages in the world, Support for Unicode in Oracle Database:
Character Set Supported in RDBMS Release Unicode Encoding
AL24UTFFSS 7.2 - 8i UTF-8
UTF8 8.0 - 11g UTF-8
UTFE 8.0 - 11g UTF-EBCDIC
AL32UTF8 9i - 11g UTF-8
AL16UTF16 9i - 11g UTF-16
To Make sure your database is Unicode, please check the value of "NLS_CHARACTERSET" Parameter and it should be AL32UTF8 or AL16UTF16 from above list.
SQL>
SQL> SELECT * FROM v$nls_parameters WHERE parameter='NLS_CHARACTERSET';
PARAMETER VALUE CON_ID
--------------------------- ------------------- ----------
NLS_CHARACTERSET AL32UTF8 0
To Change the value of Parameter, Please Take the Fullback up because ALTER DATABASE statement cannot be rolled back and the Use following statements:
SHUTDOWN IMMEDIATE
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;
ALTER DATABASE CHARACTER SET AL32UTF8;
SHUTDOWN IMMEDIATE;
STARTUP;

Resources