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 12-7 INMEMORY_ONNX_MODEL Procedure Parameters
| Parameter | Description |
|---|---|
|
|
Name of the model in the form
|
|
|
Specify whether to enable or disable in-memory sharing for the ONNX model. Possible options:
|
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 MODELprivilege on the specified model. - When
enableis set toTRUE(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 theALL_MINING_MODELSview asINMEMORY = YES. - When
enableis set toFALSE, 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 toINMEMORY = NOin 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.
- Models that are in-memory enabled can be exported.
- Upon import, models are always set to
INMEMORY = NOand must be explicitly re-enabled. - Use the dictionary and fixed views (
ALL_MINING_MODELS,V$IM_ONNX_MODEL, andV$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
ENABLEtoFALSE) 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
Parent topic: DBMS_VECTOR