nls_db6_nw731_w10.pdf

8/9/2019 nls_db6_nw731_w10.pdf

http://slidepdf.com/reader/full/nlsdb6nw731w10pdf 1/41

How-To Guide

Document version: 2.02 – 2014-05-28

Enabling SAP NetWeaver Business WarehouseSystems to Use IBM DB2 for Linux, UNIX, andWindows as Near-Line Storage (NLS)For SAP Systems based on SAP NetWeaver 7.3, 7.31, and 7.4

CUSTOMER

8/9/2019 nls_db6_nw731_w10.pdf


Document History

Caution

Before you start the implementation, make sure you have the latest version of this document. You can find the

latest version at the following location: service.sap.com/instguidesnw <Your SAP NetWeaver Release>

Operations Database-Specific Guides .

The following table provides an overview of the most important document changes:

Version Date Description

1.0 2010-11-29 Initial version

1.1 2011-11-21 Updated version: Additional information about deleting archived data from NLS

1.2 2012-09-05 Updated version: Additional information about NLS databases running on IBM DB2 10.1 for

Linux, UNIX, and Windows

1.3 2013-05-10 Updated version: Small additions for SAP NetWeaver 7.4

2.0 2013-12-03 Updated version: Additional information about NLS databases running on IBM DB2 10.5 for

Linux, UNIX, and Windows

2.01 2014-04-24 Minor update: New tablespace names for NLS tablespaces (chapter Database Layouts for NLS

Objects)

2.02 2014-05-28 Minor update: Correction of navigation path in chapter Enabling BW Queries to Read NLS Data

2

CUSTOMER

© Copyright 2014 SAP AG.

All rights reserved.

Enabling SAP NetWeaver Business Warehouse Systems to Use IBM DB2 for Linux, UNIX, and

Windows as Near-Line Storage (NLS)

Document History

http://service.sap.com/instguidesnw

8/9/2019 nls_db6_nw731_w10.pdf


Content

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Installation of the NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Installing DB2 for Linux, UNIX, and Windows as NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Setting Up the Connection to the NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Database Layout of NLS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Database Layout of an NLS Infocube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Database Layout of an NLS DataStore Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 NLS Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Creating a Data Archiving Process for an InfoProvider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Archiving Data to the NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Reloading Archived Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.4 Deleting Archived Data from NLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5 Reloading Deleted Requests from ADK to NLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.6 Using NLS InfoProviders in a MultiProvider Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Administration of the NLS Database Using the DBA Cockpit . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1 Monitoring NLS Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.2 Deleting Invalid Data from the NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6 Business Warehouse Query Processing With NLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.1 Enabling BW Queries to Read NLS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 Using the Improved Query Look-Up Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7 Backup and Recovery of the NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1 Configuring the NLS Database for Archive Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.2 Backing Up the NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.3 Recovering the NLS Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8 Using DB2 as NLS Database with a BW System Running on a Different Database

Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9 Improving NLS Database Performance Using DB2 10.5 BLU Acceleration . . . . . . . . . . . . . . . . . 38

10 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39



Content

CUSTOMER


All rights reserved. 3

8/9/2019 nls_db6_nw731_w10.pdf


4

CUSTOMER





8/9/2019 nls_db6_nw731_w10.pdf


1 Introduction

This document describes how you enable an SAP NetWeaver Business Warehouse (BW) system to use IBM DB2 for

Linux, UNIX, and Windows as a near-line storage (NLS) database.

NLS is a new category of data persistency that is similar to archiving. Using an NLS database enables you to transfer

historical read-only data of your InfoProviders (for example, InfoCubes and DataStore objects) to an additional NLS

database. The database server and the storage devices of the NLS solution can be located on the same server as

the SAP NetWeaver BW system or on a dedicated server. However, you can still access the separated data in the

NLS database transparently from an SAP NetWeaver BW system.

The following figure shows a basic setup of the NLS solution with DB2 for Linux, UNIX, and Windows as NLS database:

Figure 1: Basic Setup of NLS Solution

You can access near-line storage data online via the OLAP processor and the additional near-line storage interface

that consists of the following parts:

●General near-line storage interface, which is database independent

● DB2-specific interface that establishes a database connection to the near-line storage database server and

accesses the near-line storage data

Note

For more information about the SAP NetWeaver BW NLS solution on DB2 for Linux, UNIX, and Windows, see SAP

Note 1405664.

Implementation Considerations

The NLS solution described in this document is available as of the following SAP NetWeaver releases and DB2

releases:



Introduction

CUSTOMER



http://service.sap.com/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=1405664&_NLANG=en&_NVERS=0


8/9/2019 nls_db6_nw731_w10.pdf


● IBM DB2 for Linux, UNIX, and Windows version 9.7 and higher (for the installation of the NLS database)

Note

To use the IBM DB2 compression feature in the NLS database, you must have purchased the correct license.

● SAP NetWeaver Business Warehouse 7.3 and higher, which is only supported with DB2 V9.7 or higher

● Only Unicode SAP NetWeaver BW systems are supported

Features

As of SAP NetWeaver Business Warehouse 7.3, the NLS solution has been enhanced as follows:

● Native support of MultiProviders without additional modeling of VirtualProviders

● You can now archive data from InfoCube F-fact tables into the NLS database. That is, you no longer have to

compress InfoCube data before it is transferred to the NLS database.

● More flexible access to NLS database

You can now configure InfoProviders using the new InfoProvider properties to define the NLS database accessas default for BW queries.

Naming Conventions

Throughout this document, the following naming conventions apply:

● Near-line storage is referred to as “NLS”.

● IBM DB2 for Linux, UNIX, and Windows is referred to as “IBM DB2 10.5”, “DB2 10.1”, “DB2 V9.7”, or “DB2” –

depending on the context used.

● The SAP NetWeaver Business Warehouse system is referred to as “SAP NetWeaver BW” or “BW system”.

6

CUSTOMER





Introduction

8/9/2019 nls_db6_nw731_w10.pdf


2 Installation of the NLS Database

2.1 Installing DB2 for Linux, UNIX, and Windows as NLSDatabase

The installation process of the NLS database has been completely integrated in the SAP installation tool and is similar

to the installation of other SAP products. The installation is fast and simple because only the database is created

and no content is loaded at the time of installation.

Procedure

To install the NLS database, run the SAP installer as described in Installing a Near-Line Storage Database for an SAP

NetWeaver BW in the installation documentation Installation Guide – SAP NetWeaver <Release> on <OS>: IBM DB2

for Linux, UNIX, and Windows that is available on SAP Service Marketplace at:

service.sap.com/instguidesnw <Your SAP NetWeaver Release> Installation Installation of SAP NetWeaver

Systems

The installer performs the following steps:

● Installs the DB2 software on the appropriate server

● Creates the operating system users and groups

● Creates a DB2 instance

● Creates and activates the DB2 database for NLS

The following table lists the most important parameters that you must specify during the dialog phase of the NLS

database installation.

Recommendation

Since you require the values of these parameters to configure the connection to your NLS database from your

BW system, we recommend that you note them down.

Table 2

Parameter Description

Database ID (DBSID) Three-letter database identifier of the NLS database

Password of database administrator Default user for the database administrator user is db2<dbsid> where

<dbsid> is the three-letter database identifier of your NLS database

Database communication port Required for TCP/IP communication between the NLS database server and

the remote DB2 clients

Note

You can leave this field empty. If you do not enter any value in this field, the

installer automatically chooses the port number for you.



Installation of the NLS Database

CUSTOMER




8/9/2019 nls_db6_nw731_w10.pdf


Parameter Description

Instance memory size Amount of memory (RAM) used by the DB2 instance running the NLS

