\n
![\"CaptureCloudNetwork\"](\"https://www.dbi-services.com/blog/wp-content/uploads/sites/2/2022/04/CaptureCloudNetwork.jpg\")
\nI don’t want to open other port, so I’m using it with ssh tunneling. Let’s see how to tunnel port 1521:
.
\nIn previous posts, I’ve installed SLOB on the Cloud Services, measured IOPS and CPU.
\nThere’s another resource that is even more important in a cloud environment: network.
\n
I’ve create a virtual instance by default where only ssh is opened:
\n
\nI don’t want to open other port, so I’m using it with ssh tunneling. Let’s see how to tunnel port 1521:
\nssh -i ~/.ssh/cloud-fr/id_rsa -L9011:localhost:1521 140.86.3.101\nThis connects to my VM on the cloud and forwards the port 1521 (my listener port on that VM) to my local host (my laptop) port 9011.
\nWhich mean that I can connect to my database from my laptop:
\n$ tnsping //localhost:9011\n \nTNS Ping Utility for 64-bit Windows: Version 12.1.0.1.0 - Production on 12-SEP-2015 17:34:44\n \nCopyright (c) 1997, 2013, Oracle. All rights reserved.\n \nUsed parameter files:\nF:\\ora\\product\\12.1.0\\client_1\\network\\admin\\sqlnet.ora\n \nUsed HOSTNAME adapter to resolve the alias\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=9011)))\nOK (90 msec)\nNote that the time to ping is 90 milliseconds here. I’m in Switzerland and I’m connecting to the European cloud (in Amsterdam).
\nIf I do the same to the US cloud I have to cross the Atlantic:
\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=9061)))\nOK (240 msec)\nBut we will see that later.
\nI don’t want to type the above ssh line everytime I want to connect to the cloud, so I use put the following in my ~/.ssh/config file:
\n\nHost test-cloud-fr\n HostName 140.86.3.101\n Port 22\n User oracle\n IdentityFile ~/.ssh/cloud-fr/id_rsa\n LocalForward 9011 test-perf:1521\n LocalForward 9012 test-perf:5500\nThen a simple ‘ssh test-cloud-fr’ will connect the the right IP address, with the oracle user, using the right rsa private key and forwarding the listener and the EM express ports.
\nIf you connect with SQL Developer, you don’t need to do that. Check Jeff Smith blog about Connecting to the Oracle Cloud.
\nIf you put your database in the cloud, you will put the application server there as well.
\nBut if you are in client/server with the client on your desktop, or if you are a developer and connect from your PC, then latency can be a concern.
\nHere I’m selecting 90000 rows from the European cloud (the one with a 90 ms latency) to my local sqlplus:
\nSQL> set time on timing on autotrace trace stat\n09:07:25 SQL> select * from dba_objects;\n \n91718 rows selected.\n \nElapsed: 00:05:15.72\n \nStatistics\n----------------------------------------------------------\n 0 recursive calls\n 0 db block gets\n 13000 consistent gets\n 0 physical reads\n 0 redo size\n 4439199 bytes sent via SQL*Net to client\n 67754 bytes received via SQL*Net from client\n 6116 SQL*Net roundtrips to/from client\n 0 sorts (memory)\n 0 sorts (disk)\n 91718 rows processed\n \n09:12:46 SQL>\n5 minutes is a lot, but that can be improved a lot. SQL Plus default fetchsize is 15 which is very low. This is why there are 6116 roundtrips (=91718/15) and it takes on average 51 ms per roundtip.
\nBut if we increase the fetchsize:
\n09:12:46 SQL> set arraysize 5000\n09:12:54 SQL> /\n \n91718 rows selected.\n \nElapsed: 00:00:07.01\n \nStatistics\n----------------------------------------------------------\n 0 recursive calls\n 0 db block gets\n 6991 consistent gets\n 0 physical reads\n 0 redo size\n 3870546 bytes sent via SQL*Net to client\n 698 bytes received via SQL*Net from client\n 20 SQL*Net roundtrips to/from client\n 0 sorts (memory)\n 0 sorts (disk)\n 91718 rows processed\n \n09:13:04 SQL>\nNow getting 100000 rows in 7 seconds is correct.
\nRemember that all default fetchsize (SQL Plus, jdbc, hibernate, etc) are too low.
\nIt is even more important with remote databases over WAN, such databases in the cloud.
I have run a tnsping from US cloud to EU cloud every second during one week, and the same in the opposite way. Here is the result:
\n\n![\"CaptureLatency2\"](\"https://www.dbi-services.com/blog/wp-content/uploads/sites/2/2022/04/CaptureLatency2.jpg\") \n | \n\n![\"CaptureLatency1\"](\"https://www.dbi-services.com/blog/wp-content/uploads/sites/2/2022/04/CaptureLatency1.jpg\") \n |
The latency is quite stable around 170 and 180 milliseconds. Rarely over 200ms.
\nHere are the only 3 peaks observed during that week:
\nMon Sep 7 15:15:01 EDT 2015 US->FR OK (1880 msec)\nFri Sep 11 15:00:18 EDT 2015 US->FR OK (410 msec)\nWed Sep 9 19:00:16 EDT 2015 EU->US OK (530 msec)\nIf it stays like that, the latency is acceptable for a DataGuard in ASYNC.
\nOracle will provide Data Guard service, but if you want to put a Data Guard between US and EU it’s possible in maximum performance.
Finally, here is a small test to measure the bandwidth between the European Cloud Services and the US one
\nI copy a big file with scp:
\n[oracle@test-cloud-us ~]$ scp test-cloud-fr:/u02/IOPS.dbf /dev/null\nIOPS.dbf 6% 5004MB 8.0MB/s 2:27:59 ETA\n8MB/s. Here doing the same but with compression:
\n\n[oracle@test-cloud-us ~]$ scp -C test-cloud-fr:/u02/IOPS.dbf /dev/null\nIOPS.dbf 7% 5564MB 17.4MB/s 1:08:02 ETA\nBut this is only to give an idea.
\nThe DBaaS is just a remote database. Latency is always something to consider: avoid to do unnecessary roundtrips when fetching data.
\nWhen you will consider to move your databases to the cloud, you will have to think about how to transfer it. There are several options to consider to minimize downtime: Physical replication (Data Guard or Dbvisit standby), Logical replication (Golden Gate or Dbvisit replicate), data virtualization (Delphix), etc.