«We has prepared a short survey for identifying gaps in Smartview for Planning for an upcoming release. We would like to have your opinion and suggestions, so could you please fill out this survey? It takes a few moments…»
get Oracle SmartView plugin
Поймал нехороший баг.
Если значения SmatView в разделе Formating->Scale имеют любое другое значение , кроме как Default то тогда числа , которые не имеют целой части , отображаются разделенными на 100 .
Т.е. вместо 0.1 получаем 0.001
Thank for Pete for excellent explanation:
– Reduce cluster and dimensional irrelavance
– Faster (though with a bigger impact in BSO cubes)
– Generally easier to build reports from
– Increased maintenance
– Bringing data inbetween cubes has a performance hit (and is required to keep all the data up to date)
– Training and change impact to teach users what they all do
– Data is all in one spot
– Users have a single cube to report from, easier to train
– One spot to maintain metadata (particularly scenarios etc)
– Decreased maintenance
– Lots of dimensional irrelavance can make it ‘tricky’ to find data
– This generally requires the developers to be very careful with consolidation operators to make sure users aren’t seeing weird things like KPIs consolidating into the balance sheet
– Performance impacts (even in ASO, defining aggregate views is generally less efficient)
– Can be confusing for ad hoc reporting
Because I live in the BSO world most of the time I’m much more of the ‘split cubes up for functionality’. Once you’ve got a layer of complexity in business function, writing the code can be tricky enough without having multiple dimensions to play in. And in BSO, adding dimensions generally starts creating a performance overhead that is problematic.
However, with the big push of the cloud (and aa requirement to effectively squeeze a lot of functionality into 3 BSO cubes) we’re seeeing a lot more consolidation. Fortuantly the advent of Hybrid has made a lot of those performance downsides significantly easier to manage. Obviously in an ASO layer you’re going to get away with much more in the way of dimensional depth and pure dimension count.
So yeah. It’s really a case by case basis. Important things to consider:
– Complexity of business requirements
– knowledge and availability of the business to support a more complex implementation
– Performance requirements
upd : also need always mention what Essbase have only one thread for reading and committing data to the disk per one application
Интересный нежданчик нашел в WP Oracle
Угадайте где Oracle рекомендует делать консолидацию и эллиминацию ? –
Oracle’s Large-Scale Essbase Implementation:
Replacing Oracle Financial Analyzer with Global, Performant
Financial Consolidation and Reporting