database.

Since the installation tool assumes that there might be other applications

running on the same host (for example, another database or an SAP

application server), the installer automatically proposes the memory size,

which is approximately one third of the overall system memory.

However, this is only a proposal. You can optionally adapt this value to improve

the performance of your NLS database.

Note● If you are installing the NLS database on a dedicated host, you might

want to increase the instance memory to approximately 90% of the

overall system memory to achieve optimal performance.

● This parameter is not relevant for the configuration of the connection

to the NLS database.

Result

After the installation has completed, you set up the connection to the NLS database in your BW system using the

DBA Cockpit.

2.2 Setting Up the Connection to the NLS Database

Note

You can only set up a connection to the NLS database using the DBA Cockpit if your BW system is running on the

DB2 database. If your BW system is running on a different database platform, follow the instructions in Using DB2

as NLS Database with a BW System Running on a Different Database Platform [page 36] .

To set up a connection to the DB2 NLS database, you can use the NLS-specific extension of the DBA Cockpit. To set

up this connection, you require the following information that is specified during the installation of the NLS database:

● Remote database name

● Remote database host name

● Remote communication port

Procedure

Set up the connection to the NLS database as described in section BW Administration: NLS Configuration in the

separate document Database Administration Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows available

at:

service.sap.com/instguidesnw <Your SAP NetWeaver Release> Operations Database-Specific Guides

8

CUSTOMER





Installation of the NLS Database



8/9/2019 nls_db6_nw731_w10.pdf


3 Database Layout of NLS Objects

This section provides information about the layout of the NLS objects that are created in the remote NLS database

for the different types of supported InfoProviders as well as the naming conventions used for NLS tables.

After you have successfully established and configured a connection to the installed DB2 NLS database, you create

a data archiving process for an InfoProvider. The following types of InfoProviders are supported for NLS:

● Standard InfoCubes

● Real-time InfoCubes

● Standard DataStore objects

● Write-optimized DataStore objects

● DataStore object for direct update● MultiProviders (only if each single InfoProvider of the MultiProvider is one of the previous types)

For more information, see Using NLS InfoProviders in a MultiProvider Environment [page 26].

● Semantically Partitioned Object

During the creation of the data archiving process, you configure the InfoProvider to use the newly created NLS

connection. As soon as the data archiving process is activated, a set of tables is created in the NLS database. If an

NLS archiving request is later executed, selected data is transferred from the BW database to the NLS tables.

The number of NLS tables and their structure mainly depends on the type of InfoProvider for which you created the

data archiving process. Even though there are different types of InfoProviders, the NLS solution with DB2 mainly

uses two data models depending on whether the InfoProvider is like an InfoCube or like a DataStore object.

The NLS table names consist of the following elements in the sequence given here:

● Namespace of the original InfoProvider

● DB2 NLS-specific prefix (OA)

● Technical name of the original InfoProvider

● For InfoCubes only:

A dimension identifier. This identifier is added in combination with the character “-“.

Note

For the fact table of an InfoCube or the active data table of a DataStore object in the NLS database, the table name

is not amended with the combination of the character “-“ and the identifier of the type of table.

The fact table of an InfoCube and the active data table of a DataStore object are the only NLS tables that are also

created as transparent tables in the ABAP Dictionary.

Example

The table name of the NLS fact table for the InfoCube ZBENCH is /BIC/OAZBENCH, where /BIC/ is the namespace,

OA the NLS-specific prefix and ZBENCH the technical name of the InfoCube.

The table lists the values that you can use as the identifier for the dimension tables of NLS objects:

Table 3

Value Description

R Archiving request data

P Package dimension data (in case of an InfoCube)



Database Layout of NLS Objects

CUSTOMER



8/9/2019 nls_db6_nw731_w10.pdf


Value Description

T Time dimension data (in case of an InfoCube)

U Unit dimension data (in case of an InfoCube)

1 First user-defined dimension data (in case of an InfoCube)

2 Second user-defined dimension data (in case of an InfoCube)

… …

C 12th user-defined dimension data (in case of an InfoCube)

D 13th user-defined dimension data (in case of an InfoCube)

As a result, the table name of the NLS package dimension table for the InfoCube ZBENCH is /BIC/OAZBENCH-P.

3.1 Database Layout of an NLS Infocube

An InfoCube is created in an SAP NetWeaver BW database with an extended star schema. This data model is

implemented in SAP NetWeaver BW with the following tables:

● Two fact tables (E and F fact table).

When data is inserted into an InfoCube, data is at first stored in the F fact table. You can use BW compression

to optionally compress records from the F fact table with the same key value in one record only. During BW

compression, data is transferred from the F fact table to the E fact table, which has only unique keys. In addition

to the key figures, the E and F fact tables also store the DIMID columns that serve as foreign keys to the InfoCube

dimension tables.

● Up to 16 dimension tables

These tables contain descriptive information in a technical format for the key figures of the fact table.

● A certain number of master data tables containing the characteristics of the InfoCube

Note

The dimension tables also act as a link between the fact tables and the master data tables.

In contrast to the extended star schema of an InfoCube in a BW system, an InfoCube is created in the NLS database

with a simplified star schema.

This data model is implemented in the NLS database with the following tables:

● One table to store the archiving request information

Throughout this document, this table is called archiving request table. Every execution of a data archiving

process to move data to the NLS database creates an archiving request.

● One fact table

This fact table stores the key figures of the original InfoCube, references to dimension tables, a reference to the

NLS archiving request table, and other archiving information.

● A set of dimension tables

These tables store the characteristics of the original InfoCube. The number of dimension tables for the NLS

object equals the number of dimension tables for the original InfoCube in the BW database.

The following figure shows the simplified star schema for an InfoCube in the NLS database:

10

CUSTOMER






8/9/2019 nls_db6_nw731_w10.pdf


Figure 2

DB2-Specific Features in an NLS InfoCube

To optimize query performance, the multidimensional clustering (MDC) feature of IBM DB2 for Linux, UNIX, and

Windows is used in the NLS fact table. The columns used in the MDC definition are (in order of their usage) as follows:

● Column containing the archiving request identifier

● Columns of the original InfoCube for which MDC has also been defined

To ensure space savings when a large amount of data is transferred to the NLS database, DB2 row compression

(introduced with DB2 V9.1) is automatically enabled for each NLS table. As of DB2 V9.7, index compression is also

automatically enabled for each newly created NLS table. As of DB2 10.1, we recommend that you use the adaptive

compression feature. Adaptive compression improves compression ratios beyond the DB2 V9.7 compression ratio.

To enable adaptive compression, follow the instructions in SAP Note 1760373.

Each dimension table in the NLS database has a unique identifier for the different combinations of characteristic

values. To simplify its handling, this identifier is represented as an identity column in the dimension table.

The fact table and dimension tables (including the archiving request table) from the NLS database are stored in

dedicated tablespaces.

The following tables list the tablespace names in the NLS database for the InfoCube ZBENCH of SAP system NL1.

Note that the tablespace names depend on the support package level of your SAP BW system and whether you have

implemented SAP Note 1846770 or not.

The tablespace names in the table below are relevant for the following SAP NetWeaver BW releases:

● SAP NetWeaver BW 7.30 with support package 9 and lower


● SAP BW 7.4 with support package 2 and lower

The tablespace names are only relevant if SAP Note 1846770 is not implemented.

Table 4: Tablespace Names - Lower Support Package Levels and no SAP Note 2007123 Implemented

InfoCube Table BW Tablespace NLS Table Name NLS Tablespace Description

/BIC/FZBENCH NL1#FACTD

NL1#FACTI

