Difference between ORABULK stage and RBDLOAD stage

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
dprasanth
Charter Member
Charter Member
Posts: 90
Joined: Fri Oct 07, 2005 7:55 am

Difference between ORABULK stage and RBDLOAD stage

Post by dprasanth »

Hi,
I was trying to bulk load a file with 5 million records.First thought I will do it by unix command line sqlldr command. Then since datastage has that facitlity I thought I will use that. I went through the help files which mentions to use ORABULK stage. But what we have is RED BRICK stage. Is there any difference between them or both are one and the same.
Thanks in Advance
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

No, they are not one and the same - they perform similar functions, but for two totally different databases. So, if your target is Oracle you could use the ORABULK stage. Similarly, if your target is Red Brick you could use the RDBLOAD stage.

Stick with command line sqlldr. Just because you've got a stage that does something doesn't mean it's the best way to do that something. :wink:
-craig

"You can never have too many knives" -- Logan Nine Fingers
dprasanth
Charter Member
Charter Member
Posts: 90
Joined: Fri Oct 07, 2005 7:55 am

Post by dprasanth »

chulett wrote:No, they are not one and the same - they perform similar functions, but for two totally different databases. So, if your target is Oracle you could use the ORABULK stage. Similarly, if your target is Red Brick you could use the RDBLOAD stage.

Stick with command line sqlldr. Just because you've got a stage that does something doesn't mean it's the best way to do that something. :wink:
Thanks for the clarification
dprasanth
Charter Member
Charter Member
Posts: 90
Joined: Fri Oct 07, 2005 7:55 am

Post by dprasanth »

chulett wrote:No, they are not one and the same - they perform similar functions, but for two totally different databases. So, if your target is Oracle you could use the ORABULK stage. Similarly, if your target is Red Brick you could use the RDBLOAD stage.

Stick with command line sqlldr. Just because you've got a stage that does something doesn't mean it's the best way to do that something. :wink:
Actually I didn't know that there was a database called Redbrick. That is why I had a doubt between those two stages. Just now found out that Redbrick is a database from IBM for business Intelligence application. Thank you so much for the guidance
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

No problem. You'll find there are alot of IBM peoples who don't know there is such a thing as Redbrick, too! :lol:
-craig

"You can never have too many knives" -- Logan Nine Fingers
kcbland
Participant
Posts: 5208
Joined: Wed Jan 15, 2003 8:56 am
Location: Lutz, FL
Contact:

Post by kcbland »

IBM only owns Redbrick because they acquired Informix, who only owned Redbrick, because they acquired it from Ralph Kimball.
Kenneth Bland

Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Red Brick should be THE database of choice for star schema designs (data warehouses and data marts) because it was designed from the ground up to do exactly that. By Ralph Kimball, acknowledged as one of the masters of data warehousing theory and practice.

Red Brick is not a transactional database. One of its performance secrets is the amount of stuff it doesn't have in it. Another is the ability to create an index over multiple tables, so that joins can be resolved in the index; by this means sub-second query response times can be had from constrained queries on billion row fact tables joined with several dimension tables. Its bulk loader can use parallel processes to update indexes as the main table's rows are being updated, and still other parallel processes to update aggregate tables automatically.

Another brilliant feature is that it monitors queries that do and could use aggregates, and can recommend that particular aggregate tables ought to be in place. Users don't need to see them; Red Brick automatically rewrites queries to use aggregate tables if appropriate aggregate tables exist.

Finally, because of what it is, Red Brick applies "query priority concurrency". Queries always get precedence over updates. And, if one process is scanning an index or table and another process needs to, the second process will "piggy back" the first, minimizing the amount of work that needs to be done. And there are lots of useful business intelligence functions in its SQL, such as ranking, tiling, moving sum and moving average, and so on.

But, alas, the news hasn't filtered through to the IBM sales dudes, who've been brainwashed into believing that DB2 is the only database the world will ever need. Or is it that the margins on Red Brick aren't nearly so large?

Here endeth the rant.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

We feel your pain, Ray. :cry:
-craig

"You can never have too many knives" -- Logan Nine Fingers
kcbland
Participant
Posts: 5208
Joined: Wed Jan 15, 2003 8:56 am
Location: Lutz, FL
Contact:

Post by kcbland »

Silly little dreamer. :lol: Who says the best product has to win?

Without a doubt, properly modeled and properly adminstrated, Redbrick is phenomenal.
Kenneth Bland

Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Post Reply