In chapter 13 the datapump discussion for NETWORK_LINK is incorrect. A log file is created but a dump file is not. Here’s the section:
“Using this method for manual migration doesn’t make much sense—if you are going to copy the data over a database link anyway, why not load it to target tables directly, using CTAS or direct-path insert, instead of dumping it to disk and reloading back later on?”
On page 39 , middle of last paragraph reads ” … decision is not be locked in stone…”. Suggest removing the
word “be” to read “…decision is not locked in stone …”.
Nice job. Been working with Exadata x2-2 and this book certainly gave me a better understanding of how things work on some things that were a little fuzzy.
Hi – page 112 last para says “Note that cellinit.ora will be discussed in more detail in chapter 8″, but it isn’t – did something get lost during the edits? If so, can you post the description of the ellinit.ora parameters here?
Thanks for a great book.
In chapter 7 (resource management) on page 181 there is a statement “This is because according to the rule priorities, the CLIENT_APPLICATION mapping rules takes precedence”. That statement should be “This is because according to the rule priorities, the CLIENT_PROGRAM mapping rules takes precedence”.
In a non-RAC configuration each compute node will have its own, non-clustered, ASM instance that provides storage for all databases on that server. Even though your database servers may be independent of on another they can still share Exadata storage (cell disks). This allows each database to make use of the full I/O bandwitdth of the Exadata storage subsystem
Maybe not a real error, but it is not made very clear they can share a cell disk as long as this disk is divided into multiple grid disks and that each grid disk can only be used by one of the db clusters (or non clustered asm instance).
On page 157 (top), a formula is given for the calculating the default value for the parallel_servers_target parameter.
This formula is stated as: ((4 * cpu_count) * parallel_threads_per_cpu) * active_instances.
In the example calculation a value of 12 is used as cpu_count, but should this not be 24 as each db machine has 2 hexacores and each core has 2 threads?
Also, in the Oracle reference guide the given formula is:
where concurrent users is depending on the memory management settings:
“if automatic memory management is disabled (manual mode), then the number of concurrent parallel users is 1. If PGA automatic memory management is enabled, the number of concurrent parallel users is 2. If global memory management or SGA memory target is used in addition to PGA automatic memory management, then the number of concurrent parallel users is 4.”
There is no mention of number of instances in the formula and CPU_COUNT seems to be per node and not the total number of cpu’s in the cluster.
When using the formula from the documentation, and 24 as cpu count and 4 for the concurrent_parallel_users, the end value is the same as in the book.
On page 153, top of page, it is stated that the default value for the parallel_adaptive_multi_user parameter is “true”.
However, in the table on page 154 it is indicated that the default value is “false”
According to the Oracle documentation (and on my own databases) the default is indeed “true”, but could it be that this is different on Exadata systems?
Hi – a minor typo, page 179, table 7-2: the table says that the the procedures SWITCH_CURRENT_CONSUMER_GROUP, SWITCH_CONSUMER_GROUP_FOR_SESSION, and SWITCH_CONSUMER_GROUP_FOR_USER are all in DBMS_SESSION. But (as you know as weel as me, of course!) it is only the first that is in DBMS_SESSION, the others are in DBMS_RESOURCE_MANAGER.
Great book, I really appreciate your work.
Please note: the following are only useful if you reprint the book,
as these are minor/typographic/stylistic suggestions.
. . .
p248 footnote is missing a 1 indicator
p259 extra quote: ERROR,’ should be ERROR,
p260 “script” should be normal font: eg: …..script (IPConf)
p339 should be: (or partition) is relatively small.
p350 is: cell single block physical read:-Apparently
should be: cell single block physical read: Apparently
p359 suggestion only:
is: but realizes that the transaction must be committed
could be: but realizes that the transaction already must have been committed
p369 suggestion: replace semicolon with a comma
could be: rollback is needed on not, and it finds the transaction….
p372 (2 words) above mentioned
p376
(Also, I respectfully suggest using “due to” instead of “thanks to”)
could be: …or other work-area operations of database block I/Os, due to chained rows or …..
p469 (missing underscore in NAME values, in all but first)
eg: DATA_DG_CD_01_CELL01
p494 (missing the command sample to remove the ASM unique name from the availableTo attribute on all grid disks)
2. just shows: CellCLI> list griddisk attributes name, availableTo
( just a guess: > alter griddisk all availableTo=’ ‘ )
p515 is: which calculates a percentage of the statements currently in….
could be: which calculates the percentage of the statements currently in….
p540 typo: abbreciation -> abbreviation
p548 typo: it’s calcualted offload percentage -> its calculated offload percentage
. . .
Please understand this is minor typo stuff that I found and offer to share.
This is a wonderful book, and I hope to work with exadata some day.
Congratulations on producing this work.
Page 128 para 1 “keep in mind writes to data files are done in the background by the DBWR processes”.
Is this 100% correct – particularly with Exadata with smart scans. I’m not sure this covers what happens with a segment level checkpoint – would it not be a concern to get writes to a particular segment to run quickly if full scans occur frequently and these are frequently causing segment checkpoints, and we are trying to make the system use smart scans….
One could argue this is a particular issue for Exadata given the lack of write cache on the storage system…… (O.5GB per cell doesn’t seem great)….
Page 126 – It would be good to know the impact of shutting down a storage cell, in order to replace a flash card or patch the software.
What I’d find interesting is:
1) storage indexes
2) flash cache
3) preferred reads
If we restart the storage cell, when does it become available for reads? As data is re-mirrored from another cell (assuming this is necessary) are storage indexes updated as the mirroring takes place? As the storage cell resilvers with the blocks in other cells does the flash cache start to cache the blocks this cell is going to be the preferred read of….
Granted this isn’t errata – but it would be good to cover the impact of restarting a storage cell, as on the face of it this is not a trivial operation (for instance if there is a restart does this throw away the contents of the data on NAND i.e. the flash cards – if so is this is done logically are there is a scrub operation on the cards…).
I’d guess as the argument is that cells don’t talk to each other that none of this happens and restarting a cell throws away a tonne of information….
Page 128 – comment box in Note. “There may be individual writes that take orders of magnitude longer than the average”. It would be interesting (at least to me) to have more discussion around this. Given we are talking about averages having an order of magnitude higher isn’t a big thing is it(?). And why is that – given that we do not have moving parts are we saying that the write wear levelling is kicking in and the gargbage collection isn’t good enough (because there’s plenty of head room as expressed in this chapter around the useable NAND vs. the actual NAND.
Page 130. Figure 5-3. I think a decent amount is being glossed over here. If we have a block in flash cache, and if we are over-writing the data block that the flash cache block is caching what happens? Do we potentially have 2 copies of the block in flash cache (a copy each for the SCNs) and the read operations look at the commit SCN of the requesting session to return the correct block….or do we overwrite the cached image of the block with the new version – if so how does this work with concurrent reads (I find this interesting as there have been bugs associated with this and it would be good to know the serialisation concerned).
Page 11 – first paragraph “the EUK version” should this be “the UEK version”
Page 18 – Figure 1.3 “IDR/RDS over infiniband”. Should this be “iDB/RDS over InfiniBand”
Page 21 – Figure 1.5 “Oracle/UDS”. Should this be “Oracle/UDP”? If this is meant to refer to Unix Datagram Sockets it would be good to make this clear as the previous paragraph is talking about UDP. I’m not sure that the last sentance on page 20 is correct …”more efficient than using a traditional TCP based protocol like UDP” should this be “more efficient than using a traditional IP based protocol like TCP”
Page 26 – section heading 2. “So you can use IPOB on a 10Ge network” should this be “So you can use IPoIB on a 10GbE network”. Not clear why we have to use 10GbE, or why we are talking about IB and Ethernet in the same sentance, why can we not use IPoIB on a 4xQDR network?
In chapter 13 the datapump discussion for NETWORK_LINK is incorrect. A log file is created but a dump file is not. Here’s the section:
“Using this method for manual migration doesn’t make much sense—if you are going to copy the data over a database link anyway, why not load it to target tables directly, using CTAS or direct-path insert, instead of dumping it to disk and reloading back later on?”
Pg. 8, first line. Typo: “cam” instead of “came”
page. 138
“The LIST FLASHCACHECURRENT command displays what’s in the cache.”
should be
“LIST FLASHCACHECONTENT”
On page 39 , middle of last paragraph reads ” … decision is not be locked in stone…”. Suggest removing the
word “be” to read “…decision is not locked in stone …”.
Nice job. Been working with Exadata x2-2 and this book certainly gave me a better understanding of how things work on some things that were a little fuzzy.
Chapter 2, the odd pages state Chapter 3.
Hi – page 112 last para says “Note that cellinit.ora will be discussed in more detail in chapter 8″, but it isn’t – did something get lost during the edits? If so, can you post the description of the ellinit.ora parameters here?
Thanks for a great book.
In chapter 7 (resource management) on page 181 there is a statement “This is because according to the rule priorities, the CLIENT_APPLICATION mapping rules takes precedence”. That statement should be “This is because according to the rule priorities, the CLIENT_PROGRAM mapping rules takes precedence”.
Thank you for a great book.
P241, below the NOTE:,
“certain tasks will he completed ” –>>
“certain tasks will be completed “
page 170 – small inconsistency:
the script is called
@fsx2whereas in the text it’s referred asxfs.sql– no 2 there.Chapter 15 – Compute node layout
Non-rac configurations section on page 500.
In a non-RAC configuration each compute node will have its own, non-clustered, ASM instance that provides storage for all databases on that server. Even though your database servers may be independent of on another they can still share Exadata storage (cell disks). This allows each database to make use of the full I/O bandwitdth of the Exadata storage subsystem
Maybe not a real error, but it is not made very clear they can share a cell disk as long as this disk is divided into multiple grid disks and that each grid disk can only be used by one of the db clusters (or non clustered asm instance).
sorry for the formatting, the “site” tag does something else then I thought
thanks for putting the book together, great job
page 73: “the two Zlib-based options (QUERY LOW and ARCHIVE HIGH)”
The Zlib based options are QUERY HIGH and ARCHIVE LOW.
Thanks Greg – submitted it to Apress
Hi Kerry,
Page 69 – QUERY HIGH: ZLIB, ARCHIVE LOW: ZLIB
Page 73 – the two Zlib-based options (QUERY LOW and ARCHIVE HIGH)
Gustavo
submitted
On page 157 (top), a formula is given for the calculating the default value for the parallel_servers_target parameter.
This formula is stated as: ((4 * cpu_count) * parallel_threads_per_cpu) * active_instances.
In the example calculation a value of 12 is used as cpu_count, but should this not be 24 as each db machine has 2 hexacores and each core has 2 threads?
Also, in the Oracle reference guide the given formula is:
PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 2
where concurrent users is depending on the memory management settings:
“if automatic memory management is disabled (manual mode), then the number of concurrent parallel users is 1. If PGA automatic memory management is enabled, the number of concurrent parallel users is 2. If global memory management or SGA memory target is used in addition to PGA automatic memory management, then the number of concurrent parallel users is 4.”
There is no mention of number of instances in the formula and CPU_COUNT seems to be per node and not the total number of cpu’s in the cluster.
When using the formula from the documentation, and 24 as cpu count and 4 for the concurrent_parallel_users, the end value is the same as in the book.
Have to look at this one a bit
On page 153, top of page, it is stated that the default value for the parallel_adaptive_multi_user parameter is “true”.
However, in the table on page 154 it is indicated that the default value is “false”
According to the Oracle documentation (and on my own databases) the default is indeed “true”, but could it be that this is different on Exadata systems?
Yep that crept in on page 157 as well. Thanks. Submitted to Apress.
Page 17: “So as you can see, there are a number of processes that look like cellrsvXXX.
There is no v within the cellrsXXX cmd names.
Thanks Martin – submitted
Hi,
Minor typo I suspect:
Page 469 on Failure Groups:
“Traditional RAID0 mirroring maintains a block-for-block duplicate of the original disk.”
Obviously meant to be RAID1.
Great book though, thoroughly readable, and highly informative.
jason.
Hi – a minor typo, page 179, table 7-2: the table says that the the procedures SWITCH_CURRENT_CONSUMER_GROUP, SWITCH_CONSUMER_GROUP_FOR_SESSION, and SWITCH_CONSUMER_GROUP_FOR_USER are all in DBMS_SESSION. But (as you know as weel as me, of course!) it is only the first that is in DBMS_SESSION, the others are in DBMS_RESOURCE_MANAGER.
Great book, I really appreciate your work.
Please note: the following are only useful if you reprint the book,
as these are minor/typographic/stylistic suggestions.
. . .
p248 footnote is missing a 1 indicator
p259 extra quote: ERROR,’ should be ERROR,
p260 “script” should be normal font: eg: …..script (IPConf)
p339 should be: (or partition) is relatively small.
p350 is: cell single block physical read:-Apparently
should be: cell single block physical read: Apparently
p359 suggestion only:
is: but realizes that the transaction must be committed
could be: but realizes that the transaction already must have been committed
p369 suggestion: replace semicolon with a comma
could be: rollback is needed on not, and it finds the transaction….
p372 (2 words) above mentioned
p376
(Also, I respectfully suggest using “due to” instead of “thanks to”)
could be: …or other work-area operations of database block I/Os, due to chained rows or …..
p469 (missing underscore in NAME values, in all but first)
eg: DATA_DG_CD_01_CELL01
p494 (missing the command sample to remove the ASM unique name from the availableTo attribute on all grid disks)
2. just shows: CellCLI> list griddisk attributes name, availableTo
( just a guess: > alter griddisk all availableTo=’ ‘ )
p515 is: which calculates a percentage of the statements currently in….
could be: which calculates the percentage of the statements currently in….
p540 typo: abbreciation -> abbreviation
p548 typo: it’s calcualted offload percentage -> its calculated offload percentage
. . .
Please understand this is minor typo stuff that I found and offer to share.
This is a wonderful book, and I hope to work with exadata some day.
Congratulations on producing this work.
p18 Figure 1-3 appears to be missing indications of ADR and DISKMON referenced on p19
p19 minor nit: should be “responsible for propagating”
p25 – 63 top of page: CHAPTER 3 should be CHAPTER 2
p145 – 173 top of page: MAKING PCBS should be EXADATA PARALLEL OPERATIONS
p165 should be “must be decompressed”
None of the above findings are material.
This book is extremely well-written.
Thanks Merrill, all typos submitted to Apress.
Page 128 para 1 “keep in mind writes to data files are done in the background by the DBWR processes”.
Is this 100% correct – particularly with Exadata with smart scans. I’m not sure this covers what happens with a segment level checkpoint – would it not be a concern to get writes to a particular segment to run quickly if full scans occur frequently and these are frequently causing segment checkpoints, and we are trying to make the system use smart scans….
One could argue this is a particular issue for Exadata given the lack of write cache on the storage system…… (O.5GB per cell doesn’t seem great)….
Me again.
Page 126 – It would be good to know the impact of shutting down a storage cell, in order to replace a flash card or patch the software.
What I’d find interesting is:
1) storage indexes
2) flash cache
3) preferred reads
If we restart the storage cell, when does it become available for reads? As data is re-mirrored from another cell (assuming this is necessary) are storage indexes updated as the mirroring takes place? As the storage cell resilvers with the blocks in other cells does the flash cache start to cache the blocks this cell is going to be the preferred read of….
Granted this isn’t errata – but it would be good to cover the impact of restarting a storage cell, as on the face of it this is not a trivial operation (for instance if there is a restart does this throw away the contents of the data on NAND i.e. the flash cards – if so is this is done logically are there is a scrub operation on the cards…).
I’d guess as the argument is that cells don’t talk to each other that none of this happens and restarting a cell throws away a tonne of information….
Not sure where my previous comments have gone…..
Page 127 – figure 5.1 is blurred.
Page 128 – comment box in Note. “There may be individual writes that take orders of magnitude longer than the average”. It would be interesting (at least to me) to have more discussion around this. Given we are talking about averages having an order of magnitude higher isn’t a big thing is it(?). And why is that – given that we do not have moving parts are we saying that the write wear levelling is kicking in and the gargbage collection isn’t good enough (because there’s plenty of head room as expressed in this chapter around the useable NAND vs. the actual NAND.
Page 130. Figure 5-3. I think a decent amount is being glossed over here. If we have a block in flash cache, and if we are over-writing the data block that the flash cache block is caching what happens? Do we potentially have 2 copies of the block in flash cache (a copy each for the SCNs) and the read operations look at the commit SCN of the requesting session to return the correct block….or do we overwrite the cached image of the block with the new version – if so how does this work with concurrent reads (I find this interesting as there have been bugs associated with this and it would be good to know the serialisation concerned).
V good book so far.
Page 11 – first paragraph “the EUK version” should this be “the UEK version”
Page 18 – Figure 1.3 “IDR/RDS over infiniband”. Should this be “iDB/RDS over InfiniBand”
Page 21 – Figure 1.5 “Oracle/UDS”. Should this be “Oracle/UDP”? If this is meant to refer to Unix Datagram Sockets it would be good to make this clear as the previous paragraph is talking about UDP. I’m not sure that the last sentance on page 20 is correct …”more efficient than using a traditional TCP based protocol like UDP” should this be “more efficient than using a traditional IP based protocol like TCP”
Page 26 – section heading 2. “So you can use IPOB on a 10Ge network” should this be “So you can use IPoIB on a 10GbE network”. Not clear why we have to use 10GbE, or why we are talking about IB and Ethernet in the same sentance, why can we not use IPoIB on a 4xQDR network?
Cheers,
Andy
p 547 – the url to this site is incorrect in the pdf version.
Glad the “final” version is out.
Page 39 – chart is incorrectly formated “Always” is split between columns in pdf version atleast.
This must have already been fixed as the copy I have has it formatted correctly.