/BIC/OAZBENCH NL1#NL1#FACTD

NL1#NL1#FACTI

Fact data and index

tablespaces




CUSTOMER








8/9/2019 nls_db6_nw731_w10.pdf



/BIC/DZBENCHT NL1#DIMD

NL1#DIMI

/BIC/OAZBENCH-T NL1#NL1#DIMD

NL1#NL1#DIMI

Dimension data and

index tablespaces

N/A N/A /BIC/OAZBENCH-R NL1#NL1#DIMD

NL1#NL1#DIMI

Archiving request data

and index tablespaces

The NLS tablespace names consist of the SAP system ID (<SAPSID>) that is appended as a prefix to the BW

tablespace name that is inherited from the original InfoProvider in the BW database.


● SAP NetWeaver BW 7.30 with support package 10 and higher


● SAP BW 7.4 with support package 3 and higher

● SAP NetWeaver BW releases with lower support package levels and SAP Note 1846770 implemented

Table 5: Tablespace Names - Higher Support Package Levels or SAP Note 2007123 Implemented


/BIC/FZBENCH NL1#FACTD

NL1#FACTI

/BIC/OAZBENCH NL1#<DBType>#

FACTD

NL1#<DBType>#

FACTI

Fact data and index

tablespaces

/BIC/DZBENCHT NL1#DIMD

NL1#DIMI

/BIC/OAZBENCH-T NL1#<DBType>#

DIMD

NL1#<DBType>#

DIMI

Dimension data and

index tablespaces

N/A N/A /BIC/OAZBENCH-R NL1#<DBType>#

DIMD

NL1#<DBType>#

DIMI


and index tablespaces

The NLS tablespace names consist of the SAP system ID (<SAPSID>) that is appended as a prefix to the database

type of the source BW system, followed by the tablespace type. For example, if the database of the source BW system

is IBM DB2 for Linux, UNIX, and Windows (DB6), the tablespace name for fact data is NL1#DB6#FACTD.

The extent size of these tablespaces is inherited from the original InfoProvider.If they do not yet exist, the NLS tablespaces are automatically created when a data archiving process is created in

the BW system.

During the tablespace creation for the dimension tables (including the archiving request table), the tablespace is

assigned to the database partition group NGRP_NLSDIM_<SAPSID>. If the tablespace of the fact table is created,

the tablespace is assigned to the database partition groupNGRP_NLSDATA_<SAPSID>. Both database partition

groups are automatically created as soon as a new NLS connection is added to the BW system using the DBA Cockpit.

With the DB2 database partitioning feature (DPF), you can improve query performance. You can add database

partitions to the NLS database, for example, by having a partitioned NLS database with n+1 database partitions

starting with partition number 0.

12

CUSTOMER






8/9/2019 nls_db6_nw731_w10.pdf


Recommendation

We recommend that you store the NLS dimension tables on database partition 0 and that you distribute the NLS

fact tables over the database partitions0, ..., n.

Example of NLS Tables for an InfoCube

The following table lists the NLS tables and their relationship with InfoCube ZBENCH.

Table 6

InfoCube Table Name NLS Table Name Description

/BIC/FZBENCH

/BIC/EZBENCH

/BIC/OAZBENCH Fact table

/BIC/DZBENCHP /BIC/OAZBENCH-P Package dimension

table

/BIC/DZBENCHT /BIC/OAZBENCH-T Time dimension

table

/BIC/DZBENCHU /BIC/OAZBENCH-U Unit dimension table

/BIC/DZBENCH1 /BIC/OAZBENCH-1 First user-defined

dimension table

… … …

/BIC/DZBENCHD /BIC/OAZBENCH-D 13th user-defined

dimension table

N/A /BIC/OAZBENCH-R Archiving request

table

3.2 Database Layout of an NLS DataStore Object

How a DataStore object (DSO) is represented in the BW database depends on the type of DataStore object. If it is a

standard DataStore object, it is represented by the following tables:

● Activation queue table

This table acts like a staging table of the DataStore object. When data is inserted into a DataStore object, it is

at first inserted into this table. During DataStore object activation process, records from DSO activation queue

table are transferred into the DSO active data table and changes are logged in the DSO change log table.

● Active data table

This table contains the consolidated data of the DataStore object and is also used for reporting.

● Change log table

This table stores - similar to a log file - the changes in the active data table after the activation queue table has

been processed.

A write-optimized DataStore object is only represented by the active data table. Data that is to be transferred to the

NLS database is only read from this active data table, which simplifies the representation in the NLS database. The

following tables are created in the NLS database when a data archiving process for a DataStore object is created:




CUSTOMER



8/9/2019 nls_db6_nw731_w10.pdf


● NLS archiving request table

This table stores the archiving request information. Every execution of a data archiving process to move data

to the NLS database creates an archiving request.

● NLS active data table

This table stores the business-related information of the original DataStore object (that is, key columns and

non key columns). In addition, the reference to the corresponding archiving request record and other archiving

information are stored in this table.

The following figure shows the layout of a DataStore object in the NLS database:

Figure 3: DSO Layout in the NLS Database

DB2-Specific Features in an NLS DataStore Object

To optimize query performance, the multidimensional clustering (MDC) feature of DB2 is used in the NLS active

data table. The columns used in the MDC definition are as follows:

● Column containing the archiving request identifier

● Columns of the original DataStore Object for which MDC has also been defined.

To ensure space savings when large amounts of data are transferred to the NLS database, DB2 row compression,

which was introduced with DB2 V9.1, is automatically enabled for each NLS table. As of DB2 V9.7, index compression

is also automatically enabled for each newly created NLS table. As of DB2 10.1, we recommend that you use the

adaptive compression feature. Adaptive compression improves compression ratios beyond the DB2 V9.7

compression ratio. To enable adaptive compression, follow the instructions in SAP Note 1760373.

The tablespace name that is used when the active data table is created in the NLS database consists of the tablespace

name inherited from the original InfoProvider in the BW database and the SAP system ID (<SAPSID>) that isappended as a prefix to the tablespace name. The extent size of this tablespace is also inherited from the BW

database. The archiving request table uses <SAPSID>_NLSGENERALD for its data and<SAPSID>_NLSGENERALI for

its indexes. Both tablespaces are created in the database partition group NGRP_NLSDIM_<SAPSID> as soon as a

new NLS connection is added to the BW system using the DBA Cockpit.

The following tables list the tablespace names in the NLS database for the DataStore objectZDSOBEN of SAP system

NL1. Note that the tablespace names depend on the support package level of your SAP BW system and whether you

have implemented SAP Note 1846770 or not.




● SAP BW 7.4 with support package 2 and lower

14

CUSTOMER








8/9/2019 nls_db6_nw731_w10.pdf


The tablespace names are only relevant if SAP Note 1846770 is not implemented.

Table 7

InfoCube Table Tablespace NLS Table Name NLS Tablespace Description

/BIC/AZDSOBEN00 NL1#ODSD

NL1#ODSI

/BIC/OAZDSOBEN NL1#NL1#ODSD

NL1#NL1#ODSI

Active data and index

tablespaces

N/A N/A /BIC/OAZDSOBEN-R NL1_GENERALD

NL1_GENERALI


and index tablespace




● SAP BW 7.4 with support package 3 and higher

●

SAP NetWeaver BW releases with lower support package levels and SAP Note 1846770 implementedTable 8

InfoCube Table Tablespace NLS Table Name NLS Tablespace Description

/BIC/AZDSOBEN00 NL1#ODSD

NL1#ODSI

/BIC/OAZDSOBEN NL1#<DBType>#

ODSD

NL1#<DBType>#

ODSI

