Performance Considerations

EF Core application performance is most optimal for binding character-based data when the .NET String entity property bind data type and the database column data type Unicode support match. If the mapping is done properly, then the application will bind the string entity property value properly as NVARCHAR2 for a NVARCHAR2 column or bind it as VARCHAR2 for a VARCHAR2 column. If the types are mismatched, then additional processing is incurred on the server side, slowing down performance.

To avoid performance related issues due to this mismatch, one of the following can be done:

• If the table already exists, use scaffolding to generate the entity classes corresponding to the relational database tables. Doing so generates the correct fluent API for each table column.

• If the entity classes exist without the corresponding database tables, use migrations to generate the corresponding database columns for the string entity properties, which will honor the IsUnicode() or HasColumnType() fluent APIs that are invoked.

• If manually creating the entity classes corresponding to the database tables, correctly map each string entity property to the NVARCHAR2 or VARCHAR2 column type using the appropriate IsUnicode() or HasColumnType() fluent API to avoid mismatches.

Other considerations:

• If both IsUnicode() and HasColumnType() fluent APIs are used, then the HasColumnType() fluent API takes precedence.

• For migrations, the .NET String entity property maps to NVARCHAR2 by default. For scaffolding, both VARCHAR2 and NVARCHAR2 columns map to .NET string.

• If the database column type is VARCHAR2, then the IsUnicode(false) or HasColumnType(“VARCHAR2(<length>)”) fluent API should be used to correctly map the string entity property to the VARCHAR2 column. This avoids the performance degradation problem.

• If a string entity property is associated with a NVARCHAR2 column, no invocations of IsUnicode() nor HasColumnType() fluent APIs are needed. Alternatively, IsUncode(true) or HasColumnType(“NVARCHAR2(<length>)”) fluent APIs can be invoked to bind the data as NVARCHAR2.

• In Oracle.EntityFrameworkCore 2.19.70 and earlier versions, string entity property values were always bound as VARCHAR2 while executing LINQ queries. The behavior changed starting with Oracle EF Core 2.19.80. The string entity property values are now bound based on the mapping specified for entity string property. An application that performed optimally with Oracle EF Core 2.19.70 can degrade in performance when upgrading to a later Oracle EF Core version.

• If you encounter a new performance problem after an Oracle EF Core upgrade, verify the string entity properties associated with VARCHAR2 columns have not set either IsUnicode(false) nor HasColumnType(“VARCHAR2(<length>)”) fluent APIs nor equivalent data annotations. If so, add one of these fluent API so that the character-based data are bound using the correct type.