Saturday, February 17, 2024

Oracle Database Deployment: EC2 vs. RDS vs. Custom RDS

 

Oracle Database Deployment: EC2 vs. RDS vs. Custom RDS


Overview

This summary contrasts three deployment models for Oracle databases, assessing control, cost, management, scalability, and availability to guide strategic decision-making.

Deployment Options

Amazon EC2 (Self-Managed Oracle)

  • Control: Maximum, with complete customization.
  • Management: High responsibility; manual updates, maintenance.
  • Cost: Higher due to manual management and operational expenses.
  • Flexibility: Full, manual scalability and availability configurations.
  • Use Case: Niche applications requiring unique configurations or specific Oracle features.

Amazon RDS for Oracle

  • Control: Moderate, with managed service benefits.
  • Management: Lowered by automated tasks (backups, patching).
  • Cost: Reduced through managed services and no upfront hardware investment.
  • Flexibility: Built-in scalability and high availability (Multi-AZ).
  • Use Case: General business applications seeking balance between management ease and customization.

Custom RDS Solution for Oracle

  • Control: High, tailored environment for Oracle.
  • Management: Significant, akin to EC2 but with potential for cloud-agnostic deployment.
  • Cost: Varied, influenced by design complexity and infrastructure choice.
  • Flexibility: Custom-configured for scalability and DR.
  • Use Case: Specific scenarios needing cloud-agnostic setups or advanced Oracle functionalities not available in Amazon RDS.

Key Considerations

  • Operational Overhead vs. Automation: Choose between hands-on control (EC2, Custom RDS) and operational efficiency (Amazon RDS).
  • Cost Implications: Consider long-term TCO, balancing upfront investments against ongoing operational savings.
  • Scalability and Reliability: Weigh the need for manual setup and customization against the convenience of managed scalability and availability.

Recommendation

Aligning with business objectives and IT capabilities is paramount. Amazon RDS for Oracle is recommended for most use cases due to its balance of ease of use, cost-effectiveness, and built-in features. EC2 or Custom RDS may be suited for specialized requirements outside RDS's scope.


For a concise, one-page summary in a comparative format that highlights the differences between Amazon EC2, Amazon RDS for Oracle, and custom RDS solutions for Oracle, a table is an effective way to present the information clearly and facilitate quick comparison. This format supports executive decision-making by directly contrasting key aspects of each option.


Comparative Summary: Oracle Database Deployment Options

CriteriaAmazon EC2Amazon RDS for OracleCustom RDS Solution
ControlMaximum (full OS and DB control)Moderate (managed DB settings)High (customizable environment)
Management EffortHigh (manual setup and maintenance)Low (automated backups, patching)High (requires manual management)
Cost EfficiencyVariable (depends on management and scaling)High (reduced operational costs)Variable (depends on complexity)
ScalabilityManual (requires planning and execution)Automated (easy scaling options)Manual (flexible but complex)
High AvailabilityManual setup (custom HA configurations)Built-in (Multi-AZ for automatic failover)Manual setup (custom HA solutions)
Backup and RecoverySelf-managed (custom backup solutions)Automated (with point-in-time recovery)Self-managed (flexible strategies)
SecuritySelf-managed (custom security measures)Managed (encryption, network isolation)Self-managed (customizable security)
Use CaseSpecialized needs (specific configurations)General business applications (balance of ease and functionality)Specific scenarios (cloud-agnostic or advanced Oracle features)

Key Takeaways

  • Amazon EC2 offers the highest level of control and customization, suited for specialized deployments that require specific Oracle features or configurations not supported by RDS.
  • Amazon RDS for Oracle provides a managed service that balances ease of use with flexibility, ideal for businesses looking for cost-effective and scalable database solutions without the need for extensive database administration.
  • Custom RDS Solution is tailored for unique requirements, offering high control and flexibility, particularly for scenarios demanding cloud-agnostic deployments or leveraging advanced Oracle functionalities beyond RDS capabilities.

Strategic Recommendation

Evaluate business needs, technical requirements, and resource availability to select the most suitable deployment option. Consider Amazon RDS for its operational efficiency and cost benefits for standard applications, while EC2 or custom RDS solutions might be better suited for specialized requirements.bad

Tuesday, February 6, 2024

Check the Oracle database is Exadata

 

Check the Oracle database is Exadata

select decode(count(cell_path),0,'Non-Exadata','Exadata') "System" from v$cell;	

