Distributed Sybase Access 
Author Message
 Distributed Sybase Access

Hi I'm using version 4.01 of Sybase and I'm not up on
the newer features. The problem I have now is
forming queries that access multiple different schemas on different
servers. I know I can kludge access with dblib calls but this seems a little
extreme.

Do newer versions of Sybase support distributed queries? Or
is there a way to do it with my current version of Sybase that I
don't know about yet?



Tue, 01 Nov 1994 23:27:26 GMT
 Distributed Sybase Access

|>
|> Hi I'm using version 4.01 of Sybase and I'm not up on
|> the newer features. The problem I have now is
|> forming queries that access multiple different schemas on different
|> servers. I know I can kludge access with dblib calls but this seems a little
|> extreme.
|>
|> Do newer versions of Sybase support distributed queries? Or
|> is there a way to do it with my current version of Sybase that I
|> don't know about yet?

As far as I can tell, there is no new functionality that any of the newer releases have to support distributed queries.  The only functionality now is to use remote procedure calls (RPC's) using stored procedures, but this is mighty limited regarding what it can do.  We have always opted for the db-lib approach.

I have heard rumblings that Sybase was considering doing something to support ditributed queries, but I don't know what.  I do know that when I talked to them about two years ago, they said that they weren't considering it because the optimization issues were too complex and the performance hit would be substantial.  I argued that it was the functionality we needed, performance can wait.  IMHO, to keep constantly having to code around this problem is a cost and time sink.

                                                /Hugh

----These comments are my own, and do not reflect that of my employer.



Wed, 02 Nov 1994 04:40:08 GMT
 Distributed Sybase Access
Quote:
>As far as I can tell, there is no new functionality that any of the newer releases have to support distributed queries.  The only functionality now is to use remote procedure calls (RPC's) using stored procedures, but this is mighty limited regarding what it can do.  We have always opted for the db-lib approach.

The remote stuff is extremely limitted, they can't be used in SQL queries, nor
can the return data be used in any useful way. They are useless except for
poking around.

Quote:
>I have heard rumblings that Sybase was considering doing something to support >ditributed queries, but I don't know what.  I do know that when I talked to them about >two years ago, they said that they weren't considering it because the optimization >issues were too complex and the performance hit would be substantial.  I argued that >it was the functionality we needed, performance can wait.  IMHO, to keep constantly >having to code around this problem is a cost and time sink.

What does Sybase think you should do for enterprise computing? Say you have
n databases spread throughout your company, different admins, different everything,
how are you supposed to share data? I think Sybase is missing the boat on this
one. Using dblib is like steering a plane by wing walking and moving the
flaps by hand. People end up duplicating data and general pissing away a lot
of time doing coding instead of developing. Maybe ingres would be better?

As for optimization I'm with you. If you are doing distributed stuff you
are much more interested in correctness and accessibility than pure speed.

BTW, does APT now use Openwindows or Motif?



Wed, 02 Nov 1994 05:11:51 GMT
 Distributed Sybase Access


   |>
   |> Hi I'm using version 4.01 of Sybase and I'm not up on
   |> the newer features. The problem I have now is
   |> forming queries that access multiple different schemas on different
   |> servers. I know I can kludge access with dblib calls but this seems a little
   |> extreme.
   |>
   |> Do newer versions of Sybase support distributed queries? Or
   |> is there a way to do it with my current version of Sybase that I
   |> don't know about yet?

FYI:  Interbase permits DB operations on multiple DBs (dissimilar schemas OK)
on different servers within a single, controllable transaction context.  Note
that this does NOT mean that a _single_ query can access multiple DBs.
--
"Usually this is a couple of lines." -Well paid consultant.



Fri, 04 Nov 1994 20:23:10 GMT
 Distributed Sybase Access
 The reason that NONE of the RDBMS's support joins across servers located
on different physical machines is because it is complex and the network
bandwidth is currently unavailable. I don't imagine that network bandwith
will come close enough to the BUS speed that ANY product will allow this
any form other than a kludgy token effort.

warren

PS this has nothing to do w/ dblib.
--
warren finnerty      | 388 Grennwich St.
Lehman Brothers      | NYC NY 10013



Sat, 05 Nov 1994 01:08:03 GMT
 Distributed Sybase Access
Quote:
> The reason that NONE of the RDBMS's support joins across servers located
>on different physical machines is because it is complex and the network
>bandwidth is currently unavailable. I don't imagine that network bandwith
>will come close enough to the BUS speed that ANY product will allow this
>any form other than a kludgy token effort.
>PS this has nothing to do w/ dblib.
>--

Isn't this like throwing the baby out with the bath water? Programmers
fake joins using dblib all the time. Doesn't seem hard to me.
Besides most of what I want to do in a distributed environment are not joins,
but are simple master/detail queries. To not have distibuted queries seems to
ingnore the development and production environment we live in today. Let people
have the power, tell them the consequences, then let them decide.


Sat, 05 Nov 1994 03:26:25 GMT
 Distributed Sybase Access

Quote:



>    |>
>    |> Hi I'm using version 4.01 of Sybase and I'm not up on
>    |> the newer features. The problem I have now is
>    |> forming queries that access multiple different schemas on different
>    |> servers. I know I can kludge access with dblib calls but this seems a little
>    |> extreme.
>    |>
>    |> Do newer versions of Sybase support distributed queries? Or
>    |> is there a way to do it with my current version of Sybase that I
>    |> don't know about yet?

> FYI:  Interbase permits DB operations on multiple DBs (dissimilar schemas OK)
> on different servers within a single, controllable transaction context.  Note
> that this does NOT mean that a _single_ query can access multiple DBs.
> --
> "Usually this is a couple of lines." -Well paid consultant.

How do you define a single query?

In InterBase, if you have two databases readied as A and B, you can put
  for a.customers cross b.invoices over cust_no etc...
and combine relations from two different databases.  Isn't this a single
query??

Graeme



Sat, 05 Nov 1994 03:11:17 GMT
 Distributed Sybase Access

Quote:

> The reason that NONE of the RDBMS's support joins across servers located
>on different physical machines is because it is complex and the network
>bandwidth is currently unavailable. I don't imagine that network bandwith
>will come close enough to the BUS speed that ANY product will allow this
>any form other than a kludgy token effort.

>warren

>PS this has nothing to do w/ dblib.
>--
>warren finnerty      | 388 Grennwich St.
>Lehman Brothers      | NYC NY 10013


Oracle has been able to do distributed joins since 1984, in version 5.1.
Though the old optimizer wasn't aware of data distributions, you could
still get good performance over a reasonable network. The new query
optimizer IS knowledgable of data statistics on remote nodes, and will
do the right thing most of the time. Oracle has LOTS of sites doing
distributed queries, with excellent performance.

In Oracle, a single SQL Statement can reference tables on any arbitrary
number of nodes, and in fact with Oracle's location transparency the
developer/end user does not need to do anything special to accomplish this.
With Oracle SQL*Connect, remote tables living in DB2/IMS/Tandem/Whatever
can also be included in distributed transactions.

- Dan

Daniel Druker
Senior Consultant
Oracle Corporation

-------------------------------------------------------------------------------
| Dan Druker                    |  work 415.506.4803                          |

-------------------------------------------------------------------------------

Disclaimer:  These are my opinions and mine alone, and don't reflect the
views or position of my employer.



Sat, 05 Nov 1994 08:12:30 GMT
 Distributed Sybase Access

Quote:

> The reason that NONE of the RDBMS's support joins across servers located
>on different physical machines is because it is complex and the network
>bandwidth is currently unavailable. I don't imagine that network bandwith
>will come close enough to the BUS speed that ANY product will allow this
>any form other than a kludgy token effort.

>warren

>PS this has nothing to do w/ dblib.
>--
>warren finnerty      | 388 Grennwich St.
>Lehman Brothers      | NYC NY 10013


- Dan

Daniel Druker
Senior Consultant
Oracle Corporation

-------------------------------------------------------------------------------
| Dan Druker                    |  work 415.506.4803                          |

-------------------------------------------------------------------------------

Disclaimer:  These are my opinions and mine alone, and don't reflect the
views or position of my employer.



Sat, 05 Nov 1994 08:02:58 GMT
 Distributed Sybase Access
The way we do it is through nested for loops.

i.e

for a1 in li_0.relation1 with /* ... */
        for b2 in qli_1.relation2 with
                b2.key =  a1.key and /* */
print /* Whatever */


These are my opinions ONLY!!!



Sat, 05 Nov 1994 23:11:16 GMT
 Distributed Sybase Access

(Warren Finnerty) writes

Quote:
>  The reason that NONE of the RDBMS's support joins across servers located
> on different physical machines is because it is complex and the network
> bandwidth is currently unavailable.

actually, a bunch of rdbms' support distributed joins, including commercial
systems like oracle and research systems like gamma at u wisc.

                                        mike olson
                                        postgres research group
                                        uc berkeley



Sat, 05 Nov 1994 23:50:38 GMT
 Distributed Sybase Access
Quote:


>(Warren Finnerty) writes

>>  The reason that NONE of the RDBMS's support joins across servers located
>> on different physical machines is because it is complex and the network
>> bandwidth is currently unavailable.

>actually, a bunch of rdbms' support distributed joins, including commercial
>systems like oracle and research systems like gamma at u wisc.

>                                    mike olson

What about updating joins. Does any system support at least local join updates?

vijay

--
===============================================================================
Vijay Raghavan                     | We can sort things out together.
Dept of Comp Sc                    |
Rensselaer Polytechnic Institute   | Ph:(518)-276-4838  



Sat, 05 Nov 1994 23:59:13 GMT
 Distributed Sybase Access

If one wants to distribute SYBASE across servers:

  Buy open-server.
  Write an application to "fake" joins etc.

Network speed is VERY slow compared to BUS speed so your
unthinking application programmers will run rough-shod
all over it and {*filter*} endlessly about "unpredictable"
query performance. If one wants a master detail type
query I don't see why rpc's with output parameters
might not be able to solve that problem.

This thread concerns an issue that we will hear more and
more of and I doubt if any armchair sales-speak will
provide a workable solution. The flexiblity of SQL
to join any item to any other item runs in direct conflict
with putting data on systems in such a way that many joins
are no do-able in any production sense. I would not like
to be the person tell upper mgmt that certain functionality
cannot be delivered because nobody envisioned joining data
from A and B in such a way. RDBMS have made application
programmers much fleeter of foot and DBA's must be very careful
when designing the physical layout of a system. Thats my $0.02
worth.  :-)
--
warren finnerty      | 388 Grennwich St.
Lehman Brothers      | NYC NY 10013



Sun, 06 Nov 1994 00:26:08 GMT
 Distributed Sybase Access
( DISCLAIMER UP FRONT:  this posting refers to work that was done at
Sun but should not be taken to represent any Sun policy, position,
or opinion and in NO way is to be regarded as a product announcement.
Nor does this have anything to do with my current employment at Dell;
I just found this thread interesting and thought I'd toss in my $0.02
anecdote. )

Quote:

>If one wants to distribute SYBASE across servers:

>  Buy open-server.
>  Write an application to "fake" joins etc.

This is fine for relatively small applications, but poor for very large
OLTP applications.  You have to be *REALLY* good to do an OpenServer
gateway which doesn't quickly become a serious bottleneck.  When I
was at Sun, we had to deal with this issue;  we talked to the Sybase
developers, surveyed commercially available apps, and finally gave up
and rolled our own.  We ended up with a system that would support several
hundred widely dispersed (across US, T1 lines) users with excellent
transaction response times over multiple (3-5) Sybase dataservers with
replicated tables.  

There should be a paper coming out about it sometime soon...  the app
was an internal IS application for doing service call management, and
is used to manage Sun's hardware and software support business.  Anyway,
proof-of-concept:  this can be done.

We did all this ~2 years ago.  There seems to be a slew of products
in development at various places which should ease the pain, but
there's just no clear off-the-shelf solution right now.  My advice,
my opinion only, is that for now you win by rolling your own.

IMHO,

Jeff Bone

--
---- Jeff Bone ----------------------------------------------------------
      "Imagination is more important than knowledge."  (A. Einstein)

                                                                       --



Sun, 06 Nov 1994 03:03:00 GMT
 Distributed Sybase Access
|>
|>>
|>>If one wants to distribute SYBASE across servers:
|>>
|>>  Buy open-server.
|>>  Write an application to "fake" joins etc.
|>
|>
|>This is fine for relatively small applications, but poor for very large
|>OLTP applications.  You have to be *REALLY* good to do an OpenServer
|>gateway which doesn't quickly become a serious bottleneck.  When I
|>was at Sun, we had to deal with this issue;  we talked to the Sybase
|>developers, surveyed commercially available apps, and finally gave up
|>and rolled our own.  We ended up with a system that would support several
|>hundred widely dispersed (across US, T1 lines) users with excellent
|>transaction response times over multiple (3-5) Sybase dataservers with
|>replicated tables.  

What are some of the causes for this bottleneck that you have found ?
I'm finishing up a DB2 OpenServer app, and in my brief two months
works with OpenServer V.2.0, I have found the coroutine support
(srv_yield) and the non-blocking I/O support (srv_select) provided
by Sybase to be quite sufficient for large number of clients
connections (srv_proc's).

I'm REALLY curious to find out some of the known problems with
OpenServer (especially the ones you had determined), as compare
to rolling out a home grown solution.

I'm very new to this field, and before your paper is available,
could you shed some light on this subject for me ?

Thanks.

other tools.
--
Jeff Lin                                        |/                

6464 Savoy Dr.       Phone:    713-975-4592    /|                  
Houston, TX 77036     ________________________/ | ______________  



Sun, 13 Nov 1994 17:12:05 GMT
 
 [ 15 post ] 

 Relevant Pages 

1. Distributing Access 1 database to Access 2 users

2. Distributing VB/Access 2000 Apps to non Access 2000 owners

3. Sybase modelers with distributed OO experience needed

4. Distributed transaction using MTS and sybase

5. Sybase Open Server vs. Distributed PowerBuilder

6. Sybase Open Server vs Distributed PowerBuilder

7. Distributed DBM with Sybase??

8. Distributed DBM with Sybase??

9. Two-phase commit and distributed DB with Sybase

10. SYBASE Next Gen. Distributed Database Engineers

11. distributed sybase support?

12. distributed SYBASE


 
Powered by phpBB® Forum Software