SSAS .abf file without partitions of fact table

Hi All,
I am trying to take a cube .abf file from Dev env. This cube contains patitions for month on one of the fact table. our each env has differnt number of months.
My problem is when i take .abf file from DEV backup it contains only 4 months of data so it as only 4paritions. But SIT conatins 8 months data they are not showing up even after full cube process. i came to know that we must take a fresh .abf file without
processing. How can i take it??
Note: I cannot create partions from SSMS.
Thanks in advance

I am trying to take a cube .abf file from Dev env. This cube contains patitions for month on one of the fact table. our each env has differnt number of months.
My problem is when i take .abf file from DEV backup it contains only 4 months of data so it as only 4paritions. But SIT conatins 8 months data they are not showing up even after full cube process.
Hi shrSan,
If we backup a cube which contains 4 partitions for the measure group, it always got 4 partitions for the measure group when we restore the cube on a new OLAP Server. If we need to filter a fact tabel with more partitions, we should create partitions by
manually on the new OLAP Server.
For more information, please see:
Filtering a Fact Table for Multiple Partitions:
http://technet.microsoft.com/en-us/library/ms175325(v=sql.105).aspx
Partitions (Analysis Services - Multidimensional Data):
http://technet.microsoft.com/en-us/library/ms175688.aspx
If I have something misunderstood, please point out and elaborate your issue with more detail.
Regards,
Elvis Long
TechNet Community Support

Similar Messages

Partitioning a fact table

I am curious to hear techniques for partitioning a fact table with OWB. I know HOW to setup the partitioning for the table, but what I am curious about is what type of partitioning everyone is suggesting. Take the following example...Lets say we have a sales transaction fact table. It has dimensions of Date, Product, and Store. An immediate partitioning idea is to partition the table by month. But my curiosity arises in the method used to partition the fact table. There is no longer a true date field in the fact table to do range partitioning on. And hash partitioning will not distribute the records by month.
One example I found was to "code" the surrogate key in the date dimension so that it was created in the following manner "YYYYMMDD". Then you could use the range partitioning based on values of the key in the fact table less than 20040200 for Jan. 2004, less than 20040300 for Feb. 2004, and so on.
Is this a good idea?

Jason,
In general, obviously, query performance and scaleability benefit from partitioning. Rather than hitting the entire table upon retrieving data, you would only hit a part of the table. There are two main strategies to identify what partitioning strategy to choose:
1) Users always query specific parts of the data (e.g. data from a particular month) in which case it makes sense for the part to be the size of the partition. If your end users often query by month or compare data on a month-by-month basis, then partitioning by month may well be the right strategy.
2) Improve data loading speed by creating partitions. The database supports partion exchange loading, supported by Warehouse Builder as well, which enables you to swap out a temporary table and a partition at once. In general, your load frequency then decides your partitioning strategy: if you load on a daily basis, perhaps you want daily partions. Beware that for Warehouse Builder to use the partition exchange loading feature you will have to have a date field in the fact table, so you would change the time dimension.
In general, your suggestion for the generated surrogate key would work.
Thanks,
Mark.

Two Filter on Two dimensions without constraining the fact table

Hi All,
does anybody know how to avoid the fact constraint when creating a report with two filters on different dimensions?
I have a big fact table with more than 10 Million rows. In the starmodel the is the dimension customer and products. I create a filter on the customer atrribute "Status" and choose the value "Active". Now I add the column "Product Type" from the dimension "Product" to the filter section. When I want to choose a value OBIEE executes a select statement within the fact table. So I have to wait very long to select a value. Is there any way to say OBIEE only to select the dimension table without joining the fact table?
Thank you very much in Advance.
Regards,
Stefan

Hi Stefan,
Generally queries on the dimensions (across dimesions also) always go through a fact. In case, you would like the queries not be through fact table, but just the dimension tables right away, you can set up a separate subject area for them.
You can create a separate subject area based on a dummy fact table to get these prompt values.
Please refer to http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_parameter_prompt_subject_area for more details on this setup.
Hope this helps.
Thank you,
Dhar

Partitioning the fact table

Hi Gurus,
I have a question regarding partitioning the cube. When you partition the cube from the Extras menu, will it partition the F table or is it the E table or both.
Second question: After partitioning, how will i know the newly created table names.
Thanks,
ANU