Active data and index

tablespaces

N/A N/A /BIC/OAZDSOBEN-R NL1_GENERALD

NL1_GENERALI


and index tablespace

If they do not already exist, the NLS tablespaces are automatically created when a data archiving process is created

in the BW system.

When the tablespace of the active data table is created, the tablespace is assigned to the database partition group

NGRP_NLSDATA_<SAPSID>. The database partition group is automatically created as soon as a new NLS connection

is added to the BW system using the DBA Cockpit.

With the DB2 database partitioning feature (DPF), you can improve query performance. You can add database

partitions to the NLS database, for example by having a partitioned NLS database with n+1 database partitions

starting with partition number 0.

Recommendation

We recommend that you store the archiving request table on database partition0 and that you distribute the NLSactive data table over the database partitions 0, ..., n.

Example of NLS Tables for a DataStore Object

The following table lists the DataStore object tables in the NLS database for a standard DataStore object named

ZDSOBEN:




CUSTOMER




8/9/2019 nls_db6_nw731_w10.pdf


Table 9

Table Name of DataStore Object NLS Table Name Description

/BIC/AZDSOBEN00 (Active data table)

/BIC/AZDSOBEN40 (Activation queue

table)

/BI0/B0...

(Change data table)

/BIC/OAZDSOBEN Active data table

N/A /BIC/OAZDSOBEN-R Archiving request table

If the DataStore object ZDSOBEN is a write-optimized DataStore object, then it has only one table:

Table 10

DataStore Object Table Name NLS Table Name Description

/BIC/AZDSOBEN00 /BIC/OAZDSOBEN Active data table

N/A /BIC/OAZDSOBEN-R Archiving request table

16

CUSTOMER






8/9/2019 nls_db6_nw731_w10.pdf


4 NLS Operations

This section provides information about how you enable InfoProviders to use the NLS database by creating a data

archiving process (DAP). In addition, you learn how to perform basic operations on the NLS database (that is,

archiving data to and reloading data from the NLS database).

4.1 Creating a Data Archiving Process for an InfoProvider

Before you can archive data to the NLS database, you have to enable the InfoProvider (for example, the InfoCube orDataStore object) to use DB2 as NLS database.

Procedure

1. In your BW system, call transaction RSA1, choose the required InfoProvider and choose Create Data Archiving

Process from the context menu.

The screen Change Data Archiving Process appears.

Figure 4: Change Data Archiving Process Screen

2. On the tab page General Settings, perform the following steps:

● In the field Long Description, enter the long text for the DAP description.

● In the field Short Description, enter the short text for the DAP description.

● If you have not installed the ADK software, deselect the checkbox ADK-Based Archiving. ADK is used for

traditional BW data archiving.



NLS Operations

CUSTOMER



8/9/2019 nls_db6_nw731_w10.pdf


● In the field Nearline Connection, enter the name of the connection to the NLS database. If this connection

has not yet been set up, perform the steps described in Setting Up the Connection to the Near-Line Storage

Database [page 8].

Note

If you are creating a DAP for a write-optimized DataStore object, you can only choose Request-Based Archiving

in the group box Selection Profile (instead of Time Slice Archiving).

That is, during NLS archiving of the write-optimized DataStore object, you must choose such time restrictions

that only complete BW requests are archived.

3. If you want to further customize the DAP, you can optionally perform the following steps on the Selection

Profile tab page:

● In the field Characteristic for Time Slices, choose the required level of time granularity from the dropdown

list. For example, if you select 0CALMONTH, you can archive data only as complete months.

●

In the group box Additional Partitioning Characteristics, define the required additional characteristics. Thatis, if you define values here, you can set additional restrictions during the data archiving process (for

example, 0CALDAY < 01.01.2000 AND 0SALESORG = EUROPE).

Note

SAP NetWeaver 7.3 only:

If you want to create a DAP for an InfoCube and you want to avoid condensing uncompressed requests before

data is archived to the NLS database, you must choose the checkbox Allow Archiving of Non-Compressed Data

on the Selection Profile tab page.

4. Save and activate the DAP.

The dialog box Log Display appears displaying the detailed status information about the created DAP for your

InfoProvider.

Result

After you have successfully activated the DAP, the appropriate NLS tables and, if required, the tablespaces are

created in the NLS tablespace. You can now archive data from this InfoProvider to the NLS database as described

in the next section.

4.2 Archiving Data to the NLS Database

You use the following procedure to archive data to the NLS database by creating an archiving request for your

InfoProvider.

Before you perform the steps described in the following procedure, consider the following:

You can archive data belonging to uncompressed and compressed requests in an InfoCube. To do so, you must

configure the DAP to allow the archival of data that is not compressed as described in Creating a Data Archiving

Process for an InfoProvider [page 17].

18

CUSTOMER





NLS Operations

8/9/2019 nls_db6_nw731_w10.pdf


Procedure

1. In your BW system, call transaction RSA1, select the required InfoProvider and choose Manage from the context

menu.

The screen InfoProvider Administration appears.

2. Choose the tab page Archiving.

If you access this screen for the first time, there are no archiving requests available.

3. To create a new archiving request, choose the Archiving Request pushbutton.

The dialog box Create and Execute Archiving Request appears.

Figure 5: Create and Execute Archiving Request: Primary Time Restriction

On the tab page Primary Time Restriction, you can choose between the following ways to specify the time

interval:

● Specifying relative time restriction

In the Relative group box, you can specify if you want to archive records older than a certain time period –

counting from today.

● Specifying absolute time restriction

In the Absolute group box, you can specify if you want to archive records that belong to an exactly specified

time frame.

Note

You can also combine both methods. In this case, only the records that meet both restrictions are archived.

4. If you had, for example, selected additional partitioning characteristics on the tab page Selection Profile when

the DAP was created, you can define the restrictions for these characteristics on the Further Restrictions tab

page of the dialog box Create and Execute Archiving Request:



NLS Operations

CUSTOMER



8/9/2019 nls_db6_nw731_w10.pdf


Figure 6: Create and Execute Archiving Request: Further Restrictions

To define restrictions as in the example shown here, specify values in the Calendar Day, Version, and Value

type fields.

5. In the field Continue Processing Until Target Status, select the target status for the processing of the archiving

request, which can be as follows:

● 10 Request Generated

● 30 Data Area of the Request is Locked Against Changes

● 40 Write Phase Completed Successfully

● 50 Verification Phase Ended Successfully

● 70 Deletion Phase Confirmed and Request Completed

Once the archiving request processing has been initiated, it has status 10 Request Generated and the archiving

request is continuously processed until the status set by you has been reached.

Note

By default, the status 70 Deletion Phase Confirmed and Request Completed is preselected. The archiving request

is only completed and available for reporting after it has reached status 70. Therefore, if you set one of the previous

status values (for example, 40 or 50), you have to complete the processing of the archiving request at a later point

in time until status 70 is reached.

6. To execute the archiving request, you can either choose the pushbutton Create Request and Execute in

Background (F9

) or Create Request and Execute in Dialog (F8

).

Note

You can also simulate a data archiving process by choosing either the pushbutton Simulate Request Processing

in the Background ( Shift + F9 ) or Simulate Request Processing in Dialog ( Shift + F8 ). Simulation mode means

that no data is transferred to the NLS database and no data is deleted from the BW database. However, all required

parts of the process are executed. You can check the amount of records to be archived and whether any errors

occur during the simulation.

If data was successfully archived (that is, transferred to the NLS database) and deleted from the BW database,

status 70 has been reached. The InfoProvider Administration screen appears. All status indicators for your

archiving request are displayed in green:

20

CUSTOMER





NLS Operations

