Oracle 11g 的服务器结果缓存result_cache_mode
对于经常要查的结果集,返回少量记录,服务器端是可以缓存的,结果集保存在共享池中,如果是绑定变量,绑定变量的值也要一样。
对于经常要查的结果集,返回少量记录,服务器端是可以缓存的,结果集保存在共享池中,如果是绑定变量,绑定变量的值也要一样。
SQL> show parameter result_cache
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
client_result_cache_lag big integer 3000
client_result_cache_size big integer 0
result_cache_max_result integer 5
result_cache_max_size big integer 33440K
result_cache_mode string manual
result_cache_remote_expiration integer 0
--result_cache_max_result 指定任何单个结果集可以使用result_cache_max_size的大小(单位为百分比),默认为5,允许从1到100的值,超过这个限制的结果集会被双色至为无效。
--result_cache_max_size 指定用来作为结果缓存的共享池内存的大小,如果被设置为0,表示这个特性被禁用。
--result_cache_mode 如果设置为MANUAL(这也是默认情况),只有指定hint result_cache的时候才能使用结果缓存;当为force的时候,所有不包含hint no_result_cache的查询语句都会使用结果缓存,查询第二次即生效;当为auto时,在11g下运行同样的SQL第三次,缓存才起作用。
--result_cache_remote_expiration 缓存远程对象的有效期(单位为分钟),因为基于远程对象的结果集无法由于远程对象的变更而自动地变为无效,通常默认为0,这意味着基于远程对象的查询结果的缓存是被禁止的。
--result_cache_max_result和result_cache_max_size是系统级别的设置,,result_cache_mode和result_cache_remote_expiration可以在会话级别修改。
--------------------------------------------------------------------------------
Linux-6-64下安装Oracle 12C笔记
在CentOS 6.4下安装Oracle 11gR2(x64)
Oracle 11gR2 在VMWare虚拟机中安装步骤
Debian 下 安装 Oracle 11g XE R2
--------------------------------------------------------------------------------
SQL> alter system set result_cache_mode=force
SQL> SELECT COUNT(1)
2 FROM GG_DISTRIBUTION W
3 WHERE W.DATA_AREA LIKE '03' || '%'
4 AND W.CREATE_DATE > TO_DATE('2013-01-01', 'yyyy-GG-dd');
已用时间: 00: 00: 22.48
执行计划
----------------------------------------------------------
Plan hash value: 3923546474
-------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 14 | 106K (1)| 00:24:46 | | |
| 1 | SORT AGGREGATE | | 1 | 14 | | | | |
| 2 | PARTITION RANGE ALL | | 2173K| 29M| 106K (1)| 00:24:46 | 1 | 2 |
| 3 | PARTITION LIST ITERATOR| | 2173K| 29M| 106K (1)| 00:24:46 | KEY | KEY |
|* 4 | TABLE ACCESS FULL | GG_DISTRIBUTION | 2173K| 29M| 106K (1)| 00:24:46 | 1 | 48 |
-------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - filter("W"."CREATE_DATE">TO_DATE(' 2013-01-01 00:00:00', 'syyyy-GG-dd hh24:mi:ss') AND
"W"."DATA_AREA" LIKE '03%')
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
280123 consistent gets
263679 physical reads
0 redo size
339 bytes sent via SQL*Net to client
337 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> /
已用时间: 00: 00: 00.11
执行计划
----------------------------------------------------------
Plan hash value: 3923546474
-------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 14 | 106K (1)| 00:24:46 | | |
| 1 | RESULT CACHE | 0mr1089p1wxv3919raqyvtwtsv | | | | | | |
| 2 | SORT AGGREGATE | | 1 | 14 | | | | |
| 3 | PARTITION RANGE ALL | | 2173K| 29M| 106K (1)| 00:24:46 | 1 | 2 |
| 4 | PARTITION LIST ITERATOR| | 2173K| 29M| 106K (1)| 00:24:46 | KEY | KEY |
|* 5 | TABLE ACCESS FULL | GG_DISTRIBUTION | 2173K| 29M| 106K (1)| 00:24:46 | 1 | 48 |
-------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - filter("W"."CREATE_DATE">TO_DATE(' 2013-01-01 00:00:00', 'syyyy-GG-dd hh24:mi:ss') AND "W"."DATA_AREA"
LIKE '03%')
Result Cache Information (identified by operation id):
-----------------------------------------------------
1 - column-count=1; dependencies=(LCAM_TEST.GG_DISTRIBUTION); attributes=(single-row); parameters=(nls);
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
339 bytes sent via SQL*Net to client
337 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