Hi Anu,
Partition Need and its definition
Infocube contains huge amount of data n the table size of the cube increases regularly. so
when a query is executed on cube then it has to check entire table to get the records for
example Sales in Jan08.
Advantage of Partition
so we can partition the cube so that smaller tables are formed .so that report performance
will increase bcoz the query hits that particular partition.
Steps for Partition
1.To partiotion a cube, it must not contain data.
2. Partition can be done using time characteristics 0CALMONTH and fiscalperiod.
steps:
1. in change of the cube, select extras menu and Partioning option.
2. select calmonth time characteristic.
3. it will ask for the time period to partiotion and no. of partiotions. give them
4. activate the cube.
In BI 7 we can partition the cube even if it contains data.
select the cube, right click , select repartitioning.
1. we can delete existing partitions
2. create new ones
3. merge partitions.
Partitioning of the Cube
http://help.sap.com/saphelp_nw04s/helpdata/en/0a/cd6e3a30aac013e10000000a114084/frameset.htm
Partitioning Fields and Values
partition of Infocube
Partitioning of cube using Fiscal period
Infocube Partition
After Partition
You can find the Partition in the following tables in SE11 >
E tables /BIC/E* or /BIC/E(cube name)
Please also go through the following links
Partioning of Cube
partioning
Partioning of ODS object
/thread/733456 [original link is broken]
Hope i had answered your question
Assign points if helpful,
Thanks and regards
Bala

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

Partition Pruning - Dimension and FACT tables..

Hi
I have a DWH environment where we have partitioned the FACT table by a date column. This is RANGE partition. The TIME dimension table joins to the FACT table based on this date. However the end user queries will typically be fired using a different column in the time dimension that will hold more VIEWABLE date values (e.g.) in format MON-YYYY or YYYY-MM etc..
The query is autogenerated by the viewer tool. The SQL has something like
select sum(balance), MONTH from fact a, dim_time b
where a.date = b.date and <-- this the partitioned key in fact
b.month_year_col = 'Apr-2006' <-- Dimension filter.
In the above case, Oracle is not doing PARTITION PRUNING. I have 24 period data and in the explain plan i can see it goes to the entire 24 periods. However if i change the query to
select sum(balance), MONTH from fact a, dim_time b
where a.date = b.date and <-- this the partitioned key in fact
b.date = '31-Apr-2006' <-- Dimension filter.
it does partition pruning. The explain plan shows that i goes to only one partition.
Any help on this please. I would need the first query to use PARTITION PRUNING.
Thanks
bala

Hi All
Got it to work with these 3 parameters
alter system set "_subquery_pruning_enabled" = true
alter session set "_subquery_pruning_cost_factor"=1;
alter session set "_subquery_pruning_reduction"=100;
Thanks for all those who had a look into my question.
Regards
bala

Modeling: Is Fact Table partitioning that important?

I read of how much partitioning a fact table can speed a query. On an upcoming project with specifications for only 4 InfoCubes, how can we take advantage in partitioning to fact tables to speed up queries?
Can this be factored into the design now or, we should wait till queries on Cube begins to perform poorly?
Thanks.

