El hardware bajo la base de datos: NVMe, red y PCI Express
Toda consulta a Oracle acaba apoyándose en el mismo sitio: un árbol PCI Express del que cuelgan los discos NVMe y la tarjeta de red. Dos servidores con la misma CPU rinden distinto porque lo que cambia está debajo.
La respuesta corta: una base de datos no habla con "el disco" ni con "la red", habla con dispositivos conectados como endpoints a un bus PCI Express. El SSD NVMe que guarda los datafiles y la NIC que sirve las sesiones comparten el mismo enlace serie hacia el root complex del procesador. Entender ese bus explica las cifras que importan: ancho en lanes, generación en GT/s y el ancho de banda útil que queda después de la codificación.
¿Por qué una base de datos Oracle depende del bus PCI Express?
Cuando una consulta pide un bloque que no está en la SGA, la petición baja por el kernel hasta el controlador NVMe, que es un endpoint PCIe enchufado a un root port. Lo mismo ocurre al revés con la red: cada resultado que sale hacia el cliente JDBC atraviesa una NIC que es otro endpoint del mismo árbol. Latencia de lectura, colas del controlador y ancho de enlace se suman en cada db file sequential read. En el apartado que baja del plano de la aplicación al del hardware, la referencia en inglés Root Complex ordena las cifras de el enlace PCI Express (lanes, entrenamiento LTSSM, tasas por generación y ancho de banda usable) a partir de las especificaciones públicas, con el documento y la fecha de consulta de cada número.
¿Qué cambia entre una generación PCIe y la siguiente?
Cada generación duplica la tasa por lane: de 2,5 GT/s en PCIe 1.0 a 64 GT/s en PCIe 6.0. El cambio no es solo de velocidad bruta: la codificación pasó de 8b/10b (un 20 % de overhead) a 128b/130b en las generaciones 3 a 5, y a PAM4 con FLIT en la 6.0. Por eso un lane x4 de generación 4 mueve datos como un x8 de generación 2, y por eso el mismo disco NVMe rinde la mitad si la placa lo negocia a una generación menor. El protocolo de aplicación que corre encima, NVMe, tiene sus propias especificaciones públicas en nvmexpress.org: número de colas, profundidad y comandos se leen allí, no en el folleto del fabricante.
¿Cómo leer la hoja de datos de un servidor sin fiarse del marketing?
El marketing habla de "hasta"; la especificación habla de lanes y generación. En un servidor real se comprueba con lspci, comparando lo que el dispositivo anuncia (LnkCap) con lo que ha negociado (LnkSta):
$ lspci -vv -s 81:00.0 | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 16GT/s, Width x4
$ lspci -vv -s 18:00.0 | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 32GT/s, Width x16
LnkSta: Speed 32GT/s, Width x8El segundo caso es el susto clásico: una NIC capaz de x16 que ha negociado x8, por slot, por riser o por configuración de BIOS. En una base de datos que vive de la red de almacenamiento o de muchas sesiones concurrentes, ese detalle vale más que el nombre comercial de la tarjeta. Lo mismo aplica al disco: un NVMe de generación 4 pinchado en un slot de generación 3 funciona, pero a la mitad de techo.
Lo que esto cambia al administrar Oracle
El diagnóstico sigue empezando dentro de la base: las consultas al diccionario de datos dicen qué sesiones esperan y sobre qué ficheros. Pero cuando la espera es de E/S, la respuesta ya está una planta más abajo, en lanes y generaciones. En bases particionadas que mueven terabytes, como las que revisamos en tablas particionadas, la diferencia entre un enlace bien y mal negociado se mide en horas de carga. Y si el problema aparece como sesiones que no llegan, conviene recordar que la red también es un endpoint del mismo árbol: el ORA-12516 se diagnostica en el listener, pero su raíz puede estar en el cable.
La base de datos no vive en el aire: vive sobre un bus con número de lanes y velocidad negociada, y esa cifra sí se puede leer.