| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle/VMS performance problems with Multithreaded Server
Getting Oracle to run right on any platform is no easy task. On OpenVMS you have to really know what you are doing and manually edit many configuration files and DCL scripts. I can't help thinking it should not have to be that hard.
The updates really do lag the other platforms and many Oracle products never make it.
One thing, though: Once well set-up, Oracle is rock-solid on OpenVMS, owing mainly to the stability of the o/s. My 8.0.5 installation has an uptime of 313 days and zero hiccups.
Just my $0.02
Gord.
Syltrem <syltrem_at_videotron.ca> wrote in message
news:M%zL5.4882$Zq6.192995_at_wagner.videotron.net...
> I see you are very angry about Oracle and the support you get from them
for
> your OpenVMS installation. Maybe you could direct your complaint to Alan
> Belancik @ compaq. He certainly would like to know that one of
hiscustomers
> is going to drop VMS because one of his partners is not doing his job
right.
>
> Syltrem
>
>
> "I.A. Saez @tue.nl>" <"i.a.saez.<secret> wrote in message
> news:39FE69A4.2DED1146_at_tue.nl...
> > OpenVMS fully supported by Oracle? No way!
> > Here is my list of complaints about Oracle on OpenVMS:
> >
> > - Oracle Apps 11i is not supported on OpenVMS
> > - did you ever try to get Oracle I. Agent working on a OpenVMS system?
> > - MTS doesn't work properly on OpenVMS; even 8.1.6. has the same problem
> > - porting of Oracle products is far behind Unix (some time more than a
> > year)
> > - etc
> >
> > That Oracle is better supported on Unix than OpenVMS is a fact.
> > Statements of direction say nothing to me. They sound like "the very
> > soon now" frases of Microsoft. The daily pratice is what matters to me.
> > I hope that Oracle will support OpenVMS better than in the past, but for
> > us it will be too late and I'm sorry because I find OpenVMS a very good
> > OS.
> >
> >
> > Syltrem wrote:
> > >
> > > Oh! Oh!
> > >
> > > When I read this, it sounded an alarm in my head! How could 7336 be
the
last
> > > "real" version of Oracle on OpenVMS, given the current agreements
between
> > > Oracle and Compaq? And how about the fact that the customer said they
will
> > > move to Unix? Hopefully not only because they think Oracle will be
more
> > > supported on that platform...
> > >
> > > In short, OpenVMS is FULLY supported by Oracle, in details, see the
comment
> > > on that from Alan Belancik, OpenVMS Relationship Manager with Oracle
at
> > > Compaq.
> > >
> > > « As the OpenVMS Relationship Manager with Oracle, I am in a position
to
> > > tell you that our two groups are working very closely together. Our
goal
is
> > > to offer customers high performance solutions that are based on
AlphaServers
> > > running the Oracle database. These have been put to use in many of the
world
> > > 's most mission critical applications requiring extremely high
> > > availability.
> > > «Your question dealt with the nature of the Oracle database and its
> > > applicability to the OpenVMS world. I can assure you that there is a
very
> > > astute team of engineers and managers in place who work on the porting
of
> > > the Oracle database to OpenVMS. These people are very well acquainted
with
> > > the OpenVMS operating system and work to ensure that the products
available
> > > from Oracle take advantage of OpenVMS's unique attributes. Our
pioneering
> > > work in clustering has been reflected in Oracle's Parallel Server
offerings.
> > > Engineers at Oracle have been working on the interplay between new
OpenVMS
> > > technologies, such as the Galaxy Software architecture for dynamic
> > > partitioning, and the new "WildFire" series of AlphaServers, the GS80,
GS160
> > > and GS320.
> > > «True, the porting of the Oracle database begins with a set of common
code,
> > > however once it is released to the various "platform groups" with in
Oracle,
> > > they begin to customize the final product to reflect the features of
that
> > > operating system and hardware combination.
> > > «Unfortunately, there is always some confusion in the field. We at
Digital
> > > Equipment, and now Compaq, have unfortunately contributed to that
confusion.
> > > One item of confusion would be the perceived differences between VMS
and
> > > OpenVMS. Some people have erroneously concluded that VMS is for VAX
systems
> > > and OpenVMS is for AlphaServer systems. Actually, OpenVMS was the new
name
> > > applied to ALL VMS in order to better reflect its adherence to many of
the
> > > world's standards for openness. I mention this because you reference
version
> > > 7.3.3 6 as being the last real VMS version. It is true that Oracle
database
> > > products were not ported to support VAX systems once Oracle made the
> > > transition from their version 7.x products to their 8.x version
products. It
> > > is very close to being correct that version 7.3.3.6 was the last
version
for
> > > VAX systems. However, I do not see how this can be said of AlphaServer
> > > systems running OpenVMS.
> > > «Nonetheless, I will confer with my Oracle colleagues to see if they
can
> > > share any insight into this contention. Naturally, it is in any
company's
> > > best interest to try to standardize the core of their product in order
to
> > > reduce operating expenses. Still, they need to be able to customize
the
> > > final product to best suit the platform it is intended for as well as
> > > optimizing its performance on that platform. We have been working
closely
> > > with the engineers in the porting group and in the performance groups
to
> > > ensure that this is the case.
> > > «We will continue to work with Oracle as our premier database partner.
Our
> > > user surveys show that approximately 88% of our OpenVMS customers who
use a
> > > commercial database use one from Oracle. We will continue to invest in
our
> > > relationship. One benefit that we expect from this relationship is a
product
> > > from Oracle that is best suited for our AlphaServer systems running
> > > OpenVMS..
> > > «Please let me know if more information comes to light or how I can be
of
> > > further assistance. Again, thank you for bringing this information to
our
> > > attention. We share your belief that OpenVMS continues to be one of
the
> > > world's best operating environments - EVER!
> > > Thanks and merci milles fois,
> > > Alan
> > > Alan Belancik
> > > Oracle Relationship Manager
> > > OpenVMS System Software Group
> > > 603-884-0363
> > > fax: 603-884-2006
> > >
> > > "I.A. Saez @tue.nl>" <"i.a.saez.<secret> wrote in message
> > > news:39F91C4B.ECB2555E_at_tue.nl...
> > > > Malcolm,
> > > >
> > > > We have the same problem with Oracle 7.3.4.4 on OpenVMS 7.1. We have
now
> > > > a mix
> > > > of MTS and dedicated connections. Dedicated for long running apps
and
> > > > MTS for short connections. Oracle did investigate the problem and
told
> > > > me it still exists in 8.1.6 for OpenVMS. Oracle 7.3.3.6 was the last
> > > > real VMS version (probably made by VMS especialists).
> > > >
> > > >
> > > > See (some) of ther tar:
> > > >
> > > >
> > > > 27-SEP-00 12:35:39
> > > >
> > > >
> > > >
> > > > 27-SEP-00 13:24:41
> > > >
> > > > To reproduce the slow MTS performance (for development)
> > > > - The following patches are installed here:
> > > > 686524-(Base BUG#544858) ORA-602 RUNNING PRO*C WITH TO_DATE AND
BIND
> > > > VARIABLES.
> > > > 1055554-(Base BUG#553138) ORA-12612 ON W95 CLIENTS AFTER APPLYING
> > > > 520734(430972.
> > > > 1218450-(Base BUG#845454) ORA-1403 REFERRING TO CERTAIN PL/SQL
TABLE
> > > > ELEMENTS.
> > > > 1326425- ORA-1013 when sqlnet.expire_time > 0.
> > > > 1309610-(Base BUG#1021962) MTS SLOW.
> > > > 1326725- Listener/Dispatchers consumes Buffered IO.
> > > > - Used the following MTS parameters in V7.3.4.4 INIT.ORA (OTS14):
> > > >
> > > >
> > > > 27-SEP-00 14:19:34
> > > >
> > > > mts_listener_address =
> > > > "(ADDRESS=(PROTOCOL=tcp)(HOST=nlvms2)(PORT=1521))"
> > > > MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)\
> > > > (HOST=nlvms2)(PORT=5000))(DISPATCHERS=1)"
> > > > MTS_DISPATCHERS="(ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)\
> > > > (HOST=nlvms2)(PORT=5001))(DISPATCHERS=1)"
> > > > mts_servers = 2
> > > > mts_service = ots14
> > > > - Restart the instance --> will register the dispatchers at the
> > > > listener
> > > > - Now within the database using SCOTT:
> > > > - Create a BIGEMP table from EMP with a large number of rows in it
> > > > (I used BIGEMP with 458752 rows) ---> BIGEMP.DMP export file
> > > > - Create two connect aliases, one for MTS (OTS14) and one for
DEDICATED
> > > > server
> > > > (OTS14D) :
> > > > ots14.world =
> > > > (DESCRIPTION =
> > > > (ADDRESS_LIST =
> > > > (ADDRESS =
> > > > (PROTOCOL = TCP)
> > > > (Host = nlvms2)
> > > > (Port = 1521)
> > > > )
> > > > )
> > > > (CONNECT_DATA =
> > > > (SID = ots14)
> > > > (GLOBAL_NAME = ots14.world)
> > > > )
> > > > )
> > > > ots14d.world =
> > > > (DESCRIPTION =
> > > > (ADDRESS_LIST =
> > > > (ADDRESS =
> > > > (PROTOCOL = TCP)
> > > > (Host = nlvms2)
> > > > (Port = 1521)
> > > > )
> > > > )
> > > > (CONNECT_DATA =
> > > > (SID = ots14)
> > > > (GLOBAL_NAME = ots14.world)
> > > > (SERVER = DEDICATED)
> > > > )
> > > > )
> > > > - Create the following test script TEST.SQL
> > > > select to_char(sysdate, 'hh24:mi:ss') from dual;
> > > > set termout off;
> > > > select * from bigemp where ename='KING';
> > > > set termout on;
> > > > select to_char(sysdate, 'hh24:mi:ss') from dual;
> > > > spool a.a
> > > > select count(*) from bigemp;
> > > > spool off;
> > > > select to_char(sysdate, 'hh24:mi:ss') from dual;
> > > > exit
> > > > - and reproduce the problem as follows:
> > > > $ sqlplus scott/tiger_at_ots14d --> dedicated server
> > > > SQL> @test
> > > > 14:08:16 --> start time
> > > > 14:08:55 --> end of query with where clause
> > > > count(*) --> 458752
> > > > 14:09:11 --> end time
> > > > Total elapsed time : 39 seconds for the first part, 16 seconds for
the
> > > > second
> > > > Now with MTS:
> > > > $ sqlplus scott/tiger_at_ots14 --> shared server
> > > > SQL> @test
> > > > 14:12:15 --> start time
> > > > 14:18:12 --> end of query with where clause
> > > > count(*) --> 458752
> > > > 14:18:29 --> end time
> > > > Total elapsed time : 357 (!!) seconds for the first part, 17
seconds
> > > > for the
> > > > second part, a huge difference with DEDICATED connection.
> > > >
> > > >
> > > > 27-SEP-00 15:47:41
> > > >
> > > > .
> > > > Tested with V8.1.6.0 on OpenVMS (same configuration, same data):
> > > > The following patches are installed on this installation:
> > > > patch#1335503 - ORA-1013 on queries when sqlnet.expire_time > 0.
> > > > $ sqlplus scott/tiger_at_ots16d ----> dedicated server
> > > > SQL> @test
> > > > 15:39:41 --> start time
> > > > 15:40:16 --> end of query with where clause
> > > > count(*) --> 458752
> > > > 15:40:29 --> end time
> > > > Total elapsed time : 35 seconds for the first part, 13 seconds for
the
> > > > second part
> > > > Now with MTS:
> > > > $ sqlplus scott/tiger_at_ots16 ----> shared server
> > > > SQL> @test
> > > > 15:45:26 --> start time
> > > > 15:47:34 --> end of query with where clause
> > > > count(*) --> 458752
> > > > 15:47:47 --> end time
> > > > Total elapsed time : 128 seconds for the first part, 13 seconds for
the
> > > > second part
> > > > Conclusion: MTS with V816 is better performing than with V7344 but
> > > > elapsed
> > > > time differs a lot from dedicated server connections.
> > > > Above needs to be transferred to development.
> > > >
> > > >
> > > > 27-SEP-00 17:06:13
> > > >
> > > > Advised customer to not use MTS where elapsed time is impacted and
> > > > database
> > > > links are accessed. Customer will setup prespawned server (although
not
> > > > error free) this evening. AGreed on assisting in tuning such
prespawn
> > > > environment when needed...
> > > >
> > > >
> > > > 27-SEP-00 17:33:19
> > > >
> > > >
> > > >
> > > > 04-OCT-00 12:47:50
> > > >
> > > > Awaiting the results of the case as distributed to development...
> > > >
> > > >
> > > > 12-OCT-00 13:02:28
> > > >
> > > > Problem is reproduced by development and under investigation...
> > > >
> > > >
> > > > 13-OCT-00 15:06:49
> > > >
> > > > Discussed status with customer:
> > > > - Problem is under control as a mix is made with both MTS and
dedicated
> > > > (for the long running jobs) server connections
> > > > - Explained that I do not expect a solution on short term based on
my
> > > > contacts with development. As the problem also reproduces with V816
> > > > I expect the problem to be fixed in a future release (and if
possible
> > > > wil be backported)
> > > > - Customer stated that a move will be made to Unix within the next
half
> > > > year
> > > > === Agreed ===
> > > > We decided to close the problem for now as a 'working' environment
is
> > > > setup
> > > > now. Will update this TAR with the 'internal' developments on this
> > > > matter and
> > > > therefore leave status at 14 'Partner (=development) Action'
> > > >
> > > >
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Ivan Saez
> > > > i.a.saez.scheihing_at_tue.nl
> > > >
> > > > Malcolm Dunnett wrote:
> > > >
> > > >
> > > >
> > > > >
> > > > > I'm running Oracle 8.1.6 on a VMS 7.2 system. I've tried
> > > > > setting up the MultiThreaded server on this system. It works
> > > > > but the performance with my programs is terrible ( queries
> > > > > that take 1 second with a dedicated server process might take 5 or
6
> > > > > with the Multithreaded server, for example ) [ ie all I do
> > > > > to get the performance difference is change the client connect
> > > > > to include a "SERVER=DEDICATED" parameter]. The programs are
> > > > > written using Oracle7 OCI calls, they fetch single rows of
> > > > > data at a time from the database - I realize they could be
> > > > > more efficient using array fetch, but it's never been an issue
> > > > > with dedicated server processes.
> > > > >
> > > > > I realize this is a pretty broad question without more detail,
> > > > > but does anyone have similar experiences ( or alternately, good
> > > > > experiences with the MTS on a VMS system ). Any ideas if there's
> > > > > anything I could do to make MTS useful?
> > > > >
> > > > >
> > >
>
 |
 |