Spend some time reviewing the links others have provided and serach SDN.
As mentioned, there are two types of partitioning generally talked about with SAP BW, logical and physical partitioning.
Logical partitioning - instead of having all your data in a single cube, you might break into separate cubes, with each cube holding aspecific year's data, e.g. you could have 5 sales cubes, one for each year 2001 thru 2005.
You would then create a Multi-Provider that allowed you to query all of them together.
A query that needs data from all 5 years would then automatically (you can control this) be split into 5 separate queries, one against each cube, running at the same time. The system automatically merges the results from the 5 queries into a single result set.
So it's easy to see when this could be a benefit. If your queries however are primarily run just for a single year, then you don't receive the benefit of the parallel processing. In non-Oracle DBs, splitting the data like this may still be a benefit by reducing the amount of rows in the fact table that must be read, but does not provide as much value to an Oracle DB since Infocube queries are using a Star_Transformation.
Physical Partitioning - I believe only Oracle and Informix currently support Range partitioning. This is a separately licensed option in Oracle.
Physical partitioning allows you to split an Infocube into smaller pieces. The pieces, or partitions, can only be created by 0FISCPER or 0CALMONTH for an InfoCube (ODSs can be partitioned, but require a DBAs involvement). The DB can then take advantage of this partitioning by "pruning" partitions during a query, e.g. a query only needs data form June 2005
The DB is smart enough to restrict the indices and data it will read to the June 2005 partition. This assumes your query restricts/filters on the partitioning characteristic. It can apply this pruning to a range of partitions as well, e.g. 0FISCPER 001/2005 thru 003/2005 would only look at the 3 partitions.
It is NOTsmart enough, however, to figure out that if your restrict to 0FISCYEAR = 2005, that it should only read 000/2005 thru 016/2005 since 0FISCYEAR is NOT the partitioning characteristic.
An InfoCube MUST be empty in order to physically partition it. At this time, there is no way to add additional partitions thru AWB, so you want to make sure that you create partitions out into the future for at least a of couple of years.
If the base cube is partitioned, any aggregates that contain the partitioning characteristic (0CALMONTH or 0FISCPER) will automatically be partitioned.
In summary, you need to figure out if you want to use physical or logical partitioning on the cube(s), or both, as they are not mutually exclusive.
So you would need to know how the data will be queried, and the volume of data. It would make little sense to partition cubes that will not be very large.

Why Negative values are entering in to fact table.

Dear All,
After Data File uploaded. The Fact table is showing Negative values.
Can any body give solution.
And in DataManager->Financial Process>FX Restatament (Is running Succussfully)
But Currency is not getting translated.
Please help.
Thanks,
Satish.

The reason the values are negative may be caused by 2 items. The first is the default method by which BPC store information; BPC is designed to store values based on the natural sign. So, if a Revenue account is positive in the Data File, and the Property "ACCTTYPE" is INC, the value is stored as a negative number. When an expense value is loaded to an account with "EXP", the value is stored as a positive. LEQ are Negative and AST are positive. (CREDITS and DEBITS storage)
BPC then uses tables and measures to report the account based on type correctly in the Excel interface. This is how BPC is designed.
There is also the CREDITPOSITIVE = YES / NO that is part of the Data Transformation instructions, and if this is setup incorrectly, you may store the reverse signs from the data file that is loaded. So this may need to be reviewed as well.
As for the FXTranslation, I assume you have rates in the RATE cube to use in the translation process. You will need to verify that the RATETYPE property is filled in for the accounts you wish to translate? DId you process the FX script logic and the RATE script logic prior to running FX.
Hope this helps.
Edited by: Petar Daniel on Dec 10, 2008 2:20 PM

Updating fact table

Hi,
I'm just starting with data warehousing. I need to design a warehouse that will record sales on a daily basis. This seems to be pretty much standard task. However in my case an order may change many times before it is fulfilled. I'm planning to handle it similar to slowly changing dimensions type 2, by adding effective date/expiration date (ref. to date dimension) to fact table. So when an order is updated I would mark the current record as expired and add a new one. I cannot just replace or remove the previous record, since it would make historical information incorrect. I also don't really like the idea of storing let's say order history and periodic snapshots separately - it seems overly complicated.
I was thinking about partitioning the fact table so that only records in the most current partition would be updated. In addition I would create a view for users "where "Expiration Date" = 'N/A'" to work with the current information.
I'm sure that it's a common situation in data warehousing, however I could not find any useful information on dealing with it. Am I on the right track? Does OWB support such functionality (find existing facts by a criteria -> update them -> load new records) well?
Thanks.

Seems like an odd situation. I mean, even if an order is revised several times does it get included in a daily sales total until it is complete? I think not.
you seem to want to be able to report on a daily order book total which is completely different than sales. Sales are generally defined as an atomic, completed transaction. So I would tend to do this via a SALES_ORDER type-2 dimension which includes order status and order_total. If you need line-item totals then you might want to look at a many-to-many relationship to hold those details.
The fact table would then just hold the associated details of completed sales (do you need to report sales by payment type/ delivery method / sales rep / cashier / location / etc? If so those are other FKs to dimensions).
I suggest this route as the current value of the order book is not summable - it is a point in time look at orders on hand. Sales, on the other hand, are summable so can be aggregated / averaged / whatever over a given time period. You just can't do that with the current value of the order book which suggests that it is NOT best served by being stored in a fact.
I think that this has to be the route to go if you want to be able to sum totals over time. You may have sales. You may need an associated
"returns" fact. But you have to pick a point in time where a sale is an atomic entity and then treat any new data as a new fact.
just my two cents worth.....
Mike
Edited by: zeppo on Sep 11, 2009 12:04 PM

