database design - Business Reporting on an OLTP Application -

-

we have oltp application using oracle database 10g enterprise edition, , plan build business reporting layer meet following needs.

  • sheilding complexity of current oltp database design
  • improving query performance of current oltp reports
  • providing read-only access other applications
  • allowing business users perform adhoc reporting

the solution thinking of create db cache layer using oracle materialized views(mv) on current oltp. mv's denormalized , designed reporting. mv log's synchronize changes mv using incremental refresh.

my questions are,

  1. does approach make sense (mv's)? has used mv's building oltp reporting solutions?
  2. what drawbacks of approach(mv)?
  3. how using oracle cdc , tables, procedures perform synchronize.
  4. any other approaches?

thank you, sherry

in general, thinking of either view layer or materialized view layer reporting users. preference unless there concrete performance issues go views eye creating occasional materialized views use query rewrite speed selected reports.

if use materialized views, you'll materializing data second time in format going result in less efficient storage. means of space in system allocated denormalized materialized views , indexes. can generate pretty hefty bill disk vendor , can create contention san resources.

materialized views mean more competition cache space between oltp , reporting users. since they're stored in different objects, reports looking recent activity won't able benefit hot blocks in cache oltp activity , vice versa. can mitigate problem throwing ram @ or moving reporting non-peak times it's not efficient solution. if have exclusively historical reporting, isn't big deal-- there no sharing anyway because processes interested in different blocks-- if have lot of operational reporting, becomes significant.

materialized views less flexible. if want present same data multiple ways, it's materializing multiple times runs real costs both in disk , cache increasing time required periodic refresh of materialized view layer. in practice, tends mean reporting users least common denominator view of data , have re-invent wheel when slice , dice data because doesn't want create new materialized view them.

as said earlier, preference regular view layer. avoids cost of storing data multiple times , makes possible share blocks in cache between oltp , reporting queries. makes relatively easy give users different views of data , eliminates need keep business users informed how stale data they're reporting on is. if , when performance becomes issue because oltp data model doesn't support sorts of queries want run, can create targetted materialized views act indexes via query rewrite. means users can query regular views , dba can later add materialized view generates or part of result , optimizer can change query plan use new materialized view rather scanning table(s) , doing things aggregating data @ runtime.

at point, you'll want move reporting traffic hit real data warehouse more dimensional data model. if find need performance of materialized view layer rather regular view layer, i'd thinking going real data warehouse facts , dimensions. you'll more flexible reporting same etl headaches you'd complete materialized view layer.


Comments

Post a Comment

Popular posts from this blog

javascript - Enclosure Memory Copies -

-
function myclass() { //lots , lots of vars , code here. this.bar = function() { //do numerous enclosed myclass vars } this.foo = function() { alert('hello'); //don't enclosed variables. } } each instance of myclass gets own copy of bar , foo, why prototyped methods use less memory. however, know more memory use of inner methods. it seems obvious me (1) below must true. agree? not distinct myclass instances have own distinct copies of bar, must have own distinct copies of myclass enclosure. (or else how bar method keep myclass variables straight on per instance basis?) now (2) question i'm after. since inner foo method doesn't use in myclass enclosure natural qustion is: javascript smart enough not keep myclass enclosure in memory use of foo? this depend entirely on implementation not language. naive implementations keep far more around others. answer true e.g. v8 (chrome's js engine) may not true spider...
Read more

php - Replacing tags in braces, even nested tags, with regex -

-
example preg_replace('/\{[a-za-z.,\(\)0-9]+\}/', 'replaced', 'lorem ipsum dolor sit {tag1({tag2()})}, consectetur adipiscing elit.'); the result: lorem ipsum dolor sit {tag1(replaced)}, consectetur adipiscing elit. question as can see "tag2" has been replaced, want replace "tag1" know how can this? (in cases might this: {tag1({tag2({tag3()})})}) , on.) btw using preg_replace_callback, easier show preg_replace here site can test code: http://www.spaweditor.com/scripts/regex/index.php you need add curly braces character set. here's pattern used: /\{[a-za-z.,\(\)\{\}0-9]+\}/ and here result: "lorem ipsum dolor sit replaced, consectetur adipiscing elit."
Read more