Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Wish list

5 posts in Product Futures Discussion Last posting was on 2003-04-22 12:27:43.0Z
Alain RICHARD Posted on 2002-01-11 17:19:57.0Z
Date: Fri, 11 Jan 2002 18:19:57 +0100
From: alain.richard@equation.fr (Alain RICHARD)
Subject: Wish list
Message-ID: <alain.richard-1101021819570001@macagr.equation.fr>
Organization: EQUATION
User-Agent: NewsWatcher-X 2.2.3b2
X-NNTP-Posting-Host: macagr.equation.fr
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 86
NNTP-Posting-Host: ns1.equation.fr 213.56.79.161
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com!macagr.equation.fr!user
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:944
Article PK: 95185

The first time I have asked for something on this newsgroup (porting
OpenClient to MacOS X), Sybase has replied by annoncing the port of Sybase
(OpenClient AND ASE) to MacOS X !!!

So I make a new attempt :-)

My wish list of the most anoying issues since several year with Sybase is :

- Support cross plateform dumps (i.e. convert between platform depent
issues like byte-ending and flot representation in order to be able to
dump from solaris and load into linux for example). Also user id must be
matched based on the username (login name) and not the userid. So when you
reload a database on an other server, either the user is rematched to its
suserid on the new server or dropped from the database.

- Add some support for catching bad performance code. The proposed
solution, using some external or internal monitoring tool, is very tedious
to setup and maintain. A very simple approch would be to have some
auditing like a top 100 commands generating the most logical I/O (this is
in general of very good indicator of problems). Also some information
about the index usage will be welcome (number of times each index has been
used may help catch badly defined or unused indexes). In my experience (12
years of Sybase), the most time consumming task is to determine which
command is consumming power, not to fix it.

- Make memory cache usage more flexible to configure. For example it is a
little silly to have to create separate pools for 2k and 16k accesses.

- a bcp functionnality a little bit more usable. For example I think we
should be able to add a bcp format that stores the information in a binary
form with both the data and the table definition. What we need here is
some possibility to migrate data (a table) from one server to an other
without having to worry about the data definition, if the definition
contains an identity column or not (this is a very anoying issue currently
because you can't use option -E on a table without identity, and if you
forget -E on a table with identity, you may corrupt you database logic !).

- some facility to truncate the log of a database (I know it's possible to
do it manually). Most of the time a live database need a lot of log, but
once it is no longer in use (or read-only), it needs only a small log.
Also why are we still forced to separate data devices from log devices ?


More difficult to implement :

- a less limitating on disk representation of data allocations. I consider
that we should be able to link a database to a disk file (something like a
device for only one database), and the disk file able to grow
(automatically or not) or shrink at will. Now that most OS uses
filesystems with logging and/or direct write to disk, the raw device model
is a little bit old.

- Page sizes defined at the database level (or device as defined on the
previous point) instead of whole server wide.

- a more compact representation of stored procs. I have a lot of databases
with stored procs representing several 10s of megabytes although the text
representation of the SQL procs is only some 1000s of lines.

- a possibility for plans in stored procs to be evaluated at the time the
SQL instruction is executed instead of the time the proc is triggered.
This will enables the optimizer to take into account the values of in proc
calculated parameters.

Just my .02 euros...


Marc Zampetti Posted on 2002-03-28 15:35:22.0Z
Message-ID: <3CA3383A.7030800@aol.com>
Date: Thu, 28 Mar 2002 10:35:22 -0500
From: Marc Zampetti <zampmarc@aol.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
Subject: Re: Wish list
References: <alain.richard-1101021819570001@macagr.equation.fr>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 19
NNTP-Posting-Host: pix-fw.wan.aol.com 152.163.190.1
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:594
Article PK: 94124

How about getting rid of the host/network dependancies in the interfaces(sql.ini) files.

Why do I care that the network about things like the TLI device, or the
hardware interface (ether). And for heavens sake, get rid of the binary
representation of the IP address.

