Blog
New Features – OCI
Category: Cloud Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 0

New Features - OCI

 
 
Today I decided to write a post with the new features that have been released in OCI in recent months.
 
I will be making detailed articles on each of these features as soon as possible.
 
Let’s go now with the new features
 
𝐎𝐒 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐒𝐞𝐫𝐯𝐢𝐜𝐞
 
– Service Available from OCI Console
– Managed instance can be managed individually or in group.
 – Easy Instance grouping – By OS or By Purpose of Instances – Easy Bulk Operations
 – Select or Create Custom software sources.
– Immediate execution as Work Request or Scheduled Jobs for OS Package Management.
– Checking for Exposures to known Common Vulnerabilities and Exposures (CVE).
– Agent based Service for Linux 6,7 or 8 Instances.
– OS Management enabled by default only Agent install needed via yum.
– For Service Operation Agent (osms-agent) must be installed.
– Compute + OS Management = Managed Instance
– Enables Package Management – Monitor, Search, Add, Remove, Update
𝐁𝐥𝐨𝐜𝐤 𝐕𝐨𝐥𝐮𝐦𝐞 𝐒𝐡𝐚𝐫𝐢𝐧𝐠 𝐑𝐞𝐚𝐝-𝐖𝐫𝐢𝐭𝐞 𝐌𝐨𝐝𝐞

 

– Two options introduced Read/Write Sharable and Read-only Sharable.
– Read-Write needs Clusterware solution on top of shared block volume.
– Read-only attachment are available in sharable mode to multiple instances.
– No need of concurrency access control or cluster-ware solution for Read-only Attach.
– Volume groups, Disk-to-Disk Clone, automated backups are available for Shared Block Volumes.
– Default attachment from Compute is non-shareable and exclusive read/write
– Available in all regions via OCI Console, CLI, SDK, Terraform.
 – Other vendors provide only Read-only Block Volumes but has limitation on Read-Write shareable attach.
Get back the Deleted Compartment.

 

– Once compartment is deleted it will be appended with random string.
– Use Filter Deleted Compartment to get the list.
– Audit Retention period is 90-365 days.
– Restore Compartment Option will allow you to restore compartment with the same appended string name.
– It will be listed in compartment list.
– All policies refer to the deleted compartment will be now pointed to restored compartment name.

 

 

I hope this helps you!!!
Andre Luiz Dutra Ontalba

 

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”

 


ZDLRA Internals, Tables and Storage
Category: Engineer System Author: Fernando Simon (Board Member) Date: 5 years ago Comments: 0

ZDLRA Internals, Tables and Storage

ZDLRA tables are owned by rasys user and are one extension of rman recovery catalog views. The internal tables that were added are just a few, but are important to understand how tasks works (mainly INDEX_BACKUP). In this post, I will show tables like plans, plans_details, blocks, and chunks. And besides that, show a little glimpse about how the files are stored.
Extra tables
If you check, officially, the rman recovery catalog already includes some columns from ZDLRA, the column VB_KEY identify the virtual backup key inside ZDLRA. It exists in RC_BACKUP_PIECE as an example. The extra tables added are linked with SBT tasks (clone to tape or cloud), replication (to other ZDLRA), storage (chunks), vbdf and plans (virtual full backup).

 

The most import tables are listed below.

 

RASYS.VBDF: This table store the reference for virtual full backups created for the datafile. Have the information about the backup piece used as the source(base) for virtual full backup and the reference to the new backup piece that was generated at virtual full creation. The most import columns are:

 

  • VB_KEY: The unique identifier to virtual backup.
  • DF_KEY: The reference to datafile key for virtual full backup.
  • CKP_ID and CHP_SCN: Checkpoint information (id/scn) for this virtual full backup.
  • SRCBP_KEY: The reference to the original backup piece (source) that was used to generate the virtual full backup. Links to table BP.
  • VCBP_KEY: Reference to the derived backup piece that was created during the index of the original (source) backup piece.

 

RASYS.PLANS: This table store the plans that link the datafile and the virtual full backup. Basically, is the reference “index” and links: virtual backup, datafile, and the number of chunks that store it. Important columns:

 

  • VB_KEY: The unique identifier to virtual backup.
  • DF_KEY: The reference to datafile key for virtual full backup.
  • NUMCHUNKS: Chunks used to store (or store) this virtual full backup.

 

RASYS.PLANS_DETAILS: IOT table that stores the detailed information for the plan for the “index”. It is partitioned over the DF_KEY column. Link the virtual full backup, datafile, block number, and chunk identification. Tells you in which chuck it is stored each block that are part of the virtual full backup. Import columns:

 

  • VB_KEY: The unique identifier to virtual backup.
  • DF_KEY: The reference to datafile key for virtual full backup.
  • BLOCKNO: Block number that are part of the datafile.
  • NUMBLKS: Number of the blocks in sequential mode starting from BLOCKNO that are equal.
  • CHUNKNO: What is the chunk id that store the BLOCKNO + NUMBKS.

 

