Wednesday, June 14, 2023

AMAON RDS

 Amazon RDS

Amazon RDS ?, if YES, then do you know how RDS will help you out for your application ?, if NO, then no worries just go through this article so that you will get to know everything about Amazon RDS and how it will be help you out for your application.

For example, your running an application with using other database products such as other than AWS database products. Then do you think that database product is more capable like in terms of backup, failure recovery, security, scaling and monitoring and metrics ? and also we can’t guarantee that no anonymous attacks will be happened to our database because of less security. So like that there are so many conflicts will occur in future. To solve all of those issues the only best solution is using Amazon RDS.

What is Amazon RDS ?

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easier to set up, operate, and scale a relational database in the AWS Cloud. It provides cost-efficient, resizable capacity for an industry-standard relational database and manages common database administration tasks.

In other words or simple words, Amazon RDS is a Database as a service(DBaas) product and as we know that AWS is fully managed service so with using Amazon RDS it is less admin overhead that means automatically it can perform scaling and it is easier to set up. It frees you to focus on your applications so you can give them the fast performance, high availability, security and compatibility they need.

NOTE: Amazon RDS is a relational database service.

Amazon RDS has their own DB engines and each engine has it’s own supported features and each version of a DB engine may include specific features.

Amazon RDS supported DB engines are:

  1. MySQL
  2. MariaDB
  3. PostgreSQL
  4. Oracle
  5. Microsoft SQL Server

RDS can be deployed in a single AZ or multi-AZ mode and supports the following instance types.

  • General Purpose(currently DB.M4 and DB.M5)
  • Memory Optimized(currently DB.R4 and DB.R5, and DB.X1e and DB.X1 for Oracle)
  • Burstable(DB.T2 and DB.T3)

RDS supports two types of storages and those are :

  • General Purpose SSD (gp2): 3 IOPS per GiB, burst to 3,000 IOPS (pool architecture like EBS)
  • Provisioned IOPS SSD (io1): 1,000 to 80,000 IOPS (engine dependent) size and IOPS can be SQL: RDS configured independently.

We have discussed that Amazon RDS is cost-effective, which means low cost so RDS will cost you based on:

  • Instance size
  • Provisioned storage (not used)
  • IOPS if using io1
  • Data transferred out
  • Any backups/snapshots beyond the 100% that is free with each DB instance

DB Instances

The basic building block of Amazon RDS is the DB instance. A DB instance is an isolated database environment in the AWS Cloud. Your DB instance can contain multiple user-created databases. You can access your DB instance by using the same tools and applications that you use with a standalone database instance. You can create and modify a DB instance by using the AWS Command Line Interface, the Amazon RDS API, or the AWS Management Console.

Each DB instance runs a DB engine. Amazon RDS currently supports the MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server DB engines. Each DB engine has its own supported features, and each version of a DB engine may include specific features. Additionally, each DB engine has a set of parameters in a DB parameter group that control the behavior of the databases that it manages.

The computation and memory capacity of a DB instance is determined by its DB instance class. You can select the DB instance that best meets your needs. If your needs change over time, you can change DB instances.

DB instance storage comes in three types: Magnetic, General Purpose (SSD), and Provisioned IOPS (PIOPS). They differ in performance characteristics and price, allowing you to tailor your storage performance and cost to the needs of your database. Each DB instance has minimum and maximum storage requirements depending on the storage type and the database engine it supports. It’s important to have sufficient storage so that your databases have room to grow. Also, sufficient storage makes sure that features for the DB engine have room to write content or log entries.

You can run a DB instance on a virtual private cloud (VPC) using the Amazon Virtual Private Cloud (Amazon VPC) service. When you use a VPC, you have control over your virtual networking environment. You can choose your own IP address range, create subnets, and configure routing and access control lists. The basic functionality of Amazon RDS is the same whether it’s running in a VPC or not. Amazon RDS manages backups, software patching, automatic failure detection, and recovery. There’s no additional cost to run your DB instance in a VPC.

Monitoring an Amazon RDS DB Instance

There are several ways that you can track the performance and health of a DB instance. You can use the Amazon CloudWatch service to monitor the performance and health of a DB instance. CloudWatch performance charts are shown in the Amazon RDS console. You can also subscribe to Amazon RDS events to be notified about changes to a DB instance, DB snapshot, DB parameter group, or DB security group.

NOTE: Amazon RDS Backup and Restore. By default, Amazon RDS creates and saves automated backups of your DB instance securely in Amazon S3 for a user-specified retention period. In addition, you can create snapshots, which are user-initiatedbackups of your instance that are kept until you explicitly delete them.

