626  Chapter 13  n  Implementing Globalization Support

Ta b l e 13 .1    ​ Oracle​ -Supported Unicode Encoding Methods  (continued)

Unicode can be used in Oracle in several ways:

NNIt can be defined as the database character set, thereby becoming the default for all SQL CHAR datatypes (CHAR, VARCHAR2, CLOB, and LONG). In this setup, the UTF-8 encoding method will be used.

NNIt can be used as needed by creating columns using the NCHAR datatypes, also known as Unicode datatypes (NCHAR, NVARCHAR2, and NCLOB). Unicode data can be encoded as either UTF-8 or UTF-16 when used in this scenario.

Using NLS Parameters

Ultimately, Oracle globalization support options are defined by NLS parameter settings. By assigning values to specific NLS parameters, you can control when, where, and how Oracle will utilize globalization support functionality. These settings can be specified in a variety of ways, and their effects may vary accordingly.

On the server side, NLS parameters are read from initialization parameter settings at instance-startup time. The values are stored in the data dictionary, as are the database and national character-set settings.

On the client side, NLS parameters can be defined as environment variables (such as NLS_LANG), or they can be set at the session level by using the ALTER SESSION statement. NLS parameters can also be defined inside SQL function calls with a scope limited to only the current function. Therefore, it is vital to understand the order of precedence that Oracle follows concerning NLS parameter settings.

In the following sections, you’ll learn about many of the different NLS parameters, how to set them, and what effect they will have on the system. You’ll also learn how Oracle prioritizes NLS parameter settings. Last, you will learn how to use NLS data dictionary and dynamic performance views to access NLS information from the database.

Setting NLS Parameters

Oracle’s globalization support is designed to be very simple to use. In many environments, globalization needs can be met by setting a single client-side parameter (NLS_LANG). This is because Oracle automatically derives lower-level specifics from the high-level settings. For instance, if the NLS_TERRITORY parameter is set to AMERICA, Oracle assumes that currency should be displayed as dollars, comma separators should be used, and so on.

However, the granularity provided by Oracle’s globalization support allows almost unlimited variations for users with even the most demanding globalization needs.

NLS parameters can be classified into the following categories:

Each category offers one or more individual parameters that can be set to meet your exact globalization needs.

In the following sections, you will learn how to set the NLS_LANG client-side environment variable to specify the NLS environment for your session. You’ll also learn about each of the different categories of NLS parameter settings and the different options they offer.

Using the NLS_LANG Parameter

NLS_LANG is a client-side environment variable that defines the language, territory, and character set for the client. It is functionally equivalent to setting the NLS_LANGUAGE, NLS_ TERRITORY, and NLS_CHARACTERSET parameters individually.

For most clients, the NLS_LANG parameter is all that needs to be set to define the entire globalization environment. This is true because the NLS_LANGUAGE and NLS_TERRITORY settings define the default settings for nearly all other NLS parameters.

The NLS_LANGUAGE parameter, for instance, specifies the default conventions to be used for all of the following globalization elements:

The NLS_TERRITORY parameter specifies the default conventions used for these globalization elements:

NN Date format

NN Decimal character

628  Chapter 13  n  Implementing Globalization Support

Therefore, no other NLS parameters need to be set unless the default settings don’t meet your needs.

The format for setting the NLS_LANG parameter is as follows:

NLS_LANG = language_territory.characterset

For example, the following are all valid:

NLS_LANG=AMERICAN_AMERICA.US7ASCII

NLS_LANG=JAPANESE_JAPAN.JA16EUC

NLS_LANG=FRENCH_CANADA.WE8ISO8859P1

The language element controls the conventions used for Oracle messages, sorting, and day and month names. If language is not set, Oracle will default to AMERICAN. Each language is identified by a unique name, such as FRENCH or GERMAN. Languages also impose a default territory and character set that will be used unless overridden.

The territory element determines the default date, monetary format, and numeric format conventions. If the territory is not defined, the default territory value from the language setting will be used. Territories carry distinct names such as AMERICA, CANADA, and GERMANY. The character-set element determines the client character set. Normally this would be

the Oracle character set that matches the character set of the operating system or terminal. Character sets have unique identifiers such as WE8ISO8859P1, US7ASCII, and JA16EUC.

All NLS_LANG definition components are optional. For example, the following is valid to set the language component independently of the other components:

NLS_LANG=FRENCH

It is also possible to set the territory and character-set components independently, but the following conventions must be followed:

For example, to set the territory to AMERICA, you could use this syntax:

NLS_LANG=_AMERICA

Oracle Character-Set Naming Convention

The naming convention for Oracle character sets is as follows: region number_of_bits standard_character_set_name [S][C]

The elements of the naming convention have the following meanings:

NNstandard_character_set_name represents the common name for the character set. This name can vary in length (ASCII, ISO8859P1, SJIS).

NNThe optional S and C are used to specify character sets that are exclusive to the server (S) or the client (C) side.

For example, US7ASCII is a 7-bit United States code commonly referred to as ASCII (American Standard Code for Information Interchange).

The Unicode character sets UTF-8 and UTF-E defy Oracle’s standard character-set naming convention.

To set the client character set to UTF-8, you could use this syntax:

NLS_LANG=.UTF8

Use caution when setting NLS_LANG. It is possible to make combinations that will not function correctly, such as specifying a character set that does not support the specified language.

In the following example, you’ll set the NLS_LANG parameter to FRENCH_FRANCE

.WE8ISO8859P1 and see how this affects your session. Remember that NLS_LANG is an environment variable setting, so it must be set in the operating system before connecting to Oracle:

$ export NLS_LANG=French_France.WE8ISO8859P1 $ sqlplus “/ as sysdba”

SQL*Plus: Release 11.1.0.6.0 - Production on Dim. Oct. 19 20:46:55 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

630  Chapter 13  n  Implementing Globalization Support

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select prod_id, time_id, round(sum(amount_sold),2) amount from sh.sales

group by prod_id, time_id;

PROD_ID TIME_ID AMOUNT

---------- -------- ----------

36292 rows selected. SQL>

As you can see in this example, the date and number formats follow the conventions established in the NLS_LANG settings.

Using Language and Territory Parameters

NLS language and territory functionality can also be defined individually using the NLS_ LANGUAGE and NLS_TERRITORY parameters.

On the server side, these parameters can be set as initialization parameters. They will then become the default settings for the Oracle instance. For example, the following lines could be inserted into the INIT.ORA file:

NLS_LANGUAGE=French

NLS_TERRITORY=France

When the database instance is next started, these settings will become the default settings for the instance.

On the client side, these parameters can be set within a session by using the ALTER SESSION statement, as shown here:

SQL> alter session set NLS_LANGUAGE=French;

Session altered.

SQL> alter session set NLS_TERRITORY=France;

Session altered.

NLS parameters modified using ALTER SESSION have a higher precedence than those set through environment variables such as NLS_LANG. Therefore, they will override the previously set parameter values. This topic will be covered later in this chapter. Of course, the value for NLS_LANGUAGE and NLS_TERRITORY must be legitimate; for example, attempting to set the NLS_TERRITORY to Fredonia will result in an error:

SQL> alter session set NLS_TERRITORY=Fredonia;

ERROR:

ORA-12705: Impossible d’acc_der aux fichiers de donn_es

NLS ou l’environnement indiqu_ n’est pas valide

And if you don’t read French but you wish to know what the error message translates to in American English, simply set your NLS_LANGUAGE to American and then attempt to set the NLS_TERRITORY to Fredonia.

SQL> alter session set NLS_LANGUAGE=American;

Session altered.

SQL> alter session set NLS_TERRITORY=Fredonia; ERROR:

ORA-12705: Cannot access NLS data files or invalid environment specified

Using Date and Time Parameters

NLS date and time functionality can also be defined individually using the following NLS parameters:

NN NLS_DATE_FORMAT

NN NLS_DATE_LANGUAGE

NN NLS_TIMESTAMP_FORMAT

NN NLS_TIMESTAMP_TZ_FORMAT

632  Chapter 13  n  Implementing Globalization Support

All of these parameters can be set within a session by using the ALTER SESSION statement. They can also be defined as initialization parameters and will then become default settings for the entire instance.

NLS_DATE_FORMAT

The NLS_DATE_FORMAT parameter specifies the default format for dates in the current session. It can be defined as any valid date-format mask, such as in this example:

SQL> ALTER SESSION SET NLS_DATE_FORMAT = MM/DD/YY;

Session altered.

You can even append text literals into the date format, if you wish, by enclosing the literal in double quotes. You must also enclose the entire format string in apostrophes (single quotes), as shown here:

SQL> alter session set NLS_DATE_FORMAT =’”Today’’s date is “MM/DD/YYYY’;

