Answers to Review Questions

1.​C.  The SET_JOB_ANYDATA_VALUE procedure allows you to set job arguments that don’t easily convert to and from a string (VARCHAR2) datatype.

2.​A, D.  Programs (as well as jobs) can be enabled in two ways: by using the ENABLE procedure or by using the SET_ATTRIBUTE procedure to set the ENABLED attribute to TRUE.

3.​C.  The calendaring syntax does not support an element named RUNDATE. It does not support the concept of specifying a single run date at all. The purpose of the calendaring syntax is to define repeat intervals that will be used to calculate run dates.

4.​B, D.  The DBA_SCHEDULER_RUNNING_JOBS view shows detailed information about all jobs currently executing. The DBA_SCHEDULER_JOBS view contains the STATE column, which shows a value of RUNNING for an executing job.

5.​B.  A schedule defined within a job object is known as an inline schedule, whereas an independent schedule object is referred to as a stored schedule. Inline schedules cannot be referenced by other objects.

6.​A, E.  A job can be altered only by changing the value of one or more of its attributes. This is accomplished by using the SET_ATTRIBUTE and SET_ATTRIBUTE_NULL procedures.

7.​B.  Jobs and programs are created in a disabled state by default. They must be enabled by setting the ENABLE parameter to TRUE in their respective CREATE statements, or by altering the object after creation.

8.​A, D.  The LOG_HISTORY parameter defines the retention period for both job logging and window logging by default. However, the WHICH_LOG parameter can be used to specify either JOB_LOG or WINDOW_LOG.

9.​A.  Executing the SET_ATTRIBUTE procedure with the job_priority attribute changes the priority of a job, with 1 being the highest priority and 5 the lowest. This procedure does not give the job priority over running jobs with the same priority (1).

10.​B.  The BYMONTHDAY element accepts negative values that represent a specific count of days from the end of the month. Also, the FREQ parameter must be set to MONTHLY because it will execute every month.

11.​A.  The job coordinator does not update the job log when a job completes. That function is performed by the job slave that has been assigned to the job.

12.​A, D.  A window does not execute programs or jobs. It specifies a resource plan that will be enabled based on a schedule. Therefore, it can reference both a schedule object and a resource-plan object. And while the resource plan may reference one or more resource consumer groups, the window object does not directly reference them.

13.​A, D.  PLSQL_BLOCK and STORED_PROCEDURE are the only valid program types that can be used with a lightweight job.

616  Chapter 12  n  Using the Scheduler to Automate Tasks

14.​B.  Java stored procedures cannot be executed by the job Scheduler unless they are called from within a PL/SQL procedure wrapper. This can be done in a stored procedure using PL/SQL’s External Procedure feature. Therefore, the job or program type setting would be

STORED_PROCEDURE.

15.​A, B, D.  Schedule objects do not specify any action to be performed; they simply generate execution dates that any job can use. Program and job arguments allow the jobs and programs to be reused by simply changing the arguments that are passed in. Job classes simplify the management of jobs, but they do not specifically encourage job reuse.

16.​D.  The Scheduler will attempt to wrap the job within a transaction and will execute a rollback if a job is stopped. However, if the job has performed commits, the rollback will roll back only uncommitted changes. This could result in inconsistent data.

17.​E.  A schedule object does not possess the ENABLED attribute. It is therefore enabled upon creation and can never be disabled.

18.​A, B, E.  When a job exceeds its end date, it will be dropped only if the AUTO_DROP attribute is set to TRUE. Otherwise, it will be disabled. In either case, the STATE column will be set to COMPLETED in the job table. A job object does not possess a CASCADE attribute or a STATE attribute.

19.​B.  Job chains are used to implement dependency-based scheduling. A job chain consists of two or more Scheduler programs.

20.​A.  The WINDOW_PRIORITY attribute can be set to either HIGH or LOW for a window. If two windows overlap and only one of the windows has a priority of HIGH, it will be chosen.

