UNIX supported locales for BOE

Locales supported for UNIX BOE Install:

Language	Browser Locales	Vesion	Solari 10	AIX Locales	Linux Locales	HP IA Locales
				(5.3 & 6.1)	RedHat 5.2 & 5.3 Suse 10 & 11	11.23 & 11.31
Tier 1	English	English (*)	en_US.UTF-8	EN_US.UTF-8	en_US.utf8	en_US.utf8
Tier 1	French	French (*)	fr_FR.UTF-8	FR_FR.UTF-8	fr_FR.utf8	fr_FR.utf8
Tier 1	Japanese	Japanese	ja_JP.UTF-8	JA_JP.UTF-8	ja_JP.utf8	ja_JP.utf8
Tier 1	Simlified Chinese	Chinese (China) [zh-cn] Chinese (Singapore) [zh-sg] Chinese [zh]	zh_CN.UTF-8@pinyin zh_CN.UTF-8@radical zh_CN.UTF-8@stroke	ZH_CN.UTF-8	zh_CN.utf8	zh_CN.utf8
Tier 1	German	German (*)	de_DE.UTF-8	DE_DE.UTF-8	de_DE.utf8	de_DE.utf8
Tier 1	Italian	Italian (*)	it_IT.UTF-8	IT_IT.UTF-8	it_IT.utf8	it_IT.utf8
Tier 1	Spanish	Spanish (*)	es_ES.UTF-8	ES_ES.UTF-8	es_ES.utf8	es_ES.utf8
Tier 1	Dutch	Dutch (*)	nl_NL.UTF-8	NL_NL.UTF-8	nl_NL.utf8	nl_NL.utf8
Tier 1	Russian	Russian	ru_RU.UTF-8	RU_RU.UTF-8	ru_RU.utf8	ru_RU.utf8
Tier 2	Korean	Korean	ko_KR.UTF-8@dict	KO_KR.UTF-8	ko_KR.utf8	ko_KR.utf8
Tier 2	Traditional Chinese	Chinese (Hong Kong SAR) [zh-hk] Chinese (Macau SAR) [zh-mo] Chinese (Taiwan) [zh-tw]	zh_TW.UTF-8@pinyin zh_TW.UTF-8@radical zh_TW.UTF-8@stroke zh_TW.UTF-8@zhuyin zh_HK.UTF-8@radical zh_HK.UTF-8@stroke	ZH_TW.UTF-8 ZH_HK.UTF-8	zh_TW.utf8 zh_HK.utf8	zh_TW.utf8 zh_HK.utf8
Tier 2	Portuguese	Portuguese (Brazil) [pt-br]	pt_BR.UTF-8	PT_BR.UTF-8	pt_BR.utf8	pt_BR.utf8
Tier 2	Swedish	Swedish [sv]	sv_SE.UTF-8	SV_SE.UTF-8	sv_SE.utf8	sv_SE.utf8
Tier-3	Polish	Polish	pl_PL.UTF-8	PL_PL.UTF-8	pl_PL.utf8	pl_PL.utf8
Tier-3	Danish	Danish	da_DK.UTF-8	DA_DK.UTF-8	da_DK.utf8	da_DK.utf8
Tier-3	Thai	Thai	th_TH.UTF-8	TH_TH.UTF-8	th_TH.utf8	No Locale
Tier-3	Norwegian	Bokmal	nb_NO.UTF-8	NO_NO.UTF-8	no_NO.utf8	no_NO.utf8
Tier-3	Czechoslovakia	Czech	cs_CZ.UTF-8	CS_CZ.UTF-8	cs_CZ.utf8	cs_CZ.utf8
Tier-3	Finnish	Finnish	fi_FI.UTF-8	FI_FI.UTF-8	fi_FI.utf8	fi_FI.utf8
Tier-3	Turkish	Turkish	tr_TR.UTF-8	TR_TR.UTF-8	tr_TR.utf8	tr_TR.utf8
Tier-3	Hungarian	Hungarian	hu_HU.UTF-8	HU_HU.UTF-8	hu_HU.utf8	hu_HU.utf8
Tier-3	Slovakian	Slovakian	sk_SK.UTF-8	SK_SK.UTF-8	sk_SK.utf8	sk_SK.utf8