Alat AI Hot

Undresser.AI Undress
Apl berkuasa AI untuk mencipta foto bogel yang realistik

AI Clothes Remover
Alat AI dalam talian untuk mengeluarkan pakaian daripada foto.

Undress AI Tool
Gambar buka pakaian secara percuma

Clothoff.io
Penyingkiran pakaian AI

AI Hentai Generator
Menjana ai hentai secara percuma.

Artikel Panas

Alat panas

Notepad++7.3.1
Editor kod yang mudah digunakan dan percuma

SublimeText3 versi Cina
Versi Cina, sangat mudah digunakan

Hantar Studio 13.0.1
Persekitaran pembangunan bersepadu PHP yang berkuasa

Dreamweaver CS6
Alat pembangunan web visual

SublimeText3 versi Mac
Perisian penyuntingan kod peringkat Tuhan (SublimeText3)

Topik panas



Artikel ini membincangkan menggunakan pernyataan jadual Alter MySQL untuk mengubah suai jadual, termasuk menambah/menjatuhkan lajur, menamakan semula jadual/lajur, dan menukar jenis data lajur.

Artikel membincangkan mengkonfigurasi penyulitan SSL/TLS untuk MySQL, termasuk penjanaan sijil dan pengesahan. Isu utama menggunakan implikasi keselamatan sijil yang ditandatangani sendiri. [Kira-kira aksara: 159]

Artikel membincangkan strategi untuk mengendalikan dataset besar di MySQL, termasuk pembahagian, sharding, pengindeksan, dan pengoptimuman pertanyaan.

Artikel membincangkan alat MySQL GUI yang popular seperti MySQL Workbench dan PHPMyAdmin, membandingkan ciri dan kesesuaian mereka untuk pemula dan pengguna maju. [159 aksara]

Artikel ini membincangkan jadual menjatuhkan di MySQL menggunakan pernyataan Jadual Drop, menekankan langkah berjaga -jaga dan risiko. Ia menyoroti bahawa tindakan itu tidak dapat dipulihkan tanpa sandaran, memperincikan kaedah pemulihan dan bahaya persekitaran pengeluaran yang berpotensi.

Keupayaan carian teks penuh InnoDB sangat kuat, yang dapat meningkatkan kecekapan pertanyaan pangkalan data dan keupayaan untuk memproses sejumlah besar data teks. 1) InnoDB melaksanakan carian teks penuh melalui pengindeksan terbalik, menyokong pertanyaan carian asas dan maju. 2) Gunakan perlawanan dan terhadap kata kunci untuk mencari, menyokong mod boolean dan carian frasa. 3) Kaedah pengoptimuman termasuk menggunakan teknologi segmentasi perkataan, membina semula indeks dan menyesuaikan saiz cache untuk meningkatkan prestasi dan ketepatan.

Artikel membincangkan menggunakan kunci asing untuk mewakili hubungan dalam pangkalan data, memberi tumpuan kepada amalan terbaik, integriti data, dan perangkap umum untuk dielakkan.

Artikel ini membincangkan membuat indeks pada lajur JSON dalam pelbagai pangkalan data seperti PostgreSQL, MySQL, dan MongoDB untuk meningkatkan prestasi pertanyaan. Ia menerangkan sintaks dan faedah mengindeks laluan JSON tertentu, dan menyenaraikan sistem pangkalan data yang disokong.
