| >1. Should he regard the Cluster as 2 SQL standalone SQL servers
> when working with SQL server management stuff like;
>
>Adding/Dropping Logins
>Configure SQL server parameters/tuning..
>Adding/changing objects on master and other local databases...
>Working with backup devices..
>Working with tasks and alerts
>
All of the above should be considered LOCAL operations. You must do
them on both servers in the cluster if you want similar information on
both nodes.
>2. Work on the shared clustered enrolled database...
>
>Creating/changing objects
>tables/views/procedures/users/permissions;
Not sure on those questions. It depends on where the information is
stored. If the info is stored within the shared database, then you
only have to do the operation ONCE. If the information is actually
stored in the server's master database, then you have to do the
operation twice (once on each server.)
We'll try to get a better answer for you.
>
>Changes in size of database and database device is
>documented, unenroll - change - enroll also in topic 800..
>Is that maybe a general rule, unenroll - change - enroll
>working on the clustered database?
Maybe not. It depends on what kind of information you're changing.
>
>What kind of SQL information is "replicated" between
>the SQL Servers when running in cluster, other than
>which databases are enrolled, primary server..
>
This question is the key to understanding.
When a database on a shared disk is "enrolled", the cluster software
replicates information about the database location and size. This
information is stored in spt_fallback tables, which are contained in a
server's MASTER database. Basically, the cluster software copies
information from the "sysdatabases", "sysdevices", and "sysusages"
system tables into the spt_fallback tables on both servers. That is
the only information that is replicated.
SOME other information about the database is contained within the
database itself (for example, the database schema). That information
doesn't need to be replicated because it fails over when the database
fails over.
|
| >2. Work on the shared clustered enrolled database...
>
>Creating/changing objects
>tables/views/procedures/users/permissions;
Ok, a better answer on these questions now: The answer for everything
except "users" is easy. When you make changes to a shared database for
tables/views/procedures, the changes failover properly because all the
information is contained within the shared database itself.
Information about users and permissions also fails over correctly IF
THE LOGIN ENTRY MATCHES EXACTLY ON BOTH SERVERS. For example, if I
create a login entry on ServerA with a name of "cja" and uid = 11, I
must also create a login entry on ServerB with the name "cja" and the
same uid ( = 11). Then I can add user "cja" to a shared database and
assign db permissions within the shared database. Permissions and
users failover just fine.
However, if login entry for "cja" on ServerA has a different uid than
the login entry on ServerB, the user information does not failover
properly.
Bottom line: make sure the "syslogins" table in the master database
looks the same on both servers. Unfortunately, the cluster software
doesn't help with that.
|