I need to change V$NLS_PARAMETER . currently default NLS_LANGUAGE is American, I want to change it ENGLISH. Alter session modifies only the current session.
How to modify it permanently.
You can set NLS parameters at different levels
As initialization parameters on the instance/server.
SQL>alter system set V$NLS_PARAMETER = 'XXX' scope = both;
As environment variables on the client.
% setenv NLS_SORT FRENCH
As ALTER SESSION parameters.
SQL> ALTER SESSION SET V$NLS_PARAMETER = = 'XXX'
Any setting overrides the setting on a higher level. So setting it server side does not guarantee that the setting is used by all clients connecting.
If you want to make sure it is set for every client connecting use a logon trigger. Even then a user can explicitly override the 'default' setting
Related
I need to set week start from sunday as default in snowflake
i used
alter session set WEEK_START = 7;
when querying in snowflake worksheet it works fine but when using the same query via api it has no effect.
is there any way to set WEEK_START from sunday without using alter session.
thanks in advance..
You could submit multipe statements per request:
Specifying Multiple SQL Statements in the Request and separate them with semicolon.
alter session set WEEK_START = 7; SELECT DAYOFWEEK()
is there any way to set WEEK_START from sunday without using alter session.
Setting the parameter on USER level that is used for making the API call.
ALTER USER <user_name_here> SET WEEK_START = 7;
Related Parameter Hierarchy and Types
Try using EXECUTE AS CALLER in SP.
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 was under the impression that when one uses the ALTER SYSTEM statement, the new setting is in effect as long as the instance is up / database is mounted:
https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm#SQLRF00902
After a reboot the setting should revert to its old value.
I have done the below change, shut down and started the instance back up and the new setting is still in effect. Any ideas?
SQL> show parameter SEC_CASE_SENSITIVE_LOGON
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon boolean TRUE
SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
System altered.
-------Restarted the database---------------------------
SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;
System altered.
In that link you provided, you have to look for the SCOPE parameter. By default is Both, if you're using SPFILE (which is the most common), means it will save on the SPFILE and change in memory as well.
Hugepage and SGA change require reboot.
su - oracle
sqlplus / as sysdba
alter system set memory_max_target=11520m scope=spfile;
--assuming an spfile is used
alter system set memory_target=11520m scope=spfile;
--assuming an spfile is used
shutdown the DB
start the DB
I have a NLS date format as DD-MON-RR. This gives me the underlying date format as YY while I want to change it to YYYY. I tried using the following query and it ran successfully
DECLARE
v_date DATE := sysdate;
BEGIN
DBMS_OUTPUT.put_line(TO_CHAR(v_date, 'MM/DD/YYYY'));
END;
But that didn't change the default format.
for some context, I am trying to import data from Oracle to Tableau. Unfortunately when I try to export a crosstab from Tableau server it looks at the underlying data rather than whats on the view. This causes the date that I have as 25-Jun-2017 to change to 25-Jun-17 in the excel.
The only workaround I have been able to understand is to change the default format of the underlying/source data which in this case is Oracle DB.
I am using TOAD and am trying to understand how can I change it to possibly DD/MON/RRRR format or something similar with 4 digits in the year column.
Any workaround is also appreciated
As already given in other answers you can set NLS_DATE_FORMAT by ALTER SESSION.
In order to set it only for you local PC, open Registry Editor and navigate to HKLM\SOFTWARE\Wow6432Node\ORACLE\KEY_%ORACLE_HOME_NAME%, resp. HKLM\SOFTWARE\ORACLE\KEY_%ORACLE_HOME_NAME%.
There you can add a String Value NLS_DATE_FORMAT, for example:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1]
"NLS_TIMESTAMP_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3"
"NLS_TIMESTAMP_TZ_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3 fmTZH:TZM"
"NLS_DATE_FORMAT"="YYYY-MM-DD HH24:MI:SS"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_OraClient11g_home1]
"NLS_TIMESTAMP_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3"
"NLS_TIMESTAMP_TZ_FORMAT"="YYYY-MM-DD HH24:MI:SSfmXFF3 fmTZH:TZM"
"NLS_DATE_FORMAT"="YYYY-MM-DD HH24:MI:SS"
You can set NLS_DATE_FORMAT also as an Environment Variable in Windows Settings.
alter session set nls_date_format='DD/MON/RRRR' programmatically in the application or
CREATE OR REPLACE TRIGGER trg_after_logon AFTER LOGON ON DATABASE
BEGIN
execute immediate 'alter session set NLS_DATE_FORMAT=''DD/MON/RRRR''';
END;
in system or sys schema.
Alternatively, you may use
alter system set NLS_DATE_FORMAT='DD/MON/RRRR' scope = both
provided you're in system or sys, again.
Manage your date format masking using the most reasonable approach
First of all, I agree with Alex regarding using to_char. This would be my first choice for modifying date masks for specific requirements.
In Toad on an ad hoc basis, you could just invoke the alter session command as needed:
ALTER SESSION SET nls_date_format='DD/MON/RRRR';
If you are partial to a specific date format mask (and you see yourself often issuing the command, ALTER SESSION SET NLS...) then perhaps you might want to consider changing your user login settings.
If you just modify your specific user preference login file, login.sql (see here ), your session will adhere to the date format mask of your choosing at the beginning of your session. I am partial to creating the environment variable, SQLPATH, and placing my login script there.
Toad will honor your login.sql file settings (e.g. see this post).
Since this is driven by specific requirements or personal preferences, I would never think of modifying this from default at the site level.
I am using oracle 11g r2, and trying to configure DB to sort order using linguistic sort.
I did
alter system set NLS_SORT='RUSSIAN' SCOPE=SPFILE;
alter system set NLS_COMP='LINUGUISTIC' SCOPE=SPFILE;
after i've restarter oracle i checked these params:
show parameters NLS_SORT;
show parameters NLS_COMP;
it show me the right values.
But when I make sort
select name from test order by name;
it show me results in not correct order, ie digits first, then letters.
but if i will do
alter session set nls_sort='RUSSIAN';
alter session set nls_comp='LINGUISTIC';
select name from test order by name;
it show me the right order.
anyone know why sysem changes not showing me right results ?
The priority for globalisation settings is shown in the documentation. You're setting priority 4 in that list, 'Specified in the initialization parameter file'. You are not setting priority 1 ('Explicitly set in SQL functions') and you get the results you want when you do set priority 2 ('Set by an ALTER SESSION statement'). By a process of elimination that indicates that your 'not correct' order is being influenced by priority 3, 'Set as an environment variable'.
You can check the values actually being used by your session with select * from nls_session_parameters.
The NLS_SORT environment variable is probably not being set directly; I suspect it's being derived from NLS_LANGUAGE, which is derived from NLS_LANG. If you aren't explicitly setting that in your operating system environment then the client will set it based on the operating system locale, generally, though the exact client you use may make a significant difference. You might need to explicitly set an NLS_COMP environment variable, if the database default for that is really being overridden.
SQL Developer, for example, allows you to specify the NLS settings in the preferences (accessed from Tools->Preferences->Database->NLS); the defaults appear to be based on operating system settings, in Windows anyway. For SQL*Plus you'd need to set operating system environment variables.
This also means that if you get it working in one place - the queries give the right order when run from SQL Developer, say - they might not work when used elsewhere, say over JDBC which has its own locale settings. Just something to watch out for.
A brute-force approach might be to add the alter session commands to a login trigger, but that doesn't sound ideal as it just masks the environment configuration.
You can set NLS parameters at different levels
As initialization parameters on the instance/server.
SQL> alter system set V$NLS_PARAMETER = 'XXX' scope = both;
As environment variables on the client.
% setenv NLS_SORT FRENCH
As ALTER SESSION parameters.
SQL> ALTER SESSION SET V$NLS_PARAMETER = = 'XXX'
Any setting overrides the setting on a higher level. So setting it server side does not guarantee that the setting is used by all clients connecting.
If you want to make sure it is set for every client connecting use a logon trigger. Even then a user can explicitly override the 'default' setting
You've got a typo in your second "ALTER SYSTEM" command (LINUGUISTIC instead of LINGUISTIC).
If your real command doesn't contain this error, I'd check whether your client sets the NLS session parameters to something else.
Regardless of the system settings, I would make every effort to ensure that your applications completely specify the NLS environment that they require. It's much more robust, particularly when you need to point the application code at different environments that may be newly setup, or shared with other systems.
In fact, I'd go as far as to say that you might be better not using setting system-level environment settings.