473,855 Members | 1,910 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

yipeee!


Just recieved a 'thought experiment' assignment from my boss.
Does it make sense, and how would it be accomplised, to move
the databases from the mainframe (small VSE 390?) to AIX?
I mentioned that we should then look at possible programs from
IBM to convert the mainframe database (VSAM?) files into DB2/AIX,
or Oracle databases. And that I thought Oracle had some facility
such that we could cluster and load-balance two+ nodes running
something like Parallel Oracle so that should a node need booting
or modifying off-line the application is still running (at
reduced capacity) for the users.

Thoughts?

Mike
Nov 12 '05
95 5385
In article <bv**********@h anover.torolab. ibm.com>, Serge Rielau wrote:
OK, so you need HA. What else?
Any specific SQL Features?
What's your companies strategie for App development? Java, .Net, both?
Any OS/Hardware preference?
What's you companies DB skillset in house?

Cheers
Serge


Since the current system is in VSAM, then no specific SQL features are
mentioned. The app development is now performed on this system in
COBOL, though over time I expect it to be C. The unix far is all AIX.
We have a DBA and several other people with RDBMS experience.

Mike
Nov 12 '05 #51
In article <bv**********@h anover.torolab. ibm.com>, Serge Rielau wrote:
My DB2 "offer" would be DB2 without DPF on two AIX boxes (OP wants AIX
it seems). The seoncd box licenced as idle standby only (1 CPU).
With clusterware to handle the failover.
This is under the assumption that a rewrite of the app to a relational
DBMS is intended.
There is not enough information to home in on which edition or box-size
to home in to.

It seems Mark A. believes CICS would be less invasive. I'm not familiar
with either VSE or CICS so I keep my mouth shut.

Let's presume 100% scalability for RAC (if you want to use it) for the
sake of math (and to not start another flame war) and similar resource
requirements (AIX, RAM/box, comparable disk overall).

Your turn
Serge


Yes, AIX and I'm thinking of 2-4 p650 with 8 cpu and 8gb running disk
off an ESS (shark). Instead of HACMP I'm looking for something where I
can take a node out of the 'cluster' for maintenance, etc., then
re-insert it back into the cluster and it will 'catch up' on the changes
it missed.

For a phased approach I'm thinking
- move entirely to CICS/AIX
- move the VSAM to DB2 on the AIX box
- use the CICS interfaces for the existing programs to reach DB2
outside of CICS
- over time re-write the CICS applications to run native AIX
Nov 12 '05 #52
Database Guy wrote:
Daniel seems to think otherwise. He clearly feels that Oracle's
allegedly faster recover from node failures outweighs its
less-than-half-speed RAC performance under BAU circumstances (i.e.
nodes working). I can't understand why Oracle nodes crash so much, but
it's not a product I know well. Hopefully someone else will explain.
DG


I don't think nodes crash often: But all hardware, all operating
systems, all platforms, and all software does have problems from
time-to-time. Reading your post someone with little or no experience
might be tempted to believe that somehow one vendor's RDBMS is more
likely to cause a CPU to die than another's: Pure nonsense. All machines
lose CPUs. All machines lose RAM. Computers are not perpetual motion
machines. And downtime has a real cost in $.

If you truly believe that hardware never crashes I presume you also
don't do nightly backups. In other words ... thanks for the hyperbole.

And if you truly believe that in the real-world RAC scaling at 128 nodes
gives less than 50% of the performance of shared nothing scaling at 128
nodes I have some stocks and bonds I'd like to sell you.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

Nov 12 '05 #53
dba
Then where are the benchmarks and real customer references to prove it?
Where are the examples of this wonderful technology displacing NCR and
IBM shared nothing implementations because it scales better?

I'll take the stocks and bonds.

DBA

Daniel Morgan wrote:
Database Guy wrote:
Daniel seems to think otherwise. He clearly feels that Oracle's
allegedly faster recover from node failures outweighs its
less-than-half-speed RAC performance under BAU circumstances (i.e.
nodes working). I can't understand why Oracle nodes crash so much, but
it's not a product I know well. Hopefully someone else will explain.
DG

