Migrating from ASE to Sybase IQ: An ASE DBA’s Perspective

Moving from an ASE specific application / decision support system to Sybase’s IQ.

An unconfirmed example: 1 exabyte compressed down to 270TB with 32 CPUs. Performance was ‘really fast’. Not sure what really fast really means in this situation.

Another example involved upgrading an IQ database from 12.6 to 12.7 with an arbitrary database. He corrupted a several terabyte database by applying the 12.7 binary, esd binary and alter upgrade the database. The fact that this caused a catalog store corruption needs to be handled as a corruption BUG. It was dismissed as a “dba didn’t follow the instructions” issue. I’m not sure if this was dismissed by IQ engineering or just by the presenter.

With respect to the scalability of Microsoft Windows Servers and Linux servers, the presenter provides half truths while raising the scalability of Solaris x86. His reasoning is that the thread models on Windows and Linux are inferior with managing a large number of threads. He says that this is purely an operating system issue and not a hardware one (Intel x86 based hardware). The problem with this is that the scalability issues are both software (OS) and hardware (x86). The scalability issues of the x86 architecture are well known and are still being addressed. His reasoning implies a biased opinion of ‘real’ Unix systems, which is unfortunate but isn’t unusual for people used to working exclusively or primarily with the classical Unix systems.

He does provide a good overview of the IQ system components. He properly stresses that if a query is running slower that what you would expect, to check to see where each component of the query is running.

For example:

Select col_a, col_b from my_table where col_a in (select getdate() )

Will cause all of the data from my_table to be sent to the SQL Anywhere (ASA) engine just so the getdate() search argument can be processed.

A better method would be to do:

Select col_a, col_b from my_table where col_a in (select getdate() from dummy_table)

This is because IQ requires a FROM clause in every query, so it hands it off to the SQL Anywhere engine.

He made the argument that if you have two ASE servers on the same box, they are completely separate in the sense that they don’t share the same resources. This isn’t exactly true. They will often share the same CPUs (a single dataserver process quite often can be handled by different CPUs at different times), network cards, disk subsystems, etc. Granted, the instructor was stating it to differentiate ASE and ASIQ.

He makes the statement that the dump file is not useful to obtain viable data out of it by unscrupulous individuals. I find the credibility of this statement to be totally and completely B.S. Even encrypted dump files, a new feature in the upcoming

He makes another statement that db devices on raw devices and file systems are the same in performance in AIX and Solaris. Not true. When O_DIRECT is used on the files, the top performance is still roughly 80% of raw devices. I’m not sure why he is stating this.

In theory, it is possible to deadlock an IQ server, but I haven’t been able to. Just out of curiosity, has anyone been able to deadlock an IQ server? Hmmm. I wonder.

Please keep in mind that he knows IQ quite well and I’m not in any way questioning his knowledge of IQ. I do believe that his understanding of the operating systems is not complete. Not everyone can be an expert at everything 😉 I have high standards with Sybase employees. Perhaps I’m raising the bar too high in this particular case.

Share Button

One Reply to “Migrating from ASE to Sybase IQ: An ASE DBA’s Perspective”

  1. In Sybase IQ 15.i, Could you please send me the dbspace level back up and restore syntax .
    Right now we have 6 years of data in our historic database in IQ 15.1 .

    I want to restoe that to New IQ 15.1 server in different partions

Leave a Reply

Your email address will not be published. Required fields are marked *