|
Performance has five things involved: disk, memory, processor and tape
and the fifth being the cabling, SAN, I/O port going to the tape. Let's
assume that one saves access paths, it's been changed to the default many
releases ago.
In a restore the biggest constraint will be tape, then disk. It takes an
awful lot to stress the connection speed to the tape library. Memory and
processor concerns follow behind.
We're talking about tape libraries with multiple drives in them. One at a
time or four at once should not matter to the tape library, since you have
multiple drives.
The biggest reason for the semi restricted state is that you don't want
users on it trying to do stuff during a full system restore. Not really
to speed up the restore, but it probably helps.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Musselman, Paul" <pmusselman@xxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 11/01/2018 04:10 PM
Subject: RE: P7 V7R3 to P9 V7R3 migration recommendations /
suggestions
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
What's the system overhead difference between a single-threaded restore in
restricted state vs 4-at-a-time in mostly restricted?
I know the system has to read the library header from the tape, then spend
a lot of time allocating space. In fully-restricted state it doesn't have
to check for any kind of conflict, and just grabs space then restores
data. In mostly-restricted, you have 4 jobs grabbing for space.
What's the tipping point between the two?
Or has faster system hardware overcome the conflict?
Paul E Musselman
PaulMmn@xxxxxxxxxxxxx
--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
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.