Category: Sybase

Posted in Amazon, Cloud, DBA, Economy & Business, Internet, IT Issues, MySQL, RDBMS, RDS, Sybase

The end of Sybase

Posted on by rwjordan

It is with sadness that I had to turn off the last Sybase Instance we had running. Our last ASE server quietly shutdown on an Amazon EC2 server on Tuesday the 20th of December, never to boot again.

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.

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

A Cloud based Sybase

Posted on by rwjordan

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 RDBMS, SQL, Sybase

MySQL Triggers weak support for referential integrity

Posted on by rwjordan

Even though my workplace and reduced costs by migrating from Sybase on Solaris to Sybase on redhat. We are now in a move from Sybase to MySQL to further reduce the license costs of the applications. This has brought to forefront one of the reasons to use Sybase. Triggers and stored procedures. And while MySQL now provides both, and transactions in InnoDB engines, Sybase triggers and Procedure are far more advanced. This forms a type of trap, they are very useful, but create serious obstacles to convert triggers that perform Referential Integrity. Just to highlight two types of these issues, take the following;

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.

Posted in IT Issues, RDBMS, Red Hat, Sybase

Sybase On Red Hat Linux

Posted on by rwjordan

I’ve been installing Sybase 15.0.2 on several systems lately, both Core 2 Duo’s and quad Xeon’s and have been impressed with the ‘normalcy’ of the installations. With the one exception that they have all has a ‘segmentation’ failure with the backup server during the initial ‘startup’ script this is due to the omission of a shell variable LD_POINTER_GUARD=0 from the standard installation script. Once you add this element in the SYBASE.sh and source it, the backup server will start normally.

Posted in IT Issues, RDBMS, Sybase

Sybase’s self-destructive business plan

Posted on by rwjordan

I have monitored all the discussions of DRM with regards to Music and Movies, but until I started installing a Sybase ASE 15.0.1 installation, as a first stage to a Sybase 12.0 upgrade at the company which I work for, that I realized that Sybase must hate it’s own customers. I say this as that’s the only reason why they would use SYSAM and this draconian DRM license software in Version 15.xx. They want to put themselves out of business by pissing off their user base.  

My company have a contract with Sybase Ireland and I am an honest DBA installing a new version of Sybase ASE exactly like the one it will replace. I’m not trying to steal from Sybase. But this DRM assumes that I am a thief, and that I cannot be trusted. Even when we as a company pay thousands per year for support we barely use (because Sybase is a solid product). I’m a thief by their own DRM definitions.

We will be moving to MySQL, as soon as we are able, Sybase will be loosing yet another customer because of their suicidal  business plan.

 

Posted in Sybase, T-SQL

Crypto in the personal privacy world

Posted on by rwjordan

I was recently presented with The Code Book and while leafing through the pages during a moment of boredom I managed to create a simple crypto using the Julius Caesar character substitution method using Sybase T-SQL. And though I’m sure that the resulting encrypted text could be broken with brute force, it would not be easy, nor very worthwhile for most messaging.

In this world of spying and privacy invasion from all directions, a little personal crypto might be in order, particularly if one is inclined to be suspicious of commercial algorithms. and while this stored procedure is simple, it can be enhanced, feel free to use it for your own needs.

UPDATE: This is stronger than used Here: BA jihadist relied on Jesus-era encryption

CREATE PROCEDURE dbo.simple_crypto
(
@key_word varchar(25),
@message varchar(255),
@direction varchar(8)
)
as

set nocount on

declare
@key_input varchar(20),
@key varchar(27),
@key2 char(27),
@olumn int, @olumnk int,
@input varchar(255),
@olumnb int,
@output varchar(255),
@out char(1), @a_char char(1),
@undone varchar(255),
@count int

select @count = 97, @olumnk = 1
select @key_input = lower(@key_word) –‘branedy’
select @input = lower(@message)

create table #alpha (a_char char(1))

while @count <= 122
begin
insert into #alpha
values (char(@count))

select @count = @count + 1
end

select @key = char(32)

while @olumnk <= datalength(@key_input)
begin
select @out = substring(@key_input, @olumnk, 1)

delete from #alpha where a_char = @out

if @@rowcount = 1
begin
select @key = @key + @out
end

select @olumnk = @olumnk+1

end

select @key = @key + a_char from #alpha

drop table #alpha