Sunday, January 28, 2024

Autonomous Database

 Benefits of Oracle Autonomous database









Youtube links-

https://www.youtube.com/watch?v=nyo3FsBpKBE

Tuesday, December 19, 2023

Relation between RMAN retention period and control_file_record_keep_time (Doc ID 397269.1)

Relation between RMAN retention period and control_file_record_keep_time 


PURPOSE


Guideline to set CONTROL_FILE_RECORD_KEEP_TIME in relation to the RETENTION POLICY

SCOPE


RMAN backup keeps the backup metadata information in the reusable section of the controlfile. It depends on the parameter CONTROL_FILE_RECORD_KEEP_TIME. CONTROL_FILE_RECORD_KEEP_TIME specifies the minimum number of days before a reusable record in the control file can be reused. In the event a new record needs to be added to a reusable section and there is not enough space then it will delete the oldest record, which are aged enough.

Backup retention policy is the rule to set regarding which backups must be retained (whether on disk or other backup media) to meet the recovery and other requirements.

If the CONTROL_FILE_RECORD_KEEP_TIME is less than the retention policy then it may overwrite the RMAN metadata in the reusable records prior to obsoleting them. Without the metadata RMAN cannot delete the backups. Therefor it is recommended that the CONTROL_FILE_RECORD_KEEP_TIME should be set to value higher than the retention policy configuration.

Please note the default control_file_record_keep_time is 7 days.


NOTE: Best practice is to NOT set to a value greater than 10. If you need retention greater than this in the controlfile, you should use an RMAN catalog .

Bigger values, will hold data for more time, But will also have bigger the size of the controlfile, which in turn can cause performance issue are more entries from controlfile need to be read.

The exception is when using Database in the Oracle Cloud, control_file_record_keep_time default value after enable backup is 40 without using Recovery Catalog

Typically control_file_record_keep_time is by default set to higher value in cloud DB systems which is approved by database cloud engineering group.

Formula

CONTROL_FILE_RECORD_KEEP_TIME = retention period + level 0 backup interval + 1

For e.g.

e.q. level 0 backup once a week with retention policy of a recovery windows of 14 days then in this case the CONTROL_FILE_RECORD_KEEP_TIME should be 14+7+1=22

To be on safer side you can always add + 2 or 3 days to above formula.

Ideally its recommended to configure a recovery catalog so that information about the backups are present in recovery catalog even though the controlfile section gets reused based on the control_file_record_keep_time due to space pressure.

RMAN-07553 / RMAN-07554 - POST DATABASE UPGRADE TO 19C (Doc ID 2887420.1)



 RMAN-07553 / RMAN-07554 - POST DATABASE UPGRADE TO 19C

APPLIES TO:Oracle Database - Enterprise Edition - Version 19.7.0.0.0 and later
Information in this document applies to any platform.

SYMPTOMS

getting warning message while executing delete obsolete


rman target /



RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF X DAYS;

RMAN> DELETE OBSOLETE;

RMAN retention policy will be applied to the command

RMAN retention policy is set to recovery window of X days

RMAN-07554: warning: CONTROL_FILE_RECORD_KEEP_TIME is too large (n days)


or

RMAN-07553: warning: RECOVERY WINDOW is more than CONTROL_FILE_RECORD_KEEP_TIME

In the above example, the parameter control_file_record_keep_time is set to n days which is greater than 30 (RMAN-07554) or recovery window is greater than CONTROL_FILE_RECORD_KEEP_TIME(RMAN-07553)
CHANGES

RMAN-07554 - Recovery catalog is not used and CONTROL_FILE_RECORD_KEEP_TIME is set to greater than 31

RMAN-07553 - Recovery catalog is not used and recovery window is greater than CONTROL_FILE_RECORD_KEEP_TIME


CAUSE


These warning messages are printed intentionally during report obsolete / delete obsolete commands which is expected to warn user if recovery window is > 31 days in nocatalog mode. Also, it warns
if control_file_record_keep_time is < recovery window in nocatalog mode.

SOLUTION

These warning messages are introduced to suggest user to use catalog db if control_file_record_keep is greater than 31 or control_file_record_keep_time is < recovery window. To avoid these warning messages, use recovery catalog or set the value for CONTROL_FILE_RECORD_KEEP_TIME to less than 31 for RMAN-07554 and set the value of control_file_record_keep_time greater than recovery window when recovery catalog is not used.