I notice a lot of activity on my sqlserver2005 box when nothing is
happening. (just query notificatins which I have set up) . I can't
find any write ups on this. To me, it seems
important.
thanks
Peter Kellner
http://peterkellner.net
Peter Kellner
http://peterkellner.netQuery notifications utilizes the Service Broker infrastructure internally to
handle the automatic activation of the notification when something changes.
This is where the activity is coming from. Query notifications were
primarily designed to allow you to maintain relatively static caches of
data. You don't want to use them in highly volitile data sets or with high
volume systems, because the notification mechanism can get overwhelmed by
the pace of changes in the environment.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Peter Kellner" <pkellnernews@.73rdstreet.com> wrote in message
news:p6l442tbga971ustvm4dg2u583ab864hlt@.
4ax.com...
>I notice a lot of activity on my sqlserver2005 box when nothing is
> happening. (just query notificatins which I have set up) . I can't
> find any write ups on this. To me, it seems
> important.
> thanks
> Peter Kellner
> http://peterkellner.net
> Peter Kellner
> http://peterkellner.net|||On Sun, 16 Apr 2006 09:57:17 -0500, "Michael Hotek"
<mike@.solidqualitylearning.com> wrote:
>Query notifications utilizes the Service Broker infrastructure internally t
o
>handle the automatic activation of the notification when something changes.
>This is where the activity is coming from. Query notifications were
>primarily designed to allow you to maintain relatively static caches of
>data. You don't want to use them in highly volitile data sets or with high
>volume systems, because the notification mechanism can get overwhelmed by
>the pace of changes in the environment.
thanks Mike. I understand now. -Peter
Peter Kellner
http://peterkellner.netsql
Showing posts with label box. Show all posts
Showing posts with label box. Show all posts
Monday, March 26, 2012
how much overhead with query notification services in sqlserer2005?
I notice a lot of activity on my sqlserver2005 box when nothing is
happening. (just query notificatins which I have set up) . I can't
find any write ups on this. To me, it seems
important.
thanks
Peter Kellner
http://peterkellner.net
Peter Kellner
http://peterkellner.netQuery notifications utilizes the Service Broker infrastructure internally to
handle the automatic activation of the notification when something changes.
This is where the activity is coming from. Query notifications were
primarily designed to allow you to maintain relatively static caches of
data. You don't want to use them in highly volitile data sets or with high
volume systems, because the notification mechanism can get overwhelmed by
the pace of changes in the environment.
--
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Peter Kellner" <pkellnernews@.73rdstreet.com> wrote in message
news:p6l442tbga971ustvm4dg2u583ab864hlt@.4ax.com...
>I notice a lot of activity on my sqlserver2005 box when nothing is
> happening. (just query notificatins which I have set up) . I can't
> find any write ups on this. To me, it seems
> important.
> thanks
> Peter Kellner
> http://peterkellner.net
> Peter Kellner
> http://peterkellner.net|||On Sun, 16 Apr 2006 09:57:17 -0500, "Michael Hotek"
<mike@.solidqualitylearning.com> wrote:
>Query notifications utilizes the Service Broker infrastructure internally to
>handle the automatic activation of the notification when something changes.
>This is where the activity is coming from. Query notifications were
>primarily designed to allow you to maintain relatively static caches of
>data. You don't want to use them in highly volitile data sets or with high
>volume systems, because the notification mechanism can get overwhelmed by
>the pace of changes in the environment.
thanks Mike. I understand now. -Peter
Peter Kellner
http://peterkellner.net
happening. (just query notificatins which I have set up) . I can't
find any write ups on this. To me, it seems
important.
thanks
Peter Kellner
http://peterkellner.net
Peter Kellner
http://peterkellner.netQuery notifications utilizes the Service Broker infrastructure internally to
handle the automatic activation of the notification when something changes.
This is where the activity is coming from. Query notifications were
primarily designed to allow you to maintain relatively static caches of
data. You don't want to use them in highly volitile data sets or with high
volume systems, because the notification mechanism can get overwhelmed by
the pace of changes in the environment.
--
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Peter Kellner" <pkellnernews@.73rdstreet.com> wrote in message
news:p6l442tbga971ustvm4dg2u583ab864hlt@.4ax.com...
>I notice a lot of activity on my sqlserver2005 box when nothing is
> happening. (just query notificatins which I have set up) . I can't
> find any write ups on this. To me, it seems
> important.
> thanks
> Peter Kellner
> http://peterkellner.net
> Peter Kellner
> http://peterkellner.net|||On Sun, 16 Apr 2006 09:57:17 -0500, "Michael Hotek"
<mike@.solidqualitylearning.com> wrote:
>Query notifications utilizes the Service Broker infrastructure internally to
>handle the automatic activation of the notification when something changes.
>This is where the activity is coming from. Query notifications were
>primarily designed to allow you to maintain relatively static caches of
>data. You don't want to use them in highly volitile data sets or with high
>volume systems, because the notification mechanism can get overwhelmed by
>the pace of changes in the environment.
thanks Mike. I understand now. -Peter
Peter Kellner
http://peterkellner.net
Wednesday, March 21, 2012
How many logical volumes for large database?
We are about to migrate a large database server (600+ GB data) onto new
hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box with
SAN attached storage. My question concerns how many logical volumes we
should have to support the various database components.
Currently, we have separate logical drives for the Data files, Indexes,
Logs, and TempDB. This was done for two reasons:
First, we had four available SCSI channels, so by creating four arrays each
on a different channel we increased disk I/O.
Second, we did it to reduce fragmentation. The database is used mainly for
running reports and analyses off of data from our main business application,
which is run on a VMS cluster. That system can't handle the performance hit
for all of the reporting, so once a week data is dumped from the mainframe
into the SQL Server. The rest of the week the SQL db is essentially
read-only. So the data volume is fairly static, growing on a weekly basis
but almost never shrinking. For performance reasons, the indexes are
dropped and recreated weekly, the logs are truncated and then grow, and of
course TempDB grows and shrinks as needed. By separating each component
onto a different logical drive, we should have less fragmentation.
Now that we are moving to a new architecture, the question has been raised
as to whether this is still the best setup, or if it just creates
unnecessary administrative overhead. Obviously we no longer get a
performance gain from multiple I/O channels, because all of the storage will
be accessed via the same fiber channel to the SAN.
As for the fragmentation issue, is it really that much of a problem? Would
it cause issues if we were to, say, combine data and indexes on the same
volume, or logs and TempDB?
The goal is to reduce administrative overhead. But since we have data
files, indexes, logs, and tempDB in any case, does it make a difference from
a management standpoint whether they are all on one volume or on four
separate ones? Would it be an issue either way from a backup/restore
standpoint?
Thanks,
Gary
Gary,
You can still benefit from multiple volumes on a SAN, specifically for data,
log, and tempdb. (Since it is essentially a read only db,
you apparently don't need a volume for backups.) Even with one HBA, having
independent sets of spindles for different types of IO (data, log, and
tempdb) usually provides some performance gain.
If the queries are active and make any use of temp tables, then you can
benefit from having tempdb on its own volume. The database log files will be
active when loading, so keeping them on their own volume should help with
load time.
I've seen many installations with that much or more data that don't use
separate volumes for indexes. If you never update the tables, and recreate
all the indexes weekly with each new load, you should not have problems with
defragmentation. But check anyway by using DBCC SHOWCONTIG.
Hope this helps,
Ron
Ron Talmage
SQL Server MVP
"Gary Dom" <domgATsutterhealthDOTorg@.no.spam> wrote in message
news:%230VstQAnEHA.2140@.TK2MSFTNGP11.phx.gbl...
> We are about to migrate a large database server (600+ GB data) onto new
> hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
> SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box
with
> SAN attached storage. My question concerns how many logical volumes we
> should have to support the various database components.
> Currently, we have separate logical drives for the Data files, Indexes,
> Logs, and TempDB. This was done for two reasons:
> First, we had four available SCSI channels, so by creating four arrays
each
> on a different channel we increased disk I/O.
> Second, we did it to reduce fragmentation. The database is used mainly
for
> running reports and analyses off of data from our main business
application,
> which is run on a VMS cluster. That system can't handle the performance
hit
> for all of the reporting, so once a week data is dumped from the mainframe
> into the SQL Server. The rest of the week the SQL db is essentially
> read-only. So the data volume is fairly static, growing on a weekly basis
> but almost never shrinking. For performance reasons, the indexes are
> dropped and recreated weekly, the logs are truncated and then grow, and of
> course TempDB grows and shrinks as needed. By separating each component
> onto a different logical drive, we should have less fragmentation.
> Now that we are moving to a new architecture, the question has been raised
> as to whether this is still the best setup, or if it just creates
> unnecessary administrative overhead. Obviously we no longer get a
> performance gain from multiple I/O channels, because all of the storage
will
> be accessed via the same fiber channel to the SAN.
> As for the fragmentation issue, is it really that much of a problem?
Would
> it cause issues if we were to, say, combine data and indexes on the same
> volume, or logs and TempDB?
> The goal is to reduce administrative overhead. But since we have data
> files, indexes, logs, and tempDB in any case, does it make a difference
from
> a management standpoint whether they are all on one volume or on four
> separate ones? Would it be an issue either way from a backup/restore
> standpoint?
> Thanks,
> Gary
>
>
hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box with
SAN attached storage. My question concerns how many logical volumes we
should have to support the various database components.
Currently, we have separate logical drives for the Data files, Indexes,
Logs, and TempDB. This was done for two reasons:
First, we had four available SCSI channels, so by creating four arrays each
on a different channel we increased disk I/O.
Second, we did it to reduce fragmentation. The database is used mainly for
running reports and analyses off of data from our main business application,
which is run on a VMS cluster. That system can't handle the performance hit
for all of the reporting, so once a week data is dumped from the mainframe
into the SQL Server. The rest of the week the SQL db is essentially
read-only. So the data volume is fairly static, growing on a weekly basis
but almost never shrinking. For performance reasons, the indexes are
dropped and recreated weekly, the logs are truncated and then grow, and of
course TempDB grows and shrinks as needed. By separating each component
onto a different logical drive, we should have less fragmentation.
Now that we are moving to a new architecture, the question has been raised
as to whether this is still the best setup, or if it just creates
unnecessary administrative overhead. Obviously we no longer get a
performance gain from multiple I/O channels, because all of the storage will
be accessed via the same fiber channel to the SAN.
As for the fragmentation issue, is it really that much of a problem? Would
it cause issues if we were to, say, combine data and indexes on the same
volume, or logs and TempDB?
The goal is to reduce administrative overhead. But since we have data
files, indexes, logs, and tempDB in any case, does it make a difference from
a management standpoint whether they are all on one volume or on four
separate ones? Would it be an issue either way from a backup/restore
standpoint?
Thanks,
Gary
Gary,
You can still benefit from multiple volumes on a SAN, specifically for data,
log, and tempdb. (Since it is essentially a read only db,
you apparently don't need a volume for backups.) Even with one HBA, having
independent sets of spindles for different types of IO (data, log, and
tempdb) usually provides some performance gain.
If the queries are active and make any use of temp tables, then you can
benefit from having tempdb on its own volume. The database log files will be
active when loading, so keeping them on their own volume should help with
load time.
I've seen many installations with that much or more data that don't use
separate volumes for indexes. If you never update the tables, and recreate
all the indexes weekly with each new load, you should not have problems with
defragmentation. But check anyway by using DBCC SHOWCONTIG.
Hope this helps,
Ron
Ron Talmage
SQL Server MVP
"Gary Dom" <domgATsutterhealthDOTorg@.no.spam> wrote in message
news:%230VstQAnEHA.2140@.TK2MSFTNGP11.phx.gbl...
> We are about to migrate a large database server (600+ GB data) onto new
> hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
> SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box
with
> SAN attached storage. My question concerns how many logical volumes we
> should have to support the various database components.
> Currently, we have separate logical drives for the Data files, Indexes,
> Logs, and TempDB. This was done for two reasons:
> First, we had four available SCSI channels, so by creating four arrays
each
> on a different channel we increased disk I/O.
> Second, we did it to reduce fragmentation. The database is used mainly
for
> running reports and analyses off of data from our main business
application,
> which is run on a VMS cluster. That system can't handle the performance
hit
> for all of the reporting, so once a week data is dumped from the mainframe
> into the SQL Server. The rest of the week the SQL db is essentially
> read-only. So the data volume is fairly static, growing on a weekly basis
> but almost never shrinking. For performance reasons, the indexes are
> dropped and recreated weekly, the logs are truncated and then grow, and of
> course TempDB grows and shrinks as needed. By separating each component
> onto a different logical drive, we should have less fragmentation.
> Now that we are moving to a new architecture, the question has been raised
> as to whether this is still the best setup, or if it just creates
> unnecessary administrative overhead. Obviously we no longer get a
> performance gain from multiple I/O channels, because all of the storage
will
> be accessed via the same fiber channel to the SAN.
> As for the fragmentation issue, is it really that much of a problem?
Would
> it cause issues if we were to, say, combine data and indexes on the same
> volume, or logs and TempDB?
> The goal is to reduce administrative overhead. But since we have data
> files, indexes, logs, and tempDB in any case, does it make a difference
from
> a management standpoint whether they are all on one volume or on four
> separate ones? Would it be an issue either way from a backup/restore
> standpoint?
> Thanks,
> Gary
>
>
How many logical volumes for large database?
We are about to migrate a large database server (600+ GB data) onto new
hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box with
SAN attached storage. My question concerns how many logical volumes we
should have to support the various database components.
Currently, we have separate logical drives for the Data files, Indexes,
Logs, and TempDB. This was done for two reasons:
First, we had four available SCSI channels, so by creating four arrays each
on a different channel we increased disk I/O.
Second, we did it to reduce fragmentation. The database is used mainly for
running reports and analyses off of data from our main business application,
which is run on a VMS cluster. That system can't handle the performance hit
for all of the reporting, so once a week data is dumped from the mainframe
into the SQL Server. The rest of the week the SQL db is essentially
read-only. So the data volume is fairly static, growing on a weekly basis
but almost never shrinking. For performance reasons, the indexes are
dropped and recreated weekly, the logs are truncated and then grow, and of
course TempDB grows and shrinks as needed. By separating each component
onto a different logical drive, we should have less fragmentation.
Now that we are moving to a new architecture, the question has been raised
as to whether this is still the best setup, or if it just creates
unnecessary administrative overhead. Obviously we no longer get a
performance gain from multiple I/O channels, because all of the storage will
be accessed via the same fiber channel to the SAN.
As for the fragmentation issue, is it really that much of a problem? Would
it cause issues if we were to, say, combine data and indexes on the same
volume, or logs and TempDB?
The goal is to reduce administrative overhead. But since we have data
files, indexes, logs, and tempDB in any case, does it make a difference from
a management standpoint whether they are all on one volume or on four
separate ones? Would it be an issue either way from a backup/restore
standpoint?
Thanks,
GaryGary,
You can still benefit from multiple volumes on a SAN, specifically for data,
log, and tempdb. (Since it is essentially a read only db,
you apparently don't need a volume for backups.) Even with one HBA, having
independent sets of spindles for different types of IO (data, log, and
tempdb) usually provides some performance gain.
If the queries are active and make any use of temp tables, then you can
benefit from having tempdb on its own volume. The database log files will be
active when loading, so keeping them on their own volume should help with
load time.
I've seen many installations with that much or more data that don't use
separate volumes for indexes. If you never update the tables, and recreate
all the indexes weekly with each new load, you should not have problems with
defragmentation. But check anyway by using DBCC SHOWCONTIG.
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"Gary Dom" <domgATsutterhealthDOTorg@.no.spam> wrote in message
news:%230VstQAnEHA.2140@.TK2MSFTNGP11.phx.gbl...
> We are about to migrate a large database server (600+ GB data) onto new
> hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
> SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box
with
> SAN attached storage. My question concerns how many logical volumes we
> should have to support the various database components.
> Currently, we have separate logical drives for the Data files, Indexes,
> Logs, and TempDB. This was done for two reasons:
> First, we had four available SCSI channels, so by creating four arrays
each
> on a different channel we increased disk I/O.
> Second, we did it to reduce fragmentation. The database is used mainly
for
> running reports and analyses off of data from our main business
application,
> which is run on a VMS cluster. That system can't handle the performance
hit
> for all of the reporting, so once a week data is dumped from the mainframe
> into the SQL Server. The rest of the week the SQL db is essentially
> read-only. So the data volume is fairly static, growing on a weekly basis
> but almost never shrinking. For performance reasons, the indexes are
> dropped and recreated weekly, the logs are truncated and then grow, and of
> course TempDB grows and shrinks as needed. By separating each component
> onto a different logical drive, we should have less fragmentation.
> Now that we are moving to a new architecture, the question has been raised
> as to whether this is still the best setup, or if it just creates
> unnecessary administrative overhead. Obviously we no longer get a
> performance gain from multiple I/O channels, because all of the storage
will
> be accessed via the same fiber channel to the SAN.
> As for the fragmentation issue, is it really that much of a problem?
Would
> it cause issues if we were to, say, combine data and indexes on the same
> volume, or logs and TempDB?
> The goal is to reduce administrative overhead. But since we have data
> files, indexes, logs, and tempDB in any case, does it make a difference
from
> a management standpoint whether they are all on one volume or on four
> separate ones? Would it be an issue either way from a backup/restore
> standpoint?
> Thanks,
> Gary
>
>sql
hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box with
SAN attached storage. My question concerns how many logical volumes we
should have to support the various database components.
Currently, we have separate logical drives for the Data files, Indexes,
Logs, and TempDB. This was done for two reasons:
First, we had four available SCSI channels, so by creating four arrays each
on a different channel we increased disk I/O.
Second, we did it to reduce fragmentation. The database is used mainly for
running reports and analyses off of data from our main business application,
which is run on a VMS cluster. That system can't handle the performance hit
for all of the reporting, so once a week data is dumped from the mainframe
into the SQL Server. The rest of the week the SQL db is essentially
read-only. So the data volume is fairly static, growing on a weekly basis
but almost never shrinking. For performance reasons, the indexes are
dropped and recreated weekly, the logs are truncated and then grow, and of
course TempDB grows and shrinks as needed. By separating each component
onto a different logical drive, we should have less fragmentation.
Now that we are moving to a new architecture, the question has been raised
as to whether this is still the best setup, or if it just creates
unnecessary administrative overhead. Obviously we no longer get a
performance gain from multiple I/O channels, because all of the storage will
be accessed via the same fiber channel to the SAN.
As for the fragmentation issue, is it really that much of a problem? Would
it cause issues if we were to, say, combine data and indexes on the same
volume, or logs and TempDB?
The goal is to reduce administrative overhead. But since we have data
files, indexes, logs, and tempDB in any case, does it make a difference from
a management standpoint whether they are all on one volume or on four
separate ones? Would it be an issue either way from a backup/restore
standpoint?
Thanks,
GaryGary,
You can still benefit from multiple volumes on a SAN, specifically for data,
log, and tempdb. (Since it is essentially a read only db,
you apparently don't need a volume for backups.) Even with one HBA, having
independent sets of spindles for different types of IO (data, log, and
tempdb) usually provides some performance gain.
If the queries are active and make any use of temp tables, then you can
benefit from having tempdb on its own volume. The database log files will be
active when loading, so keeping them on their own volume should help with
load time.
I've seen many installations with that much or more data that don't use
separate volumes for indexes. If you never update the tables, and recreate
all the indexes weekly with each new load, you should not have problems with
defragmentation. But check anyway by using DBCC SHOWCONTIG.
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"Gary Dom" <domgATsutterhealthDOTorg@.no.spam> wrote in message
news:%230VstQAnEHA.2140@.TK2MSFTNGP11.phx.gbl...
> We are about to migrate a large database server (600+ GB data) onto new
> hardware. It is currently on a 450 MHz quad CPU, 4 GB RAM box with local
> SCSI storage, and will be moving to a new 3 GHz Quad CPU, 6 GB RAM box
with
> SAN attached storage. My question concerns how many logical volumes we
> should have to support the various database components.
> Currently, we have separate logical drives for the Data files, Indexes,
> Logs, and TempDB. This was done for two reasons:
> First, we had four available SCSI channels, so by creating four arrays
each
> on a different channel we increased disk I/O.
> Second, we did it to reduce fragmentation. The database is used mainly
for
> running reports and analyses off of data from our main business
application,
> which is run on a VMS cluster. That system can't handle the performance
hit
> for all of the reporting, so once a week data is dumped from the mainframe
> into the SQL Server. The rest of the week the SQL db is essentially
> read-only. So the data volume is fairly static, growing on a weekly basis
> but almost never shrinking. For performance reasons, the indexes are
> dropped and recreated weekly, the logs are truncated and then grow, and of
> course TempDB grows and shrinks as needed. By separating each component
> onto a different logical drive, we should have less fragmentation.
> Now that we are moving to a new architecture, the question has been raised
> as to whether this is still the best setup, or if it just creates
> unnecessary administrative overhead. Obviously we no longer get a
> performance gain from multiple I/O channels, because all of the storage
will
> be accessed via the same fiber channel to the SAN.
> As for the fragmentation issue, is it really that much of a problem?
Would
> it cause issues if we were to, say, combine data and indexes on the same
> volume, or logs and TempDB?
> The goal is to reduce administrative overhead. But since we have data
> files, indexes, logs, and tempDB in any case, does it make a difference
from
> a management standpoint whether they are all on one volume or on four
> separate ones? Would it be an issue either way from a backup/restore
> standpoint?
> Thanks,
> Gary
>
>sql
How many instances in one luster box
hi,
How many instances could have in an active/passive and an active/active
cluster box ?
Thanks,
It states in the SQL2005 cluster active/passive (SQL2005foc.pdf) install
that you can have over 21 but the requirements for each instance is a
dedicated data drive if you intend for the failover to work per
instance, Network Name and IP per instance (this could be a "maybe"
depending on port/connections requirements of your apps and if they are
cluster aware). How many drive letters are availiable if you have to
assign one per instance
. Resources like Memory and CPU may be
difficult to assign. Enjoy!
Mary
info@.sqltime.com
*** Sent via Developersdex http://www.codecomments.com ***
|||The names come from when we were dealing primarily with 2-node clusters.
Active/passive = 1 instance of SQL Server running (meaning only one of the
two servers was being used). Active/Active = 2 instances of SQL Server running
(typically one instance per physical server).
As far as how many instances you can run on one cluster, I believe it depends
on the # of instances allowed per version of SQL Server, cluster or not.
Those numbers are:
SQL Server 2000: 16
SQL Server 2005: 16 (not Enterprise Edition), 50 (Enterprise Edition)
The limit for SQL Server 2005 Enterprise Edition could never be reached,
though, because you would exhaust the # of drive letters (26 max). The example
given in the SQL Server 2005 Books Online documentation has 23 separate instances...
which I suppose is possible if the first 3 drive letters are assigned to
the system drive, the quorum drive, and the DTC drive.
K. Brian Kelley, brian underscore kelley at sqlpass dot org
http://www.truthsolutions.com/
> hi,
> How many instances could have in an active/passive and an
> active/active cluster box ?
> Thanks,
>
|||I've had 16 instances on serveral 4 node x64 clusters which is a fairly
reasonable practical limit because as has already been stated you will run
out of drive letters. In this scenario, we used mount points for each
instance for data/logs/tempdb/backups. It actually worked very well (takes a
while to install and service pack mind you!) after some initial sql setup
related issues with the consistency checker which were fixed by applying the
latest COM+ hotfix rollup.
HTH,
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
"mecn" <mecn2002@.yahoo.com> wrote in message
news:O6DhThmaHHA.2448@.TK2MSFTNGP02.phx.gbl...
> hi,
> How many instances could have in an active/passive and an active/active
> cluster box ?
> Thanks,
>
|||Can you use Mount Points if one side of your cluster is a Virtual Server
(or VMware server)?
Thanks,
Mary
*** Sent via Developersdex http://www.codecomments.com ***
|||Not sure, I've never tried mixing a physical server with a VM in a cluster
(it would certainly be an unsupported configuration). I've actually found
Virtual Server to be more useful for testing than VMWare as we seem to see a
lot of delayed lost writes with VMWare shared disks (although this may be a
configuration issue). I find using VM's very useful for training and testing
our automated cluster installation.
HTH,
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
"Mary Myers Devlugt" <info@.sqltime.com> wrote in message
news:ejUs68zaHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Can you use Mount Points if one side of your cluster is a Virtual Server
> (or VMware server)?
> Thanks,
> Mary
>
> *** Sent via Developersdex http://www.codecomments.com ***
|||"Mary Myers Devlugt" <info@.sqltime.com> wrote in message
news:ejUs68zaHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Can you use Mount Points if one side of your cluster is a Virtual Server
> (or VMware server)?
Yes you can.
However, such a configuration would not be supported. A non-supported
configuration sure doesn't meet the requirements of a highly available
environment, either.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
How many instances could have in an active/passive and an active/active
cluster box ?
Thanks,
It states in the SQL2005 cluster active/passive (SQL2005foc.pdf) install
that you can have over 21 but the requirements for each instance is a
dedicated data drive if you intend for the failover to work per
instance, Network Name and IP per instance (this could be a "maybe"
depending on port/connections requirements of your apps and if they are
cluster aware). How many drive letters are availiable if you have to
assign one per instance
. Resources like Memory and CPU may bedifficult to assign. Enjoy!
Mary
info@.sqltime.com
*** Sent via Developersdex http://www.codecomments.com ***
|||The names come from when we were dealing primarily with 2-node clusters.
Active/passive = 1 instance of SQL Server running (meaning only one of the
two servers was being used). Active/Active = 2 instances of SQL Server running
(typically one instance per physical server).
As far as how many instances you can run on one cluster, I believe it depends
on the # of instances allowed per version of SQL Server, cluster or not.
Those numbers are:
SQL Server 2000: 16
SQL Server 2005: 16 (not Enterprise Edition), 50 (Enterprise Edition)
The limit for SQL Server 2005 Enterprise Edition could never be reached,
though, because you would exhaust the # of drive letters (26 max). The example
given in the SQL Server 2005 Books Online documentation has 23 separate instances...
which I suppose is possible if the first 3 drive letters are assigned to
the system drive, the quorum drive, and the DTC drive.
K. Brian Kelley, brian underscore kelley at sqlpass dot org
http://www.truthsolutions.com/
> hi,
> How many instances could have in an active/passive and an
> active/active cluster box ?
> Thanks,
>
|||I've had 16 instances on serveral 4 node x64 clusters which is a fairly
reasonable practical limit because as has already been stated you will run
out of drive letters. In this scenario, we used mount points for each
instance for data/logs/tempdb/backups. It actually worked very well (takes a
while to install and service pack mind you!) after some initial sql setup
related issues with the consistency checker which were fixed by applying the
latest COM+ hotfix rollup.
HTH,
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
"mecn" <mecn2002@.yahoo.com> wrote in message
news:O6DhThmaHHA.2448@.TK2MSFTNGP02.phx.gbl...
> hi,
> How many instances could have in an active/passive and an active/active
> cluster box ?
> Thanks,
>
|||Can you use Mount Points if one side of your cluster is a Virtual Server
(or VMware server)?
Thanks,
Mary
*** Sent via Developersdex http://www.codecomments.com ***
|||Not sure, I've never tried mixing a physical server with a VM in a cluster
(it would certainly be an unsupported configuration). I've actually found
Virtual Server to be more useful for testing than VMWare as we seem to see a
lot of delayed lost writes with VMWare shared disks (although this may be a
configuration issue). I find using VM's very useful for training and testing
our automated cluster installation.
HTH,
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
"Mary Myers Devlugt" <info@.sqltime.com> wrote in message
news:ejUs68zaHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Can you use Mount Points if one side of your cluster is a Virtual Server
> (or VMware server)?
> Thanks,
> Mary
>
> *** Sent via Developersdex http://www.codecomments.com ***
|||"Mary Myers Devlugt" <info@.sqltime.com> wrote in message
news:ejUs68zaHHA.4552@.TK2MSFTNGP05.phx.gbl...
> Can you use Mount Points if one side of your cluster is a Virtual Server
> (or VMware server)?
Yes you can.
However, such a configuration would not be supported. A non-supported
configuration sure doesn't meet the requirements of a highly available
environment, either.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
Monday, March 12, 2012
how long to restore
I am trying to restore an sql database it still showing SQL is currently in
the process of restoring a backup.set box
It been like this for over hour no incatation in progress bar yet.
My databse is 4gb so I except take a long time but is there something wrong
when it not showing any process or is this a bug or something? My second
question will show progress evntually or will just complete and finally apmx
how long should it take? on p4 1gb computerHi Frank,
I suggest you to go through BACKUP section in BOL. One of the parameter
called STATS gives the progress of the restore.
--
Thanks
Yogish
the process of restoring a backup.set box
It been like this for over hour no incatation in progress bar yet.
My databse is 4gb so I except take a long time but is there something wrong
when it not showing any process or is this a bug or something? My second
question will show progress evntually or will just complete and finally apmx
how long should it take? on p4 1gb computerHi Frank,
I suggest you to go through BACKUP section in BOL. One of the parameter
called STATS gives the progress of the restore.
--
Thanks
Yogish
Friday, February 24, 2012
How I can register MSSQL Server 2000 by IP Address
How I can register MSSQL Server 2000 by IP Address-
I installed MSSQL Server 2000 sp3a, Enterprise edition on windows 2000 advanced server box with sp4. Its primarily give instance with name like servername/sqlindia, Where sqlindia is instance and servername is physical machine name.
I would like to registration of sqlserver instance by IP Address. How I can do it.
Thanking You
R.MallEnsure the client network utility is mentioned with ALIAS using IP Address.
I installed MSSQL Server 2000 sp3a, Enterprise edition on windows 2000 advanced server box with sp4. Its primarily give instance with name like servername/sqlindia, Where sqlindia is instance and servername is physical machine name.
I would like to registration of sqlserver instance by IP Address. How I can do it.
Thanking You
R.MallEnsure the client network utility is mentioned with ALIAS using IP Address.
Subscribe to:
Posts (Atom)