[quote1256139636=Keeripes!]
Are you developing an algorithm for a certain hardware configuration, or adapting/creating algorithm to streamline your current config or a general software package?
I lack the linchpin, the crux, my good sir... I lack context.
Once again, you introduce to me a new concept which for some reason I decide to go research instead of studying for my midterm du jour. End up with more questions than I start with.
If you are developing some sort of hot new code, please send all documentation to me
K. Herpez
1337 Noob Avenue
TB
Canada
7I7 5UK
so I may:
1) Learn Leroy's Secrets
2) Whiteout and replace his name on the patent paper
3) ???????
4) $$$PROFIT$$$$
[/quote1256139636]
Context:
OLTP -> ODS -> OLAP
We are updating our ODS every 15 minutes from our OLTP system. We have a functional requirement to return claims information in under 2 secs, so we need a light method of copying data from our OLTP to ODS. We use Oracle's CDC to capture the changes and provide a view. From there, I come in, pull these changes, and push them into our ODS.
I designed the "algorithm" from the standpoint, of how to pull/push the data, and coded it (yay plsql), optimized the ODS system for the data, and whammo, was getting reported times. Its actually not a lot of data that we're moving (besides row count), however, we have to maintian referential integrity, and most importantly security (the data must not leave our Oracle)
Anyways, pseudo code documentation as follows.
1. Disable target table constraints
2. Disable target table indices
3. bulk collect all data for a given range from the source CDC tables (that is, the data that has changed), and store in a memory structure.
4. "push" (Best way to describe it, really), all in one go
5. Enable table constraints
6. Rebuild indices
So, this is how your average DBA with a coding background would do it.
However, I am not your average DBA, and my coding background is... ahem.. extensive
So I started pulling out some crazy times, by multi-threading the data push mechanism. I fired up C# (Only because it was on my computer, and didn't really want to jump through teh hoops to make C++ work nicely with Oracle) and each thread sends the range of data in its own process. Also, the session is not shared between threads. Playing around with thread counts, I found it performed best with 3-4 threads, although I came close with around 10 threads. I think this is just the nature of the dev system, and the limitations of the Oracle latching mechanism.
Its so enjoyable, I think I might whore myself out on a couple contracts for data movement.