Thank You so much Krishna
As we are planning to capture the workload starting 5AM , So we are
planning to build/restore the test system/database from the prod
backup(Prod is ~20TB in size) till that exact 5AM. So that the subsequent
replay(mainly DML) wont error out and will give us a good view of the DML
performance too. But in case we have to break the capture into 3-4 pieces ,
say one capture 5 to 7Am, another capture was taken from 9Am to 11Am etc.
So even there was very minimal activity between 7AM to 9AM (and thus we
didn't capture the workload ), but that can cause failure of the 9AM to
11AM replay on the same test database , if some of the DML happens between
7Am to 9AM. Please correct me if I'm wrong? or you are suggesting to
restore it multiple times, say one with 5AM another with 9AM and perform
the replay/test activity each time by flashing back the test database to
the previous point?
On Tue, Aug 31, 2021 at 2:12 PM Krishnaprasad Yadav <chrishna0007@xxxxxxxxx>
wrote:
Pap,
i suggest you can divide the slot based on workload, in your case i would
recommend having 3/4 rounds of testing for 2 hours each. capture and replay
for every 2 hours slot will be based on busy time , i believe you will
cover most of the busy time in this fashion.
Regards,
Krishna
On Tue, 31 Aug 2021 at 14:07, Pap <oracle.developer35@xxxxxxxxx> wrote:
And thus the question coming to mind is, if we say we have our normal day
starting from 5AM till 11PM, should there be an option for us to divide the
capture into multiple pieces/periods to only cover the busy work loads and
not include idle hours? or one capture workload of 5AM to 11PM for a full
period is recommended only?
On Tue, Aug 31, 2021 at 1:46 PM Pap <oracle.developer35@xxxxxxxxx> wrote:
Thank you so much.
Got your point regarding the preprocessing time, which depends on the
capture time and may not be linearly proportional. But what my
question was, if we capture the workload for long hours say 15-16 hours
won't the replay happen exactly in the same time gap and same frequency
same order of how the sqls(insert/update/delete/selects) were submitted in
the production system while the workload was captured?
Say our system was busy or jobs were running from 1AM to 5AM and then
again there was no activity from 5AM to 8AM and the jobs again started from
8AM to 11AM. So I am expecting the awr to capture the details(for a period
of 1Am to 11AM) in the same order/time gap/frequency etc as during capture
, so it should not average out the performance(ASH/AWR) figures
during replay on the test system even if the capture time is larger or
smaller. Please correct me if my understanding is wrong here?
On Tue, Aug 31, 2021 at 11:25 AM Krishnaprasad Yadav <
chrishna0007@xxxxxxxxx> wrote:
Hi,
If your capture file size is high , then preprocessing also take high
amount of time and replay too take more than capture time depending upon
paramteres involved in replay .
Sample testing can't be assured to be accurate.
Regards,
Krishna
On Tue, 31 Aug 2021, 03:22 Anton Spitsyn, <antonio.spitsyn@xxxxxxxxx>
wrote:
Hi Pap,
After you capture the workload, the next step it's preprocessing. It
depends on the size and type of your workload, but be aware that
preprocessing time increases nonlinearly with increasing capture workload
time. For example, we were able to preprocess only 30-60 minutes of
captured production workload in the cluster in a reasonable amount of
time.
--
Anton Spitsyn
Database Administrator
http://aspitsyn.wordpress.com
On Mon, Aug 30, 2021 at 11:18 PM Pap <oracle.developer35@xxxxxxxxx>
wrote:
Hello Listers, We are trying to use the "real application testing"
feature to test one of the upgrade changes. And during the capture
workload
from production ,we want to do it for the whole day(~15-16hrs) as we have
different critical jobs running throughout and want to replay that
~15-16hrs of captured workload to see and compare their response as
against
run time production.
Few team members stating we should not capture the workload for such
a long duration but should do it for a 5-6hrs window only as a bigger
window will average out the results and we may miss real performance
issues? Want to understand from experts, if that thought is correct?
