Question about comunication issues between Principal and Mirror

Hi there.

Imagine this scenario in High Availability mode :

The principal sends a transaction log to the mirror, then the mirror saves the log on disk and then notify the principal. What happen if the acknowledge is lost, because a network failure(back on track in 1 or 2 seconds) and the principal dont receive it ?

In this case an automatic failover will not occurr, and i dont really know what happen next...

Will the mirror resend the ack ?

The heartbeat mechanism plays an important role in solving this scenario ?

The principal must receive the ack to commit the transaction, and i′m not seeing how the problem is solved.

I have one other question. In "Database Mirroring in SQL Server 2005" document, is said that "...unlike a distributed transaction, failures to commit on the mirror will not cause a transaction rollback on the principal".

But in this case the mirror will be inconsistent with the principal. How is this problem solved ?

Thanks in advance.

RDSC wrote:

Imagine this scenario in High Availability mode :

The principal sends a transaction log to the mirror, then the mirror saves the log on disk and then notify the principal. What happen if the acknowledge is lost, because a network failure(back on track in 1 or 2 seconds) and the principal dont receive it ?

...

But in this case the mirror will be inconsistent with the principal. How is this problem solved ?

Hi there,

In high availability mode the principle will continue to serve SQL, and your mirror will be out of sync (the witness server is the key here, and an error state 6 (mirror lost) should be evident).

The inconsistency will be resolved when the mirror is successfully synchronized, depending on the cause of the problem, when the mirror is able to communicate with the witness again it should sync automatically, or you might be able to issue a ALTER DATABASE databasename SET PARTNER RESUME command to resync the mirror.

|||

Hi there, yesterday i saw some documentation about DBMirroring and suceeded in finding the answers about this issues.

That′s true what you say, thanks for the help.

question about cached queries

Hi
I am trying to understand SQL Server's internals and I was wondering
how syscacheobjects works with memory.
If an application sends a query to the database, does the execution plan
stay in both memory and syscacheobjects or is syscacheobjects
a table representation of what's in memory? When the optimizer
looks to try to re use a plan, where does it look?
TIA
Dave
syscacheobjects is not a real table:
SELECT OBJECTPROPERTY(id, 'TableIsFake')
FROM sysobjects
WHERE id = OBJECT_ID('syscacheobjects')
It is essentially a view over the procedure cache, which is the area in
memory where procedures are cached (good name for it, isn't it?) The
optimizer looks at the memory structures, not at the table.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"Dodo Lurker" <none@.noemailplease> wrote in message
news:3cudnTXSXpYJJgzeRVn-hg@.comcast.com...
> Hi
> I am trying to understand SQL Server's internals and I was wondering
> how syscacheobjects works with memory.
> If an application sends a query to the database, does the execution plan
> stay in both memory and syscacheobjects or is syscacheobjects
> a table representation of what's in memory? When the optimizer
> looks to try to re use a plan, where does it look?
> TIA
> Dave
>

question about cached queries

Hi
I am trying to understand SQL Server's internals and I was wondering
how syscacheobjects works with memory.
If an application sends a query to the database, does the execution plan
stay in both memory and syscacheobjects or is syscacheobjects
a table representation of what's in memory? When the optimizer
looks to try to re use a plan, where does it look?
TIA
Davesyscacheobjects is not a real table:
SELECT OBJECTPROPERTY(id, 'TableIsFake')
FROM sysobjects
WHERE id = OBJECT_ID('syscacheobjects')
It is essentially a view over the procedure cache, which is the area in
memory where procedures are cached (good name for it, isn't it?) The
optimizer looks at the memory structures, not at the table.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"Dodo Lurker" <none@.noemailplease> wrote in message
news:3cudnTXSXpYJJgzeRVn-hg@.comcast.com...
> Hi
> I am trying to understand SQL Server's internals and I was wondering
> how syscacheobjects works with memory.
> If an application sends a query to the database, does the execution plan
> stay in both memory and syscacheobjects or is syscacheobjects
> a table representation of what's in memory? When the optimizer
> looks to try to re use a plan, where does it look?
> TIA
> Dave
>

question about cached queries

Hi
I am trying to understand SQL Server's internals and I was wondering
how syscacheobjects works with memory.
If an application sends a query to the database, does the execution plan
stay in both memory and syscacheobjects or is syscacheobjects
a table representation of what's in memory? When the optimizer
looks to try to re use a plan, where does it look?
TIA
Davesyscacheobjects is not a real table:
SELECT OBJECTPROPERTY(id, 'TableIsFake')
FROM sysobjects
WHERE id = OBJECT_ID('syscacheobjects')
It is essentially a view over the procedure cache, which is the area in
memory where procedures are cached (good name for it, isn't it?) The
optimizer looks at the memory structures, not at the table.
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"Dodo Lurker" <none@.noemailplease> wrote in message
news:3cudnTXSXpYJJgzeRVn-hg@.comcast.com...
> Hi
> I am trying to understand SQL Server's internals and I was wondering
> how syscacheobjects works with memory.
> If an application sends a query to the database, does the execution plan
> stay in both memory and syscacheobjects or is syscacheobjects
> a table representation of what's in memory? When the optimizer
> looks to try to re use a plan, where does it look?
> TIA
> Dave
>