RDS’s preeminent advantage over other cloud database solutions is that it integrates seamlessly with AWS’s robust ecosystem of cloud-based tools, services, and solutions. AWS is far and away the leading cloud provider with the most powerful, reliable, and flexible suite of cloud services that integrate flawlessly with one another.

Why do you want a managed relational database service ?

  1. Generally when we purchase a server, we will get CPU, memory, storage, and IOPS, all bundled together. With Amazon RDS, these are split apart so that you can scale them independently. If you need more CPU, less IOPS, or more storage, you can easily allocate them.
  2. Amazon RDS manages backups, software patching, automatic failure detection, and recovery.
  3. To deliver a managed service experience, Amazon RDS doesn’t provide shell access to DB instances. It also restricts access to certain system procedures and tables that require advanced privileges.
  4. You can have automated backups performed when you need them, or manually create your own backup snapshot. You can use these backups to restore a database. The Amazon RDS restore process works reliably and efficiently.
  5. You can get high availability with a primary instance and a synchronous secondary instance that you can fail over to when problems occur. You can also use MySQL, MariaDB, or PostgreSQL read replicas to increase read scaling.
  6. You can use the database products you are already familiar with: MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server.
  7. In addition to the security in your database package, you can help control who can access your RDS databases by using AWS Identity and Access Management (IAM) to define users and permissions. You can also help protect your databases by putting them in a virtual private cloud.

How does RDS works ?

RDS operates within an instance (an isolated, cloud-based database environment). When you create a new database, you choose the database engine it runs.

RDS is compatible with the most popular engines:

  • MySQL
  • MariaDB
  • PostgreSQL
  • Oracle
  • Microsoft SQL Server
  • Aurora

The computation and memory resources allocated to the database are determined by what AWS calls its “instance class.” As a database grows, its instance class can easily be upgraded with very little downtime to provide more resources making it a highly scalable and flexible solution.

There are currently 27 instance classes to choose from with a range of resource options. Instances can have as little as 1 GB of memory up to 256 GB and provide a single processing core up to 64 cores. There’s an instance class to fit pretty much every use case and all of these instance sizes are available to Pagely customers so RDS is part of what makes Pagely such a flexible, customizable hosting solution for companies with unique technical demands.

Read Replicas

Using Read Replicas “you can elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads.” Source

To get started with Read Replicas you first pick a database that will operate as the source. A snapshot is created to duplicate the database and that duplicate version is updated whenever there is a change to the source database.

Note that Read Replicas are only compatible with MariaDB, MySQL, Oracle, and PostgreSQL engines.

Why to use RDS ?

  1. No infrastructure management
  2. Cost-effective
  3. Application compatibility
  4. Instant provisioning
  5. Scale up/down

RDS use cases

  1. Web and Mobile applications
  2. Ecommerce applications
  3. Mobile and online games

RDS Benefits

  1. Easy to administer
  2. Highly scalable
  3. Available and durable
  4. Fast
  5. Secure
  6. Inexpensive

Posted by at No comments:
Labels:

Monday, May 22, 2023

Oracle Exadata Database Service on Cloud@Customer

 

Oracle Exadata Database Service on Cloud@Customer

Get Started

Oracle Exadata Database Service on Cloud@Customer combines cloud simplicity, agility, and elasticity with deployment inside your data center to provide full-featured Oracle Database instances hosted on Oracle Exadata Database Machine.

Oracle Exadata Database Service on Cloud@Customer On Premises server deployment and infrastructure administration.

To obtain additional information about the features and management of databases on Oracle Exadata Database Service on Cloud@Customer, which is deployed using Oracle Cloud Infrastructure management APIs, you can access the latest documentation for Exadata and Oracle Database management using the Oracle Cloud Infrastructure Console, the application programming interface (API), or the command-line interface (CLI).

To prepare your data center and administer your Oracle Exadata Database Service on Cloud@Customer server, use the menu to locate the information that you require.


Prepare to Oracle Exadata Database Service on Cloud@Customer On Premises

Posted by at No comments:
Labels: ,

Sunday, May 21, 2023

How to resize ASM disks in Exadata

 How to resize ASM disks in Exadata 


The ASM disks in Exadata are provisioned as griddisks from Exadata storage cells. The griddisks are created from the celldisks. Normally, there is no free space in celldisks, as all space is used for griddisks, as seen in this example from storage cell 1:

# cellcli -e "list celldisk where name like 'CD.*' attributes name, size, freespace"
CD_00_exacell01 528.734375G 0
CD_01_exacell01 528.734375G 0
CD_02_exacell01 557.859375G 0
...