Cubes with different dimensions based on the same fact table

I have a fact table (f_a) with three dimensions (dim_a, dim_b, dim_c) and a one measure (m_a).
Is it possible to create cube with only one dimension (dim_a)?
Data for other two dimensions (dim_b, dim_c) should be aggreagated together.
Of course i can create second fact table with only one dimension, and then creating that cube would be no problem.
But is it possible doing this directly from the primary fact table (without creating second fact table)?
Raf
PS:i use AWM 9.2 to create target cubes. Source cubes i create with OEM 9.2

At the beginning i was confused by the numberous kind of cubes...
for example when i created cube in MS i just designed cube, picked fact table, and that's all. In Oracle firstly i create project of cube (first cube) in OWB. Then i export it to the OLAP Catalog (second cube). That cube in OLAP catalog is a source cube for the AW cube (third cube). Then i need to enable AW cube for OLAPI by creating another cube in OLAP Catalog (i use 9iR2, so OLAPI doesn't have direct access to AW cubes).
I spent much time until i could see my first sample cube in Discoverer or Excel as a final user should see it. :-)
Now i'm facing another problem - when you redesign cube (for example add another dimension), you can't just "refresh" it as it was in MS. You have to delete old cube and create new one. And deleting cube isn't so simple (i'm not sure which elements i should delete).
For testing and learning purposes i just create every cube in seperate AW. deleting whole AW is much simplier that deleting one cube.
Raf

SSAS Tabular - Vertically partitioned Fact Table Relationships

Hi All, I have a very wide (300 column) fact table and hence it is partitioned into 2 fact tables vertically with the common key in both tables for relation (1:1). Both the tables have some measures and degenerate dimensions to be used for analyisis.
How should the data model look like? I am stuck because the bi-directional relationships doesnt seem to be supported and only one direction works when degenerate dimensions are used.
Also, these two fact tables are related to some common dimensions and when i connect all of them together, some of the relationships get deactivated due to circular naure of relationships. Using USERELATIONSHIPS is going to be very timeconsuming considering
the number of measures.
What is the guidance around modelling vertically partitoned fact tables? Do I combine both the tables into one wide table using a View or Query? Any help appreciated.
Thanks, Ashish Singh

Hi Thomas, Unfortunately I do not have any control over the DW design and the client says that they require most of the columns for analysis. I do not want to combine the fact tables into a wider table but stuck with the relationship design in Tabular mode.
1) Bi-directional relationships are not supported. So, if both the fact tables have degenerate dimensions on which the mesaures have to be analyzed, it cannot work because the relationships are unidirectional in tabular mode.
2) Relationships get deactivated. Since both the tables are connected to each other using a KEY column, any attempt to connect both the tables to some common dimension results in INACTIVE relationships which needs either using USERELATIONSHIP or importing
the same table again with a different alias which complicates the model.
3) Inferenced relationships cant be modelled. If Fact1 is connected to a dimension, the measures of Fact2 cannot be analyzed on that dimension even though Fact1 and Fact 2 are connected using a 1:1 relationship.
All these design challenges make me lean towards using a SQL View and joining the 2 Fact tables in the Tabular model so that I could provide the users with the analysis they require using the current DB structure. Is there a different approach to achieve?
Any better ideas would be heplful.
Thanks, Ashish Singh

Alternate fact table without disturbing the existing fact table in EIS

I have a question in EIS, how to load or work with alternate fact table, without disturbing the existing fact table, pls provide me with some procedure and steps
thank u in advance
sunil

Yes you can have multiple models and metaoutlines load one cube. I've done it before. The trick is you ahve one "master" metaoutline that you put all the measures in (even if they are manually added. You use that to build the cube. Then you can have multiple metaoutlines build different measures within the cube. The idea is you have to have them update different intersections or the last one in will be what you get. I have a client that gets sales info from one source, shipment info from a different relational source . in all I have 10 differnt models and metaoutlines that build one cube. you just lump the load statements into one CBS file. It works great (or as great as EIS works). The biggest issue is timing to make sure all the sources are available when the load is going to be doe. Of course you could build different parts at different times.

