Posted in IT Issues, RDBMS

Twitter and Jaiku performance issues

Posted on by rwjordan

One thing I’ve noticed about Twitter and Jaiku, is a common thread in IT, Scaleability! It’s an issue that I worked on in my days with AT&T Wireless. Mobile phone vendors have been dealing with SMS and voice connection transactions for many years and the volume of such transactions have only grown over the years since I had to deal with 25+ million transactions per day. If the current growing pains of these Web 2.0 social networking systems are projected, they are both headed for failure in the form of catastrophic system overload. While I admire innovative Ideas, like these services, their infrastructure does not appear well thought out. A bit more foundation in the infrastructure, and less optimism of the performance, should have been the first design requirement.

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.

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 Forecasting

Pattern Matching vs Prediction

Posted on by rwjordan

I stumbled upon this article about Who Will Win the 2008 U.S. Presidential Election?. And realized that what they we claiming here was not a predictive method, but merely these people’s attempt to fit, to pattern match, ‘Presidential Electability’ factors to winners of elections. And making a half hearted attempt to apply these historical factors to up coming election. I’ll give you some examples, these are the factors they used in a previous ‘prediction’ Who Should Win the 2004 U.S. Presidential Election? they used factors like

if the candidate served as Director of Central Intelligence (e.g., George H. W. Bush), was a four- or five-star general officer in the United States Armed Forces (e.g., Dwight D. Eisenhower), or ordered the combat use of nuclear weapons (e.g., Harry S. Truman),

as you can see such ‘factors’ could only be applied to demonstrate why Truman beat Dewey, not as a general rule that proves the model.The factors used in the 2008 ‘prediction’ only suggest combinations of Presidential candidates , but can not predict them, because the factors are based on historical artifacts as part of the pattern matching, factors that can not be predicted in advance.

With that in mind there are no factors for emotional content, or future historical events.

They further go on to make this statement, We assume that major party primary voters are rational and will understand the empirical power of our algorithm. and we all know that voters for both nominees or candidates are not rational. And with a model that does not factor the level of ‘rational’ or irrationality of the electoral process, they can not forecast or predict. In other words, they can’t put their money where their mouths are.

They make another bold statement Readers of this paper could make a lot of money at Intrade.com if our assumption that major party primary voters are rational is correct. but you don’t see them making money.

The old adage is this, never take investment advice from a poor broker.

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.

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

Sybase vs Oracle

Posted on by rwjordan

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.