|
midrange.com
That's what i'm talking about and a much more exact way of describing it.
;)
It sounds like you'll be doing it in an LPAR, so the target LPAR would have
to be big enough to contain a copy of all the Mimix'ed files, some much
smaller amount of 'in flight' data in receivers, and whatever growth you
forecast in the source/target database sizes over a certain time period.
rob@xxxxxxxxx
Sent by:
midrange-l-bounce To
s@xxxxxxxxxxxx Midrange Systems Technical
Discussion
<midrange-l@xxxxxxxxxxxx>
10/26/2006 04:11 cc
PM
Subject
RE: Going from little to no
Please respond to journalling to MIMIX
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
By "additional copies" do you simply mean LIBRARYa/FILEb on System1 now
also being duplicated in LIBRARYa/FILEb on System2, or, is there some
other concept I need to be aware of?
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
ChadB@xxxxxxxxxxxxxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/26/2006 03:48 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc
Subject
RE: Going from little to no journalling to MIMIX
From what i've seen of the Mimix journaling activity on our system the
size
of the receivers doesn't get too bad. Because they are sent off to the
backup box so frequently, they don't really build up all that much. There
is probably a good bit of choice in how this can be configured (we are an
OLD Mimix shop and really are running an older version of the app, and
over
SNA at that...). I would think the latest greatest versions are even more
efficient in terms of DASD impact.
It seems like the bulk of the DASD used would be for the additional copies
of the DB files that are kept up to date by the Mimix journal activity
(which should be pretty easy to define, at least initally - then they
should grow at a similar rate to your 'main' DB files that are being
mirrored). The receivers themselves should be more ephemeral 'in flight'
type objects that run at (more or less) a steady size, but don't really
accumulate.
"Jones, John
\(US\)"
<John.Jones@xxxxx To
l.com> "Midrange Systems Technical
Sent by: Discussion"
midrange-l-bounce <midrange-l@xxxxxxxxxxxx>
s@xxxxxxxxxxxx cc
Subject
10/26/2006 03:37 RE: Going from little to no
PM journalling to MIMIX
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
I can't give any projection as the journal hits will depend a lot on the
nature of your database activity and if you journal everything vs. the
minimum. See http://www.redbooks.ibm.com/abstracts/tips0626.html and
http://www.redbooks.ibm.com/abstracts/tips0607.html .
That said, how about only keeping the minimum amount of receivers on the
production machine? Cut your receivers frequently and once you know
MIMIX has shipped the contents to the remote box just delete them. Back
'em up first if desired or if your audit policy dictates.
We journal the bulk of the main JDE database. Without the minimizing
techniques above our receiver goes anywhere from 700MB-2.5GB a day with
around 300 concurrent users. Basically it's small enough that I don't
even think about it. YMMV of course.
If you're concerned about performance and can stand a risk of losing the
most recent transactions in a catastrophic failure, check this tip about
journal caching: http://www.redbooks.ibm.com/abstracts/tips0627.html
John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces+john.jones=am.jll.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+john.jones=am.jll.com@xxxxxxxxxxxx] On Behalf
Of rob@xxxxxxxxx
Sent: Thursday, October 26, 2006 2:15 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Going from little to no journalling to MIMIX
Boss wanted some projections on how much disk would be needed on a whole
new lpar for Mimix. Our current system has little to no journalling and
receivers. So I basically had to WAG a growth estimate for that of 30%.
Anyone have some before/after RTVDSKINF/PRTDSKINF combos? I would think
that it might change based on age afterwards, receiver retention policy
and a host of other things I think I'll learn very quickly about.
Here's some projections. However it may not paste well from Excel into
simply text supported by a list server.
GDIHQ - Current
% of Size in
Description Disk 1,000,000 bytes
User libraries 11.66 551242.5
User directories 70.89 3351637.58
Folders and documents 0.02 715.67
QSYS 0.13 6304.52
Other IBM libraries 0.57 27064.37
Licensed Internal Code 0.09 4443.1
Temporary space 0.83 39396.16
Unused space 15.54 734666.63
System internal objects 0.17 7915.72
Objects not in a library0.02 712.21
TOTAL 99.92 4724098.46
GDIHQ2 - Projected
% of Size in
Description Disk 1,000,000 bytes
User libraries 45.72% 716615.25
User directories 28.75% 450673.7357 * Minus Domino &
some IXS cards
Folders and documents 0.05% 715.67
QSYS 0.40% 6304.52
Other IBM libraries 1.73% 27064.37
Licensed Internal Code 0.28% 4443.1
Temporary space 2.51% 39396.16
Unused space 20.00% 313460.1839
System internal objects 0.51% 7915.72
Objects not in a library 0.05% 712.21
TOTAL 100.00% 1567300.92
3 IXS cards -418051.5047
New Total 1149249.415
Subtract these directories bytes
/Domino 60,143,998,145
/DOMFAX01 863,139,842
/GDDATA 14,754,848,886
/GDSHELP 23,109,347,466
/GDSSALES 3,334,388,500
/INTERNOTES 2,043,500,278
/LEISERVE 1,027,821,254
/NOTES01 468,804,094,348
/QUALITY 36,456,664,248
/SAMETIME01 1,098,278,047
611,636,081,014
Subtract these IXS files bytes
CITRIX1 16,680,919,302
CITRIX2 17,618,601,222
CITRIX4 17,774,881,542
GDSBAAN1 11,227,541,508
GDSEDI1 19,954,612,490
GDSSQL 26,493,678,342
HQLINUX 2,109,463,757,082
PVCSQL 35,113,771,782
2,254,327,763,270
Leaving these IXS cards bytes
GDSNT 290,574,616,596
HELPSERV 92,476,888,072
Add this (as yet to be determined) IXS card
Unknown IXS card 35,000,000,000
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.
This email is for the use of the intended recipient(s) only. If you have
received this email in error, please notify the sender immediately and
then
delete it. If you are not the intended recipient, you must not keep, use,
disclose, copy or distribute this email without the author's prior
permission. We have taken precautions to minimize the risk of
transmitting
software viruses, but we advise you to carry out your own virus checks on
any attachment to this message. We cannot accept liability for any loss
or
damage caused by software viruses. The information contained in this
communication may be confidential and may be subject to the
attorney-client
privilege. If you are the intended recipient and you do not wish to
receive
similar electronic messages from us in future then please respond to the
sender to this effect.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs.
For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
ForwardSourceID:NT00056FF2--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs.
For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
ForwardSourceID:NT00057026
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