The interfaces file is supposed to be a mapping from logical name to
physical connection information. Just make it the type of line
(master,query, etc), the hostname and the port. Make it the same on all
hosts. I don't really care if ASE or Open Client has to convert the
hostname to an IP address to a hex string before using TLI. That's an
implementation issue that I as a user should NEVER know about.

Marc Zampetti


"joop" Posted on 2002-03-28 15:54:00.0Z
From: "joop" <joop(at)sybase(dot)com>
References: <alain.richard-1101021819570001@macagr.equation.fr> <3CA3383A.7030800@aol.com>
Subject: Re: Wish list
Date: Thu, 28 Mar 2002 16:54:00 +0100
Lines: 47
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <5GIgXEn1BHA.216@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: 83dyn137.com21.casema.net 62.234.60.137
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:592
Article PK: 94119

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Marc Zampetti" <zampmarc@aol.com> wrote in message
news:3CA3383A.7030800@aol.com...
> How about getting rid of the host/network dependancies in the
> interfaces(sql.ini) files.
>
> Why do I care that the network about things like the TLI device, or
> the hardware interface (ether). And for heavens sake, get rid of
> the binary representation of the IP address.
>
> The interfaces file is supposed to be a mapping from logical name
> to physical connection information. Just make it the type of line
> (master,query, etc), the hostname and the port. Make it the same on
> all hosts. I don't really care if ASE or Open Client has to
> convert the hostname to an IP address to a hex string before using
> TLI. That's an implementation issue that I as a user should NEVER
> know about.
>
> Marc Zampetti
>
>
>

use ldap (ase125 up)


- --
joop

"It came from outer space, born in the heart of a sun"

Senior Consultant Sybase Professional Services
http://home.wanadoo.nl/species8472/
ICQ#:47048869
pgp key available

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQA/AwUBPKM8l6r/nxhltM4HEQKBBwCfcQTeOMNS10qmc/WajgR6pMs6rGIAnjdt
owAeK93LW2C7rizmZvO8MlIi
=4j5h
-----END PGP SIGNATURE-----


Sethu Posted on 2002-03-05 02:41:34.0Z
Message-ID: <3C84305E.9577D951@sybase.com>
Date: Mon, 04 Mar 2002 21:41:34 -0500
From: Sethu <sethu@sybase.com>
Organization: Sybase, Inc.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alain RICHARD <alain.richard@equation.fr>
Subject: Re: Wish list
References: <alain.richard-1101021819570001@macagr.equation.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 124
NNTP-Posting-Host: 10.22.91.118
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:751
Article PK: 94278

Hi Alain,

Thanks for all these feature request. I'll try to answer these issues
in as much technical info. that I can give.

> My wish list of the most anoying issues since several year with Sybase is :
>
> - Support cross plateform dumps (i.e. convert between platform depent
> issues like byte-ending and flot representation in order to be able to
> dump from solaris and load into linux for example). Also user id must be
> matched based on the username (login name) and not the userid. So when you
> reload a database on an other server, either the user is rematched to its
> suserid on the new server or dropped from the database.

As you have rightly mentioned the issue is with respect to
big-endian/little-endian.
There are so many C structures serialized and stored in the database pages.
Including a int on disk when copied to a C structure equivalent you have
to make conversions (a 4 byte data on disk stored in little-endian has to
be converted and stored in memory has big-endian). We will look into
see how we can provide such a facility.
Regarding the remapping of userids after loads, if you can give me specifics,
let me look into this.

>
> - Add some support for catching bad performance code. The proposed
> solution, using some external or internal monitoring tool, is very tedious
> to setup and maintain. A very simple approch would be to have some
> auditing like a top 100 commands generating the most logical I/O (this is
> in general of very good indicator of problems). Also some information
> about the index usage will be welcome (number of times each index has been
> used may help catch badly defined or unused indexes). In my experience (12
> years of Sybase), the most time consumming task is to determine which
> command is consumming power, not to fix it.

