113 lines
4.6 KiB
Markdown
113 lines
4.6 KiB
Markdown
# Oracle E-commerce and Accounting Workload
|
|
|
|
This project contains three SQL*Plus/SQLcl scripts for creating and exercising
|
|
an Oracle e-commerce and accounting schema.
|
|
|
|
## Requirements
|
|
|
|
- Oracle Database 12c or later. The schema uses identity columns and daily
|
|
interval partitioning.
|
|
- Run the scripts while connected as the schema owner.
|
|
- The activity procedure uses `DBMS_LOCK.SLEEP`. The schema owner may need a
|
|
direct grant from a DBA:
|
|
|
|
```sql
|
|
GRANT EXECUTE ON SYS.DBMS_LOCK TO your_schema;
|
|
```
|
|
|
|
A role grant may not be sufficient when compiling a stored procedure.
|
|
|
|
## Scripts and execution order
|
|
|
|
Run these scripts in order from SQL*Plus or SQLcl:
|
|
|
|
```sql
|
|
@oracle_ecommerce_schema.sql
|
|
@oracle_ecommerce_seed_2gb.sql
|
|
@oracle_ecommerce_activity.sql
|
|
```
|
|
|
|
The schema script creates objects only. The seed script expects the schema to
|
|
be empty and should be run once. The activity script creates or replaces the
|
|
workload procedure and can be rerun to install procedure changes.
|
|
|
|
## `oracle_ecommerce_schema.sql`
|
|
|
|
Creates 22 tables with primary keys, foreign keys, unique and check
|
|
constraints, and supporting indexes. Seven event/transaction tables use
|
|
one-day interval range partitioning; Oracle creates daily interval partitions
|
|
automatically for inserted dates after the initial partition boundary.
|
|
|
|
The model covers:
|
|
|
|
- **Reference and customer data:** `CURRENCIES`, `SALES_CHANNELS`,
|
|
`CUSTOMERS`, `CUSTOMER_ADDRESSES`, `SUPPLIERS`, `PRODUCT_CATEGORIES`,
|
|
`WAREHOUSES`, and `GL_ACCOUNTS`.
|
|
- **Catalog and inventory:** `PRODUCTS`, `INVENTORY_BALANCES`, and
|
|
`INVENTORY_MOVEMENTS`.
|
|
- **Sales and fulfillment:** `SALES_ORDERS`, `SALES_ORDER_LINES`, `PAYMENTS`,
|
|
`SHIPMENTS`, `SHIPMENT_ITEMS`, and `RETURNS`.
|
|
- **Purchasing and accounting:** `PURCHASE_ORDERS`, `PURCHASE_ORDER_LINES`,
|
|
`JOURNAL_ENTRIES`, and `JOURNAL_LINES`.
|
|
- **Operational history:** `AUDIT_EVENTS`.
|
|
|
|
Daily interval-partitioned tables are `SALES_ORDERS`, `PAYMENTS`, `SHIPMENTS`,
|
|
`INVENTORY_MOVEMENTS`, `JOURNAL_ENTRIES`, `RETURNS`, and `AUDIT_EVENTS`.
|
|
|
|
## `oracle_ecommerce_seed_2gb.sql`
|
|
|
|
Loads reference and transactional sample data, followed by an audit-event
|
|
payload of 2 GiB (2,147,483,648 ASCII characters/bytes in the `DETAILS`
|
|
column). Oracle table, index, and segment overhead makes the allocated
|
|
database storage larger than 2 GiB. The script generates 1,073,742 audit
|
|
rows and commits them in batches; the final row contains the remaining
|
|
payload bytes.
|
|
|
|
This is a large load and can consume substantial database time, redo, and
|
|
storage. It is intended for a test database with enough available space, not
|
|
for a production data environment. To change its payload size, edit
|
|
`c_target_payload_bytes` in the script. The number of characters per audit
|
|
row is controlled by `c_payload_chars` and must remain within the
|
|
`AUDIT_EVENTS.DETAILS` column capacity.
|
|
|
|
## `oracle_ecommerce_activity.sql`
|
|
|
|
Creates `SIMULATE_COMMERCE_ACTIVITY`, which randomly performs single-row
|
|
INSERT, UPDATE, and DELETE operations across these 16 tables:
|
|
|
|
`RETURNS`, `PURCHASE_ORDERS`, `PURCHASE_ORDER_LINES`, `PRODUCTS`,
|
|
`CUSTOMER_ADDRESSES`, `SHIPMENTS`, `PAYMENTS`, `CUSTOMERS`,
|
|
`JOURNAL_ENTRIES`, `SALES_ORDERS`, `INVENTORY_MOVEMENTS`, `SHIPMENT_ITEMS`,
|
|
`SALES_ORDER_LINES`, `JOURNAL_LINES`, `INVENTORY_BALANCES`, and `AUDIT_EVENTS`.
|
|
|
|
The procedure selects parent keys from existing rows for inserts and limits
|
|
parent-row deletes to records with no dependent rows. Each successful DML
|
|
operation affects one row. Updates change representative values/statuses;
|
|
inserts use synthetic data. Operations commit after each iteration, making
|
|
changes visible to other sessions, but also committing any uncommitted work
|
|
already present in the caller's session.
|
|
|
|
### Parameters
|
|
|
|
| Parameter | Meaning |
|
|
| --- | --- |
|
|
| `p_iterations` | Number of workload iterations; must be non-negative. |
|
|
| `p_seconds_between_iterations` | Delay between iterations in seconds; must be non-negative. |
|
|
| `p_average_rows_per_iteration` | Target average successful DML rows per iteration; must be between 0 and 10,000. Fractional values are randomly rounded across iterations. |
|
|
|
|
An iteration may affect fewer rows than its target if it cannot find an eligible
|
|
row or exhausts its bounded number of attempts. The average is therefore a
|
|
best-effort target, not a guarantee.
|
|
|
|
Example: run 100 iterations, wait 2 seconds between them, and target an average
|
|
of 5.5 successful row operations per iteration:
|
|
|
|
```sql
|
|
SET SERVEROUTPUT ON
|
|
EXEC simulate_commerce_activity(100, 2, 5.5);
|
|
```
|
|
|
|
The procedure prints a one-line summary for each iteration and a final total
|
|
and realized average. `DBMS_OUTPUT` is buffered, so SQL*Plus/SQLcl may display
|
|
the output after the procedure completes.
|