8/9/2019 nls_db6_nw731_w10.pdf


Figure 7: InfoProvider Administration

If you were executing the archiving request in dialog mode, at the end of the data archiving process a new screen

appears displaying the status of the archiving request as well as log information as shown in the following figure:

Figure 8: Logs

If the archiving request was running as a background job, you can view the log information for completed

archiving processes (that is, processes that are not currently running regardless of the final status) by choosingthe Display Logs pushbutton on the Archiving tab page of the InfoProvider Management screen.

Note

You can also automate the data archiving steps by defining BW process chains.

For more information about how to schedule data archiving processes using process chains, see the SAP Library

for your SAP NetWeaver release at:

help.sap.com

Special Considerations for Write-Optimized DataStore Objects

For write-optimized DataStore objects, there is a minor difference in the display options on the Requests tab page.Since write-optimized DataStore objects only support the request-based NLS archiving, the green check mark in



NLS Operations

CUSTOMER



http://help.sap.com/

8/9/2019 nls_db6_nw731_w10.pdf


the column Request is Archived is set for all BW requests that have been transferred to the NLS database as shown

in the following figure:

Figure 9: Requests Tab Page

Recommendation for Parallel NLS Archiving

To improve the performance of the data load process in case of InfoCubes and standard DataStore Objects, you can

also start several archiving requests in parallel for the same InfoProvider. Before you do so, you should consider the

following recommendations:

● Define multiple data archiving requests each with a different time restriction so that they do not overlap.

Otherwise, an error can occur and the archiving process is terminated.

Example

The following is an example of how to define the time interval for parallel NLS archiving:

You want to archive historical data between 2001 and 2003 from your InfoProvider to the NLS database. If you

want to archive the data in three parallel archiving requests, you define absolute time restrictions by splitting the

data into complete years, for example,Year 2001, Year 2002, Year 2003. If you want to archive the data in

six parallel archiving requests, you define time restrictions by splitting the data into six months:January 2001-June 2001, July 2001-December 2001, and so on.

● You must only execute all your parallel archiving requests to target status of maximum 50 Verification Phase

Ended Successfully. The highest status 70 Deletion Phase Confirmed and Request Completed can only be

reached after the deletion phase. However, the deletion phase cannot be executed in parallel because of BW

InfoProvider locking.

● After all your parallel archiving requests have successfully reached status 50 Verification Phase Ended

Successfully, you should create and schedule a process chain that executes sequentially every request until the

final status 70 has reached. You can also manually continue every request sequentially until status 70 Deletion

Phase Confirmed and Request Completed is reached by using transaction RSA1.

4.3 Reloading Archived Data

Procedure

Once data has been successfully archived, you can no longer modify the data in the NLS database. That is, you can

neither delete nor modify the archived data (for example, you cannot add records to the archived time frame). If you

want to delete the archived data from your InfoProvider or if you want to modify the data of this InfoProvider, you

must reload the data from the NLS database back into the BW system where data becomes changeable.

1. In your BW system, call transaction RSA1, select the required InfoProvider and chooseManage from the context

menu.

22

CUSTOMER





NLS Operations

8/9/2019 nls_db6_nw731_w10.pdf


The InfoProvider Administration screen appears.

2. To reload data, choose the Archiving tab page and double-click the required archiving request.

The Process Request dialog box appears.

Figure 10: Process Request

3. Choose the Reload radio button and execute the request either by choosing the pushbutton Execute Required

Option in Background ( F9 ) or the Execute Required Option in Dialog ( F8 ).

The Archiving tab page appears again and the new request transfers data from the NLS database back in to the

BW system.

Figure 11: Archiving Tab Page

4. To display the latest request on the Archiving tab page, choose the Refresh pushbutton.

The time restriction for the reloading request is the same as the time restriction for the corresponding archivingrequest. The values displayed in the Records and Size/KByte columns are the same for both types of archiving

requests (archiving or reloading). However, the value for the reloading request has a negative sign indicating

that data was transferred from the NLS database back to the BW system.

Note

Even after the request was reloaded into the BW system and after data was marked as invalid in the NLS database,

the data records belonging to that request still exist in the NLS database. Invalid data records are not available

for query reporting. To delete these data records from the NLS database, you can use the DBA Cockpit as

described in Deleting Invalid Data from the NLS Database [page 28].



NLS Operations

CUSTOMER



8/9/2019 nls_db6_nw731_w10.pdf


Checking for Reloaded Requests

To check if data has been successfully reloaded into the BW system, go to the Requests tab page on the InfoProvider

Administration screen and choose the Refresh pushbutton.

In the event of a successful reload, the request (without InfoPackage) appears on the list as shown in the following

figure:

Figure 12: Checking for Reloaded Requests

This new BW request contains all data from the NLS archiving request that was reloaded. You can now perform all

usual operations on this request, such as, reporting, aggregate rollup, compression into the E fact table (in case of

an InfoCube), deletion, and so on.

Modifying Reloaded Data

After data was reloaded into the BW system, you can modify data by loading new data into your BW InfoProvider

with the same time characteristics as the reloaded data. After you have modified the data, you can then archive it

again. Since you cannot directly maintain data in the NLS database, reloading data into the BW system is the only

option to change data that was once archived to the NLS database.

Note

If you want to archive such a reloaded request again and the DAP configuration does not allow the archival of

uncompressed data, you must first compress the selected BW request into the E fact table (on the Collapse tab

page on the InfoProvider Administration screen). Afterwards, you can archive the data to the NLS database.

Reloading Data for Write-Optimized DataStore Objects

For write-optimized DataStore objects, there is a small difference in the reloading algorithm for the archived data:After the data was reloaded, no new requests appear on the Requests tab page. The green check mark in the column

Request is Archived is removed from the BW requests that were previously archived to the NLS database, as shown

in the following figure:

Figure 13: Reloading Data for Write-Optimzed DataStore Objects

24

CUSTOMER





NLS Operations

8/9/2019 nls_db6_nw731_w10.pdf


4.4 Deleting Archived Data from NLS

To save space in the NLS database, you can delete archived data that you no longer need.

Prerequisites

To be able to delete archived data from NLS, you need the following minimum releases and support package levels:

● SAP NetWeaver BW 7.30 with Support Package 5

● SAP NetWeaver BW 7.31 with Support Package 2

● SAP NetWeaver BW 7.4 or higher

If you work with SAP NetWeaver BW 7.30 or 7.31 and a lower support package level, you need SAP Note 1620752.

Procedure

1. In your SAP BW system, call transactionRSA1.

2. Select the required InfoProvider and choose Manage from the context menu.

The InfoProvider administration screen appears.

Note

You can only mark nearline requests for deletion if the corresponding archiving request has run successfully and

has the request status Deletion Phase Confirmed and Request Completed. This is indicated with the green traffic

light icon in the Status column on the Archiving tab page.

3. To delete the data of the archiving request, click the green traffic light icon.

4. In the Process Request dialog box, choose Delete NLS-Request and schedule the request in the background or

in dialog.

The NLS request is now marked for deletion in the RSDANLREQ table. The new status of the request is also

displayed in the NL Req-Status column on the Archiving tab page.

5. To physically delete the data from the database, run the reportRSDA_NEARLINE_REQUEST_DELETE.

Note

If a nearline request is marked for deletion, the system considers the request as deleted. This means that SAP

does not support an undo of the actions INVALIDATE or DELETE. Even if you use NLS without ADK, you cannot

access the data any more: the data of the time slice that you marked for deletion remains locked.

4.5 Reloading Deleted Requests from ADK to NLS

If you use NLS with ADK, the ADK files remain on the database although the nearline request has been deleted. Yet,

