Showing posts with label disk. Show all posts
Showing posts with label disk. Show all posts

Thursday, March 29, 2012

Does SQL server support failover without sahred disk or external storage

Hi fellow,
I'd like to know if is it possible to configure SQL Server in a cluster enviroment to provide failover, without using shared disks or external storages.
What I wish is setup and cluster to provide failover in case of a hardware malfuction only between servers A and B. The data "integrity" however will be guarantee by my application. I only wish to provide my clients an transparent and automatic way to c
onnect to server B in case of failure of server A, behaving just like the virtual server in a cluster enviroment.
Anyone knows if this is possible?
Cheers,
Eric.
SQL does not have such a feature. The SQL failover cluster model requires a
common dagta store that can be arbitrated between nodes so that a single
node failure is recoverable.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Eric" <anonymous@.discussions.microsoft.com> wrote in message
news:8F02A739-E588-4C27-9CF2-63999EFBE802@.microsoft.com...
> Hi fellow,
> I'd like to know if is it possible to configure SQL Server in a cluster
enviroment to provide failover, without using shared disks or external
storages.
> What I wish is setup and cluster to provide failover in case of a
hardware malfuction only between servers A and B. The data "integrity"
however will be guarantee by my application. I only wish to provide my
clients an transparent and automatic way to connect to server B in case of
failure of server A, behaving just like the virtual server in a cluster
enviroment.
> Anyone knows if this is possible?
> Cheers,
> Eric.
|||Yes, SQL Server does support failover in that situation. It will not
operate exactly like a virtual server in a cluster environment.
You can use either replication or log shipping to create the second copy of
the database on Server B. Each will have latency as far as what data
exists. Each one has different processes for failing over as well as
failing back. If you search back across this newsgroups and the replication
newsgroup for the last 2 months, there will be more than enough information
posted about that subject.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||Hi Michel,
The replication and log shipping solves the problem of keeping data between servers ok, but my point is related to the client.
Is there a way to make the client service start using the second server automatically in case of server A failure? For example, my apllication use ODBC to connect to DB_SERVER, wich will be directed to Server A only if it is availble. If not, then DB_SE
RVER will point automatically to Server B. The Client is unware of any change, just like a failover cluster.
Cheers,
Eric
|||Not in the current version of SQL Server. However, database mirroring in
Yukon may be of interest to you. Have a look here:
http://www.microsoft.com/technet/pro...n123121120120.
Of course, the downside is that Yukon won't be available until next year...
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"Eric" <anonymous@.discussions.microsoft.com> wrote in message
news:32D7E78D-55B4-4B49-A1FE-2385D41E9BA0@.microsoft.com...
> Hi Michel,
> The replication and log shipping solves the problem of keeping data
between servers ok, but my point is related to the client.
> Is there a way to make the client service start using the second server
automatically in case of server A failure? For example, my apllication use
ODBC to connect to DB_SERVER, wich will be directed to Server A only if it
is availble. If not, then DB_SERVER will point automatically to Server B.
The Client is unware of any change, just like a failover cluster.
> Cheers,
> Eric
|||Nope to the original question and no even to database mirroring.
If using replication or log shipping, you will have to write code into you
application to detect it, redirect, and reconnect.
When Yukon ships and if database mirroring is in the product, when the
primary fails, you will be disconnected. You will then have to reinitiate
the connection. You just won't have to redirect to a different server name.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||From Lubor's presentation at the PASS Summit (public info here), there is
supposed to be client library awareness so that an automatic, transparent
shift happens with database mirroring.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:%23ukY8TiLEHA.3096@.TK2MSFTNGP11.phx.gbl...
> Nope to the original question and no even to database mirroring.
> If using replication or log shipping, you will have to write code into you
> application to detect it, redirect, and reconnect.
> When Yukon ships and if database mirroring is in the product, when the
> primary fails, you will be disconnected. You will then have to reinitiate
> the connection. You just won't have to redirect to a different server
name.
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>
|||Yes, there is supposed to be client library awareness. The feature is
currently called "transparent client redirect". The transparent redirect
part is that an application doesn't need to change names. It is called
"redirect". It is not called "reconnect". The information is in the PASS
session you refer to. The same basic information with a few extensions is
also contained in a database mirroring session I did in London at DevWeek as
well as in Vienna at XtremeSQL.
There is also a very big word of caution here since this has the potential
to head the wrong direction. Yukon is still in Beta 1. Beta 1 is still
NDA. The only thing allowed to be discussed is what is publicly released.
Outside of that, there are a small group of people authorized to talk about
it. At this point, it is best to not even discuss Yukon features or
functionality. If there are specific questions on Yukon, they can be asked
in "other venues".
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||I am very aware of my NDA obligations on Yukon. I only discuss items where
I can refer to a public statement by an authorized Microsoft representative,
such as the Beta 1 presentations at PASS.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:%23O$GGamLEHA.3324@.TK2MSFTNGP10.phx.gbl...
> Yes, there is supposed to be client library awareness. The feature is
> currently called "transparent client redirect". The transparent redirect
> part is that an application doesn't need to change names. It is called
> "redirect". It is not called "reconnect". The information is in the PASS
> session you refer to. The same basic information with a few extensions is
> also contained in a database mirroring session I did in London at DevWeek
as
> well as in Vienna at XtremeSQL.
> There is also a very big word of caution here since this has the potential
> to head the wrong direction. Yukon is still in Beta 1. Beta 1 is still
> NDA. The only thing allowed to be discussed is what is publicly released.
> Outside of that, there are a small group of people authorized to talk
about
> it. At this point, it is best to not even discuss Yukon features or
> functionality. If there are specific questions on Yukon, they can be
asked
> in "other venues".
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>