RASYS.BLOCKS: IOT table that stores the info for each block that belongs to the datafile. It is partitioned over the DF_KEY column. There is no link to any backup, but store each version of a single block that is needed to restore any backup (the block number needed can be found in the PLAN_DETAILS and SCN come from other tables). Import columns:

 

  • DF_KEY: The reference to datafile key for virtual full backup.
  • BLOCKNO: Block number that are part of the datafile.
  • SCN and CKP_ID: Checkpoint and SCN for this specific version of the block.

 

RASYS.CHUNK: IOT table that has the information about the chunks that was used to store the backups for the datafile. Important columns:

 

  • DF_KEY: The reference to datafile key for virtual full backup.
  • CHUNKNO: What is the chunk id.
  • FILESIZE: Size for this chunk
  • FILENAME: Derived file name that store the chunk (no represent the file inside ASM).

 

These tables are the most important for ZDLRA for the internal part of ZDLRA. They are not needed in daily basis activities but I think that is useful if you want to understand how things work internally. The list above is just a glimpse for internal tables, but based on that you can easily: identify what are the datafile blocks that belongs for specific virtual backup, where the blocks are stored (which chunk), and how this virtual full backup was build (the plan that contains all the blocks).

 

 

Storage

 

As you saw above, the blocks are stored in chunks and in CHUNKS table we have filename information. But this is not related where the data are really stored, there are other places used too. All of these tables are stored at RA_POOL tablespace but don’t store the backup itself. The structure that does this is “CONTAINERS” and represent files inside ASM diskgroup.
If you see the ZDLRA doc (look the image below) this is called DELTA POOLS (CONTAINERS and CHUNKS) and is stored inside one “Delta Store” (ASM diskgroup). For ASM diskgroups you can see the CATALOG and DELTA. The CATALOG, as I wrote in this post, store the metadata information about the backups (mostly the rman catalog views) and the DELTA (the Delta Store) have the info related the backups itself.
For tablespaces, there are two important RA_POOL and RA_CATALOG. The tables listed before (in the “Extra Tables topic”) resides at RA_POOL tablespace. But the backup data itself is stored in CONTAINER files at DELTA diskgroup and you can check them in the table SYS.AMCONT$. Another option is going in ASM diskgroup and check the list at DELTA/CONTAINER files (each file have the default of 2TB):
ASMCMD> pwd

+DELTA/ZDLRA/CONTAINER

ASMCMD> ls -s

Block_Size      Blocks          Bytes          Space  Name

       512  4294959104  2199019061248  4398059094016  con.561.935405781

       512  4294959104  2199019061248  4398059094016  con.562.935405789

       512  4294959104  2199019061248  4398059094016  con.563.935405797

       512  4294959104  2199019061248  4398059094016  con.564.935405805

…

…

       512  4294959104  2199019061248  4398059094016  con.656.935406489

       512   308051968   157722607616   315692679168  con.657.935406495

ASMCMD>
You can see more info checking tables SYS.AM* tables and views (SYS.AMAU$, SYS.AMCONT$, and SYS.AM$CONTAINER are examples). The list for containers files are not even listed as ZDLRA database (as datafile in dba_data_files) but are created directly by ZDLRA library.
You can even test the performance (before starting to use ZDLRA usage) to create these files using rastat.pl: https://docs.oracle.com/cd/E88198_01/AMAGD/amagd_monitor.htm#AMAGD1503. And this is the only info in the docs about CONTAINERS files.
Last info about ZDLRA database and storage, the database operates in NOARCHIVLOG mode. The backups for it are daily exports from the metadata information and in case of corruption/lost you can reconstruct the information reading the con files.
Conclusion
Understand the tables involved for ZDLRA are important to see what’s happening internally, how the index is stored and how works virtual full backup. The tables listed above are not used in daily bases for ZDLRA, you usually go to rman catalog view (RC_*), everything is there.
But, PLANS, PLANS_DETAILS, and VCBP are the base for a task like INDEX_BACKUP and to sustain virtual full backups. I needed to pass over these tables before explaining in more details the virtual full creation and INDEX_BACKUP task.
The storage part, containers and ASM diskgroup are needed just to help support to identify some bottleneck or problem. You don’t need to use it but I think that it is important to show you, at least superficially, how its work.

 

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community.”


Webinar – Understanding ZDLRA
Category: Engineer System Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 1

Webinar - Understanding ZDRLA

Hi guys !!
On December 18th at 19:00 PM (CET) we will have our Understanding ZDRLA Webinar.

