I have checked documentation, forums and a lot of discussions regarding the subject, but some points are still not clear to me.
From the info I could gather, many people just treat both of them as the same thing ("ORACLE_UNQNAME is the database unique name"; "ORACLE_SID is the name set to your database"), what sounds very suspicious, since it would be very unnecessarily redudant having 2 variables for the exact same thing.
I suspect that the two follow something like a "taxonomy" schema, being ORACLE_UNQNAME the "genus" and ORACLE_SID the "species" level.
Thus, there could be more than 1 SID defined under a single UNQNAME.
Is my conclusion right? Any feedback is appreciated.
Thank you in advance.
When installing Oracle Database on your laptop, this will most likely apply:
ORACLE_SID = DB_NAME = DB_UNIQUE_NAME = SERVICE_NAME
My XE laptop installation (docker)
sys#XEPDB1> show parameter db_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_name string XE
sys#XEPDB1> show parameter db_unique
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string XE
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
service_names string XE
sys#XEPDB1> show parameter sid
sys#XEPDB1> -- hey no value for SID found!
But as soon as installing an Oracle Database for the Enterprise, things change. An Enterprise installation will require high availability and disaster recovery.
In such an environment this will most likely apply:
ORACLE_SID <> DB_NAME <> DB_UNIQUE_NAME <> SERVICE_NAME
ORACLE_SID defines the instance (process + memory).
DB_NAME defines the name of the database no matter where it is located. Cannot be changed after creation.
DB_UNIQUE_NAME must be unique in a DR configuration. Defines disk file-layout
SERVICE_NAME defines the name of the database service. My one HA/DR Oracle Database can serve content for all our schemas (databases) in the one Oracle Database. i.e WEBSHOP1,WEBSHOP2,...,WEBSHOPN ...
If more isolation is needed enter multitenant architecture and pluggable database.
Related
we have recently upgraded our test environment database to 12.2.0.1 from 11.2.0.3.
I see that NLS_TERRITORY value and NLS_LANG value in NLS_SESSION_PARAMETERS is not showing correct value after ORACLE 12C Upgrade.
It should be GERMANY and GERMAN and instead it is AMERICAN and AMERICA and hence some of the query do not show the correct result is terms of currency.
as the parameter "NLS_NUMERIC_CHARACTERS" is dependent of NLS_TERRITORY value.
I see that the NLS_DATABASE_PARAMETERS & NLS_INSTANCE_PARAMETERS, but the NLS_SESSION_PARAMETERS is wrong and hence it is affecting with some of our scripts where we are displaying the numbers.
I do not want to change it via ALTER SESSION and execute the SQL or hardcode in the SQL syntax with the parameter which handles the numbers.
Please let me know if there is any solution for the same so that NLS_SESSION_PARAMETER can be changed.
as the ORACLE DB is reading the PFILE, I have the below values set for NLS parameters are:-
NLS_LANGUAGE = GERMAN
NLS_TERRITORY = GERMANY
nls_length_semantics = char
I found the solution myself, it was a silly environment configuration and somehow reading wrong entry from another profile which is pointed by the actual profile file for the envrionment NLS_LANG.
it was export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
and hence whenever the DB was booting, the NLS session was loaded with the wrong NLS_LANG and NLS_TERRITORY value from this NLS_LANG envrionment variable.
I removed that wrong profile entry and used the NLS_LANG as below:-
export NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15 in the actual profile file such that the DB gets the correct information.
then when I rebooted the DB, the NLS Session values gets fixed by itself and hence I do not have to change something in my scripts and will now work as same as they werr working with previous Oracle version.
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 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).
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:
When connecting to Oracle the JDBC driver identifies itself as "JDBC Thin Client" to Oracle (in v$session as the 'program'). There is also a 'ClientInfo' column in v$session that might be used for this, but it's always empty.
We have a need to identify different applications connecting to Oracle (which are running on the same host, so the 'machine' column in v$session is all the same), so is it possible to change how the Oracle JDBC Thin Client driver identifies itself (so we could put the application name in, for example)?
Or is there a recommended way to do this? One restriction is that we're doing this within Struts for some of the applications, which is handling the connection setup internally.
[Identical to this answer]
java.util.Properties props = new java.util.Properties();
props.setProperty("password","mypassword");
props.setProperty("user","myusername");
props.put("v$session.osuser", System.getProperty("user.name").toString());
props.put("v$session.machine", InetAddress.getLocalHost().getCanonicalHostName());
props.put("v$session.program", "My Program Name");
DriverManager.registerDriver (new oracle.jdbc.OracleDriver());
Connection conn=
DriverManager.getConnection("jdbc:oracle:thin:#myhostname:1521:mysid", props);
SQL>select username,osuser,program,machine
from v$session
where username = 'ROB';
USERNAME OSUSER PROGRAM MACHINE
--------- ----------- ------------------ -----------
ROB rmerkw My Program Name machine
At application level you can use the following methods to set client_info, module and action in v$session:
dbms_application_info.set_client_info
dbms_application_info.set_module
dbms_application_info.set_action
There is also an Oracle function:
dbms_application_info.set_client_info('Client Info');
which sets the ClientInfo column in v$session.