The article I submitted (migration to Oracle from Sybase and surviving in the workplace) was so very different as to the article that was published. My piece was too controversial for ISUG to release (Sybase to Oracle) so it was changed, not be me and not by the editor. It became a weird Unix to Windows rant. Yup, I agreed to the revised article but was trying to calm a screaming toddler and pamper a pregnant lady… not excuses just explaining where my brain was when I agreed to it. ugh what a mess.
Ultimately, the publication of the article was my fault. So please, just ignore my article in the Jan/Feb 2009 issue of the ISUG Technical Journal.
Last night I updated Workspace’s DTP with the standard DTP release from Eclipse’s website. Several oddities started showing up when accessing the DTP releases:
Testing the connection worked fine but when you open the database connection to a Sybase ASE database errors are reported:
If you run into this issue, you will need to uninstall Sybase’s Workspace (delete the %SYBASE%/Workspace directory after the uninstall is complete) to resolve it.
I’ve created feature request CR 565285 with Sybase:
Workspace’s DTP (data tools platform) should be updated with the DTP current release from Eclipse. This will allow developers that work in a mixed environment to use Workspace with non-Sybase DBMS’s (view stored procedures, triggers, etc).
If you believe that this feature request is desired, please let Sybase know.
The premise is when a mysterious double sided platinum blade is found in a cave, the largest deposit of platinum (multi billion $$$) on the planet is discovered three miles under a mountain. A mining company, called Earth Core, needs not only to stake a claim but find a way to extract the platinum. The miners have their hands full when the platinum ‘deposit’ fights back.
From the super ex-CIA agent to the spelunking uber-geologist, the story is a wild one. I’m very impressed with Mr. Sigler’s ability to make the characters and the scenario seem very real.
If you are into adventure stories and a little gore won’t phase you, treat yourself to a good time by reading or listening to Earth Core. You won’t forget it. 🙂
Over on ISUG‘s SIG-ASE mailing list, Peter Thawley wrote up the following reply that I think everyone using Sybase ASE and is thinking of using a RAM disk should be aware of. When I asked Peter if I could repost his message on my blog he agreed 🙂
Joe and Shane are spot-on about a task context switching off the engine on an i/o to a RAM-disk based device … and yes Joe, there is nothing you can do about this right now. Normally, one would think of this as a good thing … and it is for that specific user since they get to consume more cpu/engine time thereby getting better response time for their request.
Now, to throw a wrench into this! In these cases where some or all of the database is cached, one does have to be aware of the potential for other user tasks to experience some amount of starvation. Image a bunch of tasks, each consuming a full time slice (100ms by default) before yielding. For systems doing pure OLTP (short) transactions with users getting on an engine and getting off reasonably quickly … little risk of a problem. For mixed workload applications with some OLTP and some DSS/reporting, the potential for starvation is quite real and nearly guaranteed for environments with fully cached DBs. I’ve seen some trading systems in tier 1 investment banks brought to their knees by an innocent IT person deciding to buy a lot of memory to cache the entire DB only to wonder why performance started going to hell. [Of course, it was Sybase’s fault … ( – ; )]
In these cases, be thinking about execution classes/engine groups to segregate OLTP and DSS users onto their own disjoint set of engines using dynamic listeners to keep execution engines and network engines aligned within the same engine groups. You may also want to consider reducing “clock tick length” to keep a timeslice period lower than 100ms … I’ve seen some sites successfully using 50ms and even less … there seems to be little downside since most systems do the async disk io and net io checks a lot more frequently than 100 ms due to the “io polling process count” param.
Just trying to present a balanced view here …. This is going to be important for more people to consider as in-memory database techniques and/or features / products become more prevalent.
Senior Director / Architect
CTO Group, WMO