if you want to make the physically deleted nearline requests visible for queries again, you can reload requests from

ADK to NLS.



NLS Operations

CUSTOMER




8/9/2019 nls_db6_nw731_w10.pdf


Procedure

1. In the SAP BW system, on the InfoProvider administration screen, double-click the archiving request that is

marked for deletion.2. In the Process Request dialog box, choose Reload NLS-Request from ADK.

Result

The system displays a new nearline request SID in the NL Req. column and the Delete icon in the NL Req.-Status

column has disappeared.

4.6 Using NLS InfoProviders in a MultiProvider Environment

As of SAP NetWeaver BW 7.3, native NLS support in MultiProviders has been available. This means that in the

configuration of the InfoProvider properties, there is a new property (NLS Usage) that you can use to administer the

access to the NLS part of an InfoProvider.

If the InfoProvider is not a MultiProvider, the property can have one of following values:

● <blank> Near-Line access switched 0ff (Default)

● X Near-Line Access Switched On

If the InfoProvider is a MultiProvider, the value P Near-Line Access Set the Same as for PartProvider is additionally

available. To activate native NLS support in MultiProviders, set the property NLS Usage to value P Near-Line Access

Set the Same as for PartProvider and configure the InfoProviders that are contained in a Multiprovider so that theycan access their NLS parts. For more information about the access of the NLS parts of InfoProvider in a MultiProvider,

see Reading Stored Data in the SAP Library at help.sap.com.

26

CUSTOMER





NLS Operations




8/9/2019 nls_db6_nw731_w10.pdf


5 Administration of the NLS Database Using

the DBA Cockpit

The following sections describe how you can administer the DB2 NLS database remotely from your BW system using

the DBA Cockpit.

To be able to do so, you first have to add the NLS database as a remote system to your system landscape as described

in Database Administration Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows.

After you have successfully established a connection to the NLS database, you can start administering it using, for

example, the following general monitoring functions of the DBA Cockpit:

● Space Tablespaces

Lets you retrieve a list of the tablespaces created in the remote NLS database. By selecting a tablespace and

using the Contents pushbutton on the Space: Tablespace Configuration screen, you can retrieve a list of tables

that were created in a particular tablespace.

● Performance Snapshots Tablespaces

Lets you retrieve performance indicators about the I/O operations

● Performance Snapshots Buffer Pools

Lets you evaluate the efficiency of the available buffer pools

● Backup and Recovery: Overview

Lets you retrieve information about the existing backups of your NLS database

Note

These monitoring functions are described in more detail in the separate document Database Administration Using

the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows.

In addition to the generic monitoring functions, the DBA Cockpit of your BW system offers the following NLS-specific

extensions (if your NLS database is running on DB2):

● BW Administration NLS Configuration

This screen provides an overview of existing connections to NLS databases. On this screen, you can also

maintain the connection to an NLS database.

For more information, see Setting Up the Connection to the NLS Database [page 8].

● BW Administration NLS Overview

On this screen, you can monitor the space consumed by the InfoProviders in the BW database and by NLS

objects in the NLS database. In addition, you can use this function to enable BW queries to automatically access

the NLS database.

● Jobs DBA Planning Calendar NLS Cleanup Job

You can use this NLS-specific job to remove invalid data from your NLS database.

More Information

Database Administration Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows




Administration of the NLS Database Using the DBA Cockpit

CUSTOMER




8/9/2019 nls_db6_nw731_w10.pdf


5.1 Monitoring NLS Objects

You can monitor, for example, the space consumption of an InfoProvider in the BW database in comparison to theremote NLS database using the NLS-specific extensions in the DBA Cockpit (transaction DBACOCKPIT, BW

Administration NLS Overview ).

On the NLS Overview screen, you can also update the configuration of your InfoProvider so that its BW queries

automatically read data from the NLS database. After the creation of a data archiving process (DAP), the InfoProvider

cannot access the NLS database to build the query results. To enable the NLS access for an InfoProvider, you have

to use the Enable Queries pushbutton on the NLS Overview screen of the DBA Cockpit.

Alternatively, you can enable the NLS access for an InfoProvider as described in Enabling Business Warehouse

Queries to Read NLS Data [page 29].

Procedure

To monitor the space consumption of the InfoProvider and to enable the NLS access for an InfoProvider, see sections

BW Administration: NLS Overview and BW Administration: NLS Configuration in the separate document Database

Administration Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows.

More Information

Database Administration Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows at:


5.2 Deleting Invalid Data from the NLS Database

When data is reloaded from the NLS database into the BW system, it continues to exist in the NLS database. It is

marked, however, as invalid. To remove this invalid data in the NLS database, you can use the NLS Cleanup job in

the DBA Planning Calendar of the DBA Cockpit.

Procedure

Follow the instructions in section Running the NLS Cleanup Job in the separate document Database Administration

Guide Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows at:


28

CUSTOMER





Administration of the NLS Database Using the DBA Cockpit




8/9/2019 nls_db6_nw731_w10.pdf


6 Business Warehouse Query Processing

With NLS

The following section describes how you can execute queries on an InfoProvider for which data has been transferred

to the NLS database.

You also learn how you can use the enhanced query lookup function that improves the performance of the query

processing for certain types of queries.

6.1 Enabling BW Queries to Read NLS Data

BW reporting tools can transparently access data in the NLS database the same way as they access regular data in

the BW database. That is, you cannot see a difference if data for the BW query is being read from the BW database

or the NLS database. To be able to read data from the NLS database, you have to enable the BW queries to also read

NLS data.

You can enable a single BW query for NLS using the BEx query monitor as described in section Read Stored Data in

the SAP Library at help.sap.com.

After you have enabled BW queries to read NLS data, the BW OLAP processor connects to both the NLS database

and the BW database, and reads data that corresponds to the query restrictions. The NLS data is also read if queries

are executed using external tools, for example, the Business Explorer (BEx).

Procedure

1. In your BW system, call transaction RSA1.

2. Select the required InfoProvider and choose Dis play from the context menu.

A Display <InfoProvider> screen appears (where<InfoProvider> can be, for example, an InfoCube or a DataStore

Object).

3. From the menu, choose Extras InfoProvider Properties Change .

4. On the InfoProvider: Edit Properties screen, choose X Near-Line Access Switched On from the dropdown list of

the NLS Storage field.

Note

If you want to disable the queries of an InfoProvider to read data from the NLS database, choose Near-Line Access

Switched Off (Default).

5. Save your changes.

All queries of this InfoProvider are now enabled to also read data from the NLS database.



Business Warehouse Query Processing With NLS

CUSTOMER






8/9/2019 nls_db6_nw731_w10.pdf


6.2 Using the Improved Query Look-Up Functionality

With Enhancement Package 1 (SP6) for SAP NetWeaver 7.0, the standard NLS interface has been extended toprovide enhanced lookup functionality. The enhanced lookup functionality uses a dedicated temporary table to store

the records for lookup. Using a dedicated temporary table improves the performance of some queries that retrieve

data from the NLS database in combination with time-dependent filtering criteria.

The NLS interface implementation based on DB2 for Linux, UNIX, and Windows has been extended accordingly to

take advantage of the new lookup functionality.

To activate the use of the lookup functionality in your BW system, you must set the RSADMIN parameter

RSDAI_LOOKUP to 3 as described in SAP Note 1167489. This SAP Note also contains detailed information about all

available values for this parameter as well as the behavior of the NLS solution for each of the values.

Example of How Queries Benefit from the Improved Lookup Functionality

The NLS table /BIC/OAEMPLOYEE has time-dependent attributes for an employee. The table consists of thefollowing columns:

