Actually, this blog post doesn’t have anything to do with upgrades – and yet it does. I will be talking about how fast you can transfer data from one VM DB System to another. How does that relate to upgrading? In some situations, it will have a direct impact on the downtime needed to upgrade a VM DB System. Allow me to explain.
For now – when you need to upgrade a VM DB System you have to provision a brand-new system, move the database and then upgrade. The move part is where the transfer speed comes into play. Whether you are transferring a cold copy of the database or doing RMAN backups you will eventually end up with a bottleneck in terms of getting the data from one system to the other. Other more elegant approaches (like having a standby on the new system) can’t be used because of the limitations of VM DB Systems. You are – for instance – not allowed to install any other Oracle Homes on a system than the one that comes when the system is provisioned.
Now back to transfer speed. There are four factors that comes into play:
- How fast can the source system read the data from disk
- How fast can the source system send the data over the network
- How fast can the target system receive the data from the network
- How fast can the target system write the data to disk
That now boils down to two things:
- I/O throughput
- Network speed
I/O Throughput
A VM DB System uses block storage that is allocated when the system is created. The speed of the storage depends on the amount of storage you provision. The more storage, the faster disks.
| Storage (GB) | Throughput MB/s |
|---|---|
| 256 | 120 |
| 512 | 240 |
| 1024 | 480 |
| 2048 | 960 |
| 4096 | 1280 |
| 6144 | 1280 |
| 8192 | 1280 |
| 10240 | 1600 |
| 12288 | 1920 |
| 14336 | 2240 |
| 16384 | 2560 |
| 18432 | 2880 |
| 20480 | 3200 |
You can scale up on storage and get more throughput but be aware that you can’t scale down. Once you have allocated storage there is no way to get rid of it again. So, it is not really suitable for a one-time operation. The good news is that storage scales online so there is no need for downtime to make changes.
But block storage is network attached. So even if the storage is really, you must still have network capacity to send it.
Network Speed
The network speed of your VM DB System depends on the number of OCPUs that you allocate. The more OCPUs, the more network speed.
| Shape | Throughput MB/s |
|---|---|
| VM.Standard.2.1 | 128 |
| VM.Standard.2.2 | 256 |
| VM.Standard.2.4 | 512 |
| VM.Standard.2.8 | 1024 |
| VM.Standard.2.16 | 2048 |
| VM.Standard.2.24 | 3200 |
You can scale up and scale down a VM DB System. So if you need more network throughput for a period of time, you can just scale up. You only need $$$ and downtime. I did some wristwatch measurements and it takes roughly 10 minutes to do a scale operation (either up or down).
Conclusion
If you want to increase the transfer speed between two VM DB Systems, you have two options:
- Add more OCPUs
- Add more storage
Adding OCPUs is easy and can be reverted once there is no longer a need for the increased throughput. Storage however can only scale up. Obviously, you have to consider the limits of both the sending system as well as the receiving system.
If you end up in a situation where downtime matters to you and you need to move data between two VM DB Systems, you can increase transfer speeds by scaling up.
But since the storage is network attached, you need twice as much network bandwidth as I/O throughput. The VM must use network bandwidth on receiving the data from the remote host, and again to send the data to the storage system. If you are using ASM with redundancy, you need even more network bandwidth.
I recommend that you test the throughput in your specific system to know the limits, and prove the numbers.
Databases Are Fun 