Why does it take logner for en Execution-job to run when trigged manually as compare to when it runs on schedule?
I have an execution job which runs in 8 mins on schedual. When i run it manually it takes 16-25 minutes to run.
I have a couple of supernatural keys in my keystore in DSA. There has been a change in a table that creates one of these keys. The question is: When an execution package is run, does it also updates the supernatural key?
Lets say my supernatural key is based on ACCOUNT_NR and CLIENT_ID. Someone in the accounts deparment changes the ACCOUNT_NR column. What is the recocmended method to update my supernatural key?
If i reset a supernatural keys, is it enough to just deply that key and then execute and deploy the tables that key is used in, or do i have to deploy the whole keystore?
Page 2 / 2
Dear @aftabp ,
Great that I worked for you. but please be advised that thurning on the ‘ only read from store’ in the dimension table is not the best practice on doing this. The way to do this is set the fact tables to ‘Only read from the store’ and have this option deselected in the dimension. The Dimensions are always the ‘master’ table in these cases. If you have multiple fact tables than both fact tables should be ‘ Only read from the store’.
The only time you might want to consider deselecting the fact table from ‘ Only read from store’ is when you know you have early arriving facts.
Hope this helps
= Daniel
@daniel Thank you for pointing out. It is infact checked on FACT table and not DIM.
I am still unsure why it has stopped working suddenly. It has worked fine all the time
@rory.smith and @Christian Hauggaard
I have a follow up question before i go ahead and make changes in PROD.
I have guarded (on deploy and execution) the table in ODX because its has 9.6 million static rows from a retired source.
Would it have any effect on the SNKs if i also guard (on deploy and execute) the table in DSA?
The table is futher used in MDW together with two other tables. All have the same SNKs but FACT_TABLE_B and FACT_TABLE_C are not guarded becasue the source is updated daily.
Hi,
if the supernatural key fields in the guarded table are correctly populated and you never need to regenerate the keystore, you could guard that table. Note that as you are using incremental load on the fact table, you should ensure that any lookups into the table from other tables will require those tables to be type 1 historical to prevent issues when records in those tables are deleted. This also goes for the fact tables you will continue to load.
Any changes to the supernatural key setup, or hash settings or similar will require you to unguard and reload the table to avoid the wrong key values being used.
@rory.smith
As for now the SNK are correctly populated. I have tested and varified.
Since the table i am refering to is static i am considering changing it from incremental to non-incremantal, since it will not get any new data. There are some look-up columns from other tables that are also static and are non-incremental.
