But I hate SQL Server too
-
I don't know if any of you has ever run into this severed bug from ms$, which can cause you a fatal lost on data files. This happened as followed:
- A desktop computer failed and the accountant was in urgent need for the data which was on q local MDF file on the local disk. The LAN was knocked out which several other desktops. So I decided to put her hard disk to the 2nd SATA wire of the working server where I hosted all the company data on SQL Server 2000. I attached the MDF + LDF files to the new database in the server (had of course to run EXEC sp_change_user_logins ‘Auto_fix’, ‘usrname’ as the only way chairman Bill could offer to fix the notorious inter-server bug for all versions of SQL Server up to 2005, but this is another story) and returned her the query result. Then next days when the failed desktops and LAN was fixed a IT department guy returned the disk to its original mother. You have no ideas why I am writing all this at this point then ….
I went back to the client 12 days later and found that the maintenance plan for my databases hanged since. I looked at the maintenance logs I found this “
…… backup operation failed or some thing similar …. Without providing any particular reasons. I checked everything on the server and SQL server and they were all fine. So guest what? The maintenance process stopped on a ‘suspect database’ which’s files were on the temporary disk which is now on the other computer. But hey, that database has nothing to do which my database and every functionality of SQL server worked but maintenance plan. It has stopped in silence and which could have caused me the lost of 6 months corporate data all together.Oracle is hateful in may ways but at least serious bug of this ms$ category is unheard. Have you?
-
<font size="6">SOMEWHAT CLEANED-UP VERSION:</font>
@tbtvn said:
I don't know if any of you has ever run into this severed bug from Microsoft, which can cause you a fatal lost on data files. This happened as followed:
A desktop computer failed and the accountant was in urgent need for the data which was on a local MDF file on the local disk. The LAN was knocked out which affected several other desktops. So I decided to put her hard disk to the 2nd SATA wire of the working server where I hosted all the company data on SQL Server 2000.
I attached the MDF + LDF files to the new database in the server (had of course to run EXEC sp_change_user_logins ‘Auto_fix’, ‘usrname’ as that is the only way Microsoft could offer to fix the notorious inter-server bug for all versions of SQL Server up to 2005, but this is another story) and returned her the query result. The
nnext dayswhen the failed desktops and LAN were fixed an IT department guy returned the disk to its original mother. You have no ideas why I am writing all this at this point.I went back to the client 12 days later and found that the maintenance plan for my databases had hanged since. I looked at the maintenance logs, where I found an error message that "backup operation failed" or something similar -- without providing any particular reasons. I checked everything on the server and SQL Server and they were all fine. So guess what? The maintenance process stopped on a ‘suspect database’ which’s files were on the temporary disk which is now on the other computer.
But hey, that database has nothing to do which my database and every functionality of SQL Server worked but maintenance plan. It had stopped in silence, which could have caused me the lost of 6 months of corporate data all together. Oracle is hateful in may ways but at least I have never heard of a serious bug like this. Have you?
P.S. I like to refer to Microsoft as "ms$" which is not only makes me sound like a douche but also doesn't make any sense.
-
@tardnugget said:
A desktop computer failed and the accountant was in urgent need for the data which was on a local MDF file on the local disk. The LAN was knocked out which affected several other desktops. So I decided to put her hard disk to the 2nd SATA wire of the working server where I hosted all the company data on SQL Server 2000.
I'm afraid to ask, but does working mean on?Also, maybe if you weren't swapping hard drives all over the place, you'd be a little more safe from losing 6 months of corporate data.
-
@tbtvn said:
Blah
I've done (almost) this exact same thing, with minor variations, on SS2K(SP4) a handful of times and never had the maintenance plans "hang". They've failed once when I had particular plans pointing explicitly to particular DBs (rather than the "all databases" option), had included a DB on the added disc, and forgot to remove it from the plan after detaching the DB and removing the disc. I would imagine you'd similarly hit problems if you removed the disc and forgot to detach the DBs first, for example.
Regardless, having read the post yesterday, I'm still pondering WTF you're so het up about? SS2K certainly has a number of WTF's, but in 8-9 years of working with it, I've never considered the slightly non-robust nature of the maintenance plan system anything but a trivial one. The secret is, extra care and attention, testing, and eyeballing now and again. ie be an attentive DBA.
-
Thank bstorer for correction of my English
-
Exactly what you said. I had pointed to one database in the maintenance plan which "hang". This is dangerous not because of the bug itself but because it is unseen from SQL Server behaviors: suppose I am sub-admin of a database Hotwind so I created a maintenance plan for Hotwind which worked. Another sub-admin who tried to get data from \driverNetA\G$\archieves\2001\ so he attached the database then detached it without me knowing about it (which is not my business anyway). So should the Hotwind fail after that? If there were any problems with Hotwind then why only with the maintenance plan but all the functionality (you can connect to the Hotwind, manual backup it, or what ever and never noticed the bug until … when it is too late).
-
Breaking News: 10-year-old edition of product, regularly considered not to have been any good before the version that came out 5 years ago, is not actually any good.
Furthermore, I'd like to state for the record that I hate MySQL (because it sucks) and PostgreSQL (because the .net API sucks) - but that has nothing to do with my hate for Oracle.
-
Sorry for the necro-post, but
@tbtvn said:
...So I decided to put her hard disk to the 2nd SATA wire of the working server where I hosted all the company data on SQL Server 2000. ...
You took a suspect drive from a crashed computer, shut down the the primary server which hosted ALL of the companied data, and installed the suspect drive there? THEN you proceeded to attatch a database from the suspect drive to the primary SQL server? And you didn't expect any issues?
You should have installed the Sql Server Desktop engine on YOUR computer, attached the drive via an external drive adapter and accessed the database locally, rather than risking who knows what (Have you seen the kinds of web sites accountants surf?) by doing it the way you did.
My bet is that you never detached the MDF from the SQL Server before removing the drive.
-
@Medezark said:
THEN you proceeded to attatch a database from the suspect drive to the primary SQL server? And you didn't expect any issues?
YOU expect a microsoft product to be able to run two instances of the same server software on a single machine? (so that you'd be able to attach the database to a secondary instance of the SQL server software.)
-
Um yes. Been there, done that. Successfully as well. It does work. SQL Server does allow the creation of individual instances.
@rew said:
YOU expect a microsoft product to be able to run two instances of the same server software on a single machine? (so that you'd be able to attach the database to a secondary instance of the SQL server software.)
But, my advice would have been for him to attach the suspect drive to a Local Client machine using the stand-alone, file based version of the product that was available at the time.
-
Re: But SQL Server
Hi. I'm going to assume that you administer that server, because of this:
@tbtvn said:
So I decided to put her hard disk to the 2nd SATA wire of the working server where I hosted all the company data
The only reallyreallyreally good reason not to transfer the database to another client with MSDE is if the file somehow exceeded the specs for MSDE. I remember some accounting software (was it Exact Globe? Not sure) that allowed end users to attach/detach their own database files, from their client, to the server, if they had the privileges. It's far fetched, but maybe it's a reason why there was an MDF on the desktop that won't run on MSDE.
Otherwise, man, what the hell were you doing??? I'm not gonna start about taking down what is apparently The Server to attach some piece of hardware, but I am on about the management part.
This stuff can also happen if somebody stops the SQL Agent service, creates a database or modifies database options (yes, that will happen to you once), or some IT grunt looks at your server and says: "Hey, what's this harddrive dangling off Giedi Prime?", and tears it off.
Database options policies were not there until SQL 2008. You are the maintenance plan. You know that you can get SQL 2000 to send notifications if you install MAPI on it, right? (Don't do it if it also runs Exchange. You don't need Outlook). Besides, there's enough evidence for a failing maintenance plan: Event Logs, SQL logs, accumulating transaction logs and an increase in disk space usage.
I agree with Medezark. You should've detached the database, and not leave it unattended for the grunts to take away (which I will assume happened unattended, for now).
-
@badcaseofspace said:
Hi. I'm going to assume that you administer that server, because of this:
@tbtvn said:
So I decided to put her hard disk to the 2nd SATA wire of the working server where I hosted all the company data
The only reallyreallyreally good reason not to transfer the database to another client with MSDE is if the file somehow exceeded the specs for MSDE. I remember some accounting software (was it Exact Globe? Not sure) that allowed end users to attach/detach their own database files, from their client, to the server, if they had the privileges. It's far fetched, but maybe it's a reason why there was an MDF on the desktop that won't run on MSDE.
Otherwise, man, what the hell were you doing??? I'm not gonna start about taking down what is apparently The Server to attach some piece of hardware, but I am on about the management part.
This stuff can also happen if somebody stops the SQL Agent service, creates a database or modifies database options (yes, that will happen to you once), or some IT grunt looks at your server and says: "Hey, what's this harddrive dangling off Giedi Prime?", and tears it off.
Database options policies were not there until SQL 2008. You are the maintenance plan. You know that you can get SQL 2000 to send notifications if you install MAPI on it, right? (Don't do it if it also runs Exchange. You don't need Outlook). Besides, there's enough evidence for a failing maintenance plan: Event Logs, SQL logs, accumulating transaction logs and an increase in disk space usage.
I agree with Medezark. You should've detached the database, and not leave it unattended for the grunts to take away (which I will assume happened unattended, for now).
And don't forget, the database was ALREADY running under an MSDE environment on the accountants machine!
-
You removed a disk containing the database files without ever telling MS SQL Server about it, never bothered to even look up how to perform such a function (or else you wouldn't have had this mess).
-Your backup code has no logic whatsoever to handle hard errors for databases that are in suspect mode for the times someone might do something utterly boneheaded.
-You have no alerting setup on failed backups at all.
-You never test restore your backups.
and somehow, this is MS SQL Servers fault and a bug??? Sir, you are a WTF. Please never touch databases in production and leave it to people who actually care about data integrity.
EDIT: CORRECTION. TRWTF is responding to a thread that died 3 years ago.
-
@LOLOMG said:
EDIT: CORRECTION. TRWTF is responding to a thread that died 3 years ago.
Around here threads never die. However, they can take very long naps.
