In all truth both Sybase instances were developer installs operating as production systems. Our two instances, operating with the 25 user limit that each was restricted to, was barely able to operate the system. But the Sybase Licensing was too archaic and inflexible to continue operating it as a small business. Thus the economics forced us to convert to MySQL.

If it hadn’t been for the previous management, who in some delusion of saving money, refused to pay the datacenter bill, forcing us to move the Sybase instances out into the Amazon cloud (EC2) in the first place we would probably have been on MySQL sooner, as that was the plan.

But the sadness remains, Sybase as a technology proved again that it would run, and run reliably, on just about any hardware, even when it was virtual, and NOT meeting the specified certified, requirements of operation. Which can’t be said for the Amazon RDS version of MySQL, which crashed spontaneously while applying an index on our live production database without warning. This having happened after weeks of testing and trial runs at operating the system on it. The only defense, the RDS instance rebooted and was available without data loss, in less time than a Sybase HA switchover would have taken, a system this production system was developed from.

So we are up in MySQL and I am now a MySQL DBA exclusively, after spending the last 25 years as a Sybase DBA and evangelist. The decision now has to be rather to remain so, or find another place of employment where Sybase remains. Those are becoming more and more rare. Maybe I should takeup MongoDB to stay at the cutting edge.

The company has been in the position of seeking less expensive IT infrastructure over the past few years, moving from Sun Enterprise servers with ASE clustering to commodity Intel based Redhat Sybase servers with poor mans replication. The final goal became a decision to convert the expensive Sybase ASE (read inflexible licensing), to MySQL, and generally into the Amazon RDS (cloud).

The move of a Sybase ASE into the Cloud was the result of an urgent desire to terminate a data-center contract early by management. The shrinking time line for the conversion of the Sybase schema to MySQL could not be guaranteed so a Plan B had to be created. Hence, the Cloud based Sybase production edition of a production server.

To my surprise, it works! after a bit of twisting, the Redhat ASE developer installation came off more or less just like any other Sybase install. There are irregularities from a normal Linux install, but functional. Being a bit of a spindle jockey, I was surprised (happily) at the overall performance of the storage systems of the EC2 instance. And the production server is now operating in the instance. (having previously moved the app and web servers into the EC2)

This post needing a point to make, is this, while working this issue, I did considerable Googling for anyone using Sybase ASE in the cloud, and nothing! or nearly nothing. What I did find first, a press release from Sybase corporate that they were now in the Amazon Cloud, dated in 2009, and not a peep since. Nothing, no product, no advertising, no options. What a missed opportunity, it’s now easy to see why Sybase has been loosing so much market to a ‘free’ RDBMS like MySQL.

The company I work for is currently spinning down into a ‘Hibernate’ mode (after I have helped it move from Sybase Databases to MySQL databases hosted in the ‘cloud’). I’ve more or less worked myself out of a Sybase Job.

So if you know of a DB opportunity or just want to talk Databases, let me know.

Thanks.

So I was left with a marginal SparcStation 5 with a missing CD drive, which booted to Solaris 2.7, but no further. But I’m a geek, and undaunted by this minor setback, I set out looking for a workaround. The googling net is full of solutions for password recovery … if you have a bootable cd (yes CD not DVD), Ok, next does eBay still have Solaris stuff that old … not cheaply, so what next.

While googling, OpenBSD presented itself, and I downloaded and burned some generic ISO’s of version 4.8. and then to solve the other hardware issue, the Sun IPX was delivered with a cartridge loading CD, but the IPX drive was housed in an external SCSI 1 case, and the SS5 was wired with a SCSI II system externally. so I dismantled the CD drive and searched for a CD cartridge carrier which as any self-respecting Geek, I had stashed away for a rainy day. Then armed with the hardware I jumpered the SCSI CD drive into the SS5 chassis, and bingo a complete and bootable SS5.

Now attempting to boot the OpenBSD was no problem, which surprised me to no end. But then I attempted a password recovery on the Solaris disk and no joy. but I did manage to mount it, and more or less destroy it (latter I found a way to fix it) and determined to go ahead and install the full OpenBSD system. Which more or less worked, there were issues with the X-Fonts archive but I found the tarball contained another version, which worked. It now booted on the internal disk, but I had to add and modify the XF86Config file to find the display, mouse and keyboard. My result does not match the examples of this file you might find on the net. So if you are interested, contact me, the Sun GB keyboard was hell to make work. but TADA:

And I even now have a browser in the form of Links

However, while it can compile most anything, there isn’t much left on the 1GB disk to compile TO. So unless I find some pre-compiled SMALL binaries, or a very cheap internal SCSI Disk to upgrade with, I’m stuck.

There may be more coming for this system, but just to make a comparison with modern hardware;

UPDATE: I found amongst the archives another external 1.2GB SCSI disk, which fits nicely in the same connector that the CD-Drive was in, so now the SS5 is without the CD-Drive but has a massive 2.2GB of disks, Impressive

I wish the Idea of IdeaForecasting would take off, but I haven’t really publicized it yet. In the mean time I’m learning a great deal about PHP, MySQL and OpenSolaris.

I have always been boring, in most conversations I almost never initiate a subject, but I can always contribute (read; shoot my mouth off). This is true in my IT skills. I know many things, but I don’t create many new things, but I can solve most puzzles and resolve problems. And in reviewing them, I find it’s more to do with not having an agenda, or operating under a set of predefined solutions. I examine the issue, then produce an alternative resolution. I become creative in my solutions, I invent extraordinary resolutions. I remain empty, of any preconceived notion of a solution (not empty of ego mind you) but I exploit the Tao of the problem. Hence I don’t project a topic of conversation, or add a new project, or imagine anything extraordinary until I have a problem to solve.

This was my dilemma about the university folks, creating answers, where there were no questions (yet?). Applications, without anywhere to apply them. For me, IT problems ARE the mother of invention.

The Tao is like a well:
used but never used up.
It is like the eternal void:
filled with infinite possibilities.

You can not use ‘select’ criteria in a trigger that returns a value. This prevents executing a select on a table to check for the existence of record prior to an insert/update. This was a major issue with a trigger used to produce a history file via a ‘update’ that had to both insert and update the history table. My workaround was to create a MySQL procedure that had no such restriction, and to call the procedure from the trigger. This worked very well, but of course meant that there was additional overhead and more coding involved.

The second example was, in my opinion, was a far more severe omission of Referential Integrity, ‘Rollback’! You cannot perform a rollback in a trigger. What! Further more, you have use ‘set autocommit=0′ either as a database default, which it is not, by default, set. Or set it during the batch or client operation that you are performing. Twice bad! Again, my solution was to call a procedure that could perform a ‘rollback’ and to ensure that either the developer set autocommit off or to insure that it was set as a database wide option.

As easy as these solutions were, they highlight an omission of functionality that requires addressing in the future development of MySQL.

I never thought I’d get to be a Senior Programmer just by getting old!

Being a database kind of guy, I can’t help but believe that a fundamental disconnect in the understanding of transactions utilized in these systems is the root cause here. I have yet to see a significant teaching or understanding of database issues in the current crop of programmers. There seems to be belief that data analysis is not a worth while task in current programming efforts. I see this in the form of articles detailing new ‘database’ products and methods, and new ‘lightweight’ database processes, etc. Mostly the requirements for ‘new’ DBMS and ‘Lightweight’ processes, is the underestimations of the data tasks of most modern IT functions. If you don’t know your own data, you don’t know anything. Any system that is not fundamentally tied in with a database system is merely a calculator.