cancel
Showing results for 
Search instead for 
Did you mean: 

HANA Restrictions and Limitations

Former Member
0 Kudos

Dear HANA community.

http://help.sap.com/hana/html/_isql_restrictions_for_sql_statements.html

next parameters  warning me:

Number of tables in a schema   131072 

SAP ERP now consist of  90-100 000 tables and still will be growing. Think this limit must be doubled.


Number of primary key columns in each table    16 

Number of columns in an index                           16 

What is the practical reason for it?  In future peoples will have HANA boxes with thousands of CPUs.

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Additional info (good news)

Number of primary key columns in each table    16   and


Number of columns in an index                           16 

Checked.

It's valid only for tables with row_storage type, for tables with column_storage type is not valid.

I was created PK on 87 column - without any problems. And also create index with 17 columns in it.

Seems to be SAP must update documentations about limitations.

Former Member
0 Kudos

Lars,

as i understand HANA cubes don't use extended star scheme. I didn't check it my self, but i hope i'll do it soon.

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/e1/5282890fb846899182bc1136918459/content.htm?frame...

SAP HANA-Optimized InfoCube

and


http://www.saphana.com/servlet/JiveServlet/previewBody/1363-102-2-1810/SDN_HANA_opt_InfoCube%20FINAL...

lbreddemann
Active Contributor
0 Kudos

Technically you can have both the extended and the HANA optimized star schema in HANA .

If you do use the HANA optimized ICs then there is a single column primary key in the fact table and a referencing column to each used characteristic.

Pretty straight forward - no problem with our current limitations.

.

lbreddemann
Active Contributor
0 Kudos

Mikhail,

As we at SAP do eat our own dog food and do listen to our customers, these limitations will be lifted once this is necessary.

As of today SAP Netweaver e.g. with SAP BW on HANA runs quite sucessfully w/o hitting this limitation.

Concerning the limits for indexes/primary key columns:

Quite obviously the limit for PK is due to the index limitation.

And this one in turn simply is still there because you can't create larger indexes/pks in NetWeaver.

Having said this and being a fan of "natural" primary keys I personally find it cumbersome to use tens of columns as a primary key.

You've to type it in every single selection. You've to store it in every FK relation. Not very efficient and not very handy.

Many (if not most) developers tend to use artificial keys instead (like GUIDs or sequences).

So this limitation again is not really something that would hinder the majority of possible users from using HANA.

Why don't you mention a more problematic (to me at least) limitation of max. 2 billion rows per table partition? These are the kind of limits that need to be addressed (and be sure: development is currently working on this!).

And while we're at it:

Why do other DBMS have limitations on these structures? What's the reason for their exact limit (e.g. cols in PK afaik DB2: 64, MS SQL: 16, Oracle: 32).

Why does IQ have a max. number of rows per table while Oracle tables actually can contain an unlimited number of rows?

Lars

Former Member
0 Kudos

Classical star scheme for Fact tables. (http://datawarehouse4u.info/Data-warehouse-schema-architecture-star-schema.html

I can't check now,  how BW on HANA can store more than 16 characteristics in cube F_Table.

> Why don't you mention a more problematic (to me at least) limitation of max. 2 billion rows per table partition?

Yes, it's strange. But i think it's 32bit limitation from trex.

https://cw.sdn.sap.com/cw/ideas/845

About other vendors, i'll checked first, then answered.

lbreddemann
Active Contributor
0 Kudos

Looks like you're missing my point here.

I'm really not after finding out why there are what kind of limitations in any products.

The point I'm taking is this: it really doesn't matter so much.

There will always be limitations on any platform.

The question here is not so much about the actual limitation but whether or not these restrict the usage of the system so much that it really matters to the users.

And since we're using the extended star schema since decades (from the times where other DBMS couldn't handle larger PK either), it's not a problem to handle more than 16 characteristics.