SAP HANA Sizing

The concept of T-shirt sizes for SAP HANA

SAP defined so-called T-shirt sizes for SAP HANA to both simplify the sizing and to limit the number of hardware configurations to support, thus reducing complexity. SAP’s hardware partners provide configurations for SAP HANA according to one or more of these T-shirt sizes. Table 3-1 lists the T-shirt sizes for SAP HANA.

 In addition to the T-shirt sizes listed in Table 3-1, you might come across the T-shirt size XL, which denotes a scale-out configuration for SAP HANA.

The T-shirt sizes S+ and M+ denote upgradable versions of the S and M sizes:

§  S+ delivers capacity equivalent to S, but the hardware is upgradable to an M size.

§  M+ delivers capacity equivalent to M, but the hardware is upgradable to an L size.

These T-shirt sizes are used when relevant growth of the data size is expected.

Sizing approach

The sizing of SAP HANA depends on the scenario in which SAP HANA is used. We discuss these scenarios here:

§  SAP HANA in a side-car data mart approach, used for business intelligence or new applications

§  SAP HANA as the database for a SAP NetWeaver Business Warehouse 7.30 SP5, as described in 3.3.2, “SAP HANA as a database for SAP NetWeaver BW”

The sizing methodology for SAP HANA is described in detail in SAP Note 15149663 (SAP HANA in a side-car approach) and SAP Note 1637145 (SAP HANA as the database for SAP BW). The the following sections provide a brief overview of sizing for SAP HANA in a sidecar approach.

Sizing the RAM needed

Sizing an SAP HANA system is mainly based on the amount of data to be loaded into the SAP HANA database, because this determines the amount of main memory (or RAM) needed in an SAP HANA system. To size the RAM, the following steps have to be performed:

1. Determine the information that has to be transferred (either by replication or extraction) to the SAP HANA database. Note that typically customers will only select a sub-set of information from their ERP or CRM database, so this has to be done at the table level. The sizing methodology is based on uncompressed source data size, so in case compression is used in the source database, this has to be taken into account as well. The information required for this step can be acquired with database tools. SAP Note 1514966 contains a script supporting this process for several database systems, for example, DB2 LUW and Oracle. The current size of all the tables (without DB indexes) storing the required information in the source database is denoted as A.

2. Although the compression ratio achieved by SAP HANA can vary depending on the data distribution, a working assumption is that, in general, a compression factor of 7 can

be achieved:

B = ( A / 7 )

B is the amount of RAM required to store the data in the SAP HANA database.

3. Only 50% of the total RAM should be used for the in-memory database. The other 50% is needed for temporary objects (for example, intermediate results), the operating system, and application code:

C = B * 2

C is the total amount of RAM required.

The total amount of RAM should be rounded up to the next T-shirt configuration size, table above.

Sizing the disks

The capacity of the disks is based on the total amount of RAM. As described in 2.1.2, “Data persistence” on page 9, there are two types of storage in SAP HANA:

§   Diskpersistence

The persistence layer writes snapshots of the database in HANA to disk in regular intervals. These are usually written to an array of SAS drives4. The capacity for this storage is calculated based on the total amount of RAM:

Diskpersistence = 4 * C

§   Disklog

This contains the database logs, written to flash technology storage devices, that is, SSDs or PCIe Flash adapters. The capacity for this storage is calculated based on the total amount of RAM:

Disklog = 1 * C

The certified hardware configurations already take these rules into account, so there is no need to perform this disk sizing. However, we still include it here for your understanding.

Sizing the CPUs

A CPU sizing only has to be performed in addition to the memory sizing if a massive amount of users working on a relatively small amount of data is expected. Choose the T-shirt configuration size that satisfies both the memory and CPU requirements.

The CPU sizing is user-based. The SAP HANA system has to support 300 SAPS for each concurrently active user. The servers used for the IBM Systems Solution for SAP HANA support about 60 - 65 concurrently active users per CPU, depending on the server model.

