Yo diría que fuera de la transacción. Ciertamente, en PostgreSQL, aspiración está diseñado para eliminar las tuplas "muertas" (es decir, la fila de edad cuando un registro ha sido cambiado o eliminado.)
Si está ejecutando vacío en una transacción que tiene registros modificados, estas filas muertos no habrá sido marcado para borrado.
Dependiendo del tipo de VACÍO que esté haciendo, también puede requerir un bloqueo de tabla que bloqueará si hay otras transacciones en ejecución, por lo que podría terminar en una situación de bloqueo (la transacción 1 está bloqueada esperando una bloqueo de tabla para hacer su VACÍO, la transacción 2 se bloquea esperando a que se lance una fila que la transacción 1 ha bloqueado).
También recomendaría que esto no se haga en una aplicación (tal vez como una tarea programada) ya que puede llevar un tiempo completarlo y puede afectar negativamente la velocidad de otras consultas.
En cuanto a SQL Server, no hay VACÍO, lo que está buscando es reducir. Puede activar la reducción automática en 2005, que recuperará espacio automáticamente cuando lo decida el servidor, o emitirá una declaración DBCC para reducir la base de datos y el archivo de registro, pero esto depende de su rutina de respaldo y estrategia por nivel de base de datos.
Se realiza después de un proceso de sincronización móvil.La transacción anterior realiza muchas modificaciones en la base de datos. Como esto se hace en el móvil, necesito emitir un VACÍO para compactar la base de datos. – Pentium10