Session altered.

SQL> select sysdate from dual;

SYSDATE

--------------------------

Today’s date is 10/19/2008

Note that normal quoting rules apply inside the text literal. Therefore, two apostrophes were required to create the string “Today’s”.

NLS_DATE_LANGUAGE

The NLS_DATE_LANGUAGE parameter governs the language used in the following situations:

NLS_DATE_LANGUAGE accepts any valid language as a value and can be set as shown here:

SQL> alter session set nls_date_language=Italian;

Session altered.

SQL> select to_char(sysdate,’Day:Dd Month YYYY’) from dual;

634  Chapter 13  n  Implementing Globalization Support

datatypes. However, as the name suggests, it adds the option of time-zone formatting, as shown here:

SQL> alter session set nls_timestamp_tz_format = ‘YYYY/MM/DD HH:MI TZH:TZM’;

Session altered.

SQL> select startup_time from sys.dba_hist_snapshot where rownum < 3;

STARTUP_TIME

-----------------------------------------------------------------------

10/11/2008 11:32:33.000 10/11/2008 11:32:33.000

SQL> select next_run_date from sys.dba_scheduler_jobs;

NEXT_RUN_DATE

-----------------------------------------------------------------------

2008/10/20 03:00 -05:00 2008/10/20 03:00 -05:00 2008/11/01 01:01 -05:00 2008/10/19 09:26 -04:00 2008/10/19 08:40 -05:00

5 rows selected. SQL>

As you can see in the example, the TZH:TZM element shows the time-zone offset in hours and minutes.

Using Calendar Parameters

Different geographical areas can use different calendaring systems. Oracle 11g’s globalization support defines seven distinct calendars, all of which are fully supported:

For each of these calendars, the following information is maintained:

First day of the week    While the United States and many other countries consider Sunday to represent the first day of the week, other countries, such as Germany, consider Monday to be the first day of the week.

First calendar week of the year    Many countries use the week number for things like bookkeeping and scheduling. However, an International Standards Organization (ISO) week can differ from the calendar-week number. (ISO weeks run from Monday through Sunday.) Oracle supports both conventions. Here are the definitions provided by Oracle:

NNIf January 1 falls on a Friday, Saturday, or Sunday, then the ISO week that includes January 1 is the last week of the previous year because most of the days in the week belong to the previous year.

NNIf January 1 falls on a Monday, Tuesday, Wednesday, or Thursday, then the ISO week is the first week of the new year because most of the days in the week belong to the new year.

Number of days/months in a year    The number of days and months in a year can differ between calendars, as shown in Table 13.2.

First year of the era    Different regions may also choose a notable year in which to start, much like the Gregorian calendar starts with Anno Domini (Latin for “the year of the Lord”), also known as the Common Era. The Islamic calendar, for example, starts with the year of the Hegria (622 AD, when the prophet Mohammed and his followers migrated from Mecca to Medina). The Japanese Imperial calendar starts from the first year of an Emperor’s reign.

The NLS_CALENDAR parameter is used to specify which calendar Oracle should use, as shown here:

SQL> alter session set NLS_CALENDAR = ‘Persian’;

Session altered.

SQL> select sysdate from dual;

in the number-format mask. Any single-byte character can be assigned, with the following exceptions:

When this parameter is set, the decimal character comes before the group separator, as shown here:

SQL> alter session set NLS_NUMERIC_CHARACTERS=”,.”;

Session altered.

SQL> select cust_id, to_char(sum(amount_sold), ‘9G999G999D99’) big_sales from sh.sales

group by cust_id

having sum(amount_sold) > 30000; CUST_ID BIG_SALES

---------- -------------

…

6960 33.407,59

7680 33.528,24

3080 43.395,67

12600 49.980,28

850 rows selected. SQL>

As you can see, the decimal character is now represented by a comma. The group separator, on the other hand, is now represented by a period.

NLS_LIST_SEPARATOR

The NLS_LIST_SEPARATOR parameter specifies the character used to separate values in a list of values. The following restrictions apply to the NLS_LIST_SEPARATOR parameter:

638  Chapter 13  n  Implementing Globalization Support

NLS_CURRENCY

The NLS_CURRENCY parameter defines the currency symbol that will be displayed by the element L in the number-format mask, as shown here:

SQL> alter session set NLS_CURRENCY = “£”;

Session altered.

SQL> select to_char(123.45,’L9G999G999D99’) amount from dual;