Selecting a T-shirt size

According to the sizing results, select a SAP HANA T-shirt size that satisfies the sizing requirements in terms of main memory, and possibly CPU capabilities. For example, a sizing result of 400 GB for the main memory (C) suggests a T-shirt size of M.

The sizing methodology described above is valid for SAP HANA in a side-car approach. Other use cases might require another sizing methodology, for example, for SAP HANA as the database for an SAP BW system. Also, SAP HANA is constantly being optimized, which might affect the sizing methodology. Consult SAP documentation regarding other use cases and up-to-date sizing information.

In addition to the sizing methodologies described in SAP Notes, SAP provides sizing support for SAP HANA in SAP Quick Sizer. SAP Quick Sizer is an online sizing tool that supports most of the SAP solutions available. For SAP HANA it supports sizing for these:

Ø  Standalone SAP HANA system, implementing the sizing algorithms described in SAP Note 1514966 (which we described above)

Ø  SAP HANA as the database for a SAP BW system, implementing the sizing algorithms described in SAP Note 1637145

Ø  Special sizing support for the SAP HANA Rapid Deployment solutions

Ø   

The SAP Quick Sizer is accessible online at: http://service.sap.com/quicksizer5

Note: The sizing approach described here is simplified and can only provide a rough idea of the sizing process for the actual sizing for SAP HANA. Consult the SAP sizing documentation for SAP HANA when performing

SAP HANA software licensing

As described in 3.2, “SAP HANA delivery model” on page 17, SAP HANA has an appliance-like delivery model. However, while the hardware partners deliver the infrastructure, including operating system and middleware, the license for the SAP HANA software has to be obtained directly from SAP. Figure 3-8 shows an overview over the licensing structure.

 
 The SAP HANA software is available in these editions:

Ø  SAP HANA platform edition

This is the basic edition containing the software stack needed to use SAP HANA as a database, including the SAP HANA database, SAP HANA Studio for data modeling and administration, the SAP HANA clients, and software infrastructure components. The software stack comes with the hardware provided by the hardware partners, whereas the license has to be obtained from SAP.

Ø  SAP HANA enterprise edition

The SAP HANA enterprise edition extends the SAP HANA platform edition with the software licenses needed for SAP LT replication or ETL-based replication.

Ø  SAP HANA extended enterprise edition

SAP HANA extended enterprise edition extends the SAP HANA platform edition with the software licenses needed for log-based replication with the Sybase Replication server.

As above figure suggests, additional licenses for SAP BusinesObjects BI tools might be needed

to get a complete SAP HANA-based solution.

The SAP HANA licenses are based on the amount of main memory for SAP HANA. The smallest licensable memory size is 64 GB, increasing in steps of 64 GB. The hardware might provide up to double the amount of main memory than licensed.

Front Side Bus (FSB) Vs Intel QuickPath Interconnect (QPI)

A front-side bus (FSB) is a computer communication interface (bus) often used in Intel-chip-based computers.

The Intel QuickPath Interconnect (QuickPath, QPI)^[1][2][3] is a point-to-point processor interconnect developed by Intel which replaces the front-side bus (FSB) in Xeon, Itanium, and certain desktop platforms

http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect

What is L1 / L2 / L3 Cache?

cache memory is a high speed memory kept in between processor and RAM to increase the data execution speed. It is kept near to the processor.
There are different levels of cache.
L1-cache is the fastest cache and it usually comes within the processor chip itself. 
The L1 cache typically ranges in size from 8KB to 64KB and uses the high-speed SRAM (static RAM) instead of the slower and cheaper DRAM (dynamic RAM) used for main memory.
The Intel Celeron processor uses two separate 16KB L1 caches, one for the instructions and one for the data.

L2 cache comes between L1 and RAM(processor-L1-L2-RAM) and is bigger than the primary cache (typically 64KB to 4MB). 

L3 cache is not found nowadays as its function is replaced by L2 cache. L3 caches are found on the motherboard rather than the processor. It is kept between RAM and L2 cache.