Table 11

Table Column Description

EMPLID Employee ID

DATETO Ending date

DATEFROM Starting date

Salary Salary of employee

Note

The columns DATETO and DATEFROM define a validity interval.

An NLS-enabled BW query retrieves data records from the NLS table /BIC/OAEMPLOYEE and builds its result set

using a list with a combination of employee IDs (MY_EMPLID) and key dates (MY_DATE) as filtering criteria.

The following table is an example of such a list:

Table 12

MY_EMPLID MY_DATE

0000004711 20071231

0000004712 20071231

0000004712 20080131

0000004713 20071231

30

CUSTOMER







8/9/2019 nls_db6_nw731_w10.pdf


Syntax

For this example, the normal SELECT SQL statement to query the NLS table /BIC/OAEMPLOYEE is as follows:

SELECT "EMPLID", “DATETO”, “DATEFROM”, “SALARY” FROM "/BIC/OAEMPLOYEE"

WHERE ( "EMPLID" = '00004711' AND

"DATETO" >= '20071231' AND

"DATEFROM" <= '20071231' OR

"EMPLID" = '00004712' AND

"DATETO" >= '20070131' AND

"DATEFROM" <= '20070131' OR

"EMPLID" = '00004712' AND

"DATETO" >= '20080131' AND

"DATEFROM" <= '20080131' OR

"EMPLID" = '00004713' AND

"DATETO" >= '20071231' AND

"DATEFROM" <= '20071231' )

The NLS table contains the following rows:

Table 13

EMPLID DATETO DATEFROM DEPTID SALARY

00004711 99991231 20070101 1233 200000

00004712 20080229 20070101 1234 300000

00004712 99991231 20080301 1233 350000

00004713 20071231 20070101 1234 400000

Using the SQL statement above, the result set is as follows:

Table 14

EMPLID DATETO DATEFROM SALARY

00004712 99991231 20080229 300000

00004713 20070101 20071231 400000

However, if there is a large number of query restrictions, the restrictions are automatically stored in a temporary

table (for example, TEMP0001). You then use a correlated subquery to query the NLS table. Otherwise, the built

SQL statement might be too long.

Syntax

The following example shows a SELECT statement using the correlated subquery:

SELECT "EMPLID", ”DATETO”, ”DATEFROM”, ”SALARY”

FROM "/BIC/OAEMPLOYEE" U

WHERE EXISTS ( SELECT * FROM "TEMP0001" T

WHERE T."MY_EMPLID" = U."EMPLID"

AND T.”MY_DATE” <= U.”DATETO”

AND T.”MY_DATE” >= U.”DATEFROM” )




CUSTOMER



8/9/2019 nls_db6_nw731_w10.pdf


7 Backup and Recovery of the NLS Database

The following sections provide basic information about backup and recovery of an NLS database that you have to

consider when using DB2 as NLS database:

● Configuring the NLS Database for Archive Logging [page 32]

● Backing Up the NLS Database [page 32]

● Recovering the NLS Database [page 33]

7.1 Configuring the NLS Database for Archive Logging

Procedure

Before you can take a backup from an NLS database, you have to configure it for archive logging. Archive logging

enables you to take online backups as well as to recover the NLS database to a certain point in time in case of a

system failure.

To enable the NLS database for archive logging, you have to set the database configuration parameter

LOGARCHMETH1. For more information, see Enabling the Database for Rollforward Recovery in the Database

Administration Guide – SAP on IBM DB2 for Linux, UNIX, and Windows at:


Note

Make sure that you have configured your NLS database for archive logging before you start using the NLS

database.

7.2 Backing Up the NLS Database

Procedure

As for any other database in your system landscape, you have to define an appropriate backup and recovery strategy

for the NLS database. This NLS-specific strategy depends on, for example, available hardware, backup devices, and

so on. Since new data is less frequently added to the NLS database than to a BW database, you do not have to take

backups from the NLS database as often as from a BW database.

The execution of BW queries does not change the data in the NLS database because the BW queries only read data.

The only operations that change data in the NLS database are creating, modifying, or deleting a data archiving

process, archiving data to NLS database, and reloading data back into the BW system.

For the NLS database, the same backup methods are supported as for the BW database because the NLS database

is a regular DB2 database. That is, you can perform an offline or online backup, you can start a backup directly from

the DB2 command prompt, or you can schedule a backup job using the DBA Planning Calendar in the DBA Cockpit.

32

CUSTOMER





Backup and Recovery of the NLS Database


8/9/2019 nls_db6_nw731_w10.pdf


For more information about how to schedule a backup job in the DBA Planning Calendar, see Database Administration

Using the DBA Cockpit: IBM DB2 for Linux, UNIX, and Windows at:


For more information about database backups, see the Database Administration Guide – SAP on IBM DB2 for Linux,

UNIX, and Windows at:


7.3 Recovering the NLS Database

Procedure

You have to recover the NLS database in one of the following situations:

● The BW database fails while data is being transferred to the NLS database.

● You have to restore and roll forward the BW database to a specific point in time.

● Due to a hardware failure in your system landscape, you have to recover the NLS database.

To fully recover the NLS database, you have to perform the following steps from the command line:

1. You restore the NLS database using a suitable backup image.

2. You roll forward the NLS database using the available log files to the end of logs or to a specific point in time.

However, note that the successful execution of the required commands does not guarantee that the information in

the NLS database is logically consistent with the BW database because these are two different databases.

Example

For example, the BW database is in a consistent state and contains the data from today. The NLS database is also

in consistent state but contains data from yesterday.This means that the data that was archived to the NLS

database today might be missing.

The NLS solution based on DB2 for Linux, UNIX, and Windows is able to identify whether the NLS database is logically

consistent with the BW database by comparing timestamps. If this is not the case, no connection to the NLS database

is allowed until the inconsistencies have been resolved.

In addition, you can perform a consistency check in your BW system using function module

FM_RSDA_DB6_SYNC_CHECKER as described in the following.

Checking the Database Consistency Using Function Module FM_RSDA_DB6_SYNC_CHECKER

The NLS solution includes function module FM_RSDA_DB6_SYNC_CHECKER that allows you to check the current

logical state of both the BW and the NLS database. Each time you execute this function module, it returns the current

status of both databases and suggests, if required, the steps to perform to reach a consistent status.

Recommendation

We strongly recommend that you use this program for consistency checks not only occasionally but especially

after either the NLS or the BW database has crashed.

Procedure

1. In your BW system, call transaction SE37.

The screen Function Builder: Initial Screen appears.




CUSTOMER





8/9/2019 nls_db6_nw731_w10.pdf


2. In the Function Module input field, enter FM_RSDA_DB6_SYNC_CHECKER and choose the Test/Execute ( F8 )

pushbutton.

The screen Test Function Module: Initial Screen appears.

3. Enter the name of the NLS connection in the input field beside the I_NLS_CONNECTION import parameter and

choose the Execute pushbutton.

Figure 14: Test Function Module: Initial Screen

The report displays one of the following messages:

● Status normal: BW and Near-Line Storage databases are completely in sync.

Figure 15: Status Normal

The timestamps of the last operation on the NLS database are identical in both the BW database (export

parameter E_BW_TIMESTAMPL) and the NLS database (export parameter E_NLS_TIMESTAMPL).

● Warning: Some Archiving Requests are not in sync. These requests may require manual interaction.

34

CUSTOMER






8/9/2019 nls_db6_nw731_w10.pdf


Figure 16: Warning

Some data archiving requests were running when one of the databases crashed. As a result, these requests

are now in an inconsistent state. The NLS database is not available but it can be repaired. For more