AMOUNT

-----------------------

£123.45

The NLS_CURRENCY parameter is not limited to a single character. It can be set to a string as well:

SQL> alter session set NLS_CURRENCY = “ USD”;

Session altered.

SQL> select to_char(123.45,’9G999G999D99L’) amount

2from dual;

AMOUNT

-----------------------

123.45 USD

Notice in the example that a space is embedded at the beginning of the string. Without the space, the output would appear as shown here:

AMOUNT

-----------------------

123.45USD

NLS_ISO_CURRENCY

The NLS_ISO_CURRENCY parameter is used to prevent ambiguity in the currency symbol. For example, the dollar sign ($) can be used for both Australian and American dollars. NLS_ISO_CURRENCY uses a unique text string in place of the currency sign. Several common examples are shown here:

USD: United States AUD: Australia

EEK: Estonia

EUR: Germany

GBP: United Kingdom

The NLS_ISO_CURRENCY parameter defines the currency symbol that will be displayed by the C element of the number-format mask. It can be modified using the ALTER SESSION statement, but instead of a text string, it requires a valid territory name, as follows:

SQL> alter session set NLS_ISO_CURRENCY=France;

Session altered.

SQL> select to_char(123.45,’9G999G999D99C’) amount

2from dual;

AMOUNT

--------------------

123.45EUR

Using the NLS_LENGTH_SEMANTICS Parameter

Single-byte character sets always use one byte to store one character. This makes storage calculation a breeze. But when you’re using a multibyte character set, such as Unicode, a single character may use several bytes of storage. Column sizing becomes much more difficult in this situation.

Length semantics, originally introduced in Oracle9i, make it possible to size columns using either bytes or characters. The method of calculating the length of character strings in bytes is known as byte semantics. Calculating the length in characters is referred to as character semantics.

The NLS_LENGTH_SEMANTICS parameter defines the default method of length semantics to either BYTE (the default) or CHAR. An example is shown here:

SQL> alter system set NLS_LENGTH_SEMANTICS = CHAR;

System altered.

Consider the following example:

SQL> create table test_table (

Last_name VARCHAR2(25));

Table created.

When length semantics are set to CHAR, the LAST_NAME column in this table will hold 25 characters, no matter how many actual bytes of storage are required.

640  Chapter 13  n  Implementing Globalization Support

When length semantics are set to BYTE, the LAST_NAME column will allocate 25 bytes of storage. If the character set requires 3 bytes to store a single character (or symbol), only 8 characters can be stored.

The default setting can be overridden by declaring the length semantics directly in the CREATE TABLE statement. For example, when you’re defining a character column, character semantics can be forced using the following syntax:

SQL> create table test_table (

Last_name VARCHAR2(25 CHAR));

Table created.

This example forces the use of character semantics, regardless of the setting of the NLS_ LENGTH_SEMANTICS parameter.

There are a few exceptions to consider when dealing with length semantics:

NNNCHAR, NVARCHAR, CLOB, and NCLOB datatypes are not affected by the NLS_ LENGTH_SEMANTICS parameter value. These are datatypes designed specifically for multi­ byte character data; therefore they will always use character semantics.

NNTables in the SYS and SYSTEM tablespaces are not governed by the NLS_LENGTH_SEMANTICS parameter. All data dictionary tables always use byte semantics.

Prioritizing NLS Parameters

Oracle databases often represent only one tier in a multitier environment. For instance, let’s assume that Arren is a user in France. He uses a custom, client-side application that connects to an application server in Italy. The application server connects to a transactionprocessing gateway in Sweden. The transaction-processing gateway connects to the Oracle database in the United States.

Each of these machines may have NLS settings appropriate for their respective locale, but none match the settings of the database server. How does the database server determine the NLS settings to honor?

There are several different ways in which NLS parameters can be specified. Therefore, when conflicting settings are issued, Oracle needs to have a method of prioritizing to determine which setting will ultimately be used.

NLS parameters can be defined using any of the following methods:

In the following sections, you will learn about each of the methods of setting NLS parameter values as well as how Oracle chooses to prioritize them.

Setting Server-Initialization Parameters

NLS settings can be defined as initialization parameters on the server. Initialization parameters are loaded at instance-startup time, as in this example:

NLS_LANGUAGE=FRENCH

The effect of initialization-parameter settings will be seen only on the server. They have no effect on the client side. They will, however, govern sessions created by the client to the server, unless the client NLS environment overrides them.