Friday, March 9, 2012

Does Disk space affect Database performance

We have aroud 12 databases running on a live production server which is
segmented
into 3 physical drives.
The E drive is where data and logs are stored.
We have implemented a back up strategy over the past week. As a result , the
E
drive has shrunk in size.
Its a total of 135 GB but has 125 MB free.
Consequently we have noticed that various VB6 and MS Access applications are
suffering from slow performance.
But..the apps are merely querying data and bringing it back to the client.
My question is the lack of disk space affecting performance?
The lack of disk space will cause performance problems, iirc the MS
recommendation is to not exceed about 80% capacity on a disk/disk set.
Not sure what you mean by backing up causing the disk to shrink in
size? Also not a good idea to have log and data files on the same
physical drive.
ALI

Does Disk space affect Database performance

We have aroud 12 databases running on a live production server which is
segmented
into 3 physical drives.
The E drive is where data and logs are stored.
We have implemented a back up strategy over the past week. As a result , the
E
drive has shrunk in size.
Its a total of 135 GB but has 125 MB free.
Consequently we have noticed that various VB6 and MS Access applications are
suffering from slow performance.
But..the apps are merely querying data and bringing it back to the client.
My question is the lack of disk space affecting performance?The lack of disk space will cause performance problems, iirc the MS
recommendation is to not exceed about 80% capacity on a disk/disk set.
Not sure what you mean by backing up causing the disk to shrink in
size? Also not a good idea to have log and data files on the same
physical drive.
ALI

Does Disk space affect Database performance

We have aroud 12 databases running on a live production server which is
segmented
into 3 physical drives.
The E drive is where data and logs are stored.
We have implemented a back up strategy over the past week. As a result , the
E
drive has shrunk in size.
Its a total of 135 GB but has 125 MB free.
Consequently we have noticed that various VB6 and MS Access applications are
suffering from slow performance.
But..the apps are merely querying data and bringing it back to the client.
My question is the lack of disk space affecting performance?The lack of disk space will cause performance problems, iirc the MS
recommendation is to not exceed about 80% capacity on a disk/disk set.
Not sure what you mean by backing up causing the disk to shrink in
size? Also not a good idea to have log and data files on the same
physical drive.
ALI