programming/Oracle_dataset/online-ecommerce1/README.md

# Oracle E-commerce and Accounting Workload

This project contains SQL*Plus/SQLcl scripts for creating and exercising an
Oracle e-commerce and accounting schema, including background workload jobs.

## 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 Scheduler management procedures require the schema owner to have the
  `CREATE JOB` system privilege. A DBA can grant it directly:

  ```sql
  GRANT CREATE JOB TO your_schema;
  ```

- 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
@oracle_ecommerce_job_management.sql
```

The schema script creates objects only. The seed script expects the schema to
be empty and should be run once. The activity and job-management scripts
create or replace their procedures 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.

## `oracle_ecommerce_job_management.sql`

Creates four procedures for managing one-time Oracle Scheduler jobs that run
`SIMULATE_COMMERCE_ACTIVITY` asynchronously. A created job is enabled
immediately, starts as soon as Scheduler can run it, executes the specified
number of iterations, and remains in the schema's Scheduler job list after
completion (`AUTO_DROP` is disabled).

```sql
SET SERVEROUTPUT ON

-- Create a background job: name, iterations, seconds between iterations,
-- average DML rows per iteration.
EXEC create_commerce_activity_job('COMMERCE_LOAD_01', 10000, 3, 5.5);

-- List Scheduler jobs for SIMULATE_COMMERCE_ACTIVITY.
EXEC list_commerce_activity_jobs;

-- Stop and disable a pending or running job; it remains listed.
EXEC stop_commerce_activity_job('COMMERCE_LOAD_01');

-- Remove the job. FORCE also stops it if it is still running.
EXEC remove_commerce_activity_job('COMMERCE_LOAD_01');
```

The list procedure reports the job state, enabled status, run/failure counts,
and last start time. `STOP` disables the job and force-stops it if running;
it does not resume automatically. `REMOVE` drops the job and force-stops it
if necessary. These operations apply to jobs owned by the connected schema.

For run history and Scheduler error messages, query the job run details view:

```sql
SELECT log_date, status, error#, additional_info
FROM user_scheduler_job_run_details
WHERE job_name = 'COMMERCE_LOAD_01'
ORDER BY log_date DESC;
```

The activity procedure's `DBMS_OUTPUT` is generated in the Scheduler worker
session and is not normally returned to the session that submitted the job.
Use Scheduler run details to inspect completion status and errors.