I don't think nodes crash often: But all hardware, all operating
systems, all platforms, and all software does have problems from
time-to-time. Reading your post someone with little or no experience
might be tempted to believe that somehow one vendor's RDBMS is more
likely to cause a CPU to die than another's: Pure nonsense. All machines
lose CPUs. All machines lose RAM. Computers are not perpetual motion
machines. And downtime has a real cost in $.

If you truly believe that hardware never crashes I presume you also
don't do nightly backups. In other words ... thanks for the hyperbole.

And if you truly believe that in the real-world RAC scaling at 128 nodes
gives less than 50% of the performance of shared nothing scaling at 128
nodes I have some stocks and bonds I'd like to sell you.


Nov 12 '05 #54
Sigh.

Check out the #1 result at
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
For RAC references go to
http://www.oracle.com/ultrasearch/ww...=7&p_Query=RAC

Did you actually even attempt to look for yourself ?

dba wrote:
Then where are the benchmarks and real customer references to prove
it? Where are the examples of this wonderful technology displacing NCR
and IBM shared nothing implementations because it scales better?

I'll take the stocks and bonds.

DBA

Daniel Morgan wrote:
Database Guy wrote:
Daniel seems to think otherwise. He clearly feels that Oracle's
allegedly faster recover from node failures outweighs its
less-than-half-speed RAC performance under BAU circumstances (i.e.
nodes working). I can't understand why Oracle nodes crash so much, but
it's not a product I know well. Hopefully someone else will explain.
DG


I don't think nodes crash often: But all hardware, all operating
systems, all platforms, and all software does have problems from
time-to-time. Reading your post someone with little or no experience
might be tempted to believe that somehow one vendor's RDBMS is more
likely to cause a CPU to die than another's: Pure nonsense. All
machines lose CPUs. All machines lose RAM. Computers are not
perpetual motion
machines. And downtime has a real cost in $.

If you truly believe that hardware never crashes I presume you also
don't do nightly backups. In other words ... thanks for the hyperbole.

And if you truly believe that in the real-world RAC scaling at 128 nodes
gives less than 50% of the performance of shared nothing scaling at 128
nodes I have some stocks and bonds I'd like to sell you.


Nov 12 '05 #55
"Mark Townsend" <ma***********@ oracle.com> wrote in message
news:40******** ******@oracle.c om...
Sigh.

Check out the #1 result at
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
For RAC references go to
http://www.oracle.com/ultrasearch/ww...=7&p_Query=RAC
Did you actually even attempt to look for yourself ?

Sigh. Again, just like with Daniel, we have failure here to understand the
difference between a data warehouse application and an OLTP application.

The TPC-C benchmarks referred to above are for OLTP, which does not benefit
from parallel database access to support complex decision support queries.
What the TPC-C benchmark measures is the ability to process multiple
transactions at one time, but each transaction is of an OLTP nature
efficiently access small portions of each table.

That is completely different from the TPC-H Benchmark that measures the
ability to process a small number of queries that typically access data from
an entire table (or tables), and benefit by accessing that data in parallel.
TPC-H (formally TPC-D) is why parallel databases (and specifically share
nothing parallel databases) were invented.

The weakness and lack of LINEAR scalability of the Oracle implementation
does not show in an OLTP environment such as TPC-C, regardless the number of
simultaneous users that are accessing the data a one time. Of course for the
person that started this thread, their primary interest (and maybe only
interest) is in OLTP processing with failover capabilities.

But there are much bigger fish to fry regarding the existing COBOL, CICS,
VSAM, etc.application before one worries about the technical merits of
Oracle vs. DB2.
Nov 12 '05 #56
Ask your favorite IBM Rep about "HADR".

Cheers
serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #57
Mark A wrote:
"Mark Townsend" <ma***********@ oracle.com> wrote in message
news:40******** ******@oracle.c om...
Sigh.

Check out the #1 result at
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
For RAC references go to

http://www.oracle.com/ultrasearch/ww...=7&p_Query=RAC
Did you actually even attempt to look for yourself ?


