Skip to content

Commit

Permalink
Exadata updates (#62)
Browse files Browse the repository at this point in the history 
* add exascale clone lab

* exascale clone lab updates

* exascale lab changes

* move exascale lab code into scripts

* exascale lab script changes

* exascale lab script changes

* add set verify off to each exascale clone script

* exascale lab changes

* exascale lab instructions updates

* add exascale lab to ocw-tenancy

* remove unused workshops

* rename ocw workshop folder and update for ocw24

* remove unused introduction files

* introduction lab update

* update help lab

* add sqlplus commands to each lab

---------

Co-authored-by: Seth-Miller <[email protected]>
  • Loading branch information
@Seth-Miller-Oracle @Seth-Miller
Seth-Miller-Oracle and Seth-Miller authored Aug 13, 2024
1 parent 419a311 commit 6dbd0fb
Show file tree
Hide file tree
Showing 5 changed files with 63 additions and 23 deletions.
22 changes: 15 additions & 7 deletions exadata-features/exascale_clone/exascale_clone.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -24,55 +24,63 @@ This lab assumes:

## Task 1:

1. Execute the SQL script `lab_exascale_clone_01.sql` to show the total space used by the data and temporary files of the source pluggable database.
1. Connect to the database with `sqlplus /@cdb as SYSDBA`. Use the alias `sqlp_sys`. The rest of the lab will be executed in sqlplus.

```text
<copy>
sqlp_sys
</copy>
```
2. Execute the SQL script `lab_exascale_clone_01.sql` to show the total space used by the data and temporary files of the source pluggable database.
```text
<copy>
@lab_exascale_clone_01.sql
</copy>
```
2. Execute the SQL script `lab_exascale_clone_02.sql` to create a full-size copy of the source pluggable database.
3. Execute the SQL script `lab_exascale_clone_02.sql` to create a full-size copy of the source pluggable database.
```text
<copy>
@lab_exascale_clone_02.sql
</copy>
```
3. Execute the SQL script `lab_exascale_clone_03.sql` to show the total space used by the data and temporary files grouped by pluggable database.
4. Execute the SQL script `lab_exascale_clone_03.sql` to show the total space used by the data and temporary files grouped by pluggable database.
```text
<copy>
@lab_exascale_clone_03.sql
</copy>
```
4. Execute the SQL script `lab_exascale_clone_04.sql` to show the increase in space used in the Exascale vault. The first value is the total increased raw space used. The second value is the increased space used after accounting for data redundancy. Since this vault is set up for normal redundancy, the second value shows half of the raw space used, which should closely match the space used by the full clone PDB created in the previous step.
5. Execute the SQL script `lab_exascale_clone_04.sql` to show the increase in space used in the Exascale vault. The first value is the total increased raw space used. The second value is the increased space used after accounting for data redundancy. Since this vault is set up for normal redundancy, the second value shows half of the raw space used, which should closely match the space used by the full clone PDB created in the previous step.
```text
<copy>
@lab_exascale_clone_04.sql
</copy>
```
5. Execute the SQL script `lab_exascale_clone_05.sql` to create a thin clone of the same source pluggable database.
6. Execute the SQL script `lab_exascale_clone_05.sql` to create a thin clone of the same source pluggable database.
```text
<copy>
@lab_exascale_clone_05.sql
</copy>
```
6. Execute the SQL script `lab_exascale_clone_06.sql` to show the total space used by data and temporary files grouped by pluggable database. The first column shows the total space used as it is represented in the database. The second column shows actual space used as it is represented on Exascale storage, which should give us an idea of the actual space used by the snapshot files of a thin clone.
7. Execute the SQL script `lab_exascale_clone_06.sql` to show the total space used by data and temporary files grouped by pluggable database. The first column shows the total space used as it is represented in the database. The second column shows actual space used as it is represented on Exascale storage, which should give us an idea of the actual space used by the snapshot files of a thin clone.
```text
<copy>
@lab_exascale_clone_06.sql
</copy>
```
7. Execute the SQL script `lab_exascale_clone_07.sql` to show the increase in space used in the Exascale vault. The space used by the thin clone should be significantly smaller than the full clone. The small amount of space that is being used is from two sources:
8. Execute the SQL script `lab_exascale_clone_07.sql` to show the increase in space used in the Exascale vault. The space used by the thin clone should be significantly smaller than the full clone. The small amount of space that is being used is from two sources:
* When creating thin clones of pluggable databases, each cloned datafile will consume 10% of its original size.
* When creating full or thin clones of pluggable databases, temporary tablespace files are never cloned. If the source pluggable database contains temporary tablespaces, these temp files will be newly created in the clone PDB and will consume space equal to the original file size.
Expand Down
18 changes: 13 additions & 5 deletions exadata-features/flash_cache/flash_cache.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -23,31 +23,39 @@ This lab assumes:

## Task 1: Query Without Flash Cache

1. Execute the query in the SQL script `lab_flash_cache_01.sql` and verify that the statistics are at or near zero values. If any statistics are significantly greater than zero then reconnect and retry.
1. Connect to the database with `sqlplus /@db`. Use the alias `sqlp`. The rest of the lab will be executed in sqlplus.

```text
<copy>
sqlp
</copy>
```
2. Execute the query in the SQL script `lab_flash_cache_01.sql` and verify that the statistics are at or near zero values. If any statistics are significantly greater than zero then reconnect and retry.
```text
<copy>
@lab_flash_cache_01.sql
</copy>
```
2. Flush the buffer cache to ensure that the queries must retrieve the required data from the storage cells.
3. Flush the buffer cache to ensure that the queries must retrieve the required data from the storage cells.
```text
<copy>
EXECUTE sys.flush_buffer_cache;
</copy>
```
3. Execute the SQL script `lab_flash_cache_02.sql`. The PL/SQL block performs 500 record lookups spread across a reasonably large table. The workload is representative of the scattered record access normally associated with an OLTP application. Note that the workload may take a few minutes to complete.
4. Execute the SQL script `lab_flash_cache_02.sql`. The PL/SQL block performs 500 record lookups spread across a reasonably large table. The workload is representative of the scattered record access normally associated with an OLTP application. Note that the workload may take a few minutes to complete.
```text
<copy>
@lab_flash_cache_02.sql
</copy>
```
4. Repeat the statistics query in the SQL script `lab_flash_cache_01.sql`. Note the high number of IO requests (`physical read total IO requests`) relative to the low number of optimized requests (`physical read requests optimized` and `cell flash cache read hits`). This indicates that the queries were mostly satisfied by using physical disk reads and is indicative of a recently emptied cache.
5. Repeat the statistics query in the SQL script `lab_flash_cache_01.sql`. Note the high number of IO requests (`physical read total IO requests`) relative to the low number of optimized requests (`physical read requests optimized` and `cell flash cache read hits`). This indicates that the queries were mostly satisfied by using physical disk reads and is indicative of a recently emptied cache.
```text
<copy>
Expand Down Expand Up @@ -98,4 +106,4 @@ You may now **proceed to the next lab**.
## Acknowledgements
* **Author** - Seth Miller, Principal Product Manager, Exadata Product Management
* **Contributors** - Alex Blythe, Exadata Product Management
* **Last Updated By/Date** - Seth Miller, July 2023
* **Last Updated By/Date** - Seth Miller, August 2024
14 changes: 11 additions & 3 deletions exadata-features/hcc/hcc.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -24,15 +24,23 @@ This lab assumes:

## Task 1: Verify the Source Table

1. Determine the size of the uncompressed CUSTOMERS table using the SQL script `lab_hcc_01.sql`.
1. Connect to the database with `sqlplus /@db`. Use the alias `sqlp`. The rest of the lab will be executed in sqlplus.

```text
<copy>
sqlp
</copy>
```
2. Determine the size of the uncompressed CUSTOMERS table using the SQL script `lab_hcc_01.sql`.
```text
<copy>
@lab_hcc_01.sql
</copy>
```
2. Verify that the CUSTOMERS table is uncompressed using the SQL script `lab_hcc_02.sql`.
3. Verify that the CUSTOMERS table is uncompressed using the SQL script `lab_hcc_02.sql`.
```text
<copy>
Expand Down Expand Up @@ -91,4 +99,4 @@ You may now **proceed to the next lab**.
## Acknowledgements
* **Author** - Seth Miller, Principal Product Manager, Exadata Product Management
* **Contributors** - Alex Blythe, Exadata Product Management
* **Last Updated By/Date** - Seth Miller, July 2023
* **Last Updated By/Date** - Seth Miller, August 2024
16 changes: 12 additions & 4 deletions exadata-features/smart_scan/smart_scan.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -23,23 +23,31 @@ This lab assumes:

## Task 1: Query Without Smart Scan

1. Execute the SQL script `lab_smart_scan_01.sql` and verify that the statistics are at or near zero values. If any statistics are significantly greater than zero then reconnect and try again.
1. Connect to the database with `sqlplus /@db`. Use the alias `sqlp`. The rest of the lab will be executed in sqlplus.

```text
<copy>
sqlp
</copy>
```
2. Execute the SQL script `lab_smart_scan_01.sql` and verify that the statistics are at or near zero values. If any statistics are significantly greater than zero then reconnect and try again.
```text
<copy>
@lab_smart_scan_01.sql
</copy>
```
2. Execute the SQL script `lab_smart_scan_02.sql`. Note the optimizer hint that disables Smart Scan for the query.
3. Execute the SQL script `lab_smart_scan_02.sql`. Note the optimizer hint that disables Smart Scan for the query.
```text
<copy>
@lab_smart_scan_02.sql
</copy>
```
3. Repeat the statistics query from the SQL script `lab_smart_scan_01.sql`. Note that all of the data processed by the query in previous step (`physical read total bytes`) is returned to the database server over the storage network (`cell physical IO interconnect bytes`).
4. Repeat the statistics query from the SQL script `lab_smart_scan_01.sql`. Note that all of the data processed by the query in previous step (`physical read total bytes`) is returned to the database server over the storage network (`cell physical IO interconnect bytes`).
```text
<copy>
Expand Down Expand Up @@ -78,4 +86,4 @@ You may now **proceed to the next lab**.
## Acknowledgements
* **Author** - Seth Miller, Principal Product Manager, Exadata Product Management
* **Contributors** - Alex Blythe, Exadata Product Management
* **Last Updated By/Date** - Seth Miller, July 2023
* **Last Updated By/Date** - Seth Miller, August 2024
16 changes: 12 additions & 4 deletions exadata-features/storage_indexes/storage_indexes.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,23 +22,31 @@ This lab assumes:

## Task 1: Query with Storage Indexes

1. Execute the SQL script `lab_storage_indexes_01.sql` and verify that the statistics are at or near zero values. If any statistics are significantly greater than zero then reconnect and retry.
1. Connect to the database with `sqlplus /@db`. Use the alias `sqlp`. The rest of the lab will be executed in sqlplus.

```text
<copy>
sqlp
</copy>
```
2. Execute the SQL script `lab_storage_indexes_01.sql` and verify that the statistics are at or near zero values. If any statistics are significantly greater than zero then reconnect and retry.
```text
<copy>
@lab_storage_indexes_01.sql
</copy>
```
2. Execute the SQL script `lab_storage_indexes_02.sql`.
3. Execute the SQL script `lab_storage_indexes_02.sql`.
```text
<copy>
@lab_storage_indexes_02.sql
</copy>
```
3. Repeat the statistics query using the SQL script `lab_storage_indexes_01.sql`. The statistic `cell physical IO bytes saved by storage index` shows that this query benefits from a storage index. Storage indexes were used to bypass a significant amount of I/O. Queries that benefit from storage indexes can execute more quickly using fewer resources which allows other workloads to benefit from the unused I/O resources.
4. Repeat the statistics query using the SQL script `lab_storage_indexes_01.sql`. The statistic `cell physical IO bytes saved by storage index` shows that this query benefits from a storage index. Storage indexes were used to bypass a significant amount of I/O. Queries that benefit from storage indexes can execute more quickly using fewer resources which allows other workloads to benefit from the unused I/O resources.
```text
<copy>
Expand All @@ -49,4 +57,4 @@ This lab assumes:
## Acknowledgements
* **Author** - Seth Miller, Principal Product Manager, Exadata Product Management
* **Contributors** - Alex Blythe, Exadata Product Management
* **Last Updated By/Date** - Seth Miller, July 2023
* **Last Updated By/Date** - Seth Miller, August 2024

0 comments on commit 6dbd0fb

Please sign in to comment.