Experiences of Partitioning FACT tables

Running BPC 7.0 SP3 for MS
We have two very large FACT tables (195milliion records and 105million records) and these are currently growing at a rate of 2m/5m records per month - we are running an incremental optimize twice per day
It has been suggested that we consider partioning the tables to improve performance, but I have not been able to find any users/customers with any experience of doing this
Specifically
1. Does it improve performance?
2. What additional complexity does it add to regular maintenance ?
3. Have there been any problems encountered implementing Partioned tables?
4. It would seem that partioning based on time would make sense - historic data in one partition, current data in another HOWEVER many of our reports pull current year and prior year so will this cause a reporting issue? Or degrade report performance?

I don't know if this is still an issue for you. You ask about Fact Table partitioning specifically, but you need to be aware that it is possible to partition either the FACT tables or the Fact table partition of the cube, or both. We have used (further) partioning of Fact table partition in the cube with success, and it sounds as if this is what you are really asking about.
The impacts are on
1. processing time, a full optimize without Compress only processes the paritions that have changed, thereby reducing the run time where there is a lot of unchanged data. You mention that you run incremental updates twice daily, this is currently reprocessing the whole database. I would have expected the lite optimize to be more effective, supported by an overnight full optimize, if you have an overnight window. You can also run the lite optimize more frequently.
2. query time. The filters defined in the partitions provide a more efficient path to data in the reporting processes than the defaults, which have the potential to scan large parts of the database.
Partitioning is not a panacea. You need to be specific about the areas of performance problem that you have and choose the performance improvement strategy to address these. Looking at the indexing of the database is also an area where you can improve performance significantly.
If you partition the cube, it is transparent to the usage of the application, from both user and admin perspective. The greatest complexity comes is the definition of the partitions in the first place, but this is a normal DBA function. The trick is ensure that the filter statements do not overlap, otherwise you might get a value duplicated in 2 partitions, and to define a catchall partition to include anything not included in specific partitions. You should expect to revist the partitioning from time to time. It is quite straightforward to repartition, you are not doing anything to the underlying data in the FACT tables
Time is a common dimension to partition and you may partition at different levels of granularity for different periods, e.g. current year by qtr or month, prior and future years by year. This reflects where the most frequent updates will be. It is also possible to define partitions based on combinations of dimensions, we use category and time, so that currenct year actuals has the most granular partitions and all historic years budgets go into a single partition.

Export table data in a flat file without using FL

Hi,
I am looking for options where I can export table data into a flat file without using FL(File Layout) i.e., by using App Engine only.
Please share your experience if you did anything as this
Thanks

A simple way to export any record (table/view) to an csv fiel, is to create a rowset and loop through all record fields, like below example code
Local Rowset &RS;
Local Record &Rec;
Local File &MYFILE;
Local string &FileName, &strRecName, &Line, &Seperator, &Value;
Local number &numRow, &numField;
&FileName = "c:\temp\test.csv";
&strRecName = "PSOPRDEFN";
&Seperator = ";";
&RS = CreateRowset(@("Record." | &strRecName));
&RS.Fill();
&MYFILE = GetFile(&FileName, "W", %FilePath_Absolute);
If &MYFILE.IsOpen Then
   For &numRow = 1 To &RS.ActiveRowCount
      &Rec = &RS(&numRow).GetRecord(@("RECORD." | &strRecName));
      For &numField = 1 To &Rec.FieldCount
         &Value = String(&Rec.GetField(&numField).Value);
         If &numField = 1 Then
            &Line = &Value;
         Else
            &Line = &Line | &Seperator | &Value;
         End-If;
      End-For;
      &MYFILE.WriteLine(&Line);
   End-For;
End-If;
&MYFILE.Close(); You can of course create an application class for generic calling this piece of code.
Hope it helps.
Note:
Do not come complaining to me on performance issues ;)

Transaction data can be loaded into the Fact table without loading the

Transaction data can be loaded into the Fact table without loading the corresponding master data (Example : Sales analysis transaction data can be loaded without populating any of its dimensions master data)
a. True
b. False

Hi Kutti,
True - You need to select the option in the infopackage - alwyas load even if no master data exists.
Bye
Dinesh

SSAS .abf file without partitions of fact table

Similar Messages

Maybe you are looking for