Sigh. Again, just like with Daniel, we have failure here to understand the
difference between a data warehouse application and an OLTP application.


I understand perfectly. I am not confused. I know exactly what each
product is capable off, down to the nth degree. It's my job to know, and
I'm very,very good at my job.

The TPC-C benchmarks referred to above are for OLTP, which does not benefit
from parallel database access to support complex decision support queries.
Exactly right. Still no confusion here
What the TPC-C benchmark measures is the ability to process multiple
transactions at one time, but each transaction is of an OLTP nature
efficiently access small portions of each table.
Exactly right. Still no confusion here
That is completely different from the TPC-H Benchmark that measures the
ability to process a small number of queries that typically access data from
an entire table (or tables), and benefit by accessing that data in parallel.
Right again. Still no confusion here
TPC-H (formally TPC-D) is why parallel databases (and specifically share
nothing parallel databases) were invented.
Ok - here is where it breaks down. Shared nothing parallelism al la UDB
and Teradata is just one way to do TPC-H. I believe that you yourself
identified that big SMP is also now a completely viable approach to
TPC-H (and the TPC-H benchmarks and Richard Winter VLDB survey also tend
to show this). Anyhow, this is taking us even further off-topc, so lets
drop it

The weakness and lack of LINEAR scalability of the Oracle implementation
does not show in an OLTP environment such as TPC-C, regardless the number of
simultaneous users that are accessing the data a one time. Of course for the
person that started this thread, their primary interest (and maybe only
interest) is in OLTP processing with failover capabilities.
Thank You. My point entirely. We ARE talking OLTP and HA. RAC is
completely in line with the original OPs requirements. Shared nothing,
NCR and TPC-H have absolutely nothing to do with what is being
discussed. So why do the IBM proponents keep bringing it up ad nausem ?
Here's how the dialogeue went.

OP: I want a low cost multi-node HA environment for OLTP. Like what
Oracle does

IBM: IBM has a better parallel shared nothing architecture (and will
be easy to migrate to).

Daniel: Of course it does, but it's not relevant for the requirements.
RAC is relevant. TAF may be relevant too (Note that this is Daniels
opininion about shared nothing, btw)

IBM: Parallel DB2 has had this function for years

