Oracle Cloud Infrastructure Architect Associate: Nine hundred terabytes, one slow volume, and a shared drop area

The semantics that matter. Lifecycle rules work on object age (time since creation), not on last-access time. A rule written as "move to Archive after 90 days" moves everything under the matching prefix that is 90 days old, including objects read yesterday. That is why the split has to be by prefix, not by intent: only the cold set should sit under a prefix that a lifecycle rule targets.

Recommended structure:

• active/ - the 5 TB streamed daily. No transition rule. Standard tier.
• nearline/ - the remainder read a few times a year. Transition to Infrequent Access at 30 days. Infrequent Access has a minimum storage duration (31 days) and a retrieval fee, but at a few reads a year it is comfortably cheaper than Standard.
• cold/ - the 60 TB untouched set. Transition to Archive at 90 days. Archive has the lowest per-GB price but bills retrieval and takes roughly an hour to restore an object, plus a minimum storage duration (90 days) that is charged even if the object is deleted earlier. That is acceptable for a set nobody reads, and unacceptable if a legal request could arrive with a 15-minute deadline.

Enforce the seven years. A lifecycle rule does not prevent deletion. Add Object Versioning and a bucket retention rule that makes objects immutable until the contractual date, then lock the rule so an administrator cannot remove it. Test the interaction between retention and lifecycle transitions on a small bucket first - retention is there to stop deletion, and you want proof that it does not also block the tiering you just built.

Alternative worth pricing: an auto-tiering bucket, which moves objects between tiers based on access patterns rather than age. It suits the unpredictable middle group; it is a poor fit where you need to explain to an auditor exactly which tier an object is in.

Why it caps. Block volume performance is set by VPUs per GB multiplied by volume size. Lower Cost is the zero-VPU setting: about 2 IOPS/GB, so a 1 TB volume tops out near 2,000 IOPS, with throughput similarly limited per GB. The measured 900 to 1,000 IOPS on a mixed read/write Oracle workload is consistent with that ceiling plus queueing. The instance is not the constraint - a 16-OCPU E4.Flex has far more block-volume headroom than 1,000 IOPS - which is exactly what iostat is telling you.

What to change:

1. Raise the performance setting. Balanced is 10 VPUs/GB with a ceiling around 60 IOPS/GB; High Performance is 20 VPUs/GB; Ultra High is 30 to 120. A 1 TB Balanced volume can reach tens of thousands of IOPS. Changing VPUs is a volume property change, not a data migration, so the filesystem and the database stay where they are.
2. Split by access pattern. Put redo logs on a small, high-VPU volume (sequential writes, latency-sensitive) and keep data files on a Balanced volume (random reads). One volume serving both patterns is why the queue builds during checkpoints.
3. Stripe if one volume is not enough. Per-volume ceilings apply, so two to four volumes aggregated by ASM or LVM multiply the ceiling.
4. Right-size before you over-buy. You pay for provisioned GB, not for VPUs, so a smaller volume at a higher tier is usually the cheapest way to buy IOPS. Check headroom against the actual peak, not the average.

Verify after the change with the same workload: IOPS, average latency and the database's own wait events. If latency stays high after the volume stops queueing, the problem was never the storage.

Service choice. OCI File Storage, mounted over NFSv3. The requirement is POSIX semantics and file locking on a shared directory that many writers touch concurrently, which is what a network file system gives you and what Object Storage does not: object storage is whole-object PUT/GET with no locking, no partial writes and no mmap, so render software that writes temp files, renames them and locks them will not work without a rewrite. Block volume is also wrong here - it attaches to one instance at a time (apart from specific multi-attach clustered cases), so twelve nodes cannot share it without a cluster filesystem.

Network prerequisites, in the order they bite:

1. A mount target in a subnet reachable from all twelve render nodes - ideally a private subnet in the same VCN, with the nodes in the same or a peered VCN.
2. Security rules on the mount target's subnet (or an NSG attached to the mount target and to the clients) allowing TCP 2049 and, for NFSv3 ancillary services, TCP/UDP 111 between the clients and the mount target. Remember that an NSG only applies to a VNIC if it was attached at create or update time; instances built before the NSG existed will not have it.
3. Route tables that actually reach that subnet, and no overlapping CIDRs if a peer is involved.
4. Confirm the mount target's placement is appropriate for the availability domain layout of the render nodes; if the nodes are spread across ADs, plan for the mount target placement to be reachable from all of them.

Then the day-two issues. A single shared drop area for 40 TB of intermediates will grow until someone deletes things, so agree a cleanup policy and who owns it - that is usually a bigger saving than the storage tier choice. Watch throughput as the twelfth node starts writing; if the shared area becomes the bottleneck, split by project into separate file systems rather than scaling one directory wider.