| Oracle® Content Database Administrator's Guide 10g Release 1 (10.2) Part Number B31268-02 |
|
|
View PDF |
| Oracle® Content Database Administrator's Guide 10g Release 1 (10.2) Part Number B31268-02 |
|
|
View PDF |
This chapter explains how to plan for an Oracle Content DB deployment.
This chapter provides information about the following topics:
This section describes the two types of Oracle Content DB deployment and provides information about high availability considerations.
This section contains the following topics:
Oracle Content DB can be installed on a single computer if the computer meets the recommended hardware and software requirements. If your computer does not meet the recommended requirements, the performance of this configuration might be less than satisfactory. See Oracle Content Database Installation Guide for your platform for more information about hardware and software requirements.
In a single-computer deployment, Oracle Content DB and all required components are installed on a single computer. These components include Oracle Identity Management and Oracle Database. A single-computer deployment does not allow you to use load balancing or failover options.
Because Oracle Content DB uses Oracle Internet Directory for credential management, the computer typically requires at least three Oracle homes: one for Oracle Database, one for OracleAS Infrastructure, and one for the Oracle Content DB middle tier. See "Oracle Content DB Sizing Guidelines" for information about the number of supported users for single-computer deployment.
Figure 2-1 shows an Oracle Content DB domain running on a single computer.
Figure 2-1 Single-Computer Oracle Content DB Deployment
See "Oracle Content DB Nodes" for more information about the Oracle Content DB processes shown in Figure 2-1.
Oracle Content DB can be deployed on multiple computers. This configuration enables you to separate the components, and configure failover, load balancers, and high availability options. With multiple-computer deployment, you can also use computers with lower hardware requirements than required for single-computer deployment. See Oracle Content Database Installation Guide for your platform for more information about hardware requirements.
With the appropriate network load balancers and computer configuration, users may not know whether the Oracle Content DB instance is running on one host or across several hosts. Users access content, such as folders and files, using the appropriate client application for a particular Oracle Content DB protocol server.
Figure 2-2 is an example of a multiple-computer deployment, with Oracle Content DB components distributed across four computers.
Figure 2-2 A Multiple-Computer Oracle Content DB Deployment
See "Oracle Content DB Nodes" for more information about the Oracle Content DB processes shown in Figure 2-2.
Each Oracle Content DB middle tier can include HTTP nodes, regular nodes, or both. Most Oracle Content DB agents can only run on one middle tier at a time. However, agents can be deployed on multiple middle tiers in an inactive state, and activated if the middle tier on which they were running fails. See the following section for more information.
When you first configure Oracle Content DB, the first middle tier that you configure contains important configuration settings that are not stored in subsequent middle tiers. Because of this, if you choose to deinstall the first Oracle Content DB middle tier, or if the first middle tier goes down, you must ensure these configuration settings are restored on another middle tier.
The following list is a summary of these configuration settings:
If you were running some or all of the Oracle Content DB agents on a particular middle tier that is deinstalled or becomes unavailable, you must configure these agents to run elsewhere. To do this, modify the node configuration of a node running on another Oracle Content DB middle tier. See "Modifying Node Configurations" for more information.
The IFS.DOMAIN.APPLICATION.ApplicationHost domain property points to a particular middle tier (typically the first that was configured). If that middle tier is deinstalled or becomes unavailable, you must update this domain property to point to another Oracle Content DB middle tier. See "Changing Domain Properties" for more information.
If you were using Oracle Mail as your SMTP server, and you were running Oracle Mail on a particular middle tier that is deinstalled or becomes unavailable, you must update the IFS.DOMAIN.EMAIL.SmtpHost and IFS.DOMAIN.EMAIL.SmtpPort domain properties to point to another SMTP server. See "Changing Domain Properties" for more information.
If you collected domain and repository metrics on a particular middle tier that is deinstalled or becomes unavailable, you must configure these metrics on another Oracle Content DB middle tier. See "Configuring Performance Metrics" for more information.
This section describes hardware requirements for a sample deployment of Oracle Content DB and formulas that allow you to determine the hardware configuration required to deploy Oracle Content DB in your organization.
This section includes the following topics:
Hardware requirements for Oracle Content DB are primarily determined by the factors described in Table 2-1.
Table 2-1 Primary Factors Determining Oracle Content DB Hardware Requirements
| Hardware Resource | Middle-tier computer requirement variables | Database computer requirement variables |
|---|---|---|
|
|
|
|
|
|
|
Not applicable |
|
|
|
Not applicable |
|
In order to determine hardware requirements, assumptions must be made about the type of work that users are performing. The following measurements are averages extrapolated from the deployment of Oracle Content DB within Oracle Corporation (40,000+ users), and are generally applicable for projecting Oracle Content DB usage.
| User Task | Number of Operations Each Connected User Performs Each Hour |
|---|---|
|
Folder opens |
8 |
|
Files read or written |
10 |
|
Queries |
0.1 |
These sizing guidelines are based on benchmarks of 10,000 concurrent connected users on Sun Microsystems hardware. The guidelines have been validated against measurements taken from internal Oracle Corporation production usage of Oracle Content DB by 55,000 Oracle employees, with 30 million files and 13TB of content. This system uses Intel Linux hardware for the middle-tier computers, and Sun hardware for the database.
|
Note: The sizing guidelines discussed in the following sections may be inaccurate if the desired user profile is significantly larger than the average measurements detailed in Table 2-2. |
This section provides formulas that you can use to determine specific hardware sizing for each middle-tier computer. Table 2-3 summarizes the sizing formulas.
Table 2-3 Oracle Content DB Sizing Recommendations for Each Middle-Tier Computer
| Component | Sizing Recommendations |
|---|---|
|
|
|
|
|
At least 500MB for Oracle Content DB |
|
Total Computer Memory, HTTP as the Primary Protocol |
If HTTP is the primary protocol: |
|
Total Computer Memory, Primary Protocol Other Than HTTP |
If HTTP is not the primary protocol, or if the desired user profile is different than the average measurements described in Table 2-2: |
Use the following formula to determine the number of CPUs required:
roundup(peak concurrent connected users / 250 + 33% headroom)
The peak concurrent connected users parameter is the number of users who are signed in to Oracle Content DB and have performed an operation during the peak hour of the day. If you do not know how many users that is likely to be, assume 10% of your entire Oracle Content DB named user population.
The headroom parameter represents the amount of CPU resources that should be left available. In order to ensure optimal efficiency, no more than 75% of the CPU should be allocated.
This formula is based on the following assumptions:
The formula assumes Sun SPARC Solaris 400MHz UltraSPARC-II processors with 8MB secondary cache.
Other RISC processors should perform roughly proportional to their MHz.
Intel Pentium III (or later) processors on Windows and Linux computers should perform roughly proportional to half their MHz. For example, an 800MHz Pentium processor is approximately equivalent to a 400MHz RISC processor.
If HTTP is the primary protocol, use the following formula to determine the total computer memory required:
480MB + (3.6MB * peak concurrent connected users)
The 480MB is for the first Oracle Content DB middle-tier computer. The value of 3.6MB is calculated from the following assumptions:
1.6 sessions per concurrent connected user: This assumes that the primary interface for Oracle Content DB is through the HTTP node. The additional 0.6 sessions are HTTP sessions which are started whenever a user of the Oracle Content DB Web client starts another Oracle Content DB Web client, or if the user accesses Web Folders or Oracle Drive.
0.1 connection pool connections per concurrent connected users: This assumes the stated user profile.
400 objects in the Java data cache per concurrent connected user: This assumes 50 files per folder and 8 folders opened per hour, assuming the stated user profile.
If HTTP is not the primary protocol, or if the desired user profile is different than the average measurements described in Table 2-2, use the following formula to determine the total computer memory required:
480MB + (1MB * peak concurrent connected users * average number of sessions in use by each concurrent connected user) + (3KB * number of objects desired in the Java object cache) + (8MB * number of connections to the database)
The 480MB is for the first Oracle Content DB middle-tier computer. The other values are calculated from the following assumptions:
The value of 1MB is high by design. Oracle Content DB has been optimized to reduce database CPU load by using middle-tier memory to cache items. This ensures a more scalable and less expensive system, because the database computer is less of a scalability bottleneck, and because memory on one- or two-processor middle-tier computers is typically less expensive than memory or CPU on high-end database computers (computers with large amounts of attached storage or with many processors).
Oracle recommends limiting the number of peak concurrent user sessions through the IFS.SERVICE.MaximumConcurrentSessions parameter in the service configuration. Oracle has tested with Java heaps up to 2GB. With this constraint, this implies up to approximately 700 concurrent connected users per node and a total of 1986MB in size, if the following are true:
Each user uses 1.6 sessions
Each session is 1MB (700 * 1.6 * 1MB = 1,120MB)
Each user needs 400 Java data cache objects
Each object is 3KB in size (700 * 400 * 3KB = 866MB)
For each additional node on the same computer, you must include the node overhead in the sizing. See Table 2-5 for more information.
The HTTP/WebDAV memory overhead includes memory for 10 simultaneous guest user requests. Because of this, guest users should not be counted as connected users for HTTP/WebDAV access.
For the average number of sessions in use by each concurrent connected user, use the value 1.6 for the HTTP node.
Calculate the number of objects desired in the Java object cache by using the following formula:
(number of folder opens in the peak hour) * (number of objects per folder) * (number peak concurrent connected users)
Use the result to set the value of the IFS.SERVICE.DATACACHE.Size parameter.
The number of connections to the database depends on the number of simultaneous read or write operations being performed. Assume 0.1 database connections per user if using a standard user profile. This is a sum of the parameters IFS.SERVICE.CONNECTIONPOOL.WRITEABLE.MaximumSize and IFS.SERVICE.CONNECTIONPOOL.READONLY.MaximumSize for each service.
See "Service Configurations and Java Memory Sizing" for more information on middle-tier memory.
This section provides formulas that you can use to determine specific hardware sizing for each database computer to be used for Oracle Content DB users. Table 2-4 summarizes the sizing formulas.
Table 2-4 Oracle Content DB Sizing Recommendations for the Database Computer
| Component | Sizing Recommendations |
|---|---|
|
|
|
|
|
|
|
|
|
Use the following formula to determine the number of CPUs required:
roundup(peak concurrent connected users / 250 + 33% headroom)
The peak concurrent connected users parameter is the number of users who are signed in to Oracle Content DB and have performed an operation during the peak hour of the day. If you do not know how many users that is likely to be, assume 10% of your entire Oracle Content DB named user population.
The headroom parameter represents the amount of CPU resources that should be left available. In order to ensure optimal efficiency, no more than 75% of the CPU should be allocated. One additional CPU is used for the background Oracle Text indexing of new file content, if you are using Oracle Text indexing.
This formula is based on the following assumptions:
The formula assumes Sun SPARC Solaris 400MHz UltraSPARC-II processors with 8MB secondary cache.
Other RISC processors should perform roughly proportional to their MHz.
Intel Pentium III (or later) processors on Windows and Linux computers should perform roughly proportional to half their MHz. For example, an 800MHz Pentium processor is approximately equivalent to a 400MHz RISC processor.
Use the following formula to determine the usable disk space required:
4.5GB + total raw file size + (total raw file size * 20%)
The 4.5GB represents the space required for Oracle software and the initial database configuration. If you are not using Oracle Text to index the content, multiply the total raw file size by 15% instead of 20%.
The following considerations can increase the amount of usable disk space required for the database computer:
Use the following formula to determine the total computer memory required:
64MB + 128MB + database buffer cache + (1MB * number of connections to the database) + (500 bytes * number of files) + (100KB * peak concurrent connected users)
This formula is based on the following assumptions:
128MB is the minimum amount of memory required to run a small Oracle Server.
Number of files: The database buffer cache in the default Oracle database configuration is sufficient for approximately 50,000 files. For deployments with more than 50,000 files, allocate 500 bytes per file for optimal performance, including wildcard filename searches. Reduce this number if users do not perform wildcard filename searches.
100KB is calculated by assuming that 0.1 database connections are needed per concurrent connected user as in the stated user profile. Each database connection takes approximately 1MB of database memory.
Table 2-5 describes approximate minimum memory overhead on the middle-tier computers for each component.
Table 2-5 Memory Overhead by Component
| Description | Approx. minimum memory (MB) for middle-tier computer running a regular node and HTTP node | Approx. minimum memory (MB) for middle-tier computer running an additional HTTP node | Approx. minimum memory (MB) for middle-tier computer running an additional regular node |
|---|---|---|---|
|
Memory used by the operating system upon booting the computer. |
60 |
60 |
60 |
|
Overhead for first Java Virtual Computer (JVM). |
30 |
30 |
30 |
|
Application Server Control. Must run on every middle tier. |
150 |
150 |
150 |
|
Regular Oracle Content DB node JVM. Typically runs the FTP server (if you enable FTP) and the Oracle Content DB agents. |
50 |
0 |
50 |
|
Oracle HTTP Server, including the default HTTP daemons. Required for Oracle Content DB Web client, HTTP, Web Folders, and Oracle Drive access. |
30 |
30 |
0 |
|
Oracle Content DB OC4J process. Required for Oracle Content DB Web client, HTTP, Web Folders, and Oracle Drive access. Must be paired with Oracle HTTP Server. |
130 |
130 |
0 |
|
Total |
450 |
400 |
290 |
This section provides information about the Oracle Content DB tablespaces, and includes the following topics:
Table 2-6 shows the different types of data stored in Oracle Content DB and describes the purpose of each tablespace. Each of these tablespaces will be discussed in further detail in subsequent sections of this file.
Table 2-6 Tablespace Definitions
| Tablespace Type | Tablespace Name | Description |
|---|---|---|
|
File Storage |
|
Stores the Large Object (LOB) data for files that are indexable by Oracle Text, such as text and word processing files. |
|
File Storage |
|
Stores the LOB data for files that are not indexed by Oracle Text, such as zip files. |
|
File Storage |
|
Stores the LOB data for files that are indexable by Oracle interMedia, such as image, audio, and video files. |
|
Oracle Text |
|
Stores words (tokens) extracted by Oracle Text from Oracle Content DB files (the Oracle table |
|
Oracle Text |
|
Stores the Oracle B*tree index on the Oracle Text tokens (the Oracle index |
|
Oracle Text |
|
Stores miscellaneous Oracle Text tables (the Oracle tables |
|
Metadata |
|
Stores metadata for files, information about users and groups, and other Oracle Content DB object data. |
|
Oracle Workflow |
Stores data for Oracle Workflow. |
|
|
General Oracle Storage |
Various |
|
Typical tablespace storage space and disk I/O are detailed in Table 2-7:
Table 2-7 Tablespace Storage Requirements and Disk I/O
| Tablespace | % of Total I/O Throughput Requirements | % of Disk Space Requirements |
|---|---|---|
|
|
50% |
2% |
|
|
20% |
1% |
|
|
10% |
1% |
|
|
8% |
35% |
|
|
5% |
55% |
|
Various |
5% |
1% |
|
|
1% |
4% |
|
|
1% |
1% |
|
Total |
100% |
100 |
Note the following issues regarding the information in Table 2-7:
I/O rates are highly dependent on the size of the db_cache_size. These measurements were taken on the Oracle-internal Oracle Content DB implementation, with 8GB db_cache_size, 17 million files, and 40,000 named users.
The CONTENT_IFS_MAIN tablespace is the most important tablespace to spread across disks for maximum I/O capacity.
Disk I/O for the CONTENT_IFS_CTX_I, CONTENT_IFS_CTX_X and CONTENT_IFS_CTX_K tablespaces is largely generated from Oracle Text batch processes (ctx_ddl.sync_index, and ctx_ddl.optimize_index), which are not critical to end-user performance. Therefore, these tablespaces can be on disks with lower I/O capacity, if necessary.
The largest consumption of disk space will occur on the disks that actually contain the files that reside within Oracle Content DB, namely the CONTENT_IFS_LOB_I tablespaces, CONTENT_IFS_LOB_N tablespaces, and CONTENT_IFS_LOB_M tablespaces. This section explains how the files are stored and how to calculate the amount of space those files will require.
As previously mentioned, files stored in Oracle Content DB are actually stored in database tablespaces. Oracle Content DB makes use of the Large Object (LOB) facility of the Oracle Database. All files are stored as Binary Large Objects (BLOBs), which is one type of LOB provided by the database. LOBs provide for transactional semantics much like the normal data stored in a database. In order to accomplish these semantics, LOBs must be broken down into smaller pieces which are individually modifiable and recoverable. These smaller pieces are referred to as chunks. Chunks are a group of one or more sequential database blocks from a tablespace that contains a LOB column.
Both database blocks and chunk information within those blocks (BlockOverhead) impose some amount of overhead for the stored data. BlockOverhead is presently 60 bytes per block, which consists of the block header, the LOB header, and the block checksum. Oracle Content DB configures its LOBs to have a 32K chunk size.
As an example, assume that the DB_BLOCK_SIZE parameter of the database is set to 8192(8K). A chunk would require four contiguous blocks and impose an overhead of 240 bytes. The usable space within a chunk would be 32768-240=32528 bytes.
Each file stored in Oracle Content DB consists of an integral number of chunks. Using the previous example, for instance, a 500K file will actually use 512000/32528=15.74=16 chunks. Sixteen chunks will take up 16*32K = 524288 bytes. The chunking overhead for storing this file would then be 524288-512000=12288 bytes which is 2.4 percent of the original file's size.
The chunk size used by Oracle Content DB is set to optimize access times for files. Note that small files, files less than one chunk, will incur a greater disk space percentage overhead since they must use at least a single chunk.
Another structure required for transactional semantics on LOBs is the LOB Index. Each LOB index entry can point to 8 chunks of a specific LOB object (NumLobPerIndexEntry = 8). In our continuing example, where a 500K file takes up 16 chunks, two index entries would be required for that object. Each entry takes 46 bytes (LobIndexEntryOverhead) and is then stored in an Oracle B*tree index, which in turn has its own overhead depending upon how fragmented that index becomes.
The last factor affecting LOB space utilization is the PCTVERSION parameter used when creating the LOB column. For information about how PCTVERSION works, please consult the Oracle Database SQL Reference.
Oracle Content DB uses the default PCTVERSION of 20 percent for the LOB columns it creates. This reduces the possibility of "ORA-22924 snapshot too old" errors occurring in read consistent views. So by default, a minimum of a 20 percent increase in chunking space must be added in to the expected disk usage to allow for persistent PCTVERSION chunks.
For large systems where disk space is an issue, Oracle recommends reducing PCTVERSION to 1, in order to reduce disk storage requirements. This may be done at any time in a running system using the following SQL commands:
alter table odmm_contentstore modify lob (globalindexedblob) (pctversion 1); alter table odmm_contentstore modify lob (emailindexedblob) (pctversion 1); alter table odmm_contentstore modify lob (emailindexedblob_t) (pctversion 1); alter table odmm_contentstore modify lob (intermediablob) (pctversion 1); alter table odmm_contentstore modify lob (intermediablob_t) (pctversion 1); alter table odmm_nonindexedstore modify lob (nonindexedblob2) (pctversion 1);
The steps for calculating LOB tablespace usage are as follows:
Calculate the number of chunks a file will use by figuring the number of blocks per chunk, then subtracting the BlockOverhead (60 bytes) from the chunk size to get the available space per chunk.
Divide the file size by the available space per chunk to get the number of chunks, per the following formula:
chunks = roundup(FileSize / ChunkSize=((ChunkSize/BlockSize) * BlockOverhead)))
For example, if FileSize = 100,000, ChunkSize = 32768, Blocksize = 8192, and BlockOverhead = 60, then:
roundup(100000 / (32768 - ((32768 / 8192) * 60))) = 4 chunks
Calculate the amount of disk space for a file by multiplying the number of chunks times the chunk size, multiplying that result by the PCTVERSION factor, and then adding the space for NumLobPerIndexEntry (8) and LobIndexEntryOverhead (46 bytes).
FileDiskSpaceInBytes = roundup(chunks * ChunkSize * PCTVERSIONFactor) + roundup(chunks / NumLobPerIndexEntry * LobIndexEntryOverhead)
Hence, if chunks = 4, ChunkSize = 32768, PCTVERSIONFactor = 1.1, NumLobPerIndexEntry = 8, and LobIndexEntryOverhead = 46:
roundup(4 * 32768 * 1.1) + (roundup(4 / 8) * 46)= 144226 FileDiskSpaceInBytes
Calculate the total disk space used for file storage by summing up the application of the preceding formulas for each file to be stored in the LOB, per the formula:
TableSpaceUsage = sum(FileDiskSpaceInBytes)
for all files stored
Oracle Content DB creates multiple LOB columns. The space calculation must be made for each tablespace based upon the amount of content that will qualify for storage in that tablespace.
The Oracle Content DB server keeps persistent information about the file system and the contents of that file system in database tables. These tables and their associated structures are stored in the CONTENT_IFS_MAIN tablespace. This tablespace contains approximately 300 tables and 500 indexes. These structures are required to support both the file system and the various protocols and user interfaces that make use of that file system.
The administration and planning tasks of this space should be very similar to operations on a normal Oracle database installation. The administrator of the system should plan for approximately 6K of overhead per file to be used from this tablespace, or about 2% of the overall content. If there is a significant amount of custom metadata, such as categories, this overhead will be larger.
The initial disk space allocated for this tablespace is approximately 50MB for a default install. Of this 50MB, 16MB is actually used at the completion of installation. This includes instantiations for all required tables and indexes and the metadata required for the approximately 700 files that are loaded into Oracle Content DB as part of the install. Different tables and indexes within this tablespace will grow at different rates depending on which features of Oracle Content DB are used in a particular installation.
When Oracle Content DB works in conjunction with Oracle Text, it allows users to access powerful search capabilities on the files stored within Oracle Content DB. Disk space for these capabilities is divided among three distinct tablespaces for optimal performance.
The CONTENT_IFS_CTX_I tablespace contains tables which hold the text tokens (separate words) that exist within the various indexed files. The storage for these text tokens is roughly proportional to the ASCII content of the file.
The ASCII content percentage varies depending on the format of the original file. Text files only have white space as their non-ASCII content and therefore incur a greater per file percentage overhead. File types such as Microsoft Word or PowerPoint contain large amounts of data required for formatting that does not qualify as text tokens. The per file percentage on these types of files is therefore lower. On a system with diverse content types the expected overhead is approximately 8% of the sum of the original sizes of the indexed files.
Table 2-8 offers general guidelines for the amount of ASCII text in a file for several popular formats:
Table 2-8 Average ASCII Content Per File Type
| Format | Plain ASCII Content as Percentage of File Size | Typical Percentage of all File ContentFoot 1 |
|---|---|---|
|
Microsoft ExcelFoot 2 |
250% |
4% |
|
ASCII |
100% |
2% |
|
HTML |
90% |
10% |
|
Rich Text Format |
80% |
2 |
|
Microsoft Word |
70% |
13% |
|
Acrobat PDF |
10% |
18% |
|
Microsoft PowerPoint |
1% |
3% |
|
Images (JPEG, BMP), Compressed files (Zip, TAR), Binary files, and so on. |
0% |
50% |
|
Total |
|
100% |
Footnote 1 From statistics of Oracle Corporation's internal usage of Oracle Content DB.
Footnote 2 By default, Oracle Text indexes each number in an Excel file as a separate word. Excel stores a number more efficiently than its ASCII equivalent, which is why the ASCII content as a percentage of the file size is greater than 100%.
The CONTENT_IFS_CTX_K tablespace contains the tables and indexes required to translate from the Oracle Content DB locator of a file (the Oracle Content DB DocID) to the Oracle Text locator of that same file (the Oracle Text DocID). The expected space utilization for this tablespace is approximately 70 bytes per indexed file.
The CONTENT_IFS_CTX_X tablespace contains the B*tree database index that is used against the text token information stored in the CONTENT_IFS_CTX_I tablespace. This will grow as a function of the ASCII content just as the CONTENT_IFS_CTX_I tablespace does. On a system with diverse content types the expected overhead is approximately 4% of the sum of the ASCII content of the files, or approximately 1% of the sum of the total sizes of the indexed files.
This section details various requirements for disk space, and offers guidance as to how necessary disk space will expand with the addition of files to the server.
Based on experience running Oracle Content DB for Oracle Corporation's internal usage, the disk overhead of Oracle Content DB for a large system (hundreds of gigabytes of file content) is approximately as detailed in Table 2-9.
Table 2-9 Disk Space Requirements Summary
| Tablespace Overhead Type | Overhead Versus Total Raw File ContentFoot 1 | Primarily Determined By |
|---|---|---|
|
File Storage |
12% |
Size of files relative to chunk size (32KB by default) |
|
Oracle Text |
5% |
Amount of ASCII content in all files |
|
Metadata |
2% |
Number of folders, files, and so on. |
|
General Oracle Storage |
1% |
Fixed, not configurable, database settings for |
|
Total |
20% |
Not applicable |
Footnote 1 This does not include: mirroring for backup and reliability; Redo log size, which should be determined by how many files are inserted and their size; unused portion of the last extent in each database file (which will occur with pre-created database files or which may be large if the next extent setting is large).
See Oracle Database Concepts for explanations of the terms Large Object, tablespace, chunk size, and extents.
Given that a large percentage of the overhead is in LOB overhead, note that the overhead for your Oracle Content DB instance may vary depending on the average and median sizes of files.
