Does SQL 2000 clustering work properly?

Howdy,

Is SQL 2000 clustering on windows 2000 any good ??

We are looking at spending *quite* a bit of money to implement it, but I need opinions of what its like from the people that actually use it & look after it.

e.g.

DOES IT WORK LIKE IT SHOULD????
Is it reliable?
Is it resource hungry?
Are there lots of bugs?

All repsonses very welcome. No response too small.

Thanks for your help.

Cheers,

SG.I can't offer too much advise except to say,... a few of the projects I have been involved in have used it. I have never had to set it up or admin it or anything. I have heard that setup can be a pain in the butt, but once it is going things tend to run okie.

As a developer I have never had any problems with what others have set up in the way of clusters.|||Hey,

This is a bit long, so I apologise for that,

but this is some text I found on www.sqlteam.com which I think is particularly relevant in this case:

//direct paste from: http://www.sqlteam.com/item.asp?ItemID=5137

Notes from the Field
I sent out an email to a few people that I know run a cluster in production and have done so for a while. Here's the information I got back from JohnDeere:

I have found the biggest shortfall to be the lack of monitoring tools for Microsoft Cluster Services. There is no built in notification if a node fails, but at least on Win2K you can install the cluster admin tool on your local workstation so you don't have to go to the server room. Terminal services does not work in the cluster.

Be sure your backup strategy will work in a cluster and be sure it will work for Sql server. Our original strategy was Compaq's virtual replicator. It does not work in a cluster and I was never sure how these snapshots would work for SQL server. We switched to a Spectra 10000 4 drive AIT backup unit.

If your cluster is not fully redundant make sure you have the spare parts in stock or on a quick delivery time frame. Our cluster is not redundant but Compaq has all the parts on a 4 hour delivery time. (SAN controllers, SAN Switch, fiber cable, disk drives We have one hot spare but none on the shelf) The basic idea is to survive a CPU fault but if any of the shared disk pieces fail and you have no redundancy the whole cluster is down. (Management really does not like this)

Be sure to mention only start and stop services from the cluster administrator. Never start or stop SQL or its related services from enterprise manager, Sql service control or the services applet from control panel. The only way I have been able to recover from this is a reboot of both nodes on the cluster.

One of the biggest issues on our cluster is disk contention. You have 2 servers fighting for time on a single physical disk cabinet. In my cluster if I start 2 backups at the same time. The time to backup doubles or If we start a major import operation on node1 the performance of node2 suffers. (graz: I'm lucky. We have two physical disk cabinets.)

I would also mention hardware sizing (# of CPU's & RAM). Make sure one of your servers has enough horsepower to run both instances of SQL Server in the event of a fail over. In the 7 world this is a little different but in 2000 you are running 2 separate instances of mssql.exe and its associated programs.

If you cluster 2000 you must name the instances and change the port from 1433 on one of the instances. If you don't have MDAC 2.6 then you must alias the non-1433 server via client network utility|||Actually, re-reading it, lol, the first paragraph is all i needed to paste (sorry it's been a long day), and this forum doesn't seem to have an edit function. Oh well... ops *slaps himself*|||it must have been a long day, check the edit link at the bottom right of your post. ;)|||The company that I'm working for has the SQL cluster servers with active to active. Like rokslide said, the setup is very tough, especially for active to active. We had Microsoft consultants to set up and cost much time and money. After it is up, that is really good.|||Oh yea, the one that says Edit, LOL...

*slaps himself again*

I thought I'd used it before, couldn't believe it when I couldn't find it.

Just think, if I can't find the edit button on this forum, imagine the quality of my code, lol (hm, i better get testing tomorrow, lol)

Document Storage inside DB?

Has anyone got any experience or opinions about the
pros/cons of storing Office Type Documents inside an
image field in the database as opposed to storing a URL
pointer to the file in the filesystem?
Assuming there will be several GB of documents Im
thinking it would be better to keep these out of the
database.
AdamA common approach is to :-
Store the documents on a file server
Store a pointer to the Documents in the DB (to aid searching)
HTH
Ryan Waight, MCDBA, MCSE
"Adam" <atoth@.msdnspam.com> wrote in message
news:07ab01c3b4d3$2e07d430$a501280a@.phx.gbl...
> Has anyone got any experience or opinions about the
> pros/cons of storing Office Type Documents inside an
> image field in the database as opposed to storing a URL
> pointer to the file in the filesystem?
> Assuming there will be several GB of documents Im
> thinking it would be better to keep these out of the
> database.
> Adam
>|||Hi,
We are providing content management software that's using such an approach -
but we are using both DB and FileSystem as a storage for the documents. For
storing the documents inside the database, we use a "document-breaker" to
split the documents in meaningfull parts (e.g. the html documents are split
in tags and text).
The advantages we have with the documents inside the database:
- one single resource that contains the whole system
- easy backup
- depending on the document splitting, we can track and validate cross
document references
The advantages we have by also storing the documents in the file system:
- fast document access (knowing the ID, we don't need a query to the DB)
- fast search capability (using Windows Index Services)
By the way: we have productive systems using this approach with 2000+
documents.
Sven
"Adam" <atoth@.msdnspam.com> wrote in message
news:07ab01c3b4d3$2e07d430$a501280a@.phx.gbl...
> Has anyone got any experience or opinions about the
> pros/cons of storing Office Type Documents inside an
> image field in the database as opposed to storing a URL
> pointer to the file in the filesystem?
> Assuming there will be several GB of documents Im
> thinking it would be better to keep these out of the
> database.
> Adam
>|||I see two approaches that use a "file system" is this the
Windows "file system" that you are referring to and if
so... how do you insure the documents are not deleted?
>--Original Message--
>Has anyone got any experience or opinions about the
>pros/cons of storing Office Type Documents inside an
>image field in the database as opposed to storing a URL
>pointer to the file in the filesystem?
>Assuming there will be several GB of documents Im
>thinking it would be better to keep these out of the
>database.
>Adam
>.
>|||>--Original Message--
>I see two approaches that use a "file system" is this
the
>Windows "file system" that you are referring to and if
>so... how do you insure the documents are not deleted?
>
Yes - I do mean the Windows File System; in answer to
your question you could disallow Delete rights (assuming
NTFS) - Ive never tried it but the option is there.
Adam|||Thanks for the reply - do you think it would still work
well with say 100,000 documents?
Adam