This document shows how to free up some space from the griddisks in RECO disk group, and then reuse that space to increase the size of disk group DATA.

Free up space on celldisks

To free up some space, say 88 GB per disk in disk group RECO, we need to reduce the disk size in ASM, and then reduce the griddisk size in Exadata storage cells. Let's do that for disk group RECO.

We start with the RECO griddisks with the size of 316.6875 GB:

# cellcli -e "list griddisk where name like 'RECO.*' attributes name, size"
RECO_CD_00_exacell01 316.6875G
RECO_CD_01_exacell01 316.6875G
RECO_CD_02_exacell01 316.6875G
...

To free up 88 GB, the new griddisks size will be 316.6875 GB - 88 GB = 228.6875 GB = 234176 MB.

Reduce size of RECO disks in ASM

Resize all disks in disk group RECO in ASM:

$ sqlplus / as sysasm

SQL> alter diskgroup RECO resize all size 234176M rebalance power 32;

Diskgroup altered.

SQL>

The command will trigger the rebalance operation for disk group RECO.

Monitor the rebalance with the following command:

SQL> select * from gv$asm_operation;

Once the command returns "no rows selected", the rebalance would have completed and all disks in disk group RECO should show new size.

SQL> select name, total_mb from v$asm_disk_stat where name like 'RECO%';

NAME                   TOTAL_MB
---------------------- --------
RECO_CD_11_EXACELL01 234176
RECO_CD_10_EXACELL01 234176
RECO_CD_09_EXACELL01 234176
...
RECOC1_CD_03_EXACELL03 234176

36 rows selected.

SQL>

Reduce size of RECO disks in storage cells

Resize the RECO griddisks on all storage cells. On storage cell 1, the command would be:

# cellcli -e alter griddisk RECO_CD_00_exacell01, RECO_CD_01_exacell01, RECO_CD_02_exacell01, RECO_CD_03_exacell01, RECO_CD_04_exacell01, RECO_CD_05_exacell01, RECO_CD_06_exacell01, RECO_CD_07_exacell01, RECO_CD_08_exacell01, RECO_CD_09_exacell01, RECO_CD_10_exacell01, RECO_CD_11_exacell01 size=234176M;

GridDisk RECO_CD_00_exacell01 successfully altered
GridDisk RECO_CD_01_exacell01 successfully altered
GridDisk RECO_CD_02_exacell01 successfully altered
...
GridDisk RECO_CD_11_exacell01 successfully altered
#

Repeat the above resize on all storage cells.

Now we have some free space on celldisks (show here on storage cell 1):

# cellcli -e "list celldisk where name like 'CD.*' attributes name, size, freespace"

  CD_00_exacell01 528.734375G 88G
  CD_01_exacell01 528.734375G 88G
  CD_02_exacell01 557.859375G 88G
...

#

Increase size of DATA disks in storage cells

We can now increase the size of DATA griddisks, and then increase all disks size of disk group DATA in ASM.

The current DATA griddisks size is 212 GB:

# cellcli -e "list griddisk where name like 'DATA.*' attributes name, size"

  DATA_CD_00_exacell01 212G
  DATA_CD_01_exacell01 212G
  DATA_CD_02_exacell01 212G

...

The new griddisks size will be 212 GB + 88 GB = 300 GB.

Resize the DATA griddisks on all storage cells. On storage cell 1, the command would be:

# cellcli -e alter griddisk DATA_CD_00_exacell01, DATA_CD_01_exacell01, DATA_CD_02_exacell01, DATA_CD_03_exacell01, DATA_CD_04_exacell01, DATA_CD_05_exacell01, DATA_CD_06_exacell01, DATA_CD_07_exacell01, DATA_CD_08_exacell01, DATA_CD_09_exacell01, DATA_CD_10_exacell01, DATA_CD_11_exacell01 size=300G;

GridDisk DATA_CD_00_exacell01 successfully altered
GridDisk DATA_CD_01_exacell01 successfully altered
GridDisk DATA_CD_02_exacell01 successfully altered
...
GridDisk DATA_CD_11_exacell01 successfully altered

# cellcli -e "list griddisk where name like 'DATA.*' attributes name, size"
  DATA_CD_00_exacell01 300G
  DATA_CD_01_exacell01 300G
  DATA_CD_02_exacell01 300G
...

#

Repeat the above resize on all storage cells.

Increase size of DATA disks in ASM

Increase the size of all disks in disk group DATA, with the following command:

$ sqlplus / as sysasm

SQL> alter diskgroup DATA resize all rebalance power 32;

Diskgroup altered.

SQL>

Note that there was no need to specify the new disks size, as ASM will get that from the griddisks. The rebalance clause is optional.

The command will trigger the rebalance operation for disk group DATA.

Monitor the rebalance with the following command:

SQL> select * from gv$asm_operation;

Once the command returns "no rows selected", the rebalance would have completed and all disks in disk group DATA should show new size:

SQL> select name, total_mb/1024 "GB" from v$asm_disk_stat where name like 'DATA%';

NAME GB
------------------------------ ----------
DATA_CD_02_EXACELL01 300
DATA_CD_09_EXACELL01 300
DATA_CD_07_EXACELL01 300
...
DATA_CD_06_EXACELL03 300

36 rows selected.

SQL>

Conclusion

If there is free space in Exadata cell disks, increasing the disk group size can be accomplished in two steps - griddisk size increase on all storage cells followed by the disk size increase in ASM. This requires a single ASM rebalance operation. If there is no free space in celldisks, some space may be freed up from other disk group(s) as shown in the example.

Note that reducing starts with reducing the disks size in ASM, followed by reducing the griddisks size. The increase starts with the griddisks size increase, followed by increasing the disks size in ASM.


Document id- 1684112.1

Posted by at No comments:
Labels:

Friday, May 19, 2023

ASM Cluster File System Snapshots on Exadata

 ASM Cluster File System Snapshots on Exadata


Database snapshots are a regularly required feature of any application development project. With Oracle Database and on Oracle Exadata, there are many ways of creating and maintaining database clones or copies, including PDB Clones, Full Database Clones, Exadata Sparse Clones, and now ACFS Snapshot Clones on Exadata!

Database clones are needed to allow organizations to test and develop against production-like database environments. Sometimes the volume of data is important, other times less so. Sometimes each developer should have (or wants) a separate environment for their work before code is moved into system test, integration, performance test environments. Some use cases for database clones may have nothing to do with development or testing — at least not in the IT sense of these terms — some organizations may want to furnish their analysts with a database for what/if analysis or model training, tuning, etc without impacting their production database. There are many reasons why a database clone may be required, and as I mentioned above, there are many different ways of supporting this requirement on Exadata.

The ASM Cluster File System (ACFS) is a POSIX compliant general-purpose file system that can also be used to house database files on Exadata. ACFS supports advanced snapshot capabilities similar to third-party copy-on-write style filesystem snapshots. Of particular note when using ACFS Snapshots, customers can create read-write test masters spanning multiple timelines.

Conceptually, something like the following is possible:

Let’s unpack that a little.

Firstly, to use ACFS Snapshots, you need to have a database — say a Data Guard Standby Database — on ACFS. You could also use gDBClone or use RMAN to create a duplicate database on ACFS. ACFS Snapshots are filesystem snapshots, unlike Exadata Sparse Clones which are sparse files that point back to a read-only datafile.

Once you have a “source” database, you would then stop redo apply, create an ACFS Snapshot — a Test Master in the above diagram — and then restart redo apply in the standby database.

What’s happening now is the ACFS Snapshot is static, but the standby is moving forward again as the primary database sends redo to it. As the standby moves forward ACFS is copying changed blocks into the snapshot directory so the “original” image of the block is available for queries and DML. Note that the initial snapshot level is read-only.

You can then create multiple read-write ACFS Snapshots and database instances with which to use the datafiles. These can in turn can be a read-write “Test Master” for subsequent read-write snapshots and databases.

If you have started with a Data Guard Standby Database, you can repeat the process of stopping redo apply, creating a new ACFS Snapshot — at the current time — and restarting redo apply, allowing multiple timelines to exist simultaneously using the same Standby as the ultimate source of data blocks.

Another way of presenting this is as follows. The opaque database at the top is our Standby Database on ACFS that continually moves forward in time as it receives and applies redo. At various intervals, ACFS Snapshots are created to act as a read-only Test Master, and then multiple snapshots at varying levels are created for use as read-only or read-write snapshot databases.

A few important points to make:

  • ACFS on Exadata supports only the Exadata Flash Cache — features such as (but not limited to) Smart Scan, Storage Indexes, Persistent Memory Data and Commit Accelerators are not available to databases located on ACFS
  • ACFS Snapshots on Exadata are for Dev/Test only
  • Oracle Grid Infrastructure 19.10 (with performance patches) or higher is required. Grid Infrastructure 19.11 is recommended
  • ACFS Encryption is NOT supported for database data files — if you need to encrypt data in any Oracle Database, you should use Transparent Data Encryption.
  • ACFS Snapshots support all types of Oracle Database:
    — CDB Databases and all Plugable Databases in said CDB
    — Individual Pluggable Databases
    — Non-CDB Databases
  • If you’re using Data Guard with ACFS, make sure you have a “true” DR Data Guard Standby Database on ASM. If you need to failover to DR, you don’t want to lose all the Exadata performance features.
  • For highest availability, the ASM diskgroups that the ACFS Filesystems are created from should be High Redundancy diskgroups
  • Do not use ACFS for database homes, encryption wallets, diagnostics, or audit destinations
  • Do not co-locate dev/test databases with production databases on the same RAC or VM Cluster

You can find more on ACFS Snapshots and Exadata Sparse Clones in this presentation from the MAA Team

These MOS Notes and documentation links are also well worth checking out as you get stuck into creating database clones.

I’d like to thank the MAA, Exadata, and of course ACFS development teams for all the work that has gone into delivering and testing ACFS Snapshots on Exadata.

Let us know what you think about ACFS Snapshots and Exadata Sparse Clones in the comments below.

Happy snapshotting!

Reference - Oracle blog

Posted by at No comments:
Labels:

April 2023 Update Available for ECC

 

April 2023 Update Available for ECC

Enterprise Command Center development colleagues have recently announced the April 2023 update of the Oracle E-Business Suite Enterprise Command Centers (ECC). This is the tenth since the Enterprise Command Centers were introduced in October 2018. 


Overall, there are now 35 Enterprise Command Centers with more than 140 role-based dashboards for the following Oracle E-Business products:

  • Financial Management: Receivables, iReceivables, Payables, Assets, Lease Contracts (Financials), Lease and Finance Management
  • Order Management and Logistics: Order Management, Inventory Management, Advanced Pricing, iStore, Landed Cost Management, Channel Revenue Management, Incentive Compensation
  • Asset Lifecycle and Service: Enterprise Asset Management, Asset Tracking, Service Contracts, Service (TeleService), Field Service, Depot Repair
  • Procurement and Projects: iProcurement, Procurement, Projects, Project Procurement, Contract Lifecycle Management for Public Sector
  • Manufacturing: Discrete Manufacturing, Process Manufacturing,Outsourced Manufacturing, Project Manufacturing, Cost Management, Quality, Bills of Material
  • Human Capital Management: Human Resources, Payroll

What's New with the ECC April 2023 Update?

The April 2023 update delivers many new functional and UI capabilities that Oracle E-Business Suite customers can use to enhance and extend current business processes. These include 11 new dashboards (*), enhancements to existing dashboards, power user personalization, enhancements to the ECC Framework, and more

Posted by at No comments:
Labels: ,

Jan 2023 Updates to EBS Technology Codelevel Checker (ETCC)

 

Jan 2023 Updates to EBS Technology Codelevel Checker (ETCC)

The E-Business Suite Technology Codelevel Checker (ETCC) utility identifies patches that need to be applied to your Oracle E-Business Suite 12.2 technology stack for the application and database tiers.

beginning with the ETCC update for the January 2023 proactive patch updates there will be two MOS notes for the consolidated list of patches and bug fixes:  one for the Oracle Fusion Middleware and one for the Oracle Database.

The following are links to the new EBS FMW consolidated list of patches and bug fixes and the updated EBS Database consolidated list of patches and bug fixes:

Note:  How ETCC works remains the same with this update to the documentation.  

Latest Updates

ETCC has been updated to include bug fixes and patching combinations for the following recommended versions and platforms:

Fusion Middleware (All Platforms)

  • WebLogic Patch Set Update 10.3.6.0.230117
  • Oracle Fusion Middleware 11.1.1.9
  • Forms and Reports 10.1.2.3.2

Database (Linux Only)

  • Oracle Database Release Update RU 19.18.0.0.230117
  • Oracle JavaVM Component Database RU 19.18.0.0.230117
  • Oracle Database Proactive BP 12.1.0.2.230117
  • Oracle Database PSU 12.1.0.2.230117
  • Oracle JavaVM Component Database PSU 12.1.0.2.230117
  • Oracle Database Patch for Exadata BP 11.2.0.4.230117
  • Oracle Database PSU 11.2.0.4.230117
  • Oracle JavaVM Component Database PSU 11.2.0.4.230117

Obtaining ETCC

We recommend using the latest version of ETCC, as new bugfixes will not be checked by prior versions of the utility. The latest version of the ETCC tool can always be downloaded via Patch 17537119 from My Oracle Support.

ETCC-Jan-2023-Part-1

References

Posted by at No comments:
Labels: , ,
Subscribe to: Posts (Atom)