Author |
Message |
Todd Ho #1 / 15
|
 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 |
|
 |
Hugh B. Barraclou #2 / 15
|
 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 |
|
 |
Todd Ho #3 / 15
|
 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 |
|
 |
Buzz Moschet #4 / 15
|
 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 |
|
 |
Warren Finner #5 / 15
|
 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 |
|
 |
Todd Ho #6 / 15
|
 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 |
|
 |
Graeme.H.. #7 / 15
|
 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 |
|
 |
Daniel Druk #8 / 15
|
 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 |
|
 |
Daniel Druk #9 / 15
|
 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 |
|
 |
Phillip Millm #10 / 15
|
 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 |
|
 |
Mike Ols #11 / 15
|
 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 |
|
 |
Vijay Raghav #12 / 15
|
 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 |
|
 |
Warren Finner #13 / 15
|
 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 |
|
 |
Jeff Bo #14 / 15
|
 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 |
|
 |
Jeff L #15 / 15
|
 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 |
|
|