-
Notifications
You must be signed in to change notification settings - Fork 18
/
oltpsetup.html
1012 lines (787 loc) · 36.8 KB
/
oltpsetup.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!-- Creator : groff version 1.22.3 -->
<!-- CreationDate: Wed May 15 16:34:57 2024 -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="generator" content="groff -Thtml, see www.gnu.org">
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<meta name="Content-Style" content="text/css">
<style type="text/css">
p { margin-top: 0; margin-bottom: 0; vertical-align: top }
pre { margin-top: 0; margin-bottom: 0; vertical-align: top }
table { margin-top: 0; margin-bottom: 0; vertical-align: top }
h1 { text-align: center }
</style>
<title>oltpsetup</title>
</head>
<body>
<h1 align="center">oltpsetup</h1>
<a href="#OVERVIEW">OVERVIEW</a><br>
<a href="#PROJECTS">PROJECTS</a><br>
<a href="#DIRECTORIES">DIRECTORIES</a><br>
<a href="#PREPARATION">PREPARATION</a><br>
<a href="#EXPERIMENTS">EXPERIMENTS</a><br>
<a href="#PARAMETERS">PARAMETERS</a><br>
<a href="#BURSTS">BURSTS</a><br>
<a href="#CONNECTION STORMS">CONNECTION STORMS</a><br>
<a href="#24H SIMULATION">24H SIMULATION</a><br>
<a href="#VERIFICATION">VERIFICATION</a><br>
<a href="#REMOTE EXECUTION">REMOTE EXECUTION</a><br>
<a href="#SAVING PASSWORDS IN KEYRING">SAVING PASSWORDS IN KEYRING</a><br>
<a href="#UNDOCUMENTED PARAMETERS">UNDOCUMENTED PARAMETERS</a><br>
<a href="#BUGS">BUGS</a><br>
<a href="#COPYRIGHT">COPYRIGHT</a><br>
<a href="#SEE ALSO">SEE ALSO</a><br>
<hr>
<h2>OVERVIEW
<a name="OVERVIEW"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">This page shows
how to setup and configure the oltp workload that is
included with the RWP*Load Simulator</p>
<h2>PROJECTS
<a name="PROJECTS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">On the system,
that will be your application server, you will be running
one or several projects that typically differ in how and to
which database they connect. Each project must have a short
name such as dbone, dbtwo, etc. For the rest of the
discussion on this page, the project name <b>key</b> is
used.</p>
<h2>DIRECTORIES
<a name="DIRECTORIES"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">In order to run
the oltp workload, you need three directories:</p>
<p style="margin-left:11%; margin-top: 1em">A <b>working
directory</b> where you keep the files that typically get
modified while you use the oltp workload. Each project will
be identified by its name and there will be two files
associated with each project; these files must be stored in
this directory. It is recommended that you create a
directory separately from your home directory, but you can
very well have multiple projects in the same directory as
each project normally just needs those two files.</p>
<p style="margin-left:11%; margin-top: 1em">A <b>results
directory</b> that will be filled with sub-directories and
files when you are using the oltp workload. You should have
one directory per project, and you should prepare sufficient
space for up to 0.5MB for each single run you perform. You
normally don’t need to inspect or modify any of the
files created.</p>
<p style="margin-left:11%; margin-top: 1em">An <b>awr
directory</b> that will be filled with sub-directories, html
files, graphs, etc while you perform the runs. This
directory must be visible externally via a browser, and it
must be writable by your login user. If you e.g. use Apache
as your web server, the directory typically must exist
somewhere under /var/www/html. You should plan to have
sufficient space for about 2MB plus 2MB per database
instance for each single run. If your webserver runs on a
different system than your runs, the directory can very well
be made available using NFS or similar.</p>
<h2>PREPARATION
<a name="PREPARATION"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">From your
RWP*Load Simulator distribution, make copies of the two
files from the oltp directory, <b>oltp.env</b> and
<b>oltp.rwl</b> to your working directory, and make the
copies named after your project. If your project it named
<b>key</b>, the files must therefore be named <b>key.env</b>
and <b>key.rwl</b></p>
<p style="margin-left:11%; margin-top: 1em">The file
<b>key.env</b> must be modified such that it sets the
environment variable RWLOLTP_NAME to your project name such
as <b>key</b>. If needed, you may also set environment
variables like TNS_ADMIN, TWO_TASK, etc. It is also
recommended to set RWLOADSIM_PATH set (include) your project
working directory.</p>
<h2>EXPERIMENTS
<a name="EXPERIMENTS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">The oltp
workload is implemented using a combination of shell and rwl
scripts. If you want to experiment with changes to the rwl
scripts, you can create a copy in your working directory of
any of the scripts found in the oltp directory of your
rwloadsim distribution. Doing so implies the script in your
working directory will be used in stead of the one in your
rwloadsim distribution, and you can therefore make those
changes you may find useful. If you do so, it is recommended
that you add a <b>printline</b> command in the beginning of
your modified script to inform about the use of an edited
rwl file.</p>
<h2>PARAMETERS
<a name="PARAMETERS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">Your projects
parameter file such as <b>key.rwl</b> contains all settings
that define your project including database credentials,
connect strings, workload size, etc. Some settings are
compulsory, others have defaults that you should initially
not change.</p>
<p style="margin-left:11%; margin-top: 1em">The following
lists all compulsory parameters.</p>
<p style="margin-left:11%; margin-top: 1em"><b>awrdirectory</b></p>
<p style="margin-left:17%;">Sets the name of the directory
where awr, html, graphs, etc will be stored. This is the
directory mentioned above that is visible externally from a
browser.</p>
<p style="margin-left:11%; margin-top: 1em"><b>resultsdir</b></p>
<p style="margin-left:17%;">Sets the name of the results
directory as explained above.</p>
<p style="margin-left:11%; margin-top: 1em"><b>normal_connect
<br>
pool_connect <br>
batch_connect</b></p>
<p style="margin-left:17%;">Sets the connect strings either
in URL style syntax such as //host/service or as names in
tnsnames.ora that will be used when the oltp workload is
executing its ordinary transactions. The first is used in
the few cases where pooling is not in effect, the latter are
used for the vast majority of cases where the transactions
use pooling, pool_connect for the typically short
transactions, batch_connect for the more batch oriented
transactions.</p>
<p style="margin-left:17%; margin-top: 1em">In most cases,
the three can be set to the same value.</p>
<p style="margin-left:17%; margin-top: 1em">If your
database under test is an autonomous database, you should
choose the connection names that have _tp at the end.</p>
<p style="margin-left:11%; margin-top: 1em"><b>pool_type
<br>
batch_type</b></p>
<p style="margin-left:17%;">Normally the vast majority of
transactions use session pools as described above. You can
alternatively run either of the two (short and more batch
oriented) using either <b>dedicated</b> or <b>drcp</b>
connections to the database by setting either of these two
parameters to the respective value.</p>
<p style="margin-left:17%; margin-top: 1em">Note that
setting either to <b>drcp</b> implies each worker thread
will use its own separate DRCP connection to the database,
and that no ordinary session pool will be created. In this
case, you must include :pooled in URL style connect string
or (server=pooled) in a tnsnames.ora entry; rwloadsim does
not verify this is done.</p>
<p style="margin-left:17%; margin-top: 1em">To achieve the
typical DRCP use case where DRCP is used <i>together</i>
with the session pool for either, you should keep the
respective parameter at its default setting implying a
session pool is used in rwloadsim, but additionally have
:pooled (or server=pooled in tnsnames.ora).</p>
<p style="margin-left:17%; margin-top: 1em">The settings
for DRCP can also be used with cman/tdm, i.e. PRCP.</p>
<p style="margin-left:17%; margin-top: 1em">Do not set
either parameter to any other value.</p>
<p style="margin-left:11%; margin-top: 1em"><b>rwl_min_pool
<br>
rwl_max_pool <br>
rwl_pool_release</b></p>
<p style="margin-left:17%;">When pool_type is set to its
default value of "sessionpool", these three
parameters control the size of the normal pool in each
process. The two former set the smallest and highest number
of database sessions in the pool, and the last parameter
sets the timeout after which idle sessions in the pool are
released by disconnecting from the database.</p>
<p style="margin-left:17%; margin-top: 1em">The default
values of respectively 3, 10 and 5.0s are normally
appropriate.</p>
<p style="margin-left:11%; margin-top: 1em"><b>max_sessionwait</b></p>
<p style="margin-left:17%;">This is the maximum time in
seconds a worker thread will wait for a session to be made
available or to be created in the pool. The time may
typically expire if the pool is already at its maximum size
and all other workers spend long time before returning their
session to the pool. This will imply the transaction will be
dropped with the drop count visible in the persec table with
a vname of ’call_failure’.</p>
<p style="margin-left:17%; margin-top: 1em">The default
value is 30.</p>
<p style="margin-left:11%; margin-top: 1em"><b>cruser_connect</b></p>
<p style="margin-left:17%;">Is set to the connect string
that will be used when schemas are created and filled with
data. In most cases, it can be the same as the
normal_connect, but if your database is an autonomous
database, using the name with _tpurgent at the end may make
data fill faster as it allows parallel processing.</p>
<p style="margin-left:11%; margin-top: 1em"><b>cruser_username
<br>
cruser_password</b></p>
<p style="margin-left:17%;">Set these to a username
respectively password that will be used for schema creation
combined with the cruser_connect connect string. The typical
username is "system" or "admin" in case
of autonomous databases.</p>
<p style="margin-left:11%; margin-top: 1em"><b>system_connect
<br>
system_username <br>
system_password</b></p>
<p style="margin-left:17%;">These will be used during
actual execution of your runs to primarily run queries
against v$ tables etc. The typical username is
"system" or "admin" in case of
autonomous databases. You can normally set them to the same
values as used for schema creation, although the connect
string should be the one ending in _tp in case of an
autonomous database.</p>
<p style="margin-left:17%; margin-top: 1em">Unless the next
three parameters are provided, the credentials will also be
used for gathering awr snapshots.</p>
<p style="margin-left:11%; margin-top: 1em"><b>sysawr_connect
<br>
sysawr_username <br>
sysawr_password</b></p>
<p style="margin-left:17%;">By default, awr snapshots and
reporting will use the credentials provided by the three
previous parameters. But if your database is a PDB, and if
you have access to the root container, you should set these
parameters to the credentials for the root rather than for
the PDB. Doing so will make the awr reports more
comprehensive as they include data from all PDBs.</p>
<p style="margin-left:11%; margin-top: 1em">If you (as
recommended) have a separate database for your RWP*Load
Simulator repository, set these:</p>
<p style="margin-left:11%; margin-top: 1em"><b>results_in_test
:= 0; <br>
results_connect <br>
results_username <br>
results_password</b></p>
<p style="margin-left:17%;">Setting results_in_test to zero
implies the repository will not be created in your database
under test. In that case, the other three parameters must be
set to point to your already created repository
database.</p>
<p style="margin-left:11%; margin-top: 1em">If you want to
perform some quick tests and do not have an existing
RWP*Load Simulator repository, you can set these
parameters:</p>
<p style="margin-left:11%; margin-top: 1em"><b>results_in_test
:= 1; <br>
results_connect <br>
results_username <br>
results_password <br>
rwloadsim_dir</b></p>
<p style="margin-left:17%;">Setting results_in_test to
non-zero implies the repository will be created in your
database under test unless one has already been created
there. The three following parameters will be used to create
the repository schema and later to access it. The
rwloadsim_dir parameter must be set to be the full path-name
to the admin directory of your installation of
rwloadsim.</p>
<p style="margin-left:11%; margin-top: 1em">During
execution, the oltp workload needs five different database
schemas for which you must provide usernames and passwords.
This is done using these ten parameters:</p>
<p style="margin-left:11%; margin-top: 1em"><b>rwl_aw1_username
rwl_aw1_username <br>
rwl_aw2_username rwl_aw2_username <br>
rwl_oe_username rwl_oe_username <br>
rwl_run1_username rwl_run1_username <br>
rwl_run2_username rwl_run2_username</b></p>
<p style="margin-left:17%;">The usernames can be any
allowed schema names as long as the schemas not already
exists. It is, however, important that the names for the
last two can be identified using a like condition, so these
two are typically named RWLRUN1 and RWLRUN2, as the like
condition RWLRUN_ can be used to identify those. The
usernames must be written in upper case. The passwords must
be chosen to match any password restrictions of your
database.</p>
<p style="margin-left:11%; margin-top: 1em"><b>rwl_run_like</b></p>
<p style="margin-left:17%;">Set to the like condition that
identifies the last two schema names mentioned above. The
like condition must be written in uppercase.</p>
<p style="margin-left:11%; margin-top: 1em"><b>default_tablespace</b></p>
<p style="margin-left:17%;">The three first schemas
mentioned above will contain actual data, and they must
therefore have a proper default tablespace configured. This
parameter names that tablespace. A very rough size estimate
is that you will initially need up to 10GB, which mostly
depends on the size of your aw_cols tables. If you are going
to make many runs, size can grow to 100GB or beyond.</p>
<p style="margin-left:11%; margin-top: 1em">The next three
parameters control how big the aw_cols table, how skew the
access to it is, and how many rows are read by each query.
If the table is almost as large as (or even larger then)
your buffer cache, you can get massive reads if there is no
skew in access to the table. The purpose of the settings is
to be able to adjust the actual amount of physical reads in
your database under test. Se the oltp.rwl file for further
information.</p>
<p style="margin-left:11%; margin-top: 1em"><b>aw_cols_256MB_doublings</b></p>
<p style="margin-left:17%;">The table is created by first
filling it to roughly 256MB and then doubling it a number of
times; this parameter sets the number of times it gets
doubled from the initial 256MB. The default is 4 resulting
in an aw_cols table of an approximate size of 4GB.</p>
<p style="margin-left:11%; margin-top: 1em"><b>aw_cols_skew</b></p>
<p style="margin-left:17%;">If not set, all rows in the
aw_cols table will be uniformly queried. If you set a value,
the rows actually queried will be skewly distributed, the
higher the value, the more skew distribution. With higher
skew, the buffer cache gets more effective. Typical values
are in the range between 5 and several hundred, but you will
normally need to experiment, in particular if your aw_cols
table is as large as or ever larger than your buffer
cache.</p>
<p style="margin-left:17%; margin-top: 1em">Note that if
your aw_cols <i>is</i> so large that it will not fit in your
buffer cache, you cannot completely prevent reads even with
very high values for aw_cols_skew, so the awr report will be
likely to report that your SGA is undersized. It is
debatable if this is a bug or a feature of the oltp
workload, and ideas for a better scheme are welcome.</p>
<p style="margin-left:11%; margin-top: 1em"><b>aw_cols_query_factor</b></p>
<p style="margin-left:17%;">This parameter sets the average
number of rows being read in each aw_cols query. Due to the
extremely poor index clustering factor, these rows are
likely to be distributed on the same amount of database
blocks. The default value is 50, which is a good starting
point for experiments.</p>
<p style="margin-left:11%; margin-top: 1em">The following
parameters impact the generated output and graphs.</p>
<p style="margin-left:11%; margin-top: 1em"><b>rwl_title</b></p>
<p style="margin-left:17%;">Set to a string that will be
put on all html files, graphs, etc that are generated.</p>
<p style="margin-left:11%; margin-top: 1em"><b>rwl_daily_html</b></p>
<p style="margin-left:17%;">Set to name the file that will
contain daily overviews when using the <a href="oltpday.html">oltpday(2rwl)</a>
utility; it should name a html file.</p>
<p style="margin-left:11%; margin-top: 1em"><b>rwl_heading</b></p>
<p style="margin-left:17%;">Set to a string that will be
the heading for the daily reports, generated using
<a href="oltpday.html">oltpday(2rwl)</a>.</p>
<p style="margin-left:11%; margin-top: 1em">The following
parameters are used to control the actual workload, and they
have reasonable default values. Note that only some
parameters are documented here, there rest are discussed in
the oltp.rwl file that you copied to a file named after your
project such as <b>key.rwl</b>.</p>
<p style="margin-left:11%; margin-top: 1em"><b>ratefactor</b></p>
<p style="margin-left:17%;">This is a double value (default
0.2) that sets the overall workload. You can very
approximately assume that with the default value together
with the default value for <b>threadcount</b>, making runs
with one process will require in the order of 0.2 database
CPU seconds per second.</p>
<p style="margin-left:11%; margin-top: 1em"><b>rategradient</b></p>
<p style="margin-left:17%;">This is a double value that can
be used to make the overall workload increase gradually
during a run. If the value is 0 (or is unset), the arrival
rate will be constant during the run; this is the default
behavior. If the value is set higher than 0 and at most to
1, the arrival rate will initially be <i>lower</i> than
specified via <b>ratefactor</b>, half way through the run it
will be what <b>ratefactor</b> specifies and at the finish
of the run, it will be <i>higher</i>. Effectively, the rate
will gradually increase from 100*rategradient percent below
normal to 100*rategradient percent above normal. Values
outside the range [0;1] will be adjusted to either 0 or
1.</p>
<p style="margin-left:11%; margin-top: 1em"><b>threadcount</b></p>
<p style="margin-left:17%;">This is an integer value
(default 50) that sets the number of worker threads per
process. If you want to experiment with, as an example,
twice the load, you can do so by doubling either of
<b>ratefactor</b>, <b>threadcount</b>, or the number of
processes.</p>
<p style="margin-left:11%; margin-top: 1em"><b>time_out</b></p>
<p style="margin-left:17%;">When time_out is set to an
actual value of 0 or more, any transaction that is delayed
by more than the value of <b>time_out</b> seconds will be
<i>dropped</i> in stead of being actually executed. When a
transaction is dropped, no database session will be
acquired, and the transaction is not executed. In stead, the
drop count will be increased by 1. This is only likely to
happen when the database is under pressure and when the
actual time to get a database session and execute a
transaction is higher than the inverse of the arrival rate.
The drop count is visible in the persec table with a vname
of ’call_failure’.</p>
<p style="margin-left:17%; margin-top: 1em">Note that this
is different from the max_sessionwait parameter which sets
the maximum time a worker will wait for a session.</p>
<p style="margin-left:11%; margin-top: 1em">The following
parameters with names starting with fix_ have effect when
the execution is fixed at starttime, i.e. when external
control is not used.</p>
<p style="margin-left:11%; margin-top: 1em"><b>fix_logoffrate</b></p>
<p style="margin-left:17%;">This is a double value that can
be set to increase the logon activity by causing session
release to also disconnect. By default, this does not
happen, but if set to a value in the range ]0;1], the value
sets the proportion of sessions doing the make_order
transaction that will disconnect during session release. The
parameter only has effect when the normal pool is a session
pool.</p>
<p style="margin-left:11%; margin-top: 1em"><b>fix_cursorleak</b></p>
<p style="margin-left:17%;">This is a double value that can
be set to make the application leak cursors at a certain
rate. By default, this does not happen, but if set to a
value in the range ]0;1], the value sets the proportion of
cursors that will be leaked. If you want to experiment with
the, start with very low values such as 0.001 and be
prepared that you will receive ORA-01000 errors.</p>
<p style="margin-left:11%; margin-top: 1em"><b>fix_hardparse</b></p>
<p style="margin-left:17%;">This is a double value that can
be set to make hard parse take place. By default, no hard
parse takes place, but if the parameter is set to a value
higher than zero, hard parse will take place. The valid
range is [0;1].</p>
<p style="margin-left:11%; margin-top: 1em"><b>orders_hashcount</b></p>
<p style="margin-left:17%;">If your database does not have
partitioning, set this to 0, otherwise leave it at the
default. This must be done before you run
<a href="oltpcreate.html">oltpcreate(2rwl)</a>.</p>
<p style="margin-left:11%; margin-top: 1em"><b>runplot_width</b></p>
<p style="margin-left:17%;">If you are using -g or -G to
show running graphs, they will by default show the latest
60s of activity, unless this parameter is set to a different
value.</p>
<p style="margin-left:11%; margin-top: 1em"><b>gnuplotjs</b></p>
<p style="margin-left:17%;">This parameter is no longer
used. However, if you are using gnuplot version 4.6 you need
to make the contents of /usr/share/gnuplot/4.6/js/*
available at usr/share/gnuplot/4.6/js/ seen from the root of
your http daemon.</p>
<p style="margin-left:11%; margin-top: 1em"><b>globalawr</b></p>
<p style="margin-left:17%;">If you set this integer to 1, a
global awr report will be created.</p>
<h2>BURSTS
<a name="BURSTS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">You can include
four different types of "bursts" in your run; one
does a burst using a higher average transaction arrival
rate, the other does a burst using a higher number of worker
threads, the third does an activity burst by changing
(logged on) sessions from being idle to being active, and
the last is an implicit burst being the result of a period
with reduced session pool sizes.</p>
<p style="margin-left:11%; margin-top: 1em">For the first,
you must provide a factor, by which the arrival rate
increases, and for the second, you must provide the count of
extra worker threads. For both, you provide the time in
seconds from the beginning of the run when the burst should
start and the length of the burst in seconds.</p>
<p style="margin-left:11%; margin-top: 1em">To include a
burst with higher arrival rate, include these
parameters:</p>
<p style="margin-left:11%; margin-top: 1em"><b>burst_start
<br>
burst_length <br>
burst_factor <br>
burst_repeat <br>
burst_function</b></p>
<p style="margin-left:17%;">The two first parameters set
the time to start and length of the burst, and the third
parameter is the factor that is applied to the arrival rate
during the burst. If burst_repeat is set to a value larger
than the sum of burst_start and burst_length, the burst will
be repeated very burst_repeat seconds. By default, the burst
is not repeated.</p>
<p style="margin-left:17%; margin-top: 1em">You can
additionally declare a function named <b>burst_function</b>
with the following shape:</p>
<p style="margin-left:17%; margin-top: 1em">function
burst_function(double runsec) <br>
return double <br>
is <br>
# your code here <br>
return 1.0; <br>
end burst_function;</p>
<p style="margin-left:17%; margin-top: 1em">If the function
is declared, it will be given runseconds() as its argument
and it should return a factor that will be used as a
multiplier to the ratefactor otherwise in use. If you want
the multiplier to depend on the actual runtime, you can use
the variable <b>runperiod</b> which contains the value of
the -r argument to oltprun. The sample code shown here will
have no impact as it always returns the value 1.0. Note that
this is an experimental feature and that it may be changed
in a later release.</p>
<p style="margin-left:11%; margin-top: 1em">To include a
burst with extra worker threads, include these
parameters:</p>
<p style="margin-left:11%; margin-top: 1em"><b>wburst_start
<br>
wburst_length <br>
wburst_count</b></p>
<p style="margin-left:17%;">The two first parameters set
the time to start and length of the burst, and the third
parameter is the number of extra worker threads during the
burst. To prevent all processes from increasing the worker
thread count at the same time, you can include procnumber in
your calculation for wburst_start. As an example, if you set
wburst_start to 200+procnumber, the increase in worker
threads will be at 200s for process 1, 201s for process 2,
etc.</p>
<p style="margin-left:11%; margin-top: 1em">All parameters
are double except wburst_count that is an integer, and you
can very well include both types of burst.</p>
<p style="margin-left:11%; margin-top: 1em">The third type
of burst is provided by specifying a point in time during
the run where the activity changes. All workers are
connected (assuming no pooling is in place), but before that
point in time, only some workers are active. When the point
in time for the change is reached, all workers get active,
which will cause an activity burst, which results in e.g.
many cursors being (soft) parsed at the same time. The four
parameters controlling this are:</p>
<p style="margin-left:11%; margin-top: 1em"><b>aburst_workers
<br>
aburst_pre_factor <br>
aburst_post_factor <br>
aburst_start</b></p>
<p style="margin-left:17%;">In the period until
aburst_start, only aburst_workers do actual work while the
remaining (i.e. threadcount-aburst_workers) are connected
but are idle. The arrival rate in the active workers during
this period is a factor aburst_pre_factor higher than
normal. If the value
aburst_pre_factor*aburst_workes/threadcount is 1.0, the
effective arrival rate during this period is the same as it
would have been without an activity burst. In the period
after aburst_start, all workers are active, in the arrival
rate of these is the normal arrival rate multiplied by
aburst_post_factor. The default for both factors is 1.0.</p>
<p style="margin-left:11%; margin-top: 1em">The last type
of bursts comes due to a backlog of transactions that are
delayed during a period with reduced sessions in the normal
pool. It only has effect when using session pools.</p>
<p style="margin-left:11%; margin-top: 1em">To include a
temporary delay by reduced session counts, include there
parameters:</p>
<p style="margin-left:11%; margin-top: 1em"><b>delay_start
<br>
delay_length <br>
delay_min_pool <br>
delay_max_pool</b></p>
<p style="margin-left:17%;">The two first parameters
(double) set the time to start and the length of the delay,
and the two latter parameter (integer) are the min and max
number of sessions in the normal pool during the delay. If
<b>delay_length</b> is zero, no delay will take place.</p>
<h2>CONNECTION STORMS
<a name="CONNECTION STORMS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">You can emulate
connection storms starting a certain timestamp during the
run. The storm can come from two souces:</p>
<table width="100%" border="0" rules="none" frame="void"
cellspacing="0" cellpadding="0">
<tr valign="top" align="left">
<td width="11%"></td>
<td width="3%">
<p>1.</p></td>
<td width="3%"></td>
<td width="83%">
<p>Having a subset of worker threads that block a session
while otherwise doing nothing. At the same time, an other
set of worker threads will get active and as a consequence
the session pool will increase its size, while the expected
arrival rate stays the same.</p></td></tr>
<tr valign="top" align="left">
<td width="11%"></td>
<td width="3%">
<p>2.</p></td>
<td width="3%"></td>
<td width="83%">
<p>Making a number of database logons that are kept open
but without doing any actual activity.</p></td></tr>
</table>
<p style="margin-left:11%; margin-top: 1em">The following
parameters control connection storms:</p>
<p style="margin-left:11%; margin-top: 1em"><b>cstorm_start
<br>
cstorm_period <br>
cstorm_threads <br>
cstorm_xtra_start <br>
cstorm_xtra_period <br>
cstorm_xtra_logons <br>
cstorm_xtra_rate</b></p>
<p style="margin-left:17%;">The first parameter sets the
time when the first type of connection storm will start. The
next two parameters sets for how long the block will last,
and the count of threads that will block a session. If
<b>cstorm_threads</b> has its default value of zero, there
will be no storm from blocking sessions.</p>
<p style="margin-left:17%; margin-top: 1em">The
<b>cstorm_xtra_start</b> and <b>cstorm_xtra_period</b>
similarly control when the extra connections (that do not do
any actual work) will initiate and for how long they will
last. The default values are the same as for the start and
period of the blocking sessions. The two last parameters set
the number of extra logons to establish, and the rate in
logons per second. If <b>cstorm_xtra_logons</b> has its
default value of zero, not extra logons will be started.</p>
<p style="margin-left:11%; margin-top: 1em">You can combine
the connection storm with the first type of burst mentioned
above.</p>
<p style="margin-left:11%; margin-top: 1em">Note that this
is an experimental feature that may change in a future
release.</p>
<h2>24H SIMULATION
<a name="24H SIMULATION"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">You can use
oltprun to simulate a full day workload with variation over
time (day/night) and with inclusion of variout types of
"issues" at intervals during the run. This is
enabled by including</p>
<p style="margin-left:11%; margin-top: 1em"><b>s24hour :=
1;</b></p>
<p style="margin-left:11%; margin-top: 1em">in your
<b>key.rwl</b> file together with several other parameters
that all have names beginning with <b>s24h_</b>. The most
important ones that all are of type double are:</p>
<p style="margin-left:11%; margin-top: 1em"><b>s24h_high_beg
<br>
s24h_high_end <br>
s24h_load_hi <br>
s24h_load_lo</b></p>
<p style="margin-left:17%;">The first are used to set the
range of the "high" period, simulating daytime
with high activity. They are multipliers to the runtime
(provided using the -r option to oltprun) and set the
beginning and end of the simulated daytime. The
<b>s24h_high_beg</b> values should be less than the
<b>s24_high_end</b> value that should be less than 1.0.
Default values are 0.30 and 0.85 implying the high period
will be from 30% to 85% into the run.</p>
<p style="margin-left:17%; margin-top: 1em">The latter two
parameers are factors that are applied to the overall
<b>loadfactor</b> during respectively the high
("daytime") and low ("nighttime")
periods. Default values are 0.2 and 1.0 implying the low
period will be 20% of the load during the high period.</p>
<p style="margin-left:11%; margin-top: 1em">24h simulation
is considered an experimental feature and the full
documentation on all parameters is currently only available
in the oltp.rwl file that you copy to your <b>key.rwl</b>
file. You can very well combine 24h simulation with
bursts.</p>
<h2>VERIFICATION
<a name="VERIFICATION"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">To verify the
directories and files are setup properly, run <b>oltpverify
-d</b>.</p>
<p style="margin-left:11%; margin-top: 1em">To verify the
settings for system users are correct, run <b>oltpverify
-s</b>.</p>
<p style="margin-left:11%; margin-top: 1em">To verify you
can connect to a repository, run <b>oltpverify -r</b>.</p>
<p style="margin-left:11%; margin-top: 1em">To create all
schemas, run <b>oltpcreate</b>; to drop all schemas expect
the repository, run <b>oltpdrop</b>.</p>
<p style="margin-left:11%; margin-top: 1em">To verify
schemas are properly created, run <b>oltpverify -u</b>.</p>
<h2>REMOTE EXECUTION
<a name="REMOTE EXECUTION"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">Normally, all
the background processes started by e.g. <b>oltprun</b> are
started on the same single host. If that host is running out
of CPU resources, you can prepare distribution of the
processes to multiple servers. This is done by declaring a
procedure named <b>rwlcall</b> taking a single integer
argument. The argument provided will be a process number in
the range from 2 until the value of the -n argument to
<b>oltprun</b>. The process with process number 1 will
always be started on the same host where <b>oltprun</b> is
executed. The procedure must output exactly two lines that
are setting sh variables named <b>rwlcall</b> and
<b>rwlcallargs</b>. Those two will be used to start the
actual background process. A sample declaration that will
distribute the workload to three different hosts is the
following:</p>
<p style="margin-left:11%; margin-top: 1em">procedure
rwlcall(integer prno) <br>
is <br>
printline "rwlcall=’ssh’"; <br>
printf "rwlcallargs=’-n -tt appsrv%02d.domain.tld
/path/to/remoterwloadsim.bash’\n" <br>
, prno%3+1; <br>
end rwlcall;</p>
<p style="margin-left:11%; margin-top: 1em">A template for
the bash script <b>remoterwloadsim.bash</b> is found in the
oltp directory of your rwloadsim distribution. It should be
copied to all remote systems and modifed according to the
instructions in the file, setting the proper environment to
execute rwloadsim remotely. Note that remote execution is an
experimental feature that may change in a later release.</p>
<p style="margin-left:11%; margin-top: 1em">If the
procedure is not declared, the following will be used</p>
<p style="margin-left:11%; margin-top: 1em">printline
"rwlcall=’rwloadsim’"; <br>
printline "rwlcallargs=’’";</p>
<p style="margin-left:11%; margin-top: 1em">implying
rwloadsim will be started locally. This is always used for
process number 1, as it must run locally.</p>
<h2>SAVING PASSWORDS IN KEYRING
<a name="SAVING PASSWORDS IN KEYRING"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">If you have
gnome keyring available, you can use that to save passwords
rather than having them in your $RWLOLTP_NAME.rwl file. To
do so, enter the needed passwords using <b>secret-tool
store</b> with the attributes <b>connect</b> and
<b>username</b> for the connect string and usernames
respectively. The sample <b>oltp.rwl</b> file has a function
called <b>keyring_password</b> that will use secret-tool to
lookup the password. To use it, you need to uncomment the
relevant lines in your $RWLOLTP_NAME.rwl file.</p>
<p style="margin-left:11%; margin-top: 1em">The primary use
of this is to safely show your $RWLOLTP_NAME.rwl file in
e.g. Zoom calls or in screen dumps. Note that passwords will
still be visible if you call oltpparams with the --human
option or if somebody can log in to your account and your
gnome keyring.</p>
<h2>UNDOCUMENTED PARAMETERS
<a name="UNDOCUMENTED PARAMETERS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">There are some
extra parameters, that you can set in either your
<b>key.rwl</b> file or using -i or -d on the oltprun command
line. To get documentation for these, you need to look at
the parameters.rwl or oltp.rwl file in the oltp
directory.</p>
<h2>BUGS
<a name="BUGS"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">All oltp
commands accept -H to get help, many also accept --help,
some also -h for that purpose while -h is used to provide
actual argument values for a few commands. For rwloadsim
itself, -h or --help is the option to output help while -H
is used to output help from useroptions. The best way to get
command syntax in a consistent way is to use rwlman; the
second best is to try with a --help option, which works in
all frequently used commands. This is confusing.</p>
<p style="margin-left:11%; margin-top: 1em">Some oltp
commands accept both single letter and gnu style long
options, which is also confusing.</p>
<h2>COPYRIGHT
<a name="COPYRIGHT"></a>
</h2>
<p style="margin-left:11%; margin-top: 1em">Copyright
© 2023 Oracle Corporation <br>
Licensed under the Universal Permissive License v 1.0 as
shown at https://oss.oracle.com/licenses/upl</p>