Posted in Amazon, DBA, EC2, Economy & Business, IT Issues, Linux, MySQL, RDBMS, RDS, Red Hat, Solaris, SQL, SUN, Sybase

A Cloud based Sybase

Over the past week I found myself in a situation as follows, during a migration, conversion from a Sybase Production server to a MySQL based version, I was required to ‘expedite’ a Sybase 15 ASE installation into an Amazon (EC2) instance, The Cloud!

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.

Posted in IT Issues, Linux, OpenBSD, Personal, Solaris, SUN

Streching the EOL on old hardware.

A couple of weeks ago a friends from work was clearing out their place, I assume she had something to do with it, but in any case my collection of computers grew a bit when he offered to gift them to me. So now I own a Sun SPARCstation 5 and a Sun SparcStation IPX along with other bits and bobs. Now as a rule I only take systems that work, and they do, however the passwords have been lost in the annals of time.

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;

SparcStation 5 Nokia N900 smartphone
Screen 1024 x 768 (9 screens) 800 x 480 (4 screens)
Memory 64 MBytes 256 MBytes
CPU Freq 110 Mhz 600 Mhz
Storage 1 GByte 32 Gbyte
Price (new) 8,000.00$ to 10,000.00$ ~500.00$

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 🙂

Posted in IT Issues, Oracle DBMS, Personal, Solaris, SQL, Sybase

Sybase vs Oracle

I’ve seen some discussion around the internet about the age old argument about which is best Sybase or Oracle. I have been reading Mr. Talebzedah article on Sybase vs. Oracle: 10 reasons to use Sybase on Linux and I would agree with many of his statements. Having installed and used both over the years, I would pick Sybase. Why more companies don’t use Sybase more, has always been a mystery to me. Sybase is cheaper to install, and operate both in hardware resource usage, and manpower utilization. As an example, which can be repeated ad finite, one of the companies I worked at required 20 DBA’s to support a single Oracle Financials system in version 7 Oracle. And they were terrified to upgrade to Oracle 8 as Oracle does not supply a migration path. Sybase in this same company was used extensively in 7/24 environments, and only had 18 DBA’s supporting more than 800 Sybase databases, with more than 15,000 logins. In Mr Talebzedah article he mentions 2.5 Oracle DBA’s to one Sybase DBA, and since you and I know that 0.5 DBA’s don’t really exist (see mythical man month) I would put that, rounding factors aside, to 3+ Oracle DBA’s to one Sybase DBA.

Oracle supporters always mention the ‘sophistication’ and maturity of Oracle features, and in the same breath include the requirements for learning more, and of it’s complexity. This complexity extends to it’s high requirements in installation, and operating Oracle databases. Ask an Oracle DBA why they have to maintain backup configuration files three or more times to feel safe? As an example of this heavy requirement for installation, Oracle makes more money consulting on how to install it, than selling the actual RDBMS product. As another cost Oracle DBA’s are higher paid than Sybase DBA’s you do have to pay for all this sophisticated knowledge. That’s not a fault of the DBA, but is is still a business expense, and adds to the TCO.

As for the maturity and sophistication, Oracle may win here, but I am not comparing ASE 15 as I have not used this, but in almost every environment I’ve ever worked in, this sophistication is never utilized. This is not a lack of programming skills in the staff. It has to do with not being locked into any particular RDBMS feature. Many companies are completely heterogeneous with regards to Databases, probably due to corporate merger mania. And database transportability is prized much more than any particular database feature. In some cases junior programmers utilize databases more as file systems than RDBMS systems and hence, gain nothing from the mature, sophisticated features Oracle might provide.

Ultimately Oracle grants nothing in the benefits column when the costs are taken into perspective. Oracle is more expensive, fragile and harder to develop applications for. Sybase is cheaper faster, more stable, and requires less hardware and manpower to operate.