Mark A: Daniel, You are confused, RAC and Parallel DB2 are two different
things. RAC does failover. Accusations of propoganda fly. (note - Mark A
does not point out the confusion in IBM, it's Daniel thats confused)

Daniel: I'm not confused. RAC is what the OP does. And RAC does two
things - failover and scale out

Database Guy: Daniel, You are confused. Where are the RAC scale out
numbers/references that compare to IBMs and Teradata's shared nothing
implementation ?

Me: What has this got to do with the topic. These are the wrong things
to be asking. Instead, what you should have asked was where are the
scale out and HA numbers and references that are relevant to the OP's
palnned usage of RAC. This is what I provided.

Mark A: You are confused....
I know Daniel rattles your cage on times, but I do not believe he was
every confused about what he was saying or proposed. It seemed people
just wanted to take him out of context and pick a fight.

But there are much bigger fish to fry regarding the existing COBOL, CICS,
VSAM, etc.application before one worries about the technical merits of
Oracle vs. DB2.


Exactly. Note however that Oracle does support COBOL ESQL, CIC's and
DRDA access.

Nov 12 '05 #58
Mark A wrote:
"Mark Townsend" <ma***********@ oracle.com> wrote in message
news:40******** ******@oracle.c om...
Sigh.

Check out the #1 result at
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
For RAC references go to

http://www.oracle.com/ultrasearch/ww...=7&p_Query=RAC
Did you actually even attempt to look for yourself ?

Sigh. Again, just like with Daniel, we have failure here to

understand the difference between a data warehouse application and an OLTP application.

I understand perfectly. I am not confused. I know exactly what each
product is capable off, down to the nth degree. It's my job to know, and
I'm very,very good at my job.

The TPC-C benchmarks referred to above are for OLTP, which does not benefit from parallel database access to support complex decision support queries.
Exactly right. Still no confusion here
What the TPC-C benchmark measures is the ability to process multiple
transactions at one time, but each transaction is of an OLTP nature
efficiently access small portions of each table.

Exactly right. Still no confusion here
That is completely different from the TPC-H Benchmark that measures the
ability to process a small number of queries that typically access data from an entire table (or tables), and benefit by accessing that data in parallel.
Right again. Still no confusion here
TPC-H (formally TPC-D) is why parallel databases (and specifically share
nothing parallel databases) were invented.

Ok - here is where it breaks down. Shared nothing parallelism al la UDB
and Teradata is just one way to do TPC-H. I believe that you yourself
identified that big SMP is also now a completely viable approach to
TPC-H (and the TPC-H benchmarks and Richard Winter VLDB survey also tend
to show this). Anyhow, this is taking us even further off-topc, so lets
drop it

The weakness and lack of LINEAR scalability of the Oracle implementation
does not show in an OLTP environment such as TPC-C, regardless the number of simultaneous users that are accessing the data a one time. Of course for the person that started this thread, their primary interest (and maybe only
interest) is in OLTP processing with failover capabilities.

Thank You. My point entirely. We ARE talking OLTP and HA. RAC is
completely in line with the original OPs requirements. Shared nothing,
NCR and TPC-H have absolutely nothing to do with what is being
discussed. So why do the IBM proponents keep bringing it up ad nausem ?
Here's how the dialogeue went.

OP: I want a low cost multi-node HA environment for OLTP. Like what
Oracle does

IBM: IBM has a better parallel shared nothing architecture (and will
be easy to migrate to).

Daniel: Of course it does, but it's not relevant for the requirements.
RAC is relevant. TAF may be relevant too (Note that this is Daniels
opininion about shared nothing, btw)

IBM: Parallel DB2 has had this function for years

Mark A: Daniel, You are confused, RAC and Parallel DB2 are two different
things. RAC does failover. Accusations of propoganda fly. (note - Mark A
does not point out the confusion in IBM, it's Daniel thats confused)

Daniel: I'm not confused. RAC is what the OP does. And RAC does two
things - failover and scale out

Database Guy: Daniel, You are confused. Where are the RAC scale out
numbers/references that compare to IBMs and Teradata's shared nothing
implementation ?

Me: What has this got to do with the topic. These are the wrong things
to be asking. Instead, what you should have asked was where are the
scale out and HA numbers and references that are relevant to the OP's
palnned usage of RAC. This is what I provided.

Mark A: You are confused....
I know Daniel rattles your cage on times, but I do not believe he was
every confused about what he was saying or proposed. It seemed people
just wanted to take him out of context and pick a fight.

But there are much bigger fish to fry regarding the existing COBOL, CICS,
VSAM, etc.application before one worries about the technical merits of
Oracle vs. DB2.


Exactly. Note that Oracle does support COBOL ESQL, and both CIC's and
DRDA access via Gateways.
Nov 12 '05 #59
"Mark Townsend" <ma***********@ comcast.net> wrote in message
<snip>
Exactly. Note that Oracle does support COBOL ESQL, and both CIC's and
DRDA access via Gateways.

I think you mean CICS. I know that Oracle supports CICS on OS/390, but does
it support CICS and COBOL on RS/6000 or other UNIX box that CICS may run on?

The originator of this thread (Mike) is thinking of picking up the entire
OS/390 application and running it on UNIX, probably converting the VSAM to
an RDMS (at least as a first step), but keeping the COBOL and CICS. There is
no DRDA access via a Gateway in such an architecture.

BTW, I may be getting a little ornery at Daniel's trolling on this forum,
but I can assure you that I am not confused.
Nov 12 '05 #60

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

48
8467
by: Luca Pinasco | last post by:
Hello I think I resolved a lot of things about this component that before didn't function correctly... I don't know, if you are interested on this...anyway, I can send the project to people ask for this...(maybe I'll put this on a blog in future...) I list all changes I made...: -Resolved the problem, that you couldn't burn or erase more than once(problem about imapi)
0
11044
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10692
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10767
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10375
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9526
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7084
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5754
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
4168
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3194
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.