Doing business on a global scale presents a new set of challenges to any company, especially to the DBA. Beyond the obvious issues of language lie a host of less obvious but equally

important issues that must be addressed—time-zone differences, mixed currency types, and differing calendars, just to name a few. But Oracle’s globalization support features provide the tools needed to meet these challenges.

Globalization support enables you to manage data in multiple languages. It provides the functionality to ensure that native language and locale conventions are followed when dealing with date, time, currency, numeric, and calendar data.

Globalization support also offers datetime datatype options for handling transactions crossing time zones. And it provides a rich set of options for linguistic sorts and searching.

In this chapter, you’ll learn what globalization support entails and how it all fits together. You’ll see how National Language Support (NLS) parameter settings can change the functionality of many of Oracle’s operations. You will learn about datetime datatypes and how they can be used to synchronize data around the globe. You’ll also learn about new linguistic sorting and searching options that allow multilingual data to be searched, sorted, and managed simply and efficiently.

Exam objectives are subject to change at any time without prior notice and at Oracle’s sole discretion. Please visit Oracle’s Training and Certification website (http://www.oracle.com/education/certification/) for the most current exam-objectives listing.

An Overview of Globalization Support

Oracle’s globalization support is a collection of features that allow you to manage data in multiple native languages within the same database instance. It also greatly simplifies application development by offering a rich set of globalization functionality to the developer.

Globalization support provides the character sets and datatypes needed to store multilingual data. It ensures that date, time, monetary, numeric, and calendar data will follow any supported locale conventions and display properly. It provides utilities and error messages translated to many different languages. It also provides the internal functionality to sort and to query multilingual data using proper linguistic rules.

In the following sections, you will learn about Oracle’s globalization support features. You will get an overview of each feature and the functionality that it provides.

You will learn about the architecture upon which globalization support is built. You’ll be introduced to the National Language Support Runtime Library (NLSRTL) and see how its modular design provides flexibility and saves resources.

You will also learn how applications interact with Oracle from a globalization perspective.

And finally, you will be introduced to Unicode and the advantages that it offers in a multilingual environment.

Globalization Support Features

Globalization support provides a rich set of functionality to the Oracle database. But it is important to make two distinctions perfectly clear regarding what globalization support does not do:

Globalization support simply provides the infrastructure to allow text to be stored, manipulated, sorted, and searched in many languages using linguistically significant means. It also allows the data to be displayed using the standard conventions for a specific region.

Globalization support includes these features:

Language support    Globalization support allows data to be stored, processed, and retrieved in virtually any scripted language. For many of these languages, Oracle provides additional support such as text-sorting conventions, date-formatting conventions (including translated month names), and even error-message and utility-interface translation.

Territory support    Cultural conventions often differ between geographical locations. For example, local time format, date format, and numeric and monetary conventions can differ significantly between regions even though they may share a common language. To allow for these differences, the NLS_TERRITORY parameter can be used to define which conventions to follow.

However, these default settings can still be overridden through the use of NLS parameter settings. Overriding the default settings allows finer granularity in defining and customizing display formats to account for special circumstances. For example, it is possible to set the primary currency to the Japanese yen and the secondary currency to the dollar even with the territory defined as India.

Linguistic sorting and searching    Globalization support offers culturally accurate case conversion, sorting, and searching for all supported languages. It offers the ability to search and sort based on the rules of language rather than simply on the order in which the characters are encoded in the character set. It also offers case-insensitive sorts and searches as well as accent-insensitive sorts and searches.

Linguistic sorts are defined separately from the language itself, allowing the ability to share sort definitions between languages. Linguistic sort defaults can also be overridden through the use of NLS parameter settings. This gives you the flexibility to customize your environment as needed.

620  Chapter 13  n  Implementing Globalization Support

Character sets and semantics    Oracle supports a vast number of character sets based on national and international standards, including Unicode. Because of the wide variety of character sets, users can often find a single set that supports all of the languages they need to support.

Unicode is a universal character set that supports all known written languages. Oracle offers full support of the Unicode 5.0 standard and offers several Unicode encoding options.

Unicode can be defined as the database character set, making it the default datatype for all character columns. If Unicode is not defined as the database character set, it can still be used by defining specific columns as Unicode datatypes (in other words, NCHAR, NVARCHAR2, NCLOB).

Many multibyte character sets use variable widths when storing data. This means that, depending on the character being stored, Oracle may use anywhere from 1 to 4 bytes to store it. Therefore, defining column widths in terms of the number of characters, rather than the number of bytes, becomes crucial. Character semantics allow character data to be specified in terms of the number of characters regardless of the number of bytes actually required. Byte semantics, the default, assume a single-byte character set, where one character always requires 1 byte of storage.

While Unicode may seem like the logical choice for any database, the decision to use it needs to be weighed carefully. There are performance and space-usage penalties associated with using Unicode. If a smaller code set is available that encompasses all of the languages you are likely to ever need, then the overhead of Unicode makes it an illogical choice.

Calendars    Different geographic areas often utilize different calendar systems, which can make international transactions hard to synchronize. Oracle supports seven distinct calendar systems: Gregorian, Japanese Imperial, ROC (Republic of China) Official, Thai Buddha, Persian, English Hijrah, and Arabic Hijrah. Globalization support offers functionality to resolve calendar-system differences.

Locale and calendar customization    Oracle’s Locale Builder utility allows customization of globalization definitions, including language, character set, territory, and linguistic sorting. Calendars can also be customized using the NLS Calendar utility. Coverage of Locale Builder and the NLS Calendar utilities fall outside the scope of this book.

Globalization Support Architecture

Globalization support in Oracle 11g is implemented through the Oracle National Language Support Runtime Library (NLSRTL). The NLSRTL offers a set of language-independent text and character-processing functions as well as functions for language-convention manipulation. The behavior of these algorithms is determined at runtime (database startup), as the name suggests.

At database startup time, NLSRTL looks for a file named lx1boot.nlb. This file defines the set of locale definitions available to the database. To determine where to look for this file, NLSRTL will first check the environment for the existence of an ORA_NLS10 variable.

If ORA_NLS10 is defined, it will contain the path to where the lx1boot.nlb file resides. If the variable is not set, the default location of $ORACLE_HOME/nls/data will be used instead.

By default, ORA_NLS10 is not set. It should be set only in a multihomed environment where the locale-specific files are shared.

The lx1boot.nlb file identifies the set of locales available to the NLSRTL. These locales are defined in a collection of locale definition files that reside in the same directory as the lx1boot.nlb file.

There are four types of locale definition files:

Each file contains data relating to only one particular locale type. For each locale type, there can be many different definition files.

This modular design of the locale definition files offers several distinct benefits:

NNBy using only the set of locales that you need, memory won’t be wasted on unnecessary locales.

For example, the file lx00001.nlb is the language file for American, as shown in the Locale Builder in Figure 13.1.

622  Chapter 13  n  Implementing Globalization Support

F i gu r e 13 .1   ​  Locale​ Builder file lx00001.nlb

The complete set of locale definition files represents the globalization options available inside the database. Locale definitions can also be added or modified to support new functionality.

Supporting Multilingual Applications

Globalization allows the database to support multitier and client/server applications in any language for which it is configured. Locale-dependent operations are governed by NLS parameters and NLS environment variables set on both the client and server sides.

In the following sections, you will learn how client applications interact with the server from a globalization viewpoint. You will learn the purpose of the character sets defined at database-creation time. You’ll learn how data-conversion issues can affect session performance. And finally, you’ll learn how clients resolve globalization environment differences when they connect to a server.

Database Character Sets

When a database is created, two session-independent NLS parameters are specified: the database character set and the national character set.

The database character set defines the character set that will govern default text storage in the database. This includes all CHAR, VARCHAR2, LONG, and CLOB data as well as all SQL and PL/SQL text.

The national character set is an alternate Unicode character set that governs NCHAR, NVARCHAR2, and NCLOB data. You may want to store characters in the database from

a character set that is not the database default; for example, the default character set may be US7ASCII, but you may also wish to store Chinese characters in the database. Use the national character set NCHAR, NVARCHAR2, and NCLOB data types to store this nondefault character-set data.

Together, these two settings define the available character sets for the database.

Setting the Database Character Set

When you create the database, you specify the database character set thusly using the CHARACTER SET clause, and set the national character set using the NATIONAL CHARACTER SET clause:

SQL> CREATE DATABASE LNETEST

…

CHARACTER SET AL32UTF8

NATIONAL CHARACTER SET AL16UTF16

…

To identify SQL and PL/SQL source code, the database character set must have either EBCDIC or 7-bit ASCII, depending on the underlying platform, as a subset. Since it is not possible to use a fixed-width multibyte character set as the database character set, you cannot specify AL16UTF16 as the database character set. You can, however, specify AL16UTF16 as the national character set.

Changing the Database Character Set

Once you’ve created the database, you must re-create it to change the database character sets. The only exception is that if the new character set is a strict superset of all of the schema data, you can use the CSALTER script to change the database character set.

If it is not possible to utilize the CSALTER script, then you can perform a full export of the database, create the new database with the new character set, then import the full database.

Automatic Data Conversion

When a client makes a connection to a database server, the character sets used on both the client and server are compared. If they do not match, Oracle will need to perform automatic data conversion to resolve the difference. There is overhead involved in this conversion process as well as a risk of data loss. Performance will be affected relative to the level of conversion required.

The exception to this rule is when the database character set is a strict superset of the client character set. Two things must be true in order to classify a character set as a strict superset of another:

NNThe encoded values of all characters defined in the subset must match their encoded values in the superset.

624  Chapter 13  n  Implementing Globalization Support

If Oracle determines that both of these requirements are met, it will not perform automatic data conversion because it is not necessary.

Resolving Client/Server Settings

Any application that connects to the server is considered to be a client, in terms of globalization. Even if the application lives on the same physical machine as the server, it will still be classified as a client. This includes middle-tier application servers. Therefore, from a globalization perspective, all applications are governed by client-side NLS parameters.

When a client application is run, the client NLS environment is initialized from the environment variable settings. All local NLS operations are executed using these settings. Local NLS operations are client operations performed independently of any Oracle server session (for example, display formatting in Oracle Developer applications).

When the application completes a connection to the database server, the resulting session is initialized with the NLS environment settings of the server.

However, immediately after the session is established, the client implicitly issues an ALTER SESSION statement to synchronize the session NLS environment to match the client’s NLS environment. In fact, the session environment can be modified at any time by using the ALTER SESSION statement, as shown here:

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.

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 sysdate from dual;

SYSDATE

---------

28-AUG-08

SQL> alter session set NLS_LANGUAGE=French;

Session altered.

SQL> select sysdate from dual;

SYSDATE

-----------

28-AOÛT -08

SQL> alter session set NLS_LANGUAGE=Italian;

Session altered.

SQL> select sysdate from dual;

SYSDATE

---------

28-AGO-08

Remember, however, that using ALTER SESSION changes only the session NLS environment. It does not change the client NLS environment.

Using Unicode in a Multilingual Database

Unicode is a universal character set that encompasses all known written languages in the world. Historically, dealing with multiple languages in a database or an application has been a difficult proposition. Existing character sets have always been too limited. Many don’t even offer all the characters required for a single language, much less for all languages!

To support a wide variety of languages, it often meant that applications, databases, and programs using different character sets would have to be able to interact and exchange data, all with proper data conversion taking place every step of the way.

To address this problem, Unicode was created with this simple motto:

Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language.

Source: www.unicode.org/standard/WhatIsUnicode.html

Unicode assigns a guaranteed unique value (known as a code point) to every character to assure that no conflicts exist. Oracle supports version 5.0 of Unicode and offers the encoding methods listed in Table 13.1.

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