SQL> select name from v$parameter where isdeprecated = 'TRUE' order by 1;
|
name |
|
background_dump_dest |
|
buffer_pool_keep |
|
buffer_pool_recycle |
|
commit_write |
|
cursor_space_for_time |
|
drs_start |
|
fast_start_io_target |
|
global_context_pool_size |
|
instance_groups |
|
lock_name_space |
|
log_archive_local_first |
|
log_archive_start |
|
max_commit_propagation_delay |
|
max_enabled_roles |
|
parallel_automatic_tuning |
|
parallel_server |
|
parallel_server_instances |
|
plsql_debug |
|
plsql_v2_compatibility |
|
remote_os_authent |
|
resource_manager_cpu_allocation |
|
serial_reuse |
|
sql_trace |
|
sql_version |
|
standby_archive_dest |
|
user_dump_dest |
26 rows selected.
이제 parameter 하나하나에 대해 의미 및 용도,
그리고 deprecate된 이유에 대해서 설명하고자 합니다.
1. background_dump_dest
● 의미 및 용도
LGWR, DBWR등의 background process들이 활동을 하면서 발생되는 trace files가
저장되는 곳으로, alert_SID.log도 이곳에 저장됩니다.
● deprecate된 이유
Oracle11g부터는 새로운 diagnosability infrastructure를 제공하는데,
이것은 "diagnostic_dest"라는 initialization parameter가 지정하는 directory에
trace and core files를 저장하도록 합니다.
background_dump_dest가 initialization parameter file에 기술되어 있어도 무시됩니다.
2. buffer_pool_keep
● 의미 및 용도
keep buffer의 사이즈(blocks수)를 결정합니다.
● deprecate된 이유
Oracle9i부터는 db_keep_cache_size로 대신할 수 있게 되어서 deprecate되었습니다.
3. buffer_pool_recycle
● 의미 및 용도
recycle buffer의 사이즈(blocks수)를 결정합니다.
● deprecate된 이유
Oracle9i부터는db_recycle_cache_size로 대신할 수 있게 되어서 deprecate되었습니다.
4. commit_write
● 의미 및 용도
asynchronous commit을 허용할지 여부를 정합니다.
이 parameter의 의미를 설명하기 위해서는
transaction이 commit되는 과정을 설명할 필요가 있습니다.
일반적인 transaction은 다음과 같은 과정을 거쳐서 처리됩니다.
(1) user가 transaction을 수행한다
(2) user가 수행하는 DMLs와 관련된 data changes를 log buffer(memory)에 담는다.
(3) user가 commit을 실행하는 순간, 즉시 해당 transaction과 관련된 내용을
log buffer로부터 online redo logs(disk)에 write한다.
(4) online redo logs에의 write가 끝난 이후에야 user에 응답한다.
(SQL*Plus인 경우에는 "Commit complete."라는 message가 반환됩니다)
위는 transaction이 commit되는 동안 발생하는 default과정으로,
(3)에서는 commit순간에 즉시(immediate) redo logs(disk)에 write를 하고 있으며,
(4)에서는 redo logs에 write가 끝날 때까지 기다린(wait) 후에 user에 응답하도록
되어 있습니다.
이 default과정 대신에
commit되는 타이밍과 관계없이 redo logs를 적당한 timing에 모아서(batch) write하고,
redo logs에 write가 끝날 때까지 기다리지 않고(nowait) 바로 user에 응답하도록
설정을 변경할 수도 있습니다.
위와 같이 설정을 변경하는 방법에는 2가지가 있는데,
하나는 "commit" command의 option을 통해 statement level에서 수행하는 것이며,
다른 하나는 "commit_write"라는 parameter를 사용해서
instance level에서 적용되도록 하는 것입니다.
일반적으로 SQL*Plus에서 commit을 실행하는 것은,
"commit write immediate wait;" (immediate과 wait의 순서가 바뀌어도 상관없다)
을 실행하는 것과 같습니다.
만약 아래와 같은 command를 실행하게 된다면,
commit write batch nowait;
transaction과 관련된 changes는 redo log files(disk)에 바로 쓰여지지 않을 것이며,
바로 user에게 "Commit complete."라는 message를 반환하게 됩니다.
이 설정을 instance level에서 적용시키고자 한다면,
alter system set commit_write = 'batch,nowait';
이라고 실행하면 됩니다.
만약 아래와 같은 command를 실행하게 된다면,
commit write immediate nowait;
transaction과 관련된 changes는 redo log files에 바로 쓰여지게 되지만,
redo log files에의 write가 끝날 때까지 기다리지 않고
바로 user에게 "Commit complete."라는 message를 반환하게 됩니다.
만약 이 parameter를 default값에서 다른 값으로 변경하는 경우,
commit performance가 좋아진다는 장점이 있지만,
redo log files에 changes가 disk에 저장되지 않은 상태에서 media failure가 발생하는 경우,
disk에 저장되지 않은 transactions에 대해서는
instance recovery를 통해서 복구할 수 없다는 큰 단점이 있습니다.
● deprecate된 이유
Oracle11g부터는 "commit_logging"과 "commit_wait"이라는 2개의 parameters로 분리시켜서
동일한 기능을 하도록 바뀌었기 때문에, "commit_write"는 deprecate되었습니다.
5. cursor_space_for_time
● 의미 및 용도
하나의 SQL문이 실행되기 위해서는 parse와 execute단계를 거치게 됩니다.
instance가 기동된 후, 처음으로 실행된 SQL문에 대해 parse된 결과는
shared pool에 저장되며, 이후에 실행되는 동일한 SQL문에 대해서는 parse를 수행하지 않고
shared pool에 저장된 parsed 정보를 이용해서 execute하게 됩니다.
새로운 정보를 shared pool(library cache)에 기록하려는 순간에
shared pool이 꽉 차 있게 되면 우선 closed cursor정보를 제거하고,
그 다음은 LRU(Least Recently Used) algorithm에 따라 낡은(aged) 정보를 제거합니다.
만약 open cursors로 shared pool이 꽉찬 경우에는
open된 cursor의 parsed 정보가 shared pool에서 제거되기도 합니다.
그러므로 다량의 SQL문이 빈번하게 발행되는 환경에서는
open된 cursor에 대해, parse단계에서 존재했었던 parsed정보가
execute단계에서 없어져 버리는 경우가 간혹 발생하게 됩니다.
결국 다시 parse(hard parse)해야 하므로 performance가 떨어지는 원인이 됩니다.
하지만 "cursor_space_for_time"을 true로 설정하게 되면,
open된 cursor의 parsed정보가 제거되지 않게 됩니다.
그런 의미에서 "cursor_space_for_time"을 통해
경우에 따라서는 약간의 성능향상을 기대할 수 있습니다.
● deprecate된 이유
위에서 언급한 것처럼 open된 cursors로 shared pool이 꽉차는 경우는
shared pool이 굉장히 작은 경우에나 발생하며,
Oracle10g이후에는 Automatic Memory Management기능을 통해
자동으로 shared pool의 크기가 관리되기 때문에
이 parameter가 성능향상에 기여하는 경우는 거의 없어지게 되었습니다.
initialization parameter수의 증가는 DB관리자를 피곤하게 할 뿐이므로,
거의 활용도가 없는 이 parameter가 deprecate된 것은 매우 긍정적이라고 생각됩니다.
6. drs_start
● 의미 및 용도
DMON(Data Guard Broker)이라는 background process를 기동할 지 여부를 정합니다.
Data Guard Broker란, Data Guard환경을 감시, 관리할 수 있도록 해주는 framework로,
DGMGRL이라는 command-line interface(dgmgrl 이라는 binary file이 존재함)
혹은 Enterprise Manager를 통해 Data Guard Broker기능을 이용할 수 있습니다.
이 drs_start라는 parameter를 true로 설정해야만
Data Guard Broker가 제공하는 기능을 이용할 수 있습니다.
drs_start를 true로 설정하지 않고 Data Guard Broker를 활용하려고 하는 경우,
다음과 같이 error가 발생하게 됩니다.
|
DGMGRL> create configuration 'DRSolution' as primary database is 'North_Sales' connect identifier is North_Sales.foo.com;
Error:
ORA-16525: the Data Guard broker is not yet available
... |
● deprecate된 이유
Oracle9iR2부터 dg_broker_start라는 parameter로 대체되면서 deprecate되었는데,
drs_start라는 parameter명이 Data Guard Broker를 떠올릴 만한 이름이 아닌 관계로,
보다 구체적이고 합리적인 parameter명으로 대체된 듯 합니다.
7. fast_start_io_target
● 의미 및 용도
이 parameter에 대해 설명하기 전에
data가 변경되는 과정에 대해서 간단히 언급하고자 합니다.
Oracle에서는 transaction을 통해 변경된 data정보를 바로 disk에 기록하지 않고,
SGA의 buffer cache에 저장한 후, Oracle 스스로 system의 부하를 고려하여
적당하다고 판단되는 타이밍에 몰아서(batch) disk에 기록을 하도록 되어 있습니다.
그러므로 buffer cache상에는 memory상의 정보는 변경되었지만
disk에는 아직 반영되지 않은 상태의 block이 항상 존재하게 됩니다.
이런 block을 Oracle에서는 "dirty block"이라고 부릅니다.
이 dirty block은 checkpoint가 발생하는 타이밍에 disk에 쓰여지게 됩니다.
fast_start_io_target는 dirty blocks의 수를 제한하기 위한 parameter로,
만약 1,000이라는 값을 설정했다면, dirty blocks가 1,000개를 넘기 전에
dirty blocks를 disk에 write하게 됩니다.
그러므로 이 fast_start_io_target를 보다 작은 값으로 설정할수록,
checkpoint에 소요되는 시간이 줄어들며,
roll forward할 양이 적어지므로 instance recovery에 걸리는 시간도 줄어들게 됩니다.
참고로, "0"으로 설정하면 이 기능이 disable됩니다.
● deprecate된 이유
10.1.0.4부터 fast_start_mttr_target parameter로 대체되면서 deprecate되었는데,
그 이유는 fast_start_io_target를 잘못 설정할 경우,
지나친 부하로 system이 다운될 수 있기 때문입니다.
8. global_context_pool_size
● 의미 및 용도
지금까지 들어 본 적도 없는 parameter인데,
조사해 보니, Oracle9i의 신기능과 더불어 등장한 parameter라고 합니다.
● deprecate된 이유
10.1.0.4부터 deprecate되었는데, Oracle10g부터 Automatic Memory Management가
주류가 되면서 이 parameter의 설정이 불필요해 진 것 같습니다.
9. instance_groups
● 의미 및 용도
RAC환경에서만 의미를 가지는 parameter로,
각각의 instance에 대해 자신이 속할 instance_group을 설정할 수 있으며,
comma(,)로 구분하여 복수의 groups에 속하도록 설정할 수도 있습니다.
여기서 설정되는 instance group은 parallel execution을 수행할 때만 의미를 가지므로,
반드시 parallel_instance_group이라는 parameter와 함께 사용되어야 합니다.
(이상하게도 parallel_instance_group parameter는 아직 deprecate되지 않았습니다.)
예를 들어, instance 4개로 구성된 RAC이 있고,
instance 1,2에 대해서만 instance_groups의 값을 sales라고 설정하고,
parallel_instance_group값을 sales라고 설정한 후에 parallel execution을 실행하게 되면,
sales group에 속하지 않은 instance 3,4는 parallel execution에 관여하지 않고
오직 instance 1,2만 parallel execution에 참여하여 관련 processes가 발생하게 됩니다.
사실 저 역시도 이 parameter를 사용해 보지 않아서 충분히 이해가 되지는 않습니다.
● deprecate된 이유
11.1.0.6부터 deprecate되었는데, 정확한 이유는 모르겠지만,
아마도 이 parameter의 사용법이 어려워서
제대로 활용하기가 힘들기 때문이 아닐까 싶습니다.
10. lock_name_space
● 의미 및 용도
DLM(Distributed Lock Manager)가 lock이름을 생성하기 위해 사용하는 namespace를
지정하는 parameter라고 하는데 잘 이해가 안되네요.
(LOCK_NAME_SPACE specifies the namespace that the distributed lock manager (DLM)
uses to generate lock names)
이 parameter는, primary database와 동일한 host상에 standby database 혹은
동일한 db_name을 가지는 clone database를 생성하고자 하는 경우에
반드시 값을 설정해야 합니다.
제가 혼자 Oracle을 공부하던 시절에 하나의 PC에
primay 뿐만 아니라 standby database까지 생성한 적이 있습니다.
이 당시에 lock_name_space를 설정하지 않으면 error가 발생했던 기억이 납니다.
● deprecate된 이유
10.1.0.4부터는 db_unique_name이라는 새롭게 등장한 parameter가
lock_name_space의 역할을 대신하게 되면서 deprecate되었습니다.
11. log_archive_local_first
● 의미 및 용도
Data Guard환경에서만 의미를 가지는 parameter로,
(=true) primary host상의 local destination에 archiving을 반드시 끝낸 이후에,
standby host에 archiving을 수행할지, 아니면
(=false) primary 및 standby host상에서 동시에 archiving을 수행할지를
정하는 parameter입니다.
전자의 경우에는, local에 archiving이 끝난 archived redo log를 standby host에 전송하는
형태를 가지기 때문에 log transport service를 archiver process(ARCn)가 담당하게 되며,
후자의 경우에는, standby destination에 동시에 redo data를 전송하기 때문에
log writer process(LGWR)가 log transport service를 담당하게 됩니다.
그러면 standby host상의 archiver process는 전송받은 redo data를 가지고
archived redo log를 생성하게 됩니다.
이 parameter는 Oracle10g부터 등장했으며, 그 이전 version에서는,
LGWR을 사용해서 동시에 archiving을 수행하는 것이 default설정이었습니다.
하지만 Oracle10g이후부터는 "log_archive_local_first"의 default값이 "true"로,
즉, local에 archiving이 끝난 이후에 standby host에 전송하는 방식이 default설정입니다.
● deprecate된 이유
Oracle11g부터 deprecate되었으며, 정확한 이유는 모르겠지만, 아마도
"log_archive_local_first"값을 "false"로 설정할 필요가 있는 경우가 거의 없고,
설정해도 큰 메리트가 없기 때문으로 보입니다.
12. log_archive_start
● 의미 및 용도
ARCHIVELOG mode상태의 database가 online redo log가 full되는 시점에
자동으로 archiving을 하도록 하기 위해 필요한 설정입니다.
● deprecate된 이유
Oracle10g부터 deprecate되었는데,
Oracle9i까지는 ARCHIVELOG mode상태의 database에 대해
이 parameter값을 "true"로 설정함으로서 자동으로 archiving이 수행되게 할 수도 있고,
이 parameter값을 "false"로 설정해서 수동으로만 archiving을 할 수 있도록
설정할 수도 있었습니다.
하지만 실제로 수동 archiving기능은 거의 사용되지 않았기 때문에,
Oracle10g부터는 ARCHIVELOG mode로 설정을 하게 되면
그 순간부터 자동 archiving이 수행되도록 바뀌었습니다.
그 결과, "log_archive_start"라는 parameter는 쓸모가 없게 되었습니다.
13. max_commit_propagation_delay
● 의미 및 용도
RAC환경에서만 적용되는 parameter인데,
한 번도 본 적도 없고 사용한 적도 없는 parameter라 잘 모르겠네요.
아래의 페이지에 잘 설명되어 있는 것 같습니다.
http://wiki.ex-em.com/index.php/MAX_COMMIT_PROPAGATION_DELAY
● deprecate된 이유
10.2.0.3부터 deprecate되었습니다.
14. max_enabled_roles
● 의미 및 용도
한 user에 grant할 수 role의 개수의 최대치를 정하는 parameter입니다.
예를 들어 이 값이 "10"인 경우, 10개의 roles까지만 grant할 수 있습니다.
(이 "10"개의 role에, 실제 자신의 schema내의 objects에 접근할 수 있는 role과
public objects에 접근할 수 있는 role, 이 2가지 role은 포함되지 않습니다)
● deprecate된 이유
Oracle10g부터 deprecate되었으며, 148개까지의 roles를 grant할 수 있습니다.
처음에는 이 parameter가 왜 생겨났는지 도무지 이해가 안되었는데,
이 parameter를 적은 값으로 설정하면 할수록
resource(특히 memory)를 절약할 수 있는 잇점이 있는 것 같습니다.
하지만 Oracle10g가 등장한 시절부터는 memory값이 많이 저렴해졌기 때문에,
이 parameter의 설정을 통해 얻을 수 있는 잇점이 거의 없어진 것 같습니다.
15. parallel_automatic_tuning
● 의미 및 용도
PX(parallel execution)와 관련된 다음의 5개의 parameters의 설정에 대해,
true인 경우에는 Oracle이 기존 설정치를 무시하고 자동으로 설정을 변경할 수 있게 하며,
false인 경우에는 자동으로 tuning하지 못하도록 하는 parameter입니다.
(1) parallel_execution_message_size
(2) parallel_adaptive_multi_user
(3) large_pool_size
(5) parallel_max_servers
이 parameter가 의미를 갖기 위해서는, 병렬처리를 하고자 하는 target tables에 대해
"parallel" clause를 반드시 지정해야 합니다.
(4) processes
● deprecate된 이유
Oracle9i까지는 를 true로 설정함으로서 parallel execution의 성능향상이 있었는데,
즉, 위의 5개의 parameters값의 새로운 default값이 의미가 있었지만,
Oracle10g부터는 이 default값이 오히려 성능을 떨어뜨리는 경우가 많아지면서
deprecate되게 되었다고 합니다.
Oracle10g부터 SGA까지도 Oracle이 자동으로 관리해 주는 방식으로 변하면서,
이 parameter가 불필요해 진 것 같습니다.
16. parallel_server
● 의미 및 용도
database를 Oracle Parallel Server(OPS)환경에서 구동시키기 위해서 필요한 parameter로,
single-instance database에서는 "false"라는 값을 가지게 되며,
multi-instance database(OPS)환경에서는 "true"값이 설정되어야 합니다.
● deprecate된 이유
이 OPS는 Oracle8i 까지 존재했던 cluster환경을 일컫는 용어이며,
Oracle9i 이후에는 OPS 대신에 RAC(Real Application Cluster)라는 용어가 사용되고 있습니다.
물론 용어만 달라진 것은 아니며, 내부 메커니즘도 크게 달라졌습니다.
Oracle9i 부터 "parallel_server"를 "cluster_database"라는 parameter가 대체하게 되면서,
이 parameter는 deprecate되었습니다.
17. parallel_server_instances
● 의미 및 용도
database를 Oracle Parallel Server(OPS)환경에서 구동시키기 위해서 필요한 parameter로,
OPS환경에 참가한 instances의 수가 설정됩니다.
single-instance database에서는 당연히 "1" 이라는 값을 가지게 되며
multi-instance로 구성된 OPS환경에서는 1보다 큰 값을 가지게 됩니다.
● deprecate된 이유
앞의 "parallel_server"과 마찬가지로
"parallel_server_instances"는 OPS환경에서 사용되던 parameter로,
Oracle9i 부터는 "cluster_database_instacnes"로 대체되면서 deprecate되었습니다.
18. plsql_debug
● 의미 및 용도
PL/SQL의 debug를 돕기 위한 parameter입니다.
programming을 마치고 debugging과정에 들어가게 되면,
어디에서 문제가 발생하고, 특정 변수에 어떤 값이 들어가는지, 등등을 알기 위해,
program 내부에 debug관련 code를 넣고,
monitor등의 standard output에 debug관련 문자열을 출력시켜 가면서
debugging하는 경우가 많이 있습니다.
이 debug용 code는 debug가 끝나면 지워야 하는데, 또 다른 bug가 발생하게 되면
다시 debug용 code를 입력해야 하는 번거로운 일이 생기게 됩니다.
이 번거로운 과정을 줄이기 위해, 등장한 parameter가 plsql_debug입니다.
아래의 예와 같이, 이 parameter값을 통해 debug문의 출력여부를 제어할 수 있습니다.
|
SQL> show parameter plsql_debug
|
name |
type |
value |
|
plsql_debug |
boolean |
false |
SQL> create or replace function sample_plsql return date
2 is
3 currentDate date;
4 begin
5 $if $$plsql_debug $then
6 dbms_output.put_line('debug point----------1');
7 $end
8 select sysdate into currentDate from dual;
9 return currentDate;
10 end sample_plsql;
11 /
Function created.
SQL> select sample_plsql from dual;
|
sample_plsql |
|
2010/02/25 16:20:36 |
-- 아래에서는 session level에서 "plsql_debug" parameter값을 변경했지만
-- system level에서 변경도 가능합니다
SQL> alter system set plsql_debug = true;
Session altered.
-- 아래의 결과를 보면 이상하게도 "plsql_debug"값을 "true"로 변경했지만
-- debug문이 출력되지 않았습니다
SQL> select sample_plsql from dual;
|
sample_plsql |
|
2010/02/25 16:21:06 |
SQL> alter function sample_plsql compile;
Function altered.
-- recompile하고 나서야 비로서 변경된 "plsql_debug"값이 반영되어
-- debug문이 출력되는 것을 알 수 있습니다.
SQL> select sample_plsql from dual;
|
sample_plsql |
|
2010/02/25 16:20:36 |
debug point----------1
SQL> alter system set plsql_debug = false;
Session altered.
SQL> alter function sample_plsql compile;
Function altered.
-- "plsql_debug"를 "false"로 설정한 뒤 compile했더니 예상대로
-- debug문이 출력되지 않았습니다
SQL> select sample_plsql from dual;
|
sample_plsql |
|
2010/02/25 16:21:06 |
SQL> alter function sample_plsql compile debug;
Function altered.
-- debug option을 붙여서 compile하게 되면, 아래의 결과와 같이
-- "plsql_debug"값과 관계없이 debug문이 출력됩니다.
SQL> select sample_plsql from dual;
|
sample_plsql |
|
2010/02/25 16:20:36 |
debug point----------1 |
※ 위의 결과는 Oracle10gR2 환경에서 실행한 결과로서 다른 version에서는
다른 결과가 나타날 수 있습니다.
● deprecate된 이유
이 parameter는 Oracle11g부터 deprecate되었는데,
위에서처럼, Oracle10gR2부터는 alter...comple문에 debug option이 사용가능해 지면서
구태여 "plsql_debug" parameter를 설정할 필요가 없어지게 되었습니다.
19. plsql_v2_compatibility
● 의미 및 용도
Oracle이 제공하는 PL/SQL에는 여러 가지 version이 있습니다.
Version 1.0 부터 시작해서 1.1(Oracle6)→2.0(Oracle7.0)→2.1(Oracle7.1)→2.2(Oracle7.2)
→2.3(Oracle7.3)→8.0(Oracle8.0)→... 으로 계속 version이 증가하고 있으며.
2.3에서 8.0으로 갑자기 크게 증가한 이유는 PL/SQL에 엄청난 성능향상이 있어서 라기 보단
PL/SQL version을 database version에 일치시키는 편이 좋다고 판단했기 때문입니다.
PL/SQL 2.x version에는 PL/SQL 8 이후의 version에서 허용하지 않는 기능이 몇가지 있는데,
이 "plsql_v2_compatibility" parameter를 "true"로 설정하게 되면,
PL/SQL library 및 compiler가 2.x version에 기반해서 동작하게 됩니다.
이 경우, PL/SQL 8 이후의 version에서만 허용하는 기능을 사용하면 error가 발생하게 됩니다.
● deprecate된 이유
Oracle11g부터 이 parameter가 deprecate되었는데, 더 이상 Oracle7에 대한 compatibility를
support하는 것은 의미없다고 Oracle이 판단한 것 같습니다.
PL/SQL version은 아래와 같이 확인할 수 있는데, 보통 database version과 동일합니다.
|
SQL> select * from v$version;
|
banner |
|
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production |
|
20. remote_os_authent
● 의미 및 용도
"os_authent_prefix" parameter에 설정된 문자열을 prefix로 하는 O/S user에 대해
remote host로부터 database에 access를 가능케 하기 위한 parameter입니다.
거의 사용할 일이 없기 때문에 자세한 설명은 생략합니다.
● deprecate된 이유
Oracle11g부터 deprecate되었으며, 그 이유는
잘 사용되지도 않을 뿐더러 보안상의 약점이 될 수 있기 때문인 것 같습니다.
21. resource_manager_cpu_allocation
● 의미 및 용도
Resource Manager가 이용할 수 있는 CPU수를 제한하는 parameter입니다.
Resource Manager는 설정된 Resource Plan에 따라 database에 연결된 sessions에 대해
CPU를 배분하는데, 보통 해당 server의 모든 physical CPUs가 활용됩니다.
하지만, 이 parameter값을 실제 CPU수보다 적은 값으로 설정하게 되면,
설정된 CPU만이 database sessions의 handling에 사용됩니다.
예를 들어, physical CPUs가 "4"이고, 의 값으로 "3"을 설정했다면,
3개의 CPUs만이 database session handling에 관여하고 1개의 CPU는 관여하지 않게 됩니다.
● deprecate된 이유
이 parameter의 역사는 무척 짧습니다.
11.1.0.6.0, 즉 11g에서 처음 등장했으며, 11.1.0.7.0에서 deprecate되었습니다.
deprecate된 정확한 이유는 모르겠습니다만,
아마 이 값을 적절하게 설정하는 것이 무척 어렵고,
설정했더니 오히려 performance가 떨어지는 경우가 많았던 것 같습니다.
22. serial_reuse
● 의미 및 용도
어떤 종류의 cursor에 대해 serial-reusable memory영역에 저장되도록 하여,
재활용(reuse)을 가능하게 할 지 정하는 parameter입니다.
물론 동일한 cursor(동일한 SQL, PL/SQL block)에 대해서만 재활용이 가능하며,
여기서 말하는 "재활용"이란, 동일한 cursor에 대해, SGA에 저장되어 있는 parse된 정보를
재활용하는 것으로 다시 한 번 parse를 하지 않도록 하는 것을 말합니다.
값으로는, select, dml, plsql, all, disable 이라는 5가지 값을 설정할 수 있습니다.
"select"는, select문에 대해서만 parse정보를 serial-reusable memory에 저장한다는 것이며,
"all"은, "select, dml, plsql"의 모든 종류의 parse정보를 저장한다는 것을 말합니다.
● deprecate된 이유
이 parameter는 8.1.7.4.0에서 처음 등장했으며, 10g에서 deprecate되었습니다.
deprecate된 정확한 이유는 모르겠습니다만,
metalink를 확인해 본 결과, 이 serial_reuse를 설정하는 것과 관련해서
여러 가지 bugs가 보고되고 있습니다.
즉, 이 parameter를 세밀하게 설정함으로서 얻는 성능향상의 효과보다는
bug 때문에 얻게 되는 손실이 더 크다고 판단되어 deprecate된 것 같습니다.
그리고 이 parameter는 memory가 부족하던 시절에 보다 효율적으로
memory를 활용하고자 하는 목적에서 등장했기 때문에,
Oracle10g가 등장한 시절은 SGA에 여유도 많이 생겼고,
그 결과 이렇게까지 세심한 tuning이 필요없어 졌다고 보입니다.
23. sql_trace
● 의미 및 용도
SQL trace의 가능여부를 정하는 parameter입니다.
유명한 parameter이므로 자세한 설명은 생략하겠습니다.
● deprecate된 이유
이 sql_trace라는 initialization parameter값을 SQL Trace를 하기 위해 true로 설정하게 되면
해당 database상에서 발생하는 모든 SQL에 대해 trace정보가 수집됩니다.
사용자가 발행하는 SQL을 제외하고도 그런 SQL을 처리하기 위해 내부적으로
data dictionary를 참조하는 SQL문이 다량으로 발행되는데 이것까지 수집됩니다.
이런 모든 SQL에 대해 trace정보를 수집하는 것은 system에 큰 부하가 걸리게 됩니다.
자칫하면 trace file로 인해 disk full이 발생할 수도 있습니다.
이런 배경에서 initialization parameter level에서 sql_trace을 true로 설정하지 못하도록
deprecate시킨 것으로 보입니다.
(dbms_monitor의 database_trace_enable 및 database_trace_disable을 사용해서
database level에서 SQL trace를 활성화시킬 수 있습니다.)
이 parameter는 Oracle10gR2부터 deprecate되었으며,
session level에서 SQL trace기능을 enable/disable하는 것은
dbms_monitor 및 dbms_session package의 session_trace_enable 및
session_trace_disable함수가 대신하게 되었습니다.
dbms_monitor package의 관련 함수의 경우에는 별도의 권한이 필요하지만,
dbms_session의 경우에는 별도의 권한없이 실행할 수 있습니다.
두 함수다 다음과 같이 parameter없이 실행할 수 있으며,
그 경우 접속중인 session에 대해서 SQL trace를 enable/disable시킵니다.
|
SQL> execute dbms_session.session_trace_enable();
PL/SQL procedure successfully completed.
SQL> select count(*) from emp;
…
SQL> execute dbms_session.session_trace_disable();
PL/SQL procedure successfully completed.
|
24. sql_version (생략)
25. standby_archive_dest
● 의미 및 용도
Data Guard상에서 standby host가 primary host로부터 전송된 archived redo logs를
저장하는 directory를 지정하는 parameter입니다.
기본적으로 primary host로부터 전송된 archived logs는 "log_archive_dest_n" parameter의
"location" attribute에 명시된 directory에 저장되는데,
이것과 다른 directory에 저장하고자 하는 경우에 "standby_archive_dest"를 설정합니다.
그러므로 이 2 parameters가 모두 설정된 경우에는 "standby_archive_dest" parameter에
설정된 값이 "log_archive_dest_n" parameter의 값을 override합니다.
참고로, standby host상에 archived logs가 저장되는 directory를 정리하면,
다음과 같은 rule에 따라 결정됩니다.
(1) "standby_archive_dest"값이 설정되어 있으면 그 곳에 저장됩니다.
(2) "standby_archive_dest"값이 설정되어 있지 않으면,
"valid_for=(standby_logfile, *)"를 포함하는 "log_archive_dest_n"의 "location"
attribute에 명시된 directory에 저장됩니다.
(3) "standby_archive_dest"값이 설정되어 있지 않으며,