Welcome to the Blog of Mike Ross

I just have to share this story. My electric bike finally croaked. It would come on OK, but when you went to pedal it, beep, beep, beep....very unhappy bicycle. Well, I replaced the batteries and called the shop where I purchased the bike. They gave me some advice, but it just flat would not work. So, I put a cover over it and parked it by the house. Rats! Next trip to Seattle I was going to get another one, and trade in this one for parts.

Well, Rhawn the electrician was talking to me about the bike and he really thought it was something minor that was wrong with it. He volunteered to take it to his house and look it over, which he did. (Via a trailer that was big enough to haul a yacht - the electric bike looked pretty funny on that gigantic trailer!).

Sure enough, Ron fixed the bike! He found that the connection between the battery pack and the bike itself had gotten loose over time. He cleaned that up, bent the copper parts that made the connection back so they were tighter, and whammo! the darn thing worked perfectly. I have been riding the bike to work ever since!

So, one thing to consider if you are getting an electric bike. This one is 8-10 years old and considered to be "obsolete" by the manufacturer and the place where I bought it. Never mind that it's quite a simple design that could last for many, many years. One small glitch and there are neither replacement parts nor anyone who will work on it for you (unless you happen to know an electrician who is interested in electric bikes!).

On September 9th Sundown crashed and was rapidly repaired by our highly competent staff. However, about a week later I received a call from John Rushing - he could not get his (previously just fine) file i/o application to work. The error he received was "illegal file operation" - not too helpful. The next thing I know Mike Soukup is on the phone. His file i/o application also quit working - "illegal file operation". Well, obviously something had gone terribly bad with the file system when the server crashed. It was possible to log in to the server as the Oracle user and view all directories and files - even write to the files. Dave said that something was corrupted on the Oracle database, but obviously it was something corrupted on the file system! After all, I had even bounced the db without so much as a whimper or an alert log. Well...... no. After several days worth of moving files, creating new directory objects and a host of other "tweaks", I noticed that the alert_aero.log had some recurring errors in it. Researching that error (it was arcane) resulted in advice from Oracle to rebuild the entire SYS schema on AERO due to probable corruption of the schema and/or the data dictionary. Oh.

So, one night Michael Ellis, Ron and I set about rebuilding the entire SYS schema and, sure enough, the file i/o problems disappeared. Let that be a lesson to you, uh, to me - listen to Dave! By the way, I had opened an SR with Oracle for this issue, but this time they were unhelpful. Sometimes an SR is so very helpful, and sometimes it is a waste of computer ink.

I did actually learn quite a bit about creating dictionary objects on the database. The old way (which is what I was still using) was to create a long list of dictionary paths in an initialization parameter called utl_file_dir. Each change or addition required a change to this parameter and bouncing the database to activate the change. Not such a great plan bringing the database down just for that. Well, Oracle must have thought so too, as they implemented directory objects that can be created and activated while the database is running - much better!

Anyway, that's a recent lesson learned about Oracle and crashing servers.