Setting Client Environment Variables

Environment variables on the client side will govern local client-side NLS operations (operations that don’t involve the database). They will also override server-side NLS settings for sessions created from the client.

In the following example, the environment variable NLS_LANGUAGE is set to French before a session is opened. Note that in a Windows environment, the environment variable could be set either using the set command or in the Environment tab in the System Properties window.

$ export NLS_LANGUAGE=French

$ sqlplus “/ as sysdba”

SQL*Plus: Release 11.1.0.6.0 - Production on Dim. Oct. 19 21:22:15 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> select to_char(sysdate, ‘Mon’) from dual;

TO_CH

-----

Oct.

When the client-side environment variable NLS_LANG was set, the server’s NLS settings were overridden for the session. The client program accomplishes this by issuing an implicit ALTER SESSION statement when a new session is opened.

642  Chapter 13  n  Implementing Globalization Support

Using the ALTER SESSION Statement

Setting NLS parameters using the ALTER SESSION statement also overrides the server-side NLS settings for the current session, as in this example:

SQL> ALTER SESSION set NLS_SORT = FRENCH;

Session altered.

Using ALTER SESSION also overrides any previous ALTER SESSION settings. Therefore, an explicit ALTER SESSION statement overrides settings from the client environment variables (which perform an implicit ALTER SESSION call).

Setting NLS Parameters in SQL Functions

NLS parameters can also be set inside certain SQL functions. Inline NLS parameter settings have the highest priority and will override any other NLS settings. However, their scope is limited to the immediate SQL function, as shown here:

SQL> select to_char(sysdate, ‘DD/MON/YYYY’,’nls_date_language=Italian’) from dual;

TO_CHAR(SYS

-----------

19/OTT/2008

SQL> select to_char(sysdate, ‘DD/MON/YYYY’) from dual;

TO_CHAR(SYSDA

-------------

19/OCT./2008

As you can see in this example, the inline NLS parameter setting affected only the function in which it was called. It had no effect on the subsequent statement.

Only specific SQL functions will accept inline NLS parameter settings.

Prioritization Summary

As you learned in the preceding sections, there are five distinct methods in which NLS parameters can be specified. Oracle prioritizes these methods to ensure that conflicting settings can be resolved. Table 13.3 summarizes these methods for NLS parameter prioritization as well as the scope for each method.

Using NLS Views

Information relating to Oracle NLS settings is stored in the data dictionary and inside fixed tables in memory. This information consists of NLS settings for the session, instance, and database. You can also view a list of the valid values that may be specified when setting NLS parameters.

The following views can be queried to find NLS information from the data dictionary and from dynamic performance tables:

NN NLS_SESSION_PARAMETERS

NN NLS_INSTANCE_PARAMETERS

NN NLS_DATABASE_PARAMETERS

NN V$NLS_VALID_VALUES

We will look at each of these views in the following sections.

NLS_SESSION_PARAMETERS

The NLS_SESSION_PARAMETERS view offers an insight into the current NLS settings for your session. Here is an example, continuing with the environment and session NLS parameters set earlier:

SQL> select * from nls_session_parameters;

644  Chapter 13  n  Implementing Globalization Support

17 rows selected.

You will notice that the NLS_SESSION_PARAMETERS view is restricted to show only the current session and nothing more. You may also see settings here that you don’t remember specifying. If so, the values represent either the default setting or the value derived from

a higher-level NLS parameter. For example, if NLS_TERRITORY is set to AMERICA, the NLS_ CURRENCY parameter will automatically be set to use dollars.

NLS_INSTANCE_PARAMETERS

The NLS_INSTANCE_PARAMETERS view returns NLS settings for the entire instance rather than for a single session. These are settings that have been set explicitly through initialization parameters or ALTER SYSTEM statements. Here is an example:

SQL> select * from nls_instance_parameters;

17 rows selected.

The results from the NLS_INSTANCE_PARAMETERS view show that many parameters have not been explicitly set. Instead, they derive their value from higher-level parameters. For example, NLS_SORT derives its value from NLS_LANGUAGE, while the currency-, date-, and time-related parameters are derived from NLS_TERRITORY.

NLS_DATABASE_PARAMETERS

The NLS_DATABASE_PARAMETERS view shows NLS settings for the database itself. These represent the default values that will govern the instance, unless they are overridden by initialization parameter settings.

An example is shown here:

SQL> select * from nls_database_parameters;