Expert Oracle Exadata - Parent Directory

CHAPTER 3 HYBRID COLUMNAR COMPRESSION19517 oracle 25 0 10.1g 88m 50m R 99.9 0.1 0:27.59 ora_p007_SANDBOX119401 oracle 25 0 10.1g 87m 54m R 99.5 0.1 0:21.31 ora_p000_SANDBOX1Clearly, loading data into an ARCHIVE HIGH compressed table is a CPU-intensive process. But noticethat we’re still only using about half the processing power on the single Database Server. Adding moreprocessors and more servers should make it go considerably faster. By the way, it’s usually worthwhile tolook at the CPU usage during the uncompressed load for comparison purposes. Here’s another snapshotfrom top taken during the loading of the uncompressed version of the SKEW3 table; in this and similarsnapshots, we’ve highlighted output items of particular interest:===No Compression Loadtop - 19:46:55 up 2 days, 11:23, 6 users, load average: 1.21, 0.61, 1.20Tasks: 833 total, 2 running, 831 sleeping, 0 stopped, 0 zombieCpu(s): 22.3%us, 1.4%sy, 0.0%ni, 75.9%id, 0.1%wa, 0.1%hi, 0.2%si, 0.0%stMem: 74027752k total, 29273532k used, 44754220k free, 110376k buffersSwap: 16771852k total, 2135368k used, 14636484k free, 25074672k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND15999 oracle 16 0 10.0g 72m 64m S 54.8 0.1 0:04.89 ora_p000_SANDBOX116001 oracle 16 0 10.0g 72m 64m S 51.5 0.1 0:04.72 ora_p001_SANDBOX116024 oracle 16 0 10.0g 69m 61m S 48.5 0.1 0:03.97 ora_p007_SANDBOX116020 oracle 16 0 10.0g 70m 61m S 44.6 0.1 0:04.16 ora_p006_SANDBOX116003 oracle 16 0 10.0g 71m 62m S 43.6 0.1 0:04.42 ora_p002_SANDBOX116014 oracle 16 0 10.0g 71m 62m S 42.9 0.1 0:04.26 ora_p005_SANDBOX116007 oracle 16 0 10.0g 69m 61m S 40.9 0.1 0:04.28 ora_p004_SANDBOX116005 oracle 15 0 10.0g 72m 64m R 38.3 0.1 0:04.45 ora_p003_SANDBOX1Notice that while the number of active processes is the same (8), the CPU usage is significantly lesswhen the data is not being compressed during the load. The other levels of compression use somewhatless CPU, but are much closer to HCC4 than to the noncompressed load.To speed up the ARCHIVE HIGH loading we could add more processes or we could allow the slaves torun on multiple nodes. Here’s a quick example:SYS@SANDBOX1> alter system set parallel_force_local=false;System altered.Elapsed: 00:00:00.09SYS@SANDBOX1> create table kso.skew3_hcc4 nologging parallel 32 compress for archive high2 as select /*+ parallel (a 32) */ * from kso.skew3 a;Table created.Elapsed: 00:03:18.96Setting the PARALLEL_FORCE_LOCAL parameter to FALSE allowed slaves to be spread across bothnodes. Setting the parallel degree to 32 allowed 16 slaves to run on each of the two nodes in our quarterrack test system. This effectively utilized all the CPU resources on both nodes. Here’s one last snapshotof top output from one of the nodes during the load. The other node showed the same basic profileduring the load.===Second HCC4 run (32 slaves)top - 18:32:43 up 2:10, 2 users, load average: 18.51, 10.70, 4.70Tasks: 862 total, 19 running, 843 sleeping, 0 stopped, 0 zombie77