information about the solution to this problem, see SAP Note 1405664.

You can display the InfoProvider names containing the inconsistent requests by double-clicking the output

table E_NLS_CUBES_DETAILS.

● Error: BW and NLS databases are NOT in sync! Restore and rollforward the NLS database to the timestamp

<consistent_time>.

Figure 17: Error

The NLS database is in a different logical state than the BW database and contains different data. One

possible cause for this problem can be a database crash (either the BW database or the NLS database)

with the resulting rollback of some transactions. Therefore, the NLS database is not available until it has

again been synchronized with the BW database.

You can solve this problem by restoring your NLS database to the point in time that is displayed in the output

of function module FM_RSDA_DB6_SYNC_CHECKER (see export parameterE_BW_TIMESTAMPL).




CUSTOMER




8/9/2019 nls_db6_nw731_w10.pdf


8 Using DB2 as NLS Database with a BW

System Running on a Different DatabasePlatform

This section provides information that you have to consider if you are planning to use the IBM DB2 NLS solution with

a BW system that is running on a different database platform.

If your BW system is running on different database platform, you can still archive data from your InfoProviders to

the DB2 NLS database, reload data into the BW system, and query NLS data without any dependencies. However,

there are differences in the basic configuration and operations that you have to consider. These differences are as

follows:

● Configuring the NLS connection for non–IBM DB2 for LUW databases

● Using the NLS objects viewer for non–IBM DB2 for LUW databases

Configuring the NLS Connection for Non–IBM DB2 for LUW Databases

After you have installed DB2 as NLS database [page 7], you have to manually configure the connection to the NLS

database because the DB2 NLS-specific extensions in the DBA Cockpit are only available if your BW system is running

on DB2.

To configure the DB2 NLS database as remote database in your DBA Cockpit, follow the instructions in SAP Note

1405664.

After you have configured the database connection and the NLS connection, you can start creating DAPs for yourInfoProviders and transferring data into the DB2 NLS database.

Using the NLS Objects Viewer for Non–IBM Databases

The DB2 NLS solution includes function moduleFM_RSDA_DB6_OBJECTS_VIEWER. You can use this function module

to display the list of the BW tables for a given InfoProvider and the corresponding list of NLS tables. This is especially

useful because your BW system is running on a different database platform than DB2, which means that DB2 NLS-

specific extensions in the DBA Cockpit are not available.

To display BW and NLS tables for a given InfoProvider, proceed as follows:

1. In your BW system, call transaction SE37.

The screen Function Builder: Initial Screen appears.

2. Enter FM_RSDA_DB6_OBJECTS_VIEWER in the Function Module input field and choose the Test/Execute ( F8 )

pushbutton.

The screen Test Function Module: Initial Screen appears.

3. Enter the following parameters and choose the Execute pushbutton.

● I_INFOPROVIDER_NAME:

Enter the name of the InfoProvider using NLS.

Note

You can also specify the wildcard “*” as the part of the name, or just enter the wildcard “*” to display all NLS tables

for all InfoProviders.

36

CUSTOMER





Using DB2 as NLS Database with a BW System Running on a Different Database Platform



8/9/2019 nls_db6_nw731_w10.pdf


● I_NLS_CONNECTION:

Enter the name of the NLS connection.

Figure 18: I_NLS_CONNECTION

To display a list with the InfoProviders matching the selection criteria specified in step 3, double-click the

result table E_NLS_OBJECTS on the output screen:

Figure 19: Structure Editor: Display E_NLS_OBJECTS from Entry 1

If you double-click an entry in the NLS_TABLES_DETAILS column, the function module displays another

table with detailed overview information including the table names of both the BW InfoProvider and the

appropriate NLS object.

The table size information (for example, in columns INFOPROVIDER_SIZE and NLS_SIZE) is displayed after

you have installed the latest version of the function module FM_RSDA_DB6_OBJECTS_VIEWER.

For more information about function module FM_RSDA_DB6_OBJECTS_VIEWER, see SAP Note 1405664.



Using DB2 as NLS Database with a BW System Running on a Different Database Platform

CUSTOMER




8/9/2019 nls_db6_nw731_w10.pdf


8/9/2019 nls_db6_nw731_w10.pdf


10 Disclaimer

By following links to IBM Documentation you are leaving the SAP product documentation and entering a site that is

not hosted by SAP. By using the link, YOU AGREE that unless expressly stated otherwise in your agreements with

SAP you are about to access an external webpage which is not part of SAP’s offering:

(i) the content of the linked-to site and any further external site is not product documentation and you may not infer

any product documentation claims against SAP based on this information;

(ii) the fact that SAP provides links to external sites does not imply that SAP agrees or disagrees with the contents

and information provided on such sites. SAP does not guarantee the correctness of the information provided.

(III) SAP DOES NOT GIVE ANY REPRESENTATION REGARDING THE QUALITY, SAFETY, SUITABILITY, ACCURACY

OR RELIABILITY OF ANY EXTERNAL WEBPAGE OR ANY OF INFORMATION, CONTENT AND MATERIALS PROVIDED

THEREON;

(IV) YOU VISIT THOSE EXTERNAL WEBPAGES ENTIRELY AT YOUR OWN RISK. SAP SHALL NOT BE DIRECTLY OR

INDIRECTLY RESPONSIBLE OR LIABLE FOR ANY DAMAGE OR LOSS CAUSED OR ALLEGED TO BE CAUSED BY OR

IN CONNECTION WITH YOUR USE OF OR RELIANCE ON ANY CONTENT, GOODS OR SERVICES AVAILABLE ON OR

THROUGH ANY SUCH LINKED WEBPAGE.



Disclaimer

CUSTOMER



8/9/2019 nls_db6_nw731_w10.pdf


Typographic Conventions

Example Description

<Example> Angle brackets indicate that you replace these words or characters with appropriate entries to

make entries in the system, for example, “Enter your <User Name> ”.

Example Example Arrows separating the parts of a navigation path, for example, menu options

Example Emphasized words or expressions

Example Words or characters that you enter in the system exactly as they appear in the documentation

www.sap.com Textual cross-references to an internet address

/example Quicklinks added to the internet address of a homepage to enable quick access to specific

content on the Web

123456 Hyperlink to an SAP Note, for example, SAP Note 123456

Example ● Words or characters quoted from the screen. These include field labels, screen titles,

pushbutton labels, menu names, and menu options.

● Cross-references to other documentation or published works

Example ● Output on the screen following a user action, for example, messages

● Source code or syntax quoted directly from a program

●File and directory names and their paths, names of variables and parameters, and namesof installation, upgrade, and database tools

EXAMPLE Technical names of system objects. These include report names, program names, transaction

codes, database table names, and key concepts of a programming language when they are

surrounded by body text, for example, SELECT and INCLUDE

EXAMPLE Keys on the keyboard

40

CUSTOMER





Typographic Conventions



http://www.sap.com/

8/9/2019 nls_db6_nw731_w10.pdf


www.sap.com

© Copyright 2014 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any

form or for any purpose without the express permission of SAP AG.

The information contained herein may be changed without prior

notice.

Some software products marketed by SAP AG and its distributors

contain proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP AG and its affiliated companies

(“SAP Group”) for informational purposes only, without

representation or warranty of any kind, and SAP Group shall not be

liable for errors or omissions with respect to the materials. The only

warranties for SAP Group products and services are those that are set

forth in the express warranty statements accompanying such

products and services, if any. Nothing herein should be construed as

constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well

as their respective logos are trademarks or registered trademarks of

SAP AG in Germany and other countries.

http://www.sap.com/

Documents

nls_db6_nw731_w10.pdf