INMEMORY_ONNX_MODEL

This procedure enables you to control the in-memory sharing of initializers for an ONNX model with external initializers within the database. When you enable in-memory sharing, the database loads the model’s initializers once into shared memory, so that all sessions using the model benefit from reduced aggregate memory consumption. You must load or import the model before calling this procedure. Attempting to enable in-memory sharing on a model that has not been imported raises an error.

Note that only models with external data can be shared using INMEMORY_ONNX_MODEL. Models without external initializers cannot be enabled for in-memory sharing; attempting to do so will raise an error.

Syntax

DBMS_VECTOR.INMEMORY_ONNX_MODEL(
   model_name IN VARCHAR2,
   enable     IN BOOLEAN DEFAULT TRUE);

Parameters

Table 7 INMEMORY_ONNX_MODEL Procedure

Parameter	Description
model_name	Name of the model in the form [schema_name.]model_name. If you do not specify a schema, then your own schema is used. See DBMS_DATA_MINING.IMPORT_ONNX_MODEL Procedure for restrictions on the name of the model.
enable	Specify whether to enable or disable in-memory sharing for the ONNX model. Possible options: TRUE: When you set this parameter to TRUE (the default), the database loads and shares the model's initializers in shared memory, allowing all processes to use the same copy during scoring. FALSE: When you set it to FALSE, the database disables in-memory sharing and reclaims the shared memory after all processes finish using the model.

Example

The following example demonstrates how you can enable in-memory sharing for an imported ONNX embedding model named MINILML6. After enabling, the model’s initializers are loaded into shared memory when you call the procedure and can be used concurrently by multiple processes with minimal memory overhead.

BEGIN
  DBMS_VECTOR.INMEMORY_ONNX_MODEL(
    model_name => 'MINILML6');
END;
/

This code snippet sets the model MINILML6 to use in-memory sharing. After calling the procedure, you can confirm the model’s in-memory status and track its usage by querying the ALL_MINING_MODELS dictionary view. If INMEMORY returns YES, the model’s initializers are now shared and accessible from shared memory for any scoring operations.

Usage Notes

• The name of the model follows the same restrictions as those used for other machine learning models. For example, if a schema is not specified, your schema is used.

• The procedure manages in-memory sharing of the initializers of a specified ONNX model that was imported with external initializers (ALL_MINING_MODELS.EXTERNAL_DATA = YES). Models without external initializers cannot be enabled for in-memory sharing; attempting to do so will raise an error.

• You must have the ALTER MINING MODEL privilege on the specified model.

• When enable is set to TRUE (the default), the procedure immediately populates the model’s initializers into shared memory. The call blocks until the full shared-memory population succeeds or fails; there is no post-call delay. Upon successful enablement, the model’s shared-initializer status is displayed in the ALL_MINING_MODELS view as INMEMORY = YES.

• When enable is set to FALSE, the model is disabled for in-memory sharing. The call blocks until cleanup of the shared registry and in-memory buffers completes, so the model is fully disabled by the time control returns to the caller. Memory allocated for the shared initializers is reclaimed after all sessions finish using the model. The model’s status changes to INMEMORY = NO in dictionary views.

• In non-RAC environments, if there is not enough memory to populate the model in-memory, the procedure raises an error. The database does not queue the request. You must call the procedure again after freeing up memory.

• In Oracle RAC environments, enabling a model for in-memory sharing triggers the operation on the instance where you call the procedure. The database updates the dictionary views and immediately populates the model into memory. On other instances in the cluster, the database updates the dictionary views, but it delays population until the first inference that uses the model on each instance. Memory usage and population status (including possible instance-specific errors) are tracked separately per instance.

  • If there isn’t enough memory, the population (and therefore the inference) will fail. An error is raised to indicate the insufficient memory issue and the model will be in the MEM_EXHAUSTED state. Memory usage and population status, including possible instance-specific errors, are tracked separately per instance.

• Models that are in-memory enabled can be exported.

• Upon import, models are always set to INMEMORY = NO and must be explicitly re-enabled.

• Use the dictionary and fixed views (ALL_MINING_MODELS, V$IM_ONNX_MODEL, and V$IM_ONNX_SEGMENT) to audit in-memory status, population details, and memory consumption for ONNX models. See ALL_MINING_MODELS, V$IM_ONNX_MODEL, and V$IM_ONNX_SEGMENT in Oracle AI Database Reference for more information.

• You may consider disabling an in-memory ONNX model (by setting ENABLE to FALSE) in the following scenarios:

  • When session isolation is required. For example, for multi-tenant or security-sensitive deployments where sharing model weights in memory between sessions may pose risks.

  • When you need a guaranteed fresh load of the model for each session, for example, during testing or troubleshooting.

  • In environments with very limited memory, to avoid retaining shared model data across sessions longer than necessary.

  • If models are reloaded or updated often during runtime, disabling sharing ensures each session gets the current version and reduces cache management complexity.

See Also: Oracle Machine Learning for SQL User’s Guide for more information about external initializers