Speaker: Fernando Simon
 
You can follow it live here or via Youtube – Click Here
 
Click here for download presentation. 

André Ontalba – Board Member

Block Volume Elastic Performance – OCI
Category: Cloud Author: Andre Luiz Dutra Ontalba (Board Member) Date: 5 years ago Comments: 0

Block Volume Elastic Performance - OCI

Oracle introduced a new feature to control the performance of Block Volume that is the Volume Performance Unit (VPU). It’s easy to manage and can be controlled with Console, API, and CLI. Its dynamic nature makes it the best option.

 

 

What Is Block Volume?
It provides high-performance constant Cloud storage in a wide range of application workloads. The Block Volume helps to provide network storage that can be used with OCI instances.
 
 
Volume Performance Unit (VPU) – New Feature
  1. Oracle charges it according to the performance units per GB per month.
  2. Higher IOPS and throughput corresponds to higher VPU.
  3. VPU is inversely proportional to the cost of the storage.
  4. Measured in terms of IO per sec and Throughput per GB.
 
 
For Block Volume Elastic Performance, there are three elastic performance configuration options, as described below.
 
 
Balanced: This is the default setting for new and existing block and boot volumes. It provides a good balance between performance and cost savings for most workloads, including those that perform random I/O such as boot volumes. This option provides linear peformance scaling with 60 IOPS/GB up to 25,000 IOPS per volume. Throughtput scales at 480 KBPS/GB up to a maximum of 480 MBPS per volume. With this option you are purchasing 10 VPUs per GB/month.
 
 
Higher Performance: Recommended for workloads with the highest I/O requirements, requiring the best possible performance, such as large databases. This option provides the best linear performance scale with 75 IOPS/GB up to a maximum of 35,000 IOPS per volume. Throughput also scales at the highest rate at 600 KBPS/GB up to a maximum of 480 MBPS per volume. With this option you are purchasing 20 VPUs per GB/month.
 
 
Lower Cost: Recommended for throughput intensive workloads with large sequential I/O, such as streaming, log processing, and data warehouses. The cost is only the storage cost, there is no additional VPU cost. This option gives you linear scaling 2 IOPS/GB upt to a maximum of 3000 IOPS per volume. This option is only available for block volumes, it is not available for boot volumes.
 
 
The following table lists the performance characteristics for each elastic performance level.

 

 

 

Performance Level

IOPS/GB

Max IOPS/Volume

Throughput/GB

Max Throughput/Volume

VPUs/GB

Lower Cost

2

3000

240

Up to 480

0

Balanced

60

25,000

480

480

10

Higher Performance

75

35,000

600

480

20

 
 
Configuring Volume Performance

 

 

You can configure the volume performance for a block volume when you create a volume. You can also change the volume performance for an existing block volume.

 

 

Create a new volume

 

 
Log into Oracle Cloud and click the Block Storage and select Block Volumes.
Click in Create Block Volume
Enter the details of Block Volume and click the “Create Block Volume”

 

Name: BV_PERF_UNIT

Compartment : <keep value>

Availability Domain : <keep value> 

Size (in GB) : 50

Compartment for Backup Policies : <keep value>

Backup Policy:  Bronze

Volume Perfomance : Lower Cost – For this example

Encryption : Encrypt
This process will take between 1 and 2 minutes to complete.
Change the volume performance

 

Log into Oracle Cloud and click the Block Storage and select Block Volumes.
Select your block volume. For this example BV_PERF_UNIT
Click in the “Change Performance”
Now it’s possible you select the best options for your environment.  For this test let’s select the “Balanced” and click in “Change Performance”
This process will take between 1 and 2 minutes to complete.
On the Storage pricing, Oracle has added Block Volume Performance unit which is priced as
Performance Units Per GB/Month
  • 0 VPUs at $0 for Lower Cost
  • 10 VPUs at $0.017 for Balanced
  • 20 VPUs at $0.034 for Higher Performance

 

As of now, OCI Block Volume Elastic Performance has 2 limitations:

 

  • Only changes Block volumes elastic performance configuration on three volumes concurrently per tenancy.
  • Boot volumes only have 2 options: Balanced or Higher performance.

 

This feature is definitely going to help the customer on the performance side and will save the costs as well.

 

I hope this helps you!!!
Andre Luiz Dutra Ontalba

 

 

Disclaimer: “The postings on this site are my own and don’t necessarily represent may actual employer positions, strategies or opinions. The information here was edited  to be useful for general purpose, specific data and identifications was removed to allow reach generic audience and to be useful.”

 


1 … 16 17 18 19 20 … 32
LUXOUG – LUXEMBOURG ORACLE USERS GROUP
© 2024 LUXOUG – LUXEMBOURG ORACLE USERS GROUP