I agree. We will be exposing some more monitoring info that is added
for drill-down as proxy tables so that you can run select from these
proxy tables just like doing from sysmonitors. There will be different
proxy tables to give views of different monitoring data.

>
> - Make memory cache usage more flexible to configure. For example it is a
> little silly to have to create separate pools for 2k and 16k accesses.

Don't understand the useability issue here ?

>
> - a bcp functionnality a little bit more usable. For example I think we
> should be able to add a bcp format that stores the information in a binary
> form with both the data and the table definition. What we need here is
> some possibility to migrate data (a table) from one server to an other
> without having to worry about the data definition, if the definition
> contains an identity column or not (this is a very anoying issue currently
> because you can't use option -E on a table without identity, and if you
> forget -E on a table with identity, you may corrupt you database logic !).

This is something we need to definitely improve. Will followup.

>
> - some facility to truncate the log of a database (I know it's possible to
> do it manually). Most of the time a live database need a lot of log, but
> once it is no longer in use (or read-only), it needs only a small log.
> Also why are we still forced to separate data devices from log devices ?

The main reason to keep log devices separate from data is such that if
the device fails for some reason, atleast you have the db dumps + the
active log to recover from media failures. The shrink of database is
a long pending request.

>
> More difficult to implement :
>
> - a less limitating on disk representation of data allocations. I consider
> that we should be able to link a database to a disk file (something like a
> device for only one database), and the disk file able to grow
> (automatically or not) or shrink at will. Now that most OS uses
> filesystems with logging and/or direct write to disk, the raw device model
> is a little bit old.

I think the jury is divided on this in the unix world.
>
> - Page sizes defined at the database level (or device as defined on the
> previous point) instead of whole server wide.

This is in the pike.

>
> - a more compact representation of stored procs. I have a lot of databases
> with stored procs representing several 10s of megabytes although the text
> representation of the SQL procs is only some 1000s of lines.

This is the first time I have heard this request. Will look into this.

>
> - a possibility for plans in stored procs to be evaluated at the time the
> SQL instruction is executed instead of the time the proc is triggered.
> This will enables the optimizer to take into account the values of in proc
> calculated parameters.

We are working on statement caching. At this point, my memory is not helping
whether the statement caching will be optionally enabled for each stmt inside a
proc
or trigger.


Thanks,
Sethu


Ilya Zvyagin Posted on 2003-04-22 12:27:43.0Z
Reply-To: "Ilya Zvyagin" <masterziv@mail.ru>
From: "Ilya Zvyagin" <masterziv@mail.ru>
References: <alain.richard-1101021819570001@macagr.equation.fr>
Subject: Re: Wish list
Date: Tue, 22 Apr 2003 16:27:43 +0400
Lines: 15
Organization: FCT
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
FL-Build: Fidolook Express 2001 UIExt. BuildID: 3BC00FAD (7/10/2001 12:17:49).
X-Comment-To: Alain RICHARD
Message-ID: <1051014463.581478@gatekeeper.fct.ru>
Cache-Post-Path: gatekeeper.fct.ru!unknown@dream.int.fct.ru
X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/)
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: gatekeeper.fct.ru 212.113.103.2
Path: forums-1-dub!forums-master.sybase.com!forums-1-dub.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:1171
Article PK: 95412

Hello, Alain!
You wrote on Fri, 11 Jan 2002 18:19:57 +0100:

AR> - a possibility for plans in stored procs to be evaluated at the time the
AR> SQL instruction is executed instead of the time the proc is triggered.
AR> This will enables the optimizer to take into account the values of in proc calculated
AR> parameters.
Does creating a proc with "WITH RECOMPILE" do the job ?

--------------------
Ilya Zvyagin, First Container Terminal of SPb Sea Port
E-mail: masterziv@*KILLSPAM*mail.ru - include HP in subject
ICQ UID: 29427861(MasterZIV)