如果您使用的是远程Oracle数据库服务，例如Oracle自治事务处理数据库或AWS RDS数据库，您如何测量网络延迟？
通常使用“ping”或其他工具的方法无法工作，因为无法访问数据库服务的底层服务器。
如果有一种方法可以测量从您所在位置直接到远程数据库服务的往返延迟，那不是很好吗？
好的，现在有了，下面是你可以做的事情。
数据库链接
本测试使用了两个数据库。作为测试源的数据库和作为测试目标的远程数据库。
数据库链接是在本地数据库中创建的，正如您可能已经意识到的那样，数据库链接连接到远程数据库。
为了获得最佳结果，此测试的sqlplus会话最好在本地数据库的服务器上运行。如果测试是从另一台计算机上的客户机运行的，那么客户机（例如您的笔记本电脑）和本地数据库之间的连接开销可能会使测试结果产生偏差。
如果客户机和本地数据库在物理上很接近，那么倾斜可能只是毫秒的一小部分。对于大多数测试而言，这可以忽略不计。
对于此测试，目标数据库是在位于美国加利福尼亚州旧金山的虚拟服务器上创建的标准Oracle数据库。旧金山距离我的位置约700英里（1126公里）。
以下是在我的本地数据库中创建的数据库链接：
create database link droplet_link connect to pingtest identified by XXXX using 'localhost:6789/ORCLPDB1'复制
这个特定的数据库链接有点特殊。该数据库正在一家低成本供应商的远程虚拟机上运行。由于我不想打开到internet的数据库端口，因此通过ssh隧道连接到此数据库。本地端口6789被转发到数据库服务器上的端口1521。
在远程虚拟机中创建此测试数据库的原因是，也可以使用“ping”测量延迟以进行比较。
既然数据库链接已经创建，就可以执行第一个测试了。
单个数据库调用
此测试包括运行此SQL语句5次，并测量执行SQL的时间与接收结果的时间之间的差异。
这是使用的SQL语句：
select systimestamp at local from dual@dblink复制
该代码实际上是一个PL/SQL块。这可以在ping-remote-db.sql中看到
SQL以2秒的间隔运行5次。由于SQL的第一次执行可能包括连接到数据库链接所引用的数据库所需的时间，因此将忽略第一个结果。
$ echo exit | sql -S -L jkstill/XXX@orcl/pdb1 @ping-remote-db.sql Local Seconds Begin: 1641640285.703832 Local Seconds End: 1641640285.799489 Round Trip: 0.095657 ============================== Local Seconds Begin: 1641640287.864372 Local Seconds End: 1641640288.054133 Round Trip: 0.189761 ============================== Local Seconds Begin: 1641640290.103683 Local Seconds End: 1641640290.471617 Round Trip: 0.367934 ============================== Local Seconds Begin: 1641640292.537824 Local Seconds End: 1641640292.671595 Round Trip: 0.133771 ============================== Local Seconds Begin: 1641640294.711450 Local Seconds End: 1641640295.176477 Round Trip: 0.465027 ============================== Iterations: 5复制
延迟为95-465毫秒。
这与“ping”相比如何？
$ ping -i 2 -c 5 137.nnn.nn.nnn PING 137.184.84.204 (137.184.84.204) 56(84) bytes of data. 64 bytes from 137.184.84.204: icmp_seq=1 ttl=48 time=31.4 ms 64 bytes from 137.184.84.204: icmp_seq=2 ttl=48 time=623 ms 64 bytes from 137.184.84.204: icmp_seq=3 ttl=48 time=194 ms 64 bytes from 137.184.84.204: icmp_seq=4 ttl=48 time=179 ms 64 bytes from 137.184.84.204: icmp_seq=5 ttl=48 time=66.5 ms --- 137.nnn.nn.nnn ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 8004ms rtt min/avg/max/mdev = 31.441/219.196/623.788/211.862 ms复制
在最初的几次测试中，数据库ping的次数大约是标准ping次数的2倍。
其他日期的测试显示时间差异较小。
与ping实用程序相比，数据库ping有额外的开销，因此预计需要花费更多的时间。
由于远程数据库是通过互联网访问的，因此，随着互联网性能的不同，时间似乎会有多长。
多行设置Ping
如果额外的时间是由于数据库开销造成的，我们应该能够设计一个测试来最小化数据库开销。
一种方法是使用一个返回多行的SELECT语句，这样只需要执行1次SQL。
精心设计SQL，使每一行都需要一个完整的TCP数据包。然后获取检索行所需的总时间，并计算平均延迟。
使用了以下SQL：
select systimestamp at local as ping_timestamp, rpad(''X'',1500-35-28,''X'') as filler from dual@dblink_name connect by level <= 10;复制
标准TCP数据包大小为1500字节，systimptime at local的长度为35，ICMP头为28字节（无论如何，在Linux上）。
当运行这个新测试时，随着数据包数量的增加，每行的平均时间应该接近使用“ping”实用程序所看到的时间。
此脚本用于执行此操作：ping-remote-db-multirow.sql
多行db-ping测试结果：
$ echo exit | sql -S -L jkstill/XXX@orcl/pdb1 @ping-remote-db-multirow.sql Local Seconds Begin: 1641644528.779681 Local Seconds End: 1641644528.849177 Round Trip: 0.069496 ============================== Local Seconds Begin: 1641644528.849205 Local Seconds End: 1641644529.350788 Round Trip: 0.501583 ============================== Local Seconds Begin: 1641644529.350817 Local Seconds End: 1641644530.000492 Round Trip: 0.649675 ============================== Local Seconds Begin: 1641644530.000530 Local Seconds End: 1641644530.042419 Round Trip: 0.041889 ============================== Local Seconds Begin: 1641644530.042447 Local Seconds End: 1641644530.146593 Round Trip: 0.104146 ============================== Local Seconds Begin: 1641644530.146621 Local Seconds End: 1641644530.264522 Round Trip: 0.117901 ============================== Local Seconds Begin: 1641644530.264549 Local Seconds End: 1641644530.625663 Round Trip: 0.361114 ============================== Local Seconds Begin: 1641644530.625691 Local Seconds End: 1641644531.093010 Round Trip: 0.467319 ============================== Local Seconds Begin: 1641644531.093038 Local Seconds End: 1641644531.397555 Round Trip: 0.304517 ============================== Local Seconds Begin: 1641644531.397584 Local Seconds End: 1641644531.448949 Round Trip: 0.051365 ============================== Connect Time: 3.449366 Round Trip Avg: 0.289347 Iterations: 10复制
现在是一个ping测试，计数为10：
$ ping -c 10 137.nnn.nn.nnn PING 137.184.84.204 (137.184.84.204) 56(84) bytes of data. 64 bytes from 137.184.84.204: icmp_seq=1 ttl=48 time=207 ms 64 bytes from 137.184.84.204: icmp_seq=2 ttl=48 time=124 ms 64 bytes from 137.184.84.204: icmp_seq=3 ttl=48 time=1281 ms 64 bytes from 137.184.84.204: icmp_seq=4 ttl=48 time=249 ms 64 bytes from 137.184.84.204: icmp_seq=5 ttl=48 time=383 ms 64 bytes from 137.184.84.204: icmp_seq=6 ttl=48 time=58.7 ms 64 bytes from 137.184.84.204: icmp_seq=7 ttl=48 time=588 ms 64 bytes from 137.184.84.204: icmp_seq=8 ttl=48 time=84.0 ms 64 bytes from 137.184.84.204: icmp_seq=9 ttl=48 time=74.8 ms 64 bytes from 137.184.84.204: icmp_seq=10 ttl=48 time=81.1 ms --- 137.nnn.nn.nnn ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9043ms rtt min/avg/max/mdev = 58.797/313.416/1281.181/360.031 ms, pipe 2复制
平均ping时间为313 ms，db-ping测试的平均时间为289 ms，两次测试的结果非常接近。
这些结果相当糟糕。在写这篇博客的几天中，我看到这个数据库的往返延迟从25-500毫秒不等。
如果这是一个真正的生产数据库，而不是一个一次性的测试数据库，那么现在是时候请一位网络工程师了。
既然我们知道db-ping测试是相当准确的，那么当与ATP数据库一起使用时，我们可以相信结果。
以下是对位于美国亚利桑那州凤凰城的Oracle OCI数据中心的ATP数据库进行测试的结果，该数据中心距离我所在的位置约1200英里（1931公里）。
以下是数据库链接的SQL：
-- for a dblink the oracle server must have access to wallets -- so the wallets must be available on the db server create database link oci_link connect to jkstill identified by XXXX using '(description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=****************atp21c01_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=true)(ssl_server_cert_dn="CN=****.uscom-east-1.oraclecloud.com,OU=Oracle BMCS US,O=Oracle Corporation,L=Redwood City,ST=California,C=US")(my_wallet_directory=/u01/app/oracle/wallets/atp21c01)))' /复制
结果如下：
$ echo exit | sql -S -L jkstill/XXX@orcl/pdb1 @ping-remote-db-multirow.sql Local Seconds Begin: 1641644841.938675 Local Seconds End: 1641644842.365383 Round Trip: 0.426708 ============================== Local Seconds Begin: 1641644842.365437 Local Seconds End: 1641644842.603871 Round Trip: 0.238434 ============================== Local Seconds Begin: 1641644842.603898 Local Seconds End: 1641644843.064586 Round Trip: 0.460688 ============================== Local Seconds Begin: 1641644843.064614 Local Seconds End: 1641644843.749951 Round Trip: 0.685337 ============================== Local Seconds Begin: 1641644843.749978 Local Seconds End: 1641644844.319656 Round Trip: 0.569678 ============================== Local Seconds Begin: 1641644844.319686 Local Seconds End: 1641644844.550935 Round Trip: 0.231249 ============================== Local Seconds Begin: 1641644844.550964 Local Seconds End: 1641644845.017424 Round Trip: 0.466460 ============================== Local Seconds Begin: 1641644845.017453 Local Seconds End: 1641644845.678804 Round Trip: 0.661351 ============================== Local Seconds Begin: 1641644845.678831 Local Seconds End: 1641644845.868892 Round Trip: 0.190061 ============================== Local Seconds Begin: 1641644845.868920 Local Seconds End: 1641644846.417399 Round Trip: 0.548479 ============================== Connect Time: 2.455469 Round Trip Avg: 0.483373 Iterations: 10<br>复制
平均延迟为483毫秒，这对于此位置来说时间过长。
连接所需的时间也在测量中。在这种情况下，连接花费了将近2.5秒。
之前在另一天进行的测试结果要好得多，因此显然目前存在一些网络性能问题。
如果有人抱怨从这个数据库检索结果的性能很慢，那么网络性能肯定是一个主要问题。
改进
结果似乎足够好，可以普遍使用，但也可以做一些改进。
TCP数据包大小
SQL中的数据包大小计算没有考虑组织返回的数据所需的开销。使用了ICMP开销和时间戳字符串的大小，但将有几个字节用于组织该数据。返回的每一行可能需要2个TCP数据包。
为了纠正这一点，可以使用“tcpdump”实用程序分析数据大小和开销，并减少SQL中使用的填充字符串的大小。
本地的网络延迟
没有尝试纠正本地的网络延迟。
例如，我的测试是从与本地数据库位于同一机架中的客户端执行的。这些机器之间存在少量延迟，约0.000250秒，或.25毫秒。时间戳通过“timestamp at local”从本地机器返回，其中local是客户端机器。
为了更准确，可以计算并解释延迟。
然而，这确实是太多的工作，因为更简单的解决方案是直接从运行本地数据库的服务器运行这些测试。
即使没有这些优化，结果对于大多数用例来说也是可以接受的。
如果你有了办法，你可以自己尝试一下。
完整代码位于db-ping
关于作者
Jared Still
Oracle经验：从Oracle 7.0.13编程经验开始：Perl、PL/SQL、Shell、SQL还有其他一些不再有用的零碎系统：网络、存储、操作系统。
原文标题：ROUND TRIP NETWORK LATENCY TESTS FOR YOUR REMOTE DATABASE SERVICE
原文作者：Jared Still
原文链接：https://blog.pythian.com/round-trip-network-latency-tests-for-your-remote-database-service/