select
@olumn = 1,
@olumnb = 1,
@key2 = ‘abcdefghijklmnopqrstuvwxyz{‘

—————–encrypt

if @direction = ‘Cipher’
begin

while @olumnb <= datalength(@input)
begin
select @output = @output + char(charindex(substring(@input, @olumnb,1), @key) + 96)
select @olumnb = @olumnb+1
end

select @input + ‘ = ‘ + @output as ‘Encrypted’

end
——————————————-decrypt

if @direction = ‘Decipher’
begin

select @output =@message

while @olumn <= datalength(@output)
begin
select
@undone = @undone+ char(ascii(substring(@key, charindex(substring(@output, @olumn,1), @key2),1))) –,
select @olumn = @olumn+1
end

select @output + ‘ = ‘ + @undone as ‘Decrypted’
end

——————————–

select ‘From the key ‘ + @key

return
GO

Posted in IT Issues, Oracle DBMS, Personal, RDBMS, Sybase

Working for the Underdog

Posted on by rwjordan

I always find it interesting that I seem to be in the position of supporting the underdog when it comes to computing, I own Apple’s and work with Sybase. Two systems that can’t manage a marketing strategy to move them into the main stream. Both manage to be on the opposite end of competition with Microsoft Software. I assume that each should be flattered that MS has chosen them to steal code and ideas from, but I’d rather hoped they had the market share back. Set aside the quality issues, credit, vindication and validation of their ideas is sadly lacking in the IT world with the exception of those that work with them.

Posted in Oracle DBMS, RDBMS, Sybase

Oracle Market share

Posted on by rwjordan

One more point in the Sybase vs Oracle debate is the size of the Oracle installed base. The claim has been made that the reason Oracle is the number one RDBMS, is that the database has been selected for it’s features, reliability and maturity.

Once again this is a false premise as the real reason that Oracle is number one, is Marketing, plain and simple salesmanship. And not generally good salesmanship, but more like that of a pushy used car salesman. I had the occasion of witnessing this, more or less first hand.

At one company I work for they were going through the usually agony of having to upgrade a project costing system. The current one, home made, was failing. The replacement was between Oracle Financial’s and some modules or Deltec Costpoint. The evaluation team went through extensive testing of the features, and the Oracle system came up short, but with Oracle promises to add the missing features. The Costpoint system was nearly a perfect fit. And hence the choice to purchase Costpoint. This set off the first of three Oracle incidents. Oracle having lost the bid, did not take it lightly. They when directly to the CEO of the company and claimed that the evaluation team had made a costly and catastrophic choice for the company which would lead to serious business loss.

The CEO having more or less picked the evaluation team, was not impressed with the Oracle arguments. But this does not complete the story. This same team, was required to also make a choice of RDBMS’s Oracle, or Sybase. And as you might have guested the same Oracle sales reps were involved. The evaluation team after considerable testing Chose Sybase. And guess what? The Oracle reps again approached the CEO claiming that the evaluation team had failed their duties and were taking the company to the brink with their choice of Sybase. And again they were shown the door by the CEO.

This does not close the door. The company operated the Costpoint system on Sybase for many years with absolutely no issues. Until Deltec was, under pressure from Oracle, was forced to migrate to “Oracle only” RDBMS support and as such required all clients to switch to Oracle as part of a Costpoint upgrade. The company was forced to upgrade all the hardware necessary to operate the costpoint system in order to manage the Oracle installation.

Clearly Oracle did not ‘win’ this on features, just pushy sales reps.

And this is not the only example of Oracle strong arm marketing , like the comedian, “I’ve got a million of ’em”!

Posted in Oracle DBMS, RDBMS, SQL, Sybase

Row level Locking

Posted on by rwjordan

In the Sybase vs Oracle discussion there is always one issue that Oracle used to win. Row level locking. In the early days of Sybase, page level locking was the lowest level of granularity that locks attained. Much of this was due to a conscious choice of increasing the performance of the transaction, rather than ensuring unique row locking in Sybase. After row level locking was added to Sybase at version 11, this was proved to be a false ‘feature’ as most Sybase installations rarely implemented it.

In retrospect most issues relating to row level being a requirement can be traced back to badly implemented transaction clients. which makes this even more evident, is that in many cases, when the client transaction were ‘repaired’ to implement true ACID transactions, the Oracle databases performed better, and the row level locking issues vanished as a requirement.

UPDATE:

One other difference between Oracle and Sybase which doesn’t get much visibility is the business of isolation levels. Oracle allows the ‘dirty’ read and Sybase does not. This is changeable in both databases, but Oracle used this to their advantage in the locking wars as shared, and shared intent locking did not cause the same kind of issues like the ones you would encounter in Sybase.