Q: Is there any ratio or certain %, that inemory_Area cannot be more than 15% of SGA ?
A: No, normal sizing still applies to the other areas of the SGA. The IM column store is in addition to those values and can be as large as your memory and the Oracle Database supports.
Q: Does data always get compressed when put into memory?
A: No, there is an option for “no memcompress”, but the default is query low.
Q: What occurs if the in-memory static size amount is insufficient for all the data in a column?
A: If there is not enough memory in the IM column store for the entire object being loaded then just part of it will be loaded and the rest w ill be accessed from the row store. A message will be written to the alert log that the IM column store is full.
Q: The data buffer cache uses a block size that matches the block size in the data file. What is the unit of storage in a columnar array?
A: The unit of store for columnar data is 1MB. This can be seen in the view v$inmemory_area.
Q: Can the in-memory extent size be adjusted?
A: No, there is no control over the in-memory extent size.
Q: Do we have to explicitly create storage indexes?
A: No, you cannot control the creation of storage indexes.
Q: Is the in-memory feature available in all license editions?
A: No, the Database In-Memory option is only available in Enterprise Edition.
Q: Does the optimizer pick a hybrid, Row and Column access methods?
A: Yes, if the entire object does not fit into the IM column store then part of it can be accessed from the IM column store and the rest from the buffer cache.
Q: In-memory may contain a list all unique values to determine which parts of the in -memory column store to access. But what if there are minimal duplicate values (as in a unique column or a column phone #s of clients)? Is this list of values maintained?
A: Compression is performed at the IMCU level and the algorithms adapt based on the data values. The compression won’t waste space if there is no compression
benefit from the values found.
Q: How does this help with ‘join cardinality’ issues?
A: Join cardinalities are the same, the optimizer uses statistics on the object as well as statistics on the inmemory object to determine the best execution plan.
Q: Once I’m done with partitioning in-memory, how do I take it out of memory?
A: alter <object> no inmemory
Q: How is duplicate different from mirroring?
A: The duplicate subclause is essentially the same as mirroring at the IMCU level but it only ocurrs in-memory.
Q: How does the database deal with a situation in which you have specified in-memory for a specific table, dropped all of the analytic indexes but the entire table doesn’t fit into the in-memory column store? Will analytic queries suffer in this situation?
A: Yes, but only because the data will have to be fetched from the row store and won’t take advantage of the IM column store’s features. Indexes won’t be used in the case where some data is accessed from the IM column store and some from the buffer cache. In general you would not want this to happen. The best practice is to populate entire objects into the IM column store.