Длина типа varchar2 oracle
VARCHAR зарезервирован Oracle для поддержки различия между NULL и пустая строка в будущем, как ANSI стандарт предписывает.
VARCHAR2 не различает NULL и пустая строка, и никогда не будет.
если вы полагаетесь на пустую строку и NULL будучи тем же самым, вы должны использовать VARCHAR2 .
В настоящее время VARCHAR ведет себя точно так же, как VARCHAR2. Однако этот тип не следует использовать, поскольку он зарезервирован для будущего использования.
взято из последней стабильной версии Oracle 12.2: Типы Данных
главное отличие в том, что VARCHAR2 это внутренний тип данных и VARCHAR это внешний тип данных. Поэтому нам нужно понять разницу между внутренним и внешним типом данных.
внутри базы данных, значения хранятся в Столбцах в таблицах. Внутри Oracle представляет данные в определенных форматах, известных как внутренние типы данных.
В общем случае приложения OCI (Oracle Call Interface) работают не с внутренними представлениями типа данных, а с типами данных языка хоста, которые предопределены языком, на котором они написаны. При передаче данных между клиентским приложением OCI и таблицей базы данных библиотеки OCI преобразуют данные между внутренними и внешними типами данных.
внешние типы обеспечивают удобство для программист путем делать его возможным работать с типами языка хозяина вместо собственнических форматов данных. OCI может выполнять широкий спектр преобразований типов данных при передаче данных между базой данных Oracle и приложением OCI. Внешних типов данных OCI больше, чем внутренних типов данных Oracle.
на VARCHAR2 тип данных представляет собой строку символов переменной длины с максимальной длиной 4000 байт. Если init.параметр Ora max_string_size по умолчанию, максимальный длина VARCHAR2 может быть 4000 байт. Если init.параметр Ora max_string_size = extended, максимальная длина a VARCHAR2 может быть 32767 байт
быстрый тест в базе данных 12.2 предполагает, что в качестве внутренний тип данных, Oracle по-прежнему лечит VARCHAR как псевдотип на VARCHAR2 . Это не SYNONYM который является фактическим типом объекта в Oracle.
есть также некоторые последствия VARCHAR для параметров Precompiler ProC / C++. Для интересующихся программистов ссылка находится по адресу:Pro*C/C++ руководство программиста
после некоторых экспериментов (см. Ниже) я могу подтвердить, что по состоянию на сентябрь 2017 года ничего не изменилось в отношении функциональности, описанной в принято отвечать:-
- rextester демо для Oracle 11g: Пустые строки вставляются как NULL s для обоих VARCHAR и VARCHAR2 .
- LiveSQL демо для Oracle 12c: те же результаты.
в историческая причина этих двух ключевых слов хорошо объясняется в ответ на другой вопрос.
в настоящее время они одинаковы. но раньше
VARCHAR зарезервирован Oracle для поддержки различия между NULL и пустая строка в будущем, как предписывает стандарт ANSI.
VARCHAR2 не различает NULL и пустая строка, и никогда не будет.
Emp_name varchar(10) - если вы вводите значение менее 10 цифр, то остальные пространство нельзя удалить. он использовал всего 10 мест.
Emp_name varchar2(10) - если вы вводите значение менее 10 цифр, то оставшееся пространство автоматически удаляется
VARCHAR2
используется для хранения строк символов переменной длины. Длина строкового значения будет храниться на диске вместе с самим значением.
тип varchar
ведет себя точно так же, как VARCHAR2. Однако этот тип не следует использовать, поскольку он зарезервирован для будущего использования
VARCHAR может хранить до 2000 байт символов, в то время как VARCHAR2 может хранить до 4000 байт символов.
если мы объявим тип данных как VARCHAR, он будет занимать место для значений NULL. В случае типа данных VARCHAR2 он не будет занимать места для значений NULL. например,
зарезервирует 6 байт памяти, даже если имя " Ravi__", тогда как
оставляем пробел в соответствии с длиной входной строки. например, 4 байта памяти для ' Ravi__'.
здесь _ представляет NULL.
Примечание: varchar зарезервирует место для нулевых значений, а varchar2 не зарезервирует место для нулевых значений.
MAX_STRING_SIZE controls the maximum size of VARCHAR2 , NVARCHAR2 , and RAW data types in SQL.
ALTER SYSTEM . SID='*' Foot 1
Modifiable in a PDB
Multiple instances must use the same value.
Use ALTER SYSTEM only when the database is in UPGRADE mode, and run the utl32k.sql script afterward, as explained in this section.
STANDARD means that the length limits for Oracle Database releases prior to Oracle Database 12 c apply (for example, 4000 bytes for VARCHAR 2 and NVARCHAR2 , and 2000 bytes for RAW ).
EXTENDED means that the 32767 byte limit introduced in Oracle Database 12 c applies.
The COMPATIBLE initialization parameter must be set to 12.0.0.0 or higher to set MAX_STRING_SIZE = EXTENDED .
You can change the value of MAX_STRING_SIZE from STANDARD to EXTENDED . However, you cannot change the value of MAX_STRING_SIZE from EXTENDED to STANDARD .
By setting MAX_STRING_SIZE = EXTENDED , users are taking an explicit action that could introduce application incompatibility in their database. Applications that do not want to use the expanded data types can be rewritten for compatibility with either setting; for example, these applications could use explicit CASTs to fix the length of VARCHAR2 expressions during CREATE TABLE AS SELECT .
Altering MAX_STRING_SIZE will update database objects and possibly invalidate them, as follows:
Tables with virtual columns will be updated with new data type metadata for virtual columns of VARCHAR2(4000) , 4000-byte NVARCHAR2 , or RAW(2000) type.
Functional indexes will become unusable if a change to their associated virtual columns causes the index key to exceed index key length limits. Attempts to rebuild such indexes will fail with ORA-01450: maximum key length exceeded .
Views will be invalidated if they contain VARCHAR2(4000) , 4000-byte NVARCHAR2 , or RAW(2000) typed expression columns.
Materialized views will be updated with new metadata VARCHAR2(4000) , 4000-byte NVARCHAR2 , and RAW(2000) typed expression columns
Increasing the Maximum Size of VARCHAR2, NVARCHAR2, and RAW Columns in a Non-CDB
To increase the maximum size of VARCHAR2 , NVARCHAR2 , and RAW columns in a non-CDB:
Shut down the database.
Restart the database in UPGRADE mode.
Change the setting of MAX_STRING_SIZE to EXTENDED .
Run the rdbms/admin/utl32k.sql script. You must be connected AS SYSDBA to run the script.
Restart the database in NORMAL mode.
The utl32k.sql script increases the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns for the views where this is required. The script does not increase the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns in some views because of the way the SQL for those views is written.
Run the rdbms/admin/utlrp.sql script to recompile invalid objects. You must be connected AS SYSDBA to run the script.
Increasing the Maximum Size of VARCHAR2, NVARCHAR2, and RAW Columns in a CDB
To increase the maximum size of VARCHAR2 , NVARCHAR2 , and RAW columns in a CDB and in all the PDBs in the CDB:
Connect to the CDB AS SYSDBA.
In the root, change the setting of MAX_STRING_SIZE to EXTENDED :
The root continues to use STANDARD semantics even after MAX_STRING_SIZE is set to EXTENDED . The reason for setting MAX_STRING_SIZE to EXTENDED in the root is so all the PDBs in the CDB can inherit the EXTENDED setting from the root.
Shut down the CDB.
Restart the CDB in UPGRADE mode.
Use the catcon.pl script to run the rdbms/admin/utl32k.sql script in the root and in all the PDBs in the CDB to increase the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns. The --force_pdb_mode ‘UPGRADE’ option is used to ensure that all PDBs, including application root clones, are opened in migrate mode. Enter the SYS password when prompted:
The utl32k.sql script increases the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns for the views where this is required. The script does not increase the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns in some views because of the way the SQL for those views is written.
Connect to the CDB AS SYSDBA and shut down the database.
Restart the CDB in NORMAL mode.
Use the catcon.pl script to run the rdbms/admin/utlrp.sql script to recompile invalid objects in the root and in all the PDBs in the CDB. The --force_pdb_mode ‘READ WRITE’ option is used to ensure that all the PDBs (including application root clones) are opened in read write mode. Enter the SYS password when prompted:
Oracle Multitenant Administrator's Guide for information about using the catcon.pl script to run Oracle-supplied scripts in a CDB and PDBs.
Increasing the Maximum Size of VARCHAR2, NVARCHAR2, and RAW Columns in a PDB
To increase the maximum size of VARCHAR2 , NVARCHAR2 , and RAW columns in a PDB:
Shut down the PDB.
Reopen the PDB in migrate mode.
The following SQL statement can be used to reopen a PDB in migrate mode when the current container is the PDB:
ALTER PLUGGABLE DATABASE pdb-name OPEN UPGRADE;
Change the setting of MAX_STRING_SIZE in the PDB to EXTENDED .
Run the rdbms/admin/utl32k.sql script in the PDB. You must be connected AS SYSDBA to run the utl32k.sql script.
Reopen the PDB in NORMAL mode.
The utl32k.sql script increases the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns for the views where this is required. The script does not increase the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns in some views because of the way the SQL for those views is written.
Run the rdbms/admin/utlrp.sql script in the PDB to recompile invalid objects. You must be connected AS SYSDBA to run the script.
Oracle Multitenant Administrator's Guide for more information about modifying the open mode of PDBs.
Increasing the Maximum Size of VARCHAR2, NVARCHAR2, and RAW Columns in an Oracle RAC Database
To increase the maximum size of VARCHAR2 , NVARCHAR2 , and RAW columns in an Oracle RAC database:
Shut down all of the Oracle RAC database instances, except one.
Restart the Oracle RAC database instance in UPGRADE mode.
Change the setting of MAX_STRING_SIZE to EXTENDED .
Run the rdbms/admin/utl32k.sql script in the Oracle RAC database instance. You must be connected AS SYSDBA to run the script.
Restart all Oracle RAC database instances in NORMAL mode.
The utl32k.sql script increases the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns for the views where this is required. The script does not increase the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns in some views because of the way the SQL for those views is written.
Run the rdbms/admin/utlrp.sql script to recompile invalid objects. You must be connected AS SYSDBA to run the script.
Increasing the Maximum Size of VARCHAR2, NVARCHAR2, and RAW Columns in an Oracle Data Guard Logical Standby Database
To increase the maximum size of VARCHAR2 , NVARCHAR2 , and RAW columns in an Oracle Data Guard logical standby database:
Shut down the Oracle Data Guard primary database and logical standby database.
Restart the primary database and logical standby database in UPGRADE mode.
Change the setting of MAX_STRING_SIZE to EXTENDED on the primary database and logical standby database.
Run the rdbms/admin/utl32k.sql script on both the primary database and the logical standby database. You must be connected AS SYSDBA to run the script.
Restart the primary database and logical standby database in NORMAL mode.
The utl32k.sql script increases the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns for the views where this is required. The script does not increase the maximum size of the VARCHAR2 , NVARCHAR2 , and RAW columns in some views because of the way the SQL for those views is written.
Run the rdbms/admin/utlrp.sql script on the primary database and logical standby database to recompile invalid objects. You must be connected AS SYSDBA to run the script.
Restart SQL Apply.
Oracle Database Globalization Support Guide for more information about the MAX_STRING_SIZE parameter
Переменные символьных типов предназначены для хранения текста, а для работы с ними используются символьные функции. Работа с символьными данными значительно различается по сложности от простой до весьма нетривиальной. В этой статье базовые средства PL/SQL по работе со строками рассматриваются в контексте однобайтовых наборов символов — например, тех, которые традиционно используются в Западной Европе и США. Если вы работаете в Юникоде или в другой многобайтовой кодировке или ваше приложение должно поддерживать несколько языков.
Хотя типы CLOB (Character Large OBject) и LONG теоретически тоже можно отнести к символьным типам, по принципам использования они отличаются от символьных типов, рассматриваемых в этой статье.
Тип данных CHAR
Тип данных CHAR определяет строку фиксированной длины. При объявлении такой строки необходимо задать ее максимальную длину в диапазоне от 1 до 32 767 байт. Длина может задаваться как в байтах, так и в символах. Например, следующие два объявления создают строки длиной 100 байт и 100 символов соответственно:
Реальный размер 100-символьной строки в байтах зависит от текущего набора символов базы данных. Если используется набор символов с переменной длиной кодировки, PL/SQL выделяет для строки столько места, сколько необходимо для представления заданного количества символов с максимальным количеством байтов. Например, в наборе UTF-8, где символы имеют длину от 1 до 4 байт, PL/SQL при создании строки для хранения 100 символов зарезервирует 300 байт (3 байта ? 100 символов).
Мы уже знаем, что при отсутствии спецификатора CHAR или BYTE результат будет зависеть от параметра NLS_LENGTH_SEMANTICS . При компиляции программы эта настройка сохраняется вместе с ней и может использоваться повторно или заменяться при последующей перекомпиляции. С настройкой по умолчанию для следующего объявления будет создана строка длиной 100 байт:
Если длина строки не указана, PL/SQL объявит строку длиной 1 байт. Предположим, переменная объявляется так:
Как только этой переменной присваивается строка длиной более одного символа, PL/SQL инициирует универсальное исключение VALUE_ERROR . Но при этом не указывается, где именно возникла проблема. Если эта ошибка была получена при объявлении новых переменных или констант, проверьте свои объявления на небрежное использование CHAR . Чтобы избежать проблем и облегчить работу программистов, которые придут вам на смену, всегда указывайте длину строки типа CHAR . Несколько примеров:
Поскольку строка типа CHAR имеет фиксированную длину, PL/SQL при необходимости дополняет справа присвоенное значение пробелами, чтобы фактическая длина соответствовала максимальной, указанной в объявлении.
До выхода версии 12c максимальная длина типа данных CHAR в SQL была равна 2000; в 12c она была увеличена до максимума PL/SQL: 32 767 байт. Однако следует учитывать, что SQL поддерживает этот максимум только в том случае, если параметру инициализации MAX_SQL_STRING_SIZE задано значение EXTENDED .
Строковые подтипы
PL/SQL поддерживает некоторые строковые подтипы (табл. 2), которые тоже могут использоваться для объявления символьных строк. Многие из этих подтипов определены только для обеспечения совместимости со стандартом ANSI SQL. Вряд ли они вам когда-нибудь понадобятся, но знать о них все же нужно.
Каждый из перечисленных в таблице подтипов эквивалентен одному из базовых типов данных PL/SQL, указанных в правом столбце. Например:
Подтип VARCHAR заслуживает особого внимания. Уже на протяжении нескольких лет корпорация Oracle собирается изменить определение подтипа данных VARCHAR (в результате чего он перестанет быть эквивалентным VARCHAR2 ) и предупреждает, что пользоваться им не следует. Я согласен с этой рекомендацией: если существует опасность, что Oracle (или комитет ANSI) изменит поведение VARCHAR , неразумно полагаться на его поведение. Используйте вместо него VARCHAR2 .
Я хочу знать, почему Oracle нуждается в параметре size в определении VARCHAR2 .
Я думаю, что это за ограничение. Было бы лучше, если бы oracle приняла этот параметр как необязательный, например NUMBER тип данных?
у меня часто возникают проблемы с изменением размера старых таблиц до больших размеров, потому что иногда значение больше, чем определение размера .
это то же самое, чтобы определить тип VARCHAR2(10 ) или VARCHAR2(1000) .
Я думаю, это ненужное ограничение. Если нет, знаете ли вы о реальном случае, когда это ограничение привело к чему-то полезному? И почему нет такой декларации в NUMBER тип ?
Это то же самое, чтобы определить тип varchar2(10) или varchar2(1000).
нет, это совсем не одно и то же.
- длина столбца-полезные метаданные для разработчиков, строящих экраны.
- аналогично автоматические инструменты запросов, такие как TOAD и SQL Developer, используют длину столбца при отображении результатов.
- база данных использует длину переменной при выделении памяти для коллекций PL/SQL. Поскольку эта память выходит из PGA, превышение объявления переменной может привести к сбою программ, потому что у сервера закончилась память.
- существуют аналогичные проблемы с объявлением отдельных переменных в программах PL/SQL, просто коллекции имеют тенденцию умножать проблему.
- Сверхразмерные столбцы создают проблемы для составных индексов. Следующие на базу с 8K блоков
но выше все остальное, размеры столбцов-это форма проверки ошибок. Если столбец должен быть длиной десять символов, а какой-то автономный процесс пытается загрузить тысячу символов, то что-то не так. Процесс должен завершиться неудачей, поэтому мы можем исследовать, почему мы загружаем данные duff. Альтернативой является база данных, полная мусора, и если это то, что мы хотели, мы должны были просто дать всем Excel и сделать с ним.
Это правда, что изменение размера столбца, когда получается мы недооценили может быть утомительно. Но это происходит не очень часто, и мы можем смягчить боль, используя объявления %TYPE и SUBTYPE в нашем PL/SQL вместо длины переменных жесткого кодирования.
"почему нет такого объявления в типе номера"
цифры разные. Для начала максимальный размер числа намного меньше текстового эквивалента (38 цифр гарантированной точности).
но ключевая разница это Oracle хранит числовые значения в научной нотации таким образом, нет прямой зависимости между арифметическим размером числа и пространством хранения, которое оно потребляет.
тем не менее, остается хорошей практикой указывать масштаб и точность везде, где это возможно, особенно когда мы имеем дело с целыми числами, скажем, или деньгами.
Я думаю, что важно помнить исторический контекст, в котором были разработаны реляционные базы данных. В то время, когда они разрабатывались (конец 70 - х-начало 80-х годов), общедоступные компьютеры были намного меньше (с точки зрения памяти и дискового пространства) и менее мощными (с точки зрения процессора), чем у нас сейчас, и управление этими ресурсами обязательно было насущной проблемой. COBOL был общим языком бизнес-вычислений (и до сих пор широко используется), а объектно-ориентированные языки, такие как как Smalltalk и C++ были неизвестны, для всех практических целей. В то время ожидалось, что программы объявят точно, сколько памяти им понадобится для каждого элемента данных, например, 10 байт для строки, 2 байта для короткого целого числа, 4 байта для float и т. д., и поэтому этот стиль объявления использовался тогда только что разработанными реляционными базами данных. Более того,предположение было сделано, чтобы каждый элемент данных объявлял (неявно или явно) сумму это требовало хранения, и это было закодировано в реляционные двигатели на очень фундаментальном уровне.
теперь со временем это требование несколько ослабло, по крайней мере, в том, что касается хранения данных на диске. Я считаю, что в Oracle тип данных NUMBER будет гибко выделять пространство, так что фактически будет использоваться только минимальный объем пространства, необходимый для хранения его значения, и что столбцы VARCHAR2 будут использовать достаточно места на диске для хранения фактических данных без хранения конечных пробелов, хотя вам все равно нужно объявить максимальный объем хранилища, необходимый для VARCHAR2.
вы можете взглянуть на SYS.Стандартный пакет, чтобы получить представление о том, как объявить подтипы VARCHAR2. Например, если вам нужен собственный тип "string", который вы можете использовать без привязки к спецификации длины, вы можете попробовать:
однако будьте осторожны, если вы собираетесь индексировать рассматриваемый столбец (как указывалось ранее @APC).
Я согласен что я бы предпочел просто объявить строку (которая, кстати, определена в SYS.Стандарт как подтип VARCHAR2) без необходимости объявлять длину, но это просто не так, как работает Oracle, и поскольку я не собираюсь начинать писать свою собственную реляционную базу данных (у меня есть свои собственные ветряные мельницы, на которых можно наклонить, спасибо :-) я просто соглашусь с статус-кво.
надеюсь, это поможет.
Почему бы каждому столбцу в каждой таблице базы данных не быть CLOB? Таким образом, вам не придется беспокоиться о максимальной длины.
ограничения длины типа данных существуют по той же причине, что и любые ограничения: они уменьшают объем проверки ошибок, который вам нужно разбрызгать по всему вашему коду приложения, гарантируя, что любые данные, успешно сохраненные в таблице, соответствуют ограничениям, которые вы определили.
несмотря на то, что он не выделяет заданное количество байтов на диске, как поле char, все еще есть достойные причины для размера:
- выделение памяти на считывателях данных (на основе максимального размера строки)
- индексирование большой столбец приносит размеры блоков в игру
- Etc.
Я уверен, что есть больше причин, которые кто-то еще может придумать, но это те, которые я видел в прошлом проекте, где кто-то решил varchar2(4000) всё.
с точки зрения извлечения информации, очень полезно знать, насколько велико поле. Например, если вам нужно напечатать адрес на конверте или отобразить его на экране, вы хотите знать, насколько большим должно быть поле.
или купить очень большие конверты.
возможно влияние производительности: в MySQL, temporary tables и MEMORY tables магазине VARCHAR столбец как столбец фиксированной длины, проложенный к ее максимальной длине.
если вы дизайн VARCHAR столбцы намного больше, чем самый большой размер, который вам нужен, вы будете потреблять больше памяти, чем вам нужно. Это влияет cache efficiency, sorting speed, etc .
таким образом, вы даете максимальную длину, которая находится под вашей строкой. например, если вы максимальная длина персонажа 10, поэтому не давайте его длину 100 или более.
I know that I can declare a varchar2 using the number of the characters that it should be able to contain.
However, in an Oracle database on which I am working, I found that a field (named PDF) is defined as follows:
What does this mean? How many characters can it contain?
Another, related question: What is the difference between a VARCHAR and a VARCHAR2 ?
I think in your case the difference between BYTE and CHAR is meaningless. Oracle does not support Boolean type so it is usually implemented as CHAR(1) . Having variable length string having max. length of one byte is non-sense.
4 Answers 4
You can declare columns/variables as varchar2(n CHAR) and varchar2(n byte).
n CHAR means the variable will hold n characters. In multi byte character sets you don't always know how many bytes you want to store, but you do want to garantee the storage of a certain amount of characters.
n bytes means simply the number of bytes you want to store.
Probably historic. At first a character was a byte. Then multi-byte characters where introduced and the meaning of the length was suddenly open to multiple interpretations.
I find it strange that when declaring a data type to store text characters, you are given the choice to specify the number of storage bytes. The underlying storage size needs to be handled transparently by the db engine based on the corresponding text encoding. If for example, as a user I need to store X number of text characters using UTF-8 encoding, a DB engine needs to figure out internally how much storage is needed for that. Letting a user set that is opening the door for trouble.
The VARCHAR datatype is synonymous with the VARCHAR2 datatype. To avoid possible changes in behavior, always use the VARCHAR2 datatype to store variable-length character strings.
If your database runs on a single-byte character set (e.g. US7ASCII , WE8MSWIN1252 or WE8ISO8859P1 ) it does not make any difference whether you use VARCHAR2(x BYTE) or VARCHAR2(x CHAR) .
It makes only a difference when your DB runs on multi-byte character set (e.g. AL32UTF8 or AL16UTF16 ). You can simply see it in this example:
VARCHAR2(1 CHAR) means you can store up to 1 character, no matter how many byte it has. In case of Unicode one character may occupy up to 4 bytes.
VARCHAR2(1 BYTE) means you can store a character which occupies max. 1 byte.
If you don't specify either BYTE or CHAR then the default is taken from NLS_LENGTH_SEMANTICS session parameter.
Unless you have Oracle 12c where you can set MAX_STRING_SIZE=EXTENDED the limit is VARCHAR2(4000 CHAR)
However, VARCHAR2(4000 CHAR) does not mean you are guaranteed to store up to 4000 characters. The limit is still 4000 bytes, so in worst case you may store only up to 1000 characters in such field.
Строковые типы данных
Oracle поддерживает четыре строковых типа данных (табл. 1). Выбор типа зависит от двух факторов:
Типы данных фиксированной длины — CHAR и NCHAR — в приложениях Oracle используются очень редко. Их вообще не рекомендуется применять, если нет особых причин работать именно со строкой фиксированной длины. Далее, в разделе «Смешение значений CHAR и VARCHAR2 » рассказывается о проблемах, которые могут возникнуть при совместном использовании строковых переменных фиксированной и переменной длины.
Тип данных VARCHAR2
В переменных типа VARCHAR2 хранятся символьные строки переменной длины. При объявлении такой строки для нее определяется максимальная длина в диапазоне от 1 до 32 767 байт. Максимальная длина может задаваться в байтах или символах, но в любом случае компилятор определяет ее в байтах. Общий синтаксис объявления VARCHAR2 :
Здесь имя_переменной — имя объявляемой переменной, макс_длина — ее максимальная длина, а CHAR и BYTE — аргументы, указывающие, что максимальная длина выражается в символах или в байтах соответственно.
Если максимальная длина строковой переменной VARCHAR2 задается в символах (спецификатор CHAR ), то ее реальная длина в байтах вычисляется на основе максимального количества байтов, используемых для представления одного символа. Например, набор символов Юникода UTF-8 использует для представления некоторых символов до 4 байтов; следовательно, если вы работаете с UTF-8, объявление переменной типа VARCHAR2 , максимальная длина которой составляет 100 символов, эквивалентно объявлению этой же переменной с максимальной длиной 300 байт.
Спецификатор длины CHAR используется в основном при работе с многобайтовыми наборами символов — такими, как UTF-8.
Если в объявлении переменной VARCHAR2 опустить спецификатор CHAR или BYTE , тогда заданное значение длины будет интерпретировано в байтах или символах в зависимости от параметра инициализации NLS_LENGTH_SEMANTICS . Текущее значение можно узнать, обратившись с запросом к NLS_SESSION_PARAMETERS . Несколько примеров объявления строк типа VARCHAR2 :
Итак, максимальная длина переменной типа VARCHAR2 в PL/SQL составляет 32 767 байт. Это ограничение действует независимо от того, определяется ли длина строки в байтах или символах. До выхода версии 12c максимальная длина типа данных VARCHAR2 в SQL была равна 4000; в 12c она была увеличена до максимума PL/SQL: 32 767 байт. Однако следует учитывать, что SQL поддерживает этот максимум только в том случае, если параметру инициализации MAX_SQL_STRING_SIZE задано значение EXTENDED ; по умолчанию используется значение STANDARD .
Если вам понадобится работать со строками длиной более 4000 байт, рассмотрите возможность их хранения в столбцах типа CLOB .
VARCHAR2
используется для хранения строк символов переменной длины. Длина строкового значения будет храниться на диске вместе с самим значением.
Читайте также:
- Память в компьютере организована из ячеек каждая из которых имеет свой
- Сравните задачи которые решают с помощью компьютеров пользователи системные администраторы
- Прерывистый звуковой сигнал схема
- Почему папки пустые куда делись файлы
- Какие меры ресурсосбережения чаще всего применяются для компьютеров и компьютерных устройств