Note the following information before you install SQL Server 2005 SP3 on a failover cluster instance:
Do not stop the cluster service before you run the SP3 Setup program, or while the installation program is running.
Do not end any running processes before you run the SP3 Setup program.
Do not take the SQL Server service off line before you run the SP3 Setup program. The SP3 Setup program will stop and start the SQL Server service.
Run the SP3 Setup program on the primary node of the failover cluster instance.
You must restart all failover cluster nodes after SP3 is finished installing.
Rolling upgrade is not supported for SP3.
Failover Cluster Installation
The following information applies only to SQL Server 2005 components that are part of a failover cluster.
To install the service pack on a failover cluster:
To ensure that SQL Server 2005 SP3 will be installed on all nodes of a failover cluster instance, verify that the TASK Scheduler is running on all passive nodes of your failover cluster instance.
If any resources have been added that have dependencies on SQL Server resources, those dependencies must either be removed or taken offline before you install SQL Server 2005 SP3. If you do not remove the dependencies, the installation of SP3 will take those resources offline.
Note:
When a clustered resource is taken offline, all dependent resources are also taken offline by the cluster service.
Run the SQL Server 2005 SP3 executable package file from the active node that owns the group containing the failover cluster instance that you plan to upgrade. This installs the service pack files on all nodes in the failover cluster. You cannot install SP3 from any passive nodes in the failover cluster.
On the Feature Selection page of the SQL Server 2005 SP3 Setup Wizard, select the failover cluster instance that you plan to upgrade. Setup will prompt you for the login credentials that are used to connect to other nodes in the cluster.
Note:
Keep all nodes of the cluster online during Setup. This ensures that the upgrade is applied to each cluster node.
If you removed dependencies or took resources offline in step 1, restore the dependencies, or bring the resources online.
Note:
Setup might require you to restart the failover cluster nodes. This restart replaces the files that were in use during Setup.
Tuesday, January 11, 2011
Thursday, January 6, 2011
Replications of SQL Server
Snapshot Replication
This form of replication is appropriate for small data sets, infrequent
update periods (or for a one-time replication operation), or management simplicity.
Transactional Replication
Transactional replication can typically keep databases in sync within about five seconds of latency, depending on the underlying network infrastructure.
Merge Replication
Merge replication allows data to be modified by the subscribers and synchronized at a later time. This synchronization could be as soon as a few seconds, or it could be a day later.
Immediate Updating
Immediate updating allows a replication target to immediately modify data at the source.This task is accomplished by using a trigger to run a distributed transaction.
This form of replication is appropriate for small data sets, infrequent
update periods (or for a one-time replication operation), or management simplicity.
Transactional Replication
Transactional replication can typically keep databases in sync within about five seconds of latency, depending on the underlying network infrastructure.
Merge Replication
Merge replication allows data to be modified by the subscribers and synchronized at a later time. This synchronization could be as soon as a few seconds, or it could be a day later.
Immediate Updating
Immediate updating allows a replication target to immediately modify data at the source.This task is accomplished by using a trigger to run a distributed transaction.
Wednesday, December 22, 2010
Moving Full Text folder in SQL Server 2005
Stopped the FT services. Copied the FTDATA contents over to new drive from existing drive. Deatched the database and attached it back by specifying new FTDATA location for FT Catalogues.
Registry changes for default FT path and noisexxx.txt and tsxxx.xml files:
Default path:
FullTextDefaultPath -- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer
Seperate keys for each language, so we had to change about 17 keys here:
NoiseFiles -- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSearch\Language -- seperate keys for each language.
Seperate keys for each language, so we had to change about 17 keys here:
TsaurusFiles - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSearch\Language\ -- seperate keys for each language.
Restarted the FT service.
Make sure that the FT catalogues are online; (query sys.database_files under teh same database) because there is a possibility that they go offline. We had few files offline and we rebuilt them and they came up OK.
Registry changes for default FT path and noisexxx.txt and tsxxx.xml files:
Default path:
FullTextDefaultPath -- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer
Seperate keys for each language, so we had to change about 17 keys here:
NoiseFiles -- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSearch\Language -- seperate keys for each language.
Seperate keys for each language, so we had to change about 17 keys here:
TsaurusFiles - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSearch\Language\ -- seperate keys for each language.
Restarted the FT service.
Make sure that the FT catalogues are online; (query sys.database_files under teh same database) because there is a possibility that they go offline. We had few files offline and we rebuilt them and they came up OK.
Tuesday, December 21, 2010
Oracle Cluster Registry Utilites
E Managing the Oracle Cluster Registry
http://download.oracle.com/docs/cd/B28359_01/rac.111/b28255/ocrsyntax.htm
http://download.oracle.com/docs/cd/B28359_01/rac.111/b28255/ocrsyntax.htm
Oracle Cluster Design
Design for scalability
It is often advised to focus system design on hardware scalability rather than on capacity. It is typically cheaper to add a new node to a system in order to achieve improved performance than to partake in performance tuning to improve the capacity that each node can handle. But this approach can have diminishing returns (as discussed in performance engineering). For example: suppose 70% of a program can be sped up if parallelized and run on multiple CPUs instead of one. If α is the fraction of a calculation that is sequential, and 1 − α is the fraction that can be parallelized, then the maximum speedup that can be achieved by using P processors is given according to Amdahl's Law: . Substituting the value for this example, using 4 processors we get . If we double the compute power to 8 processors we get . Doubling the processing power has only improved the speedup by roughly one-fifth. If the whole problem was parallelizable, we would, of course, expect the speed up to double also. Therefore, throwing in more hardware is not necessarily the optimal approach.
[edit] Weak versus strong scaling
In the context of high performance computing there are two common notions of scalability. The first is strong scaling, which is defined as how the solution time varies with the number of processors for a fixed total problem size[6]. The second is weak scaling, which is defined as how the solution time varies with the number of processors for a fixed problem size per processor.
It is often advised to focus system design on hardware scalability rather than on capacity. It is typically cheaper to add a new node to a system in order to achieve improved performance than to partake in performance tuning to improve the capacity that each node can handle. But this approach can have diminishing returns (as discussed in performance engineering). For example: suppose 70% of a program can be sped up if parallelized and run on multiple CPUs instead of one. If α is the fraction of a calculation that is sequential, and 1 − α is the fraction that can be parallelized, then the maximum speedup that can be achieved by using P processors is given according to Amdahl's Law: . Substituting the value for this example, using 4 processors we get . If we double the compute power to 8 processors we get . Doubling the processing power has only improved the speedup by roughly one-fifth. If the whole problem was parallelizable, we would, of course, expect the speed up to double also. Therefore, throwing in more hardware is not necessarily the optimal approach.
[edit] Weak versus strong scaling
In the context of high performance computing there are two common notions of scalability. The first is strong scaling, which is defined as how the solution time varies with the number of processors for a fixed total problem size[6]. The second is weak scaling, which is defined as how the solution time varies with the number of processors for a fixed problem size per processor.
Thursday, December 9, 2010
Subscribe to:
Posts (Atom)