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:
Related
I enabled auditing on my Oracle XE server via the following run by the sys user:
SQL> ALTER SYSTEM SET audit_sys_operations=true SCOPE=spfile;
SQL> ALTER SYSTEM SET audit_trail=XML,EXTENDED SCOPE=spfile;
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP
When I run queries as the sys user, an xml file records the queries in the default location (e.g., /u01/app/oracle/admin/XE/adump/xe_ora_2339_1.xml). However, if I run a query as a different user (e.g., test_user), no updates occur in any of the files in the adump directory.
I've confirmed that the parameter is set for the test_user:
SQL> show parameter audit;
NAME TYPE VALUE
------------------------ ------- ------------------------------
audit_file_dest string /u01/app/oracle/admin/XE/adump
audit_sys_operations boolean TRUE
audit_syslog_level string
audit_trail string XML, EXTENDED
I also tried restarting my sqlplus session (i.e., reconnecting with the test_user), as well as disabling audit_sys_operations, and the issue remains.
Version info: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production (via this docker image).
My issue was that, in addition to enabling auditing, I also needed to specify what to audit with the AUDIT command. In my case, I wanted everything, so I added the following (commands mentioned in this tutorial):
SQL> AUDIT ALL; # note: it seems like the next two statements would be included with "all", but I didn't verify this.
SQL> AUDIT SELECT TABLE, UPDATE TABLE, INSERT TABLE, DELETE TABLE;
SQL> AUDIT EXECUTE PROCEDURE;
Note that with AUDIT_TRAIL=XML,EXTENDED (and maybe all the file-based auditing settings?), it looks there is some buffering of writing the XML file, as I didn't get a query showing up until my test user disconnected, so if you are missing a log entry, try logging the user out to see if it shows up.
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 ...
I am using Oracle XE 11g R2 and due to a mistake all the archivelogs where deleted by running delete archivelog all; command on RMAN.
Also one set of redo logs were deleted i.e. redo_g02a.log, redo_g02b.log and redo_g02c.log
Other redolog are available i.e. redo_g01a.log, redo_g01b.log, redo_g01c.log and redo_g03a.log, redo_g03b.log and redo_g03c.log
Is there a way I can startup the database now? It is a production database and I am really worried.
I tried copying from redo_g01a.log to redo_g02a.log ... but alert logs say:
ORA-00312: online log 2 thread 1: '/u01/app/oracle/fast_recovery_area/XE/onlinelog/redo_g02a.log'
USER (ospid: 30663): terminating the instance due to error 341
Any help will be much much appreciated.
First make a copy of your datafiles, redo logs, and control file. That way you can get back to this point.
If the database was shut down clean you can try clearing the group and it will be recreated for you.
SQL> connect / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2260048 bytes
Variable Size 675283888 bytes
Database Buffers 385875968 bytes
Redo Buffers 5517312 bytes
Database mounted.
SQL> alter database clear logfile group 2;
Database altered.
SQL> alter database open;
Database altered.
SQL>
If not you will need to recover and open with the resetlogs option. Unfortunately because you lost an entire log group you may also have lost data.
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).
I have to change the character set from AL32UTF8 to WE8MSWIN1252 in a Oracle 11g r2 Express instance... I tried to use the command:
ALTER DATABASE CHARACTER SET WE8MSWIN1252;
But it fails saying that MSWIN1252 isn't a superset of AL32UTF8. Then I found some articles talking about CSSCAN, and that tool doesn't seem to be available in Oracle 11 Express.
http://www.oracle-base.com/articles/10g/CharacterSetMigration.php
Anyone has an idea on how to do that? Thanks in advance
Edit
Clarifying a little bit: The real issue is that I'm trying to import data into a table that has a column defined as VARCHAR(6 byte). The string causing the issue is 'eq.mês', it needs 6 bytes in MSWIN1252 and 7 bytes in UT8
You can't.
The Express Edition of 11g is only available using a UTF-8 character set. If you want to go back to the express edition of 10g, there was a Western European version that used the Windows-1252 character set. Unlike with the other editions, Oracle doesn't support the full range of character sets in the Express Edition nor does it support changing the character set of an existing XE database.
Why do you believe you need to change the database character set? Other than potentially taking a bit more storage space to support the characters in the upper half of the Windows-1252 range, which generally aren't particularly heavily used, there aren't many downsides to a UTF-8 database.
I would say that your best option when you want to go to a character set that supports only a subset of the original characters, that your best option is to use exp and imp back (or expdp and impdp).
Are you sure that no single table will contain any character not found in the 1252 code page ?
The problem of only execute that ALTER DATABASE command is that the Data Dictionary was not converted and it can be corrupted.
I had the same problem. In my case, we are using a Oracle 11g Express Edition (11.2.0.2.0) and we really need that it runs on WE8MSWIN1252 character set, but I cannot change the character set on installation (it always install with AL32UTF8).
With a Oracle Client 11g installed as Administrator and run only the csscan full=y (check this link https://oracle-base.com/articles/10g/character-set-migration) and we notice that are lossy and convertible data problems in our database. But, the problems are with the MDSYS (Oracle Spatial) and APEX_040000 (Oracle Application Express) schemas. So, as we dont need this products, we remove them (check this link: http://fast-dba.blogspot.com.br/2014/04/how-to-remove-unwanted-components-from.html).
Then, we export with expdp the users schemas and drop the users (they must be recreated at the end of the process).
Executing csscan again with full=y capture=y, it reports that: The data dictionary can be safely migrated using the CSALTER script. If the report doesnt have this, the csalter.plb script will not work, because there are some conditions that will not be satisfied:
changeless for all CHAR VARCHAR2, and LONG data (Data Dictionary and Application Data)
changeless for all Application Data CLOB
changeless and/or convertible for all Data Dictionary CLOB
In our case, this conditions were satisfied and we could ran the CSALTER script successfully. Moreover, this script executes the ALTER DATABASE command you are trying to run and it converts the CLOB data of Data Dictionary that is convertible.
Finally, we create the users and the tablespaces of our application and we import the dump of the user data successfully.