So if your system has L1,L2 and L3 cache data fetching will be L1->L2->L3->RAM
ie. If data is not there in L1 it will check L2 then L3 then RAM...


A memory cache, sometimes called a cache store or RAM cache, is a portion of memory made of high-speed static RAM (SRAM) instead of the slower and cheaper dynamic RAM (DRAM) used for main memory. Memory caching is effective because most programs access the same data or instructions over and over. By keeping as much of this information as possible in SRAM, the computer avoids accessing the slower DRAM. 

Short for Level 1 cache, a memory cache built into the microprocessor. 

Short for Level 2 cache, cache memory that is external to the microprocessor. In general, L2 cache memory, also called the secondary cache, resides on a separate chip from the microprocessor chip. 

As more and more processors begin to include L2 cache into their architectures, Level 3 cache is now the name for the extra cache built into motherboards between the microprocessor and the main memory. 

the l2 cache is now always built onto the processor for x86 archetechure

What is SAP HANA?

SAP In-Memory Database:

􀂾  The SAP In-Memory Database is a hybrid in-memory database that combines row-based, column-based, and object-based database technology. It is optimized to exploit parallel processing capabilities of modern multi-core/CPU architectures. With this architecture, SAP applications can benefit from current hardware technologies.


􀂾  The SAP In-Memory Database is at the heart of SAP offerings like SAP HANA thathelp customers to improve their operational efficiency, agility, and flexibility.



􀂾  SAP HANA is a flexible, data-source-agnostic appliance that allows customers toanalyze large volumes of SAP ERP data in real-time, avoiding the need to materialize transformations.


􀂾  SAP HANA is a hardware and software combination that integrates a number of SAP components including the SAP In-Memory Database, Sybase Replication technology and SAP LT (Landscape Transformation) Replicator, which replicate SAP ERP data to SAP HANA by means of state-of-the-art replication technologies.


􀂾  SAP HANA is delivered as an optimized appliance in conjunction with leading SAP hardware partners.



The SAP IM Database installation currently supports three kinds of installations/upgrades:

server (in-memory computing engine)
client (in-memory computing interfaces like odbc, jdbc, sqldbc, odbo)
studio (in-memory computing studio for administration, monitoring, sql query execution, modelling BI queries, ...)
The SAP IM Database installation provides the following tools for execution on
Command line
hdbinst (install a server or install/update a client or studio)
hdbupd (upgrade a server)
hdbuninst (remove a installation)
hdbaddhost (add an additional host to an existing SAP IM Database system)
hdbrename (rename an existing SAP IM Database system / customize a master copy
hdbsetup (Installation tool with graphical)
hanaconfig (Command-line tool for reconfiguring a system)


Services are:

Nameserver : The nameserver stores the database topology, meta data and authorization information. The Master services stores data in its persistence disk area. Slave nameserver communicate with the master but have no own persistence disk area.


Indexserver : Indexservers store user data and serve SQL requests. They perform the indexing of column based tables. The master index server and slave index servers have a persistence disk space.

Statisticsserver : The statisticsserver collects monitoring data from the indexservers and stores it in statistics tables. Furthermore it checks the health of the database and thoughts alerts in case of undesired behaviors. The database runs one statisticsserver.

Xsengine : This service performs the tasks the HANA XS Server. It uses persistence disk space, usually with low space requirements.

Preprocessor : The preprocessor is responsible for preparing data (especially text data) to be indexed by the column engine. It doesn't store persistent data.

XS Engine Introduction

XS Engine:

•Provides access to HANA DB by transforming persistence model stored in the DB into consumption model for clients exposed via HTTP

•Uses SAP ICM for HTTP server

•Hosts system services that are part of the HANA DB (ex. Search service, built-in web server that provides access to static content in the repository)

•Optional component of HANA

•Does not store data

JUnit Vs TestNG

JUnit 4 Vs TestNG

JUnit 4 and TestNG are both very popular unit test framework in Java. Both frameworks look very similar in functionality. Which one is better? Which unit test framework should i use in Java project?

http://www.mkyong.com/unittest/junit-4-vs-testng-comparison/