If either one of the systems go down, they both go down. I'm not looking for a high availability solution. I'm looking for:
1. User issues INSERT statement on SERVER A, it gets replicated to SERVER B.
2. If user issues INSERT on SERVER B, it gets replicated to SERVER A.
Rules:
1. An INSERT is not committed to either system until it has replicated to the remote system.
I'd also settle for a topology where if rule #1 can't be obtained out of the box then whichever system was the first one to INSERT wins, and the last one to UPDATE wins.
As I understanding it journaling does most of this, but I have found no documentation that states how to do bi-directional and also shows you the topology diagrams along with the control panels/GUI tools that aide in conflict resolution, as well as how to define conflict resolution rules within IBM i DB2.
Again, documentation seems scarce on this subject. Very plentiful in LUW and other DB platforms. Just point me to the redbook please :-)
-----Original Message-----
From: CRPence [mailto:CRPbottle@xxxxxxxxx]
Sent: Monday, March 11, 2013 3:11 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: SQL Result Paging
On 11 Mar 2013 12:28, Mike Wills wrote:
I have a query that is sub-second. When I run it on the green-screen,
I get a result as soon as I hit "enter". So I know that that query
itself isn't the problem. I am returning around 800 results.
The interactive STRSQL query report run output to display runs with
effectively the implicit clause specifications of OPTIMIZE FOR 19 ROWS
and FOR READ ONLY, and probably also the WITH NC. Unless B=Bottom with
REFRESH(*FORWARD) had been requested after the first subset of rows
appeared, the query is still pending completion; i.e. only the first
FETCH was requested.
Comparing the plans for the two query requests may have value.
However, when I pipe it through my C# ASP.NET application, it takes
FOREVER (okay 3 minutes), but lets be honest, that is forever in the
web world.
And when that SQL query includes all of those clauses noted above?
If just the OPTIMIZE clause for a smaller number of rows improves the
query response for the return of all data, then that may indicate an
issue with the optimizer implementing via a sub-optimal path.
<<SNIP paging inquiry>>
midrange.com
