{ Abhilash Kumar Bhattaram : Follow on LinkedIn }
Scaling up databases is an outome as the business hosting the database grows , this post is to ensure OCI Engineers and DBA's take all required precautions from what I have seen and observed.
DB System is a class of OCI Databases , I have explained in depth on the internals of the DB System in the link below , would suggest reading this in case you are new to this subject.
https://dev.to/abhilash8/bcoug-presentation-on-db-system-and-exacs-25-apr-2023-52fk
Coming to the topic of scaling up DB System , there are 3 broad categories of Scale up
- CPU & Memory
- ASM Storage
#1) CPU & Memory
Sclaing up of CPU & Memory is categorized together as they will be scaled up together and either of them cannot be scaled up independently , i.e. if you are wondering you would need to scale up only meory alone you cannot and must not attempt do thar or if you would like to increase CPU's and retain the same memory settings you cannot do that as well ( you might possible be able to reduce memory but I seldom see that as a use case.)
For CPU & Memory Scaling scaling it's important to understnad that the settings are fixed for the the VM sizes , the following sizes are available at the time of writing this blog , more options are possible later.
NOTE : Scale up of CPU & Memory is not a dynamic chage , it will effect a reboot if the DB System
Available Shapes
-------------------------------------------------
DB System Shape CPU Memory
-------------------------------------------------
VM.Standard2.1 1 15 GB
VM.Standard2.2 2 30 GB
VM.Standard2.4 4 60 GB
VM.Standard2.8 8 120 GB
VM.Standard2.16 16 240 GB
VM.Standard2.24 24 320 GB
-------------------------------------------------
The complete Documentation of DB System are available in the below link in Oracle Documentation , I would recommend a read on the available sizes
Available Sizes
Reference to Change System Shapes
Areas to be cautious while scaling up
a) Backup /etc/hosts every time before scaling up , the reason for this is I had an issue with scale up CPU cires and the OCI tooling missed out the two lines ( due to some Ansible Bug in the sclae up process ) , I had to work with MOS to work with this issue.
Without the host entries the listener did not startup upon reboot nor I could start it up manually.
[grid@orclhost ~]$ srvctl start listener
PRCR-1079 : Failed to start resource ora.LISTENER.lsnr
CRS-5052: invalid host name or IP address 'orclhost-vip.labzone.labvcn.oraclevcn.com'
CRS-2674: Start of 'ora.orclhost.vip' on 'orclhost' failed
[grid@orclhost ~]$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.16.18 orclhost-priv.labzone.labvcn.oraclevcn.com orclhost-priv
10.24.3.196 orclhost.labzone.labvcn.oraclevcn.com orclhost
## Manual Fix Needed ( entries were removed by OCI Scale up Tooling )
10.24.3.196 orclhost-vip.labzone.labvcn.oraclevcn.com orclhost-vip
10.24.3.196 orclhost-scan.labzone.labvcn.oraclevcn.com orclhost-scan
b) Memory Settings
The memory settings are an important part of scaling up , if you are relatively new to this memory setting part basically the recommendation is DO NOTHING with the memory once it is set up . OCI sets up the max allowable huge pages for sga_max_size for DB Systems , It is due to this change every scale up or scale down will require an instance restart. However as needed internal SGA components like shared_pool_size and streams_pool_size can be modified to tune the memory , but please be aware when you are down scaling , these settings may need to be reset to it's defaults.
Kindly check the slides here for more details on DB System / Memory Internals
https://dev.to/abhilash8/bcoug-presentation-on-db-system-and-exacs-25-apr-2023-52fk
Once the above entries were updated manually , the listener was able to start.
[grid@orclhost ~]$ srvctl start listener
[grid@orclhost ~]$
c) Backup of PArameter file
It's always a good idea to take a parameter file backup , in case of reverting the parameter to it's earlier settings post scale up , a DBA ould normally have many such settings workign with MOS for various issues.
SQL> crate pfile='/home/oracle/before_change.ora' from spfile;
2) ASM Storage
Scaling up of Storage starts with 256 GB of ASM , we would have options od DATA / RECO sizes needed to be adjusted. Note that ASM Storage will be of EXTERNAL Redundancy only , this is engineered in such a way that Oracle would provide storage from its's internal array of Block Storage devices on demand , it would not be practical with HIGH Redundancy.
NOTE : You cannot scale down ASM storage once storage is allocated. Scaling down the DB System is also possible but only with available shapes as mentioned above.
There are multiple possible issues that can go wrong during a system change , it's always a good idea to add a procactive SR with MOS before such changes.
Top comments (0)