BOFH: Go on, beancounter, type DROP TABLE asset; "Don't put that there," I snap - calmly, but firmly, as a Beancounter goes to drop a chunk of IT detritus on my desk. "What?" he asks, feigning innocence. "That. Don't put it on my desk, it doesn't belong there." "But it's IT equipment!" he bleats. "It's IT crap and it doesn't belong on my desk - any more that real crap …
This post has been deleted by its author
Also, one of our servers tape drives decided to give up the ghost, one of my colleagues spotted the alarm when logging into it one day. He phoned the people at the data centre.
"Oh I did wonder why there was a red light on it"
"The one next to the words 'error' by any chance?"
"Yes."
"So how long has it been on"
"A while now"
"And you've just been changing the tapes"
"Yes!"
happy BOFH day to me, Happy BOFH day to me.....
Its like turning up to a new (to me) customer to restore all their data as they had deleted it, ask for the backup tape and they reply - "oh the helpdesk told me you would install the backup after you had restored all our data ......"
I'm sure half the people here have a story like this: going back on-site to fix a customer's ID card database, I find that the tape in the tape drive was the one that I put there five years earlier, and the backup on it was the one that I had taken all those years ago.
Nobody had clicked the "make a backup" icon once. Sigh.
Nobody had clicked the "make a backup" icon once. Sigh.
Which is why you automate backups with a scheduled task and a robotic tape changer. Although at a former employer the tape changer looked like it had been constructed from perspex and aluminium oddments in a school technology lesson, and managed to jam a tape in such a way that it unspooled all over the machine room floor.
My personal favourite is finding the same tape you put in weeks ago still in the drive and a box full of unused blank tapes on the next shelf over, even though you know the full backup takes three tapes.
Apparently the helpful folks on the night shift didn't understand why the tape kept popping out of the drive and just pushed it back in every time. That caused some kind of meaningless warning to appear on the backup console, but there was no reason to read it as selecting "OK" made that go away as well.
My favorite was an elderly couple whose son had given them a used computer. They were keeping their household books on it. Called out to upgrade the software for their book keeping and discovered that the son hadn't bothered to explain what a floppy disk, or that their computer had a floppy drive. They had been under the impression for three years(!!) that the slot in the front of the computer was for ventilation.
I haven't read BOFH in well over a year (basically back to when it came off the rails) and that was a pleasant return to form, it may have been that I was swearing at an UPDATE statement at the time because it wasn't using the index unless I forced it with a hint but hey, I enjoyed it nonetheless.
"Those would be the tapes that are in the cardboard box sat on top of the floor standing server,..."
... overhanging just enough so that they fall on the passing beancounter's head... distracting him for long enough to let him step on the missing floor tile... making him stumble and hit his head on a strategically placed chair... and fall on a piece of old carpet that just *happened* to lie around...
No, they would be the tapes that sat next to the old CRT for more than 3 years, and may have been slowly erased by the magnetic field it generated.
I once had a QIC (quarter inch cartridge) tape drive band snap during a high speed rewind; the resulting mess INSIDE the cartridge was a sight to behold.
A jobsworth clown bounced a Linux server 3 times in15 mins without telling us, Hundreds of seriously fscked files that had to be cleaned out manually. Fortunately we had a list of the file ids so colleague fires up sqlplus & DELETE FROM (huge_table)
WHERE FILEID IN (list of 10 file ids); This runs fine so:
DELETE FROM (huge_table)
--WHERE FILEID IN (list of 10 file ids);
WHERE FILEID IN (list of next 10 fields);
Whoops. 1.4 billion rows deleted before he wondered why it was taking a while. It took us a week to reprocess all the zapped data. Shame he hadn't RTFM...
This is why you should *always* have a transaction open. Oops, something went wrong... hit Ctrl-C, type 'rollback' if the SIGINT doesn't automatically roll you back, start again. If the worst comes to the worst, you just kill your client session and the server will automatically roll its transaction back. Of course, this does assume you're using a sane database engine; I use PostgreSQL, others also work, just avoid MySQL.
The BOFH clearly knows this, hence the explicit 'commit' to seal the assets' (and DBA's) doom.
This works well in SSMS:
select * from <table name>
--update <table name> set <field> = <value>
where <clauses>
Run the whole statement, check you are updating the rows you want and then highlight from the update command and hit F5. It's not idiot proof but it is fool proof.
Every time I show that to someone they say "Oooh, that's a good idea!".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
