Why cube cannot exceed 16 dimension tables?

hi experts,
why a cube can't exceed or limited with 16 dimension tables,what is the background or technical specification for this limitation
what is answer if i questioned, why you cannot create more than 16 dimension tables for a cube.
pl help me regarding this
thanks & regards
venkat

Hi,
It is more related to db level restriction.Since we may not have more than 16 key fields in a table so we can not have more than 16 dim table for cube.Please give a close look the doc below that will help you a lot.
http://help.sap.com/bp_biv235/BI_EN/documentation/Multi-dimensional_modeling_EN.doc
Regards.

Similar Messages

Why I cannot split a partition table whose partitions are in a tablespace?

SQL> CREATE TABLE "GDRK"."LT2_701C_RANGE"
2 ( "CHAR_CODE" VARCHAR2(40),
3 "STAT_UNIT_CODE" VARCHAR2(20),
4 "ORGN_TYPE_CODE" CHAR(1) NOT NULL ENABLE,
5 "ORGN_CODE" VARCHAR2(26) NOT NULL ENABLE,
6 "ORGN_NAME" VARCHAR2(60) NOT NULL ENABLE,
7 "UUID" VARCHAR2(36) NOT NULL ENABLE,
8 "CYC_CODE" VARCHAR2(2) NOT NULL ENABLE,
9 "H10" VARCHAR2(2),
10 "H11" VARCHAR2(3),
11 "H12" VARCHAR2(1),
12 "H13" VARCHAR2(1),
13 "H14" VARCHAR2(1),
14 "H15" VARCHAR2(1),
15 "H16" VARCHAR2(1),
16 "H17" VARCHAR2(1),
17 "H18" VARCHAR2(1),
18 "H19_01" VARCHAR2(3),
19 "H19_02" VARCHAR2(1),
20 "H2" VARCHAR2(1),
21 "H20" VARCHAR2(4),
22 "H3_01" VARCHAR2(2),
23 "H3_02" VARCHAR2(2),
24 "H4_01" VARCHAR2(1),
25 "H4_02" VARCHAR2(1),
26 "H5_01" VARCHAR2(1),
27 "H5_02" VARCHAR2(1),
28 "H6" VARCHAR2(1),
29 "H7" VARCHAR2(1),
30 "H8" VARCHAR2(1),
31 "H9" VARCHAR2(4),
32 "REG_NUM" NUMBER,
33 "ERA_NUM" NUMBER,
34 "POWER_1" FLOAT(126),
35 "POWER_2" FLOAT(126)
36 )
37 PARALLEL
38 partition by range(CHAR_CODE) --substr(c1,1,1)
39 (
40 partition p0 values less than ('10'),
41 partition p1 values less than ('20'),
42 partition p2 values less than ('50'),
43 partition p5 values less than (maxvalue));
Table created.
SQL> set timi on
SQL> insert /*+ append */ into LT2_701C_RANGE select * from LT2_701C;
539398 rows created.
Elapsed: 00:00:28.02
SQL> commit;
Commit complete.
Elapsed: 00:00:00.06
SQL> select count(*) from LT2_701C_RANGE partition(p0);
COUNT(*)
0
Elapsed: 00:00:00.00
SQL> c/p0/p5
1* select count(*) from LT2_701C_RANGE partition(p5)
SQL> /
COUNT(*)
0
Elapsed: 00:00:00.02
SQL> c/p5/p2
1* select count(*) from LT2_701C_RANGE partition(p2)
SQL> /
COUNT(*)
539398
Elapsed: 00:00:01.15
SQL> ALTER TABLE LT2_701C_RANGE SPLIT PARTITION p2 at ('4420')INTO (
2 PARTITION p20,
3 PARTITION p21);
ALTER TABLE LT2_701C_RANGE SPLIT PARTITION p2 at ('4420')INTO (
ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in tablespace EPRAS
Elapsed: 00:00:00.89

SQL> drop table LT2_701c_RANGE;
Table dropped.
Elapsed: 00:00:00.58
SQL> drop index idx_c_p2;
drop index idx_c_p2
ERROR at line 1:
ORA-01418: specified index does not exist
Elapsed: 00:00:00.00
SQL> CREATE TABLE "GDRK"."LT2_701C_RANGE"
2 ( "CHAR_CODE" VARCHAR2(40),
3 "STAT_UNIT_CODE" VARCHAR2(20),
4 "ORGN_TYPE_CODE" CHAR(1) NOT NULL ENABLE,
5 "ORGN_CODE" VARCHAR2(26) NOT NULL ENABLE,
6 "ORGN_NAME" VARCHAR2(60) NOT NULL ENABLE,
7 "UUID" VARCHAR2(36) NOT NULL ENABLE,
8 "CYC_CODE" VARCHAR2(2) NOT NULL ENABLE,
9 "H10" VARCHAR2(2),
10 "H11" VARCHAR2(3),
11 "H12" VARCHAR2(1),
12 "H13" VARCHAR2(1),
13 "H14" VARCHAR2(1),
14 "H15" VARCHAR2(1),
15 "H16" VARCHAR2(1),
16 "H17" VARCHAR2(1),
17 "H18" VARCHAR2(1),
18 "H19_01" VARCHAR2(3),
19 "H19_02" VARCHAR2(1),
20 "H2" VARCHAR2(1),
21 "H20" VARCHAR2(4),
22 "H3_01" VARCHAR2(2),
23 "H3_02" VARCHAR2(2),
24 "H4_01" VARCHAR2(1),
25 "H4_02" VARCHAR2(1),
26 "H5_01" VARCHAR2(1),
27 "H5_02" VARCHAR2(1),
28 "H6" VARCHAR2(1),
29 "H7" VARCHAR2(1),
30 "H8" VARCHAR2(1),
31 "H9" VARCHAR2(4),
32 "REG_NUM" NUMBER,
33 "ERA_NUM" NUMBER,
34 "POWER_1" FLOAT(126),
35 "POWER_2" FLOAT(126)
36 )
37 PARALLEL
38 partition by range(CHAR_CODE) --substr(c1,1,1)
39 (
40 partition p0 values less than ('4410'),
41 partition p1 values less than ('4420'),
42 partition p2 values less than ('4450'),
43 partition p5 values less than (maxvalue));
Table created.
Elapsed: 00:00:00.22
SQL> insert /*+ append */ into LT2_701C_RANGE select * from LT2_701C;
insert /*+ append */ into LT2_701C_RANGE select * from LT2_701C
ERROR at line 1:
ORA-01688: unable to extend table GDRK.LT2_701C_RANGE partition P0 by 128 in
tablespace EPRAS
Elapsed: 00:00:06.20
SQL> show parameter recy
NAME TYPE VALUE
buffer_pool_recycle string
db_recycle_cache_size big integer 0
recyclebin string OFF

Inactive Dimension Tables for Cube

Hi Gurus ,
I am transporting a cube from one system to another and the transport fails becasue the dimension tables are in active in the target system. Now since this system is read only I cannot manually activate it , last resort I even trioed opening the system and activating it and re transported the transport. I get the same error saying that table /BIC/ZXXXXX is inactive.
Can anyone help....please....

hi Sanjeev,
did you change any dimensions in dev ?
like delete some characteristics from existing dimension,
or add new characteristic or move from one to another
dimension ?
if so, you may need to delete production data first,
to avoid this, please change back characteristics to previous dimension, and create a new dimension and add new characteristic to the new create dimension.
another possibility is database problem, try to search oss note for infocube dimension inactive.
hope this helps.

Why dimension tables are denormalized?

why dimension tables are denormalized?
Duplicate post
Edited by: Pravender on Jun 17, 2011 12:31 AM

Hi,
As pr my understanding, if you have a normalized structure for say, a cube, mean you have 10 table connected to single central table. So while queying you are trying to read data in a single SELECT on virtually a view of 10 different tables.
While in the present denormalized cube structure, you go for different selects virtually F table -> DIM table -> SID table -> Mastertable -> Text table. One can imagine sort of parallel SELECTs.
So if for small amount of data this denormalized structure may be slow but if you imagine for huge volume, this method is better.

Detailed analysis about the dimension tables of a cube

Hi Experts,
how can I get a detailed analysis about the dimension tables of a cube? (E.g. how many records include the fact tables, dimension tables and how much percent are these records compared with the whole records of the cube?!)
Thx in advance for your answers!

Hi,
You will get most of the information in LISTSCHEMA transaction code. If you want to see further you can see the records in SE11.
Regards
Githen

Identify the Cubes where dimension table size exactly 100% of the fact tabl

Hello,
We want to Identify the Cubes where dimension table size exactly 100% of the fact table.
Is there any table or standard query which can give me this data?
Regards,
Shital

use report (se38) SAP_INFOCUBE_DESIGNS
M.

Why do dimension tables contain data?

Hi there,
as far as I understodd the BW datamodel, the dimensions are to summon characteristics that do belong to the specific view I want to access via my InfoCube. So, the dimensional tables should contain just the mapping between DimIDs and SID, shouldn't they? What else do these dimensional tables contain??
Thanks,
Pascal

Hi,
I think the concept of using dimension table as the intermediate to SID And Facttable is to develope <i>extended star schema</i>. So that it allowing more than 13 characterstics in infocube.
With rgds,
Anil Kumar Sharma .P

What is '#Distinct values' in Index on dimension table

Gurus!
I have loaded my BW Quality system (master data and transaction data) with almost equivalent volume as in Production.
I am comparing the sizes of dimension and fact tables of one of the cubes in Quality and PROD.
I am taking one of the dimension tables into consideration here.
Quality:
/BIC/DCUBENAME2 Volume of records: 4,286,259
Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as 4,286,259
Prod:
/BIC/DCUBENAME2 Volume of records: 5,817,463
Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as 937,844
I would want to know why the distinct value is different from the dimension table count in PROD
I am getting this information from the SQL execution plan, if I click on the /BIC/ECUBENAME table in the code. This screen gives me all details about the fact table volumes, indexes etc..
The index and statistics on the cube is up to date.
Quality:
E fact table:
Table   /BIC/ECUBENAME
Last statistics date                  03.11.2008
Analyze Method               9,767,732 Rows
Number of rows                         9,767,732
Number of blocks allocated         136,596
Number of empty blocks              0
Average space                            0
Chain count                                0
Average row length                      95
Partitioned                                  YES
NONUNIQUE Index   /BIC/ECUBENAME~P:
Column Name                     #Distinct
KEY_CUBENAMEP                                  1
KEY_CUBENAMET                                  7
KEY_CUBENAMEU                                  1
KEY_CUBENAME1                            148,647
KEY_CUBENAME2                          4,286,259
KEY_CUBENAME3                                  6
KEY_CUBENAME4                                322
KEY_CUBENAME5                          1,891,706
KEY_CUBENAME6                            254,668
KEY_CUBENAME7                                  5
KEY_CUBENAME8                              9,430
KEY_CUBENAME9                                122
KEY_CUBENAMEA                                 10
KEY_CUBENAMEB                                  6
KEY_CUBENAMEC                              1,224
KEY_CUBENAMED                                328
Prod:
Table   /BIC/ECUBENAME
Last statistics date                  13.11.2008
Analyze Method                      1,379,086 Rows
Number of rows                       13,790,860
Number of blocks allocated       187,880
Number of empty blocks            0
Average space                          0
Chain count                              0
Average row length                    92
Partitioned                               YES
NONUNIQUE Index /BIC/ECUBENAME~P:
Column Name                     #Distinct
KEY_CUBENAMEP                                  1
KEY_CUBENAMET                                 10
KEY_CUBENAMEU                                  1
KEY_CUBENAME1                            123,319
KEY_CUBENAME2                            937,844
KEY_CUBENAME3                                  6
KEY_CUBENAME4                                363
KEY_CUBENAME5                            691,303
KEY_CUBENAME6                            226,470
KEY_CUBENAME7                                  5
KEY_CUBENAME8                              8,835
KEY_CUBENAME9                                124
KEY_CUBENAMEA                                 14
KEY_CUBENAMEB                                  6
KEY_CUBENAMEC                                295
KEY_CUBENAMED                                381

Arun,
The cube in QA and PROD are compressed. Index building and statistics are also up to date.
But I am not sure what other jobs are run by BASIS as far as this cube in production is concerned.
Is there any other Tcode/ Func Mod etc which can give information about the #distinct values of this Index or dimension table?
One basic question, As the DIM key is the primary key in the dimension table, there cant be duplicates.
So, how would the index on Ftable on this dimension table show #distinct values less than the entries in that dimension table?
Should the entries in dimension table not exactly match with the #Distinct entries shown in
Index /BIC/ECUBENAME~P on this DIM KEY?

[39008] Logical dimension table has a source that does not join to any fact

Dear reader,
After deleting a fact table from my physical layer and deleting it from my business model I'm getting an error: [39008] Logical dimension table TABLE X has a source TABLE X that does not join to any fact source. I do have an other fact table in the same physical model and in the same business model wich is joined to TABLE X both in the physical and business model.
I cannot figure out why I'm getting this error, even after deleting all joins and rebuilding the joins I'm getting this error. When I look into the "Joins Manager" these joins both in physical as well as logical model do exist, but with consistency check it warns me about [39008] blabla. When I ignore the warning and go to answers and try to show TABLE X (not fact, but dim) it gives me the following error.
Odbc driver returned an error (SQLExecDirectW).
Error Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: TABLE X.column X Please fix the metadata consistency warnings. (HY000)
SQL Issued: SELECT TABLE X.column X saw_0 FROM subject area ORDER BY saw_0
There is one *"special"* thing about this join. It is a complex join in the physical layer, because I need to do a between on dates and a smaller or equal than current date like this example dim.date between fact.date_begin and fact.date_end and dim.date <= current_date. In the business model I've got another complex join
Any help is kindly appreciated!

Hi,
Have you specified the Content level of the Fact table and mapped it with the dimension in question? Ideally this should be done by default since one of the main features of the Oracle BI is its ability to determine which source to use and specifying content level is one of the main ways to achieve this.
Another quick thing that you might try is creating a dimension (hierarchy) in case it is not already present. I had a similar issue few days back and the warning was miraculously gone by doing this.
Regards

Dimension key 16 missing in dimension table /BIC/DZPP_CP1P

Hi all,
I have a problem with an infocube ZPP_CP1. I am not able to delete nor load any data. It was working fine till some time back.
Below is the outcome of running RSRV check on this cube. I tried to run the error correction in RSRV. But n o use
Please help.
Dimension key 16 missing in dimension table /BIC/DZPP_CP1P
Message no. RSRV018
Diagnosis
The dimension key 16 that appears as field KEY_ZPP_CP1P in the fact table, does not appear as a value of the DIMID field in the dimensions table /BIC/DZPP_CP1P.
There are 17580 fact records that use the dimension key 16.
The facts belonging to dimension key 16 are therefore no longer connected to the master data of the characteristic in dimension.
Note that errors that are reported for the package dimension are not serious (They are thus shown as warnings (yellow) and not errors (red). When deleting transaction data requests, it can arise that the associated entries in the package dimension have already been deleted. As a result, the system terminates when deleting what can be a very large number of fact records. At the moment, we are working on a correction which will delete such data which remains after deletion of the request. Under no circumstances must you do this manually. Also note that data for request 0 cannot generally be deleted.
The test investigates whether all the facts are zero. If this is the case, the system is able to remove the inconsistency by deleting these fact records. If the error cannot be removed, the only way to re-establish a consistent status is to reconstruct the InfoCube. It may be possible for SAP to correct the inconsistency, for which you should create an error message.
Procedure
This inconsistency can occur if you use methods other than those found in BW to delete data from the SAP BW tables (for example, maintaining tables manually, using your own coding or database tools).

Hi Ansel,
There has been no changes in the cube. I am getting this problem in my QA server. So I retransported the cube again from Dev to QA. But did not help me..
Any other ideas??
Regards,
Adarsh

Fact Tables without Dimension Tables.

Hi,
I am currently working on a project where a data warehouse is being developed using an application database as the source. Since the application database is already normalised, the tables are being loaded in as they are and the consultant involved is creating
data marts for them. I have asked about why he is not creating separate dimension and fact tables as data marts, and he has told me that he will create a fact table with the dimensions as column names without any dimension tables created as you might expect
as per star/snowflake schema.
Is this right, as I always thought you had to have dimension and fact tables, especially if you want to start using SSAS?
Regards,
W.

create a fact table with the dimensions as column names without any dimension tables created as you might expect as per star/snowflake schema.
This is the trouble with denormalization: where is the stopping point?
If the data warehouse is the source for SSAS OLAP cubes, it is better to go with the usual star schema.
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Urgent-Issue in the Dimension tables

Hi Experts,
Question1:
I have a flat file load to a cube.this flat file has 1.5 mil records.One of the dimension created has a 2 dates(original date & current date) assigned.
When i look at dimension table for # entries is 30million.And when i look at the table i see the sids as 0,0 ( for 2 dates) and dim id's being creted.
When i did a search on the dimension table with current date & original date as not equal to 0.I see only 76,000 records.
Question 2:
we have an ODS which loads to the cube.In the process chain we have program that deletes the data in ods which does not match some conditions and then loads it tot he cube.
My question is,since we are not deleting contents from the cube and reloading it from the ODS(Full update).Will i not be seeing same records coming in with Full update which get agrregated in the cube.
Ex: i have a record in ODS.
A   X Z 100 1000
After full update to the cube,the cube would have
A   X Z 100 1000
When i run the process chain and data is dleeted from ODS on some condition and i still have hte same record in ODS and when this loads into cube wont this be aggregated with the previous record.
A X   Z 200 2000
Would appreciate,if anyone could explain if i am missing anything.

Hello,
If you can't see the SID means you have not loaded the master data, that why there is no reference to the SID table and the values are 0.
InfoCube by default will have aggregated values, when there are duplicate records on the Keyfigures will be aggregated.
For example I have a Material Dimension and Customer Dimension
In the fact table, it will be like this
DIM1     DIM2    KF1   KF2
Mat001 Cust1 100    10
Mat001 Cust2 200    5
for this there will be 1 entry in Material DIM table for Mat001 and 2 entries for Customer DIM table for Customer Cust1 and Cust2.
Material Dimension
DIM ID    SID
1             Mat001 (Here it will be SID from Material Master)
Customer Dimension
1             Cust1 (Here it will be SID from Customer Master)
2             Cust2 (Here it will be SID from Customer Master)
Note : DIM ID is the combination of one or more SID in the dimension table.
So the exact fact table will look like
MATDIM    CUSDIM       AMT      QTY
1               1                  100        10
1               2                  200        5
If you load the data again with same characteristics values then the key figure will be aggregated
Example if you load
Mat001 Cust2 25 5
then the fact table will not have a new entry instead the it will aggregates and looks like (bolded one)
MATDIM    CUSDIM       AMT      QTY
1               1                  100        10
1               2                  220        10
Hope its clear
thanks
Chandran

Fact and dimension table partition

My team is implementing new data-warehouse. I would like to know that when should we plan to do partition of fact and dimension table, before data comes in or after?

Hi,
It is recommended to partition Fact table (Where we will have huge data). Automate the partition so that each day it will create a new partition to hold latest data (Split the previous partition into 2). Best practice is to create partition on transaction
timestamps so load the incremental data into a empty table called (Table_IN) and then Switch that data into main table (Table). Make sure your tables (Table and Table_IN) should be on one file group.
Refer below content for detailed info
Designing and Administrating Partitions in SQL Server 2012
A popular method of better managing large and active tables and indexes is the use of partitioning. Partitioning is a feature for segregating I/O workload within
SQL Server database so that I/O can be better balanced against available I/O subsystems while providing better user response time, lower I/O latency, and faster backups and recovery. By partitioning tables and indexes across multiple filegroups, data retrieval
and management is much quicker because only subsets of the data are used, meanwhile ensuring that the integrity of the database as a whole remains intact.
Tip
Partitioning is typically used for administrative or certain I/O performance scenarios. However, partitioning can also speed up some queries by enabling
lock escalation to a single partition, rather than to an entire table. You must allow lock escalation to move up to the partition level by setting it with either the Lock Escalation option of Database Options page in SSMS or by using the LOCK_ESCALATION option
of the ALTER TABLE statement.
After a table or index is partitioned, data is stored horizontally across multiple filegroups, so groups of data are mapped to individual partitions. Typical
scenarios for partitioning include large tables that become very difficult to manage, tables that are suffering performance degradation because of excessive I/O or blocking locks, table-centric maintenance processes that exceed the available time for maintenance,
and moving historical data from the active portion of a table to a partition with less activity.
Partitioning tables and indexes warrants a bit of planning before putting them into production. The usual approach to partitioning a table or index follows these
steps:
1. Create
the filegroup(s) and file(s) used to hold the partitions defined by the partitioning scheme.
2. Create
a partition function to map the rows of the table or index to specific partitions based on the values in a specified column. A very common partitioning function is based on the creation date of the record.
3. Create
a partitioning scheme to map the partitions of the partitioned table to the specified filegroup(s) and, thereby, to specific locations on the Windows file system.
4. Create
the table or index (or ALTER an existing table or index) by specifying the partition scheme as the storage location for the partitioned object.
Although Transact-SQL commands are available to perform every step described earlier, the Create Partition Wizard makes the entire process quick and easy through
an intuitive point-and-click interface. The next section provides an overview of using the Create Partition Wizard in SQL Server 2012, and an example later in this section shows the Transact-SQL commands.
Leveraging the Create Partition Wizard to Create Table and Index Partitions
The Create Partition Wizard can be used to divide data in large tables across multiple filegroups to increase performance and can be invoked by right-clicking
any table or index, selecting Storage, and then selecting Create Partition. The first step is to identify which columns to partition by reviewing all the columns available in the Available Partitioning Columns section located on the Select a Partitioning Column
dialog box, as displayed in Figure 3.13. This screen also includes additional options such as the following:
Figure 3.13. Selecting a partitioning column.
The next screen is called Select a Partition Function. This page is used for specifying the partition function where the data will be partitioned. The options
include using an existing partition or creating a new partition. The subsequent page is called New Partition Scheme. Here a DBA will conduct a mapping of the rows selected of tables being partitioned to a desired filegroup. Either a new partition scheme should
be used or a new one needs to be created. The final screen is used for doing the actual mapping. On the Map Partitions page, specify the partitions to be used for each partition and then enter a range for the values of the partitions. The
ranges and settings on the grid include the following:
Note
By opening the Set Boundary Values dialog box, a DBA can set boundary values based on dates (for example, partition everything in a column after a specific
date). The data types are based on dates.
Designing table and index partitions is a DBA task that typically requires a joint effort with the database development team. The DBA must have a strong understanding
of the database, tables, and columns to make the correct choices for partitioning. For more information on partitioning, review Books Online.
Enhancements to Partitioning in SQL Server 2012
SQL Server 2012 now supports as many as 15,000 partitions. When using more than 1,000 partitions, Microsoft recommends that the instance of SQL Server have at
least 16Gb of available memory. This recommendation particularly applies to partitioned indexes, especially those that are not aligned with the base table or with the clustered index of the table. Other Data Manipulation Language statements (DML) and Data
Definition Language statements (DDL) may also run short of memory when processing on a large number of partitions.
Certain DBCC commands may take longer to execute when processing a large number of partitions. On the other hand, a few DBCC commands can be scoped to the partition
level and, if so, can be used to perform their function on a subset of data in the partitioned table.
Queries may also benefit from a new query engine enhancement called partition elimination. SQL Server uses partition enhancement automatically if it is available.
Here’s how it works. Assume a table has four partitions, with all the data for customers whose names begin with R, S, or T in the third partition. If a query’s WHERE clause
filters on customer name looking for ‘System%’, the query engine knows that it needs only to partition three to answer
the request. Thus, it might greatly reduce I/O for that query. On the other hand, some queries might take longer if there are more than 1,000 partitions and the query is not able to perform partition elimination.
Finally, SQL Server 2012 introduces some changes and improvements to the algorithms used to calculate partitioned index statistics. Primarily, SQL Server 2012
samples rows in a partitioned index when it is created or rebuilt, rather than scanning all available rows. This may sometimes result in somewhat different query behavior compared to the same queries running on SQL Server 2012.
Administrating Data Using Partition Switching
Partitioning is useful to access and manage a subset of data while losing none of the integrity of the entire data set. There is one limitation, though. When
a partition is created on an existing table, new data is added to a specific partition or to the default partition if none is specified. That means the default partition might grow unwieldy if it is left unmanaged. (This concept is similar to how a clustered
index needs to be rebuilt from time to time to reestablish its fill factor setting.)
Switching partitions is a fast operation because no physical movement of data takes place. Instead, only the metadata pointers to the physical data are altered.
You can alter partitions using SQL Server Management Studio or with the ALTER TABLE...SWITCH
Transact-SQL statement. Both options enable you to ensure partitions are
well maintained. For example, you can transfer subsets of data between partitions, move tables between partitions, or combine partitions together. Because the ALTER TABLE...SWITCH statement
does not actually move the data, a few prerequisites must be in place:
• Partitions must use the same column when switching between two partitions.
• The source and target table must exist prior to the switch and must be on the same filegroup, along with their corresponding indexes,
index partitions, and indexed view partitions.
• The target partition must exist prior to the switch, and it must be empty, whether adding a table to an existing partitioned table
or moving a partition from one table to another. The same holds true when moving a partitioned table to a nonpartitioned table structure.
• The source and target tables must have the same columns in identical order with the same names, data types, and data type attributes
(length, precision, scale, and nullability). Computed columns must have identical syntax, as well as primary key constraints. The tables must also have the same settings for ANSI_NULLS and QUOTED_IDENTIFIER properties.
Clustered and nonclustered indexes must be identical. ROWGUID properties
and XML schemas must match. Finally, settings for in-row data storage must also be the same.
• The source and target tables must have matching nullability on the partitioning column. Although both NULL and NOT
NULL are supported, NOT
NULL is strongly recommended.
Likewise, the ALTER TABLE...SWITCH statement
will not work under certain circumstances:
• Full-text indexes, XML indexes, and old-fashioned SQL Server rules are not allowed (though CHECK constraints
are allowed).
• Tables in a merge replication scheme are not allowed. Tables in a transactional replication scheme are allowed with special caveats.
Triggers are allowed on tables but must not fire during the switch.
• Indexes on the source and target table must reside on the same partition as the tables themselves.
• Indexed views make partition switching difficult and have a lot of extra rules about how and when they can be switched. Refer to
the SQL Server Books Online if you want to perform partition switching on tables containing indexed views.
• Referential integrity can impact the use of partition switching. First, foreign keys on other tables cannot reference the source
table. If the source table holds the primary key, it cannot have a primary or foreign key relationship with the target table. If the target table holds the foreign key, it cannot have a primary or foreign key relationship with the source table.
In summary, simple tables can easily accommodate partition switching. The more complexity a source or target table exhibits, the more likely that careful planning
and extra work will be required to even make partition switching possible, let alone efficient.
Here’s an example where we create a partitioned table using a previously created partition scheme, called Date_Range_PartScheme1.
We then create a new, nonpartitioned table identical to the partitioned table residing on the same filegroup. We finish up switching the data from the partitioned table into the nonpartitioned table:
CREATE TABLE TransactionHistory_Partn1 (Xn_Hst_ID int, Xn_Type char(10)) ON Date_Range_PartScheme1 (Xn_Hst_ID) ; GO CREATE TABLE TransactionHistory_No_Partn (Xn_Hst_ID int, Xn_Type
char(10)) ON main_filegroup ; GO ALTER TABLE TransactionHistory_Partn1 SWITCH partition1 TO TransactionHistory_No_Partn; GO
The next section shows how to use a more sophisticated, but very popular, approach to partition switching called a sliding
window partition.
Example and Best Practices for Managing Sliding Window Partitions
Assume that our AdventureWorks business is booming. The sales staff, and by extension the AdventureWorks2012 database, is very busy. We noticed over time that
the TransactionHistory table is very active as sales transactions are first entered and are still very active over their first month in the database. But the older the transactions are, the less activity they see. Consequently, we’d like to automatically group
transactions into four partitions per year, basically containing one quarter of the year’s data each, in a rolling partitioning. Any transaction older than one year will be purged or archived.
The answer to a scenario like the preceding one is called a sliding window partition because
we are constantly loading new data in and sliding old data over, eventually to be purged or archived. Before you begin, you must choose either a LEFT partition function window or a RIGHT partition function window:
1. How
data is handled varies according to the choice of LEFT or RIGHT partition function window:
• With a LEFT strategy, partition1 holds the oldest data (Q4 data), partition2 holds data that is 6- to 9-months old (Q3), partition3
holds data that is 3- to 6-months old (Q2), and partition4 holds recent data less than 3-months old.
• With a RIGHT strategy, partition4 holds the holds data (Q4), partition3 holds Q3 data, partition2 holds Q2 data, and partition1
holds recent data.
• Following the best practice, make sure there are empty partitions on both the leading edge (partition0) and trailing edge (partition5)
of the partition.
• RIGHT range functions usually make more sense to most people because it is natural for most people to to start ranges at their lowest
value and work upward from there.
2. Assuming
that a RIGHT partition function windows is used, we first use the SPLIT subclause of the ALTER PARTITION FUNCTIONstatement
to split empty partition5 into two empty partitions, 5 and 6.
3. We
use the SWITCH subclause
of ALTER TABLE to
switch out partition4 to a staging table for archiving or simply to drop and purge the data. Partition4 is now empty.
4. We
can then use MERGE to
combine the empty partitions 4 and 5, so that we’re back to the same number of partitions as when we started. This way, partition3 becomes the new partition4, partition2 becomes the new partition3, and partition1 becomes the new partition2.
5. We
can use SWITCH to
push the new quarter’s data into the spot of partition1.
Tip
Use the $PARTITION system
function to determine where a partition function places values within a range of partitions.
Some best practices to consider for using a slide window partition include the following:
• Load newest data into a heap, and then add indexes after the load is finished. Delete oldest data or, when working with very large
data sets, drop the partition with the oldest data.
• Keep an empty staging partition at the leftmost and rightmost ends of the partition range to ensure that the partitions split when
loading in new data, and merge, after unloading old data, do not cause data movement.
• Do not split or merge a partition already populated with data because this can cause severe locking and explosive log growth.
• Create the load staging table in the same filegroup as the partition you are loading.
• Create the unload staging table in the same filegroup as the partition you are deleting.
• Don’t load a partition until its range boundary is met. For example, don’t create and load a partition meant to hold data that is
one to two months older before the current data has aged one month. Instead, continue to allow the latest partition to accumulate data until the data is ready for a new, full partition.
• Unload one partition at a time.
• The ALTER TABLE...SWITCH statement
issues a schema lock on the entire table. Keep this in mind if regular transactional activity is still going on while a table is being partitioned.
Thanks Shiven:) If Answer is Helpful, Please Vote

Development Class for Dimension Tables

I'm trying to change the development package for a dimension within our salecube. Right now its assigned to $TMP. I'm very familar with the basic steps to change this but its not there. The cube itself is assigned to a "z" package but not the dimension. Can someone tell me how to change the package on a dimension.
(will award points)

Hi Richard,
You should be able to do this in SE11 > yrcubename and F4 will give you all the tables fo the dube including the dimension tables. Then Display the table. On the mneu Goto > Object Directory Entry.
Hope this helps...
Message was edited by: Bhanu Gupta
- But why would you like to do this?

Help on Setting logical Levels in Fact tables and on Dimension tables

Hi all
Can any body provide any blogs or any king of material on what exactly is levelling .
Like after creating the Dimensional hierarchies we need to set the logical levels for the LTS of fact tabels ri8 .So what is the difference between setting logical levels to fact tabels and also Setting levelling on Dimension tables .
Any kind of help is appreciated
Thanks
Xavier.
Edited by: Xavier on Aug 4, 2011 10:50 AM

I have read these blogs ,but what my question is
Setting the logical levels in LTS of Fact tables i understood .
But we can also set the logical levels for dimensions also ri8 .I didn't understand why do we set the logical levels for dimensions .Is there any reason why we go with the levelling at dimensions
Thanks
Xavier
Edited by: Xavier on Aug 4, 2011 2:03 PM
Edited by: Xavier on Aug 4, 2011 2:32 PM

Why cube cannot exceed 16 dimension tables?

Similar Messages

Maybe you are looking for