Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 3 ■ FILES 75 ops$tkyte@ORA10G> alter system set sort_area_size = 65536 deferred; System altered. • SCOPE=MEMORY|SPFILE|BOTH indicates the “scope” of this parameter setting. We have the choice of setting the parameter value with the following: • SCOPE=MEMORY changes it in the instance(s) only; it will not survive a database restart. The next time you restart the database, the setting will be whatever it was before the change. • SCOPE=SPFILE changes the value in the SPFILE only. The change will not take place until the database is restarted and the SPFILE is processed again. Some parameters may only be changed using this option—for example, the processes parameter must use SCOPE=SPFILE, as we cannot change the active instance value. • SCOPE=BOTH means the parameter change takes place both in memory and in the SPFILE. The change will be reflected in the current instance and, the next time you restart, this change will still be in effect. This is the default value for scope when using an SPFILE. When using an init.ora parameter file, the default and only valid value is SCOPE=MEMORY. • sid='sid|*' is mostly useful in a clustered environment; sid='*' is the default. This allows you to specify a parameter setting uniquely for any given instance in the cluster. Unless you are using Oracle RAC, you will not need to specify the sid= setting. A typical use of this command is simply ops$tkyte@ORA10G> alter system set pga_aggregate_target=1024m; System altered. or, better yet, perhaps, using the COMMENT= assignment to document when and why a particular change was made: ops$tkyte@ORA10G> alter system set pga_aggregate_target=1024m 2 comment = 'changed 01-jan-2005 as per recommendation of George'; System altered. ops$tkyte@ORA10G> select value, update_comment 2 from v$parameter 3 where name = 'pga_aggregate_target'; VALUE ------------------------------------------------------------------------------- UPDATE_COMMENT ------------------------------------------------------------------------------- 1073741824 changed 01-jan-2005 as per recommendation of George
76 CHAPTER 3 ■ FILES Unsetting Values in SPFILEs The next question that arises is, “OK, so we set a value, but we would now like to ‘unset’ it—in other words, we don’t want that parameter setting in our SPFILE at all, and we would like it removed. Since we cannot edit the file using a text editor, how do we accomplish that?” This, too, is done via the ALTER SYSTEM command, but using the RESET clause: Alter system reset parameter sid='sid|*' Here the SCOPE/SID settings have the same meaning as before, but the SID= component is not optional. The documentation in the Oracle SQL Reference manual is a bit misleading on this particular command, as it seems to indicate that it is only valid for RAC (clustered) databases. In fact, it states the following: The alter_system_reset_clause is for use in a Real Application Clusters environment. Later, it does go on to state In a non-RAC environment, you can specify SID='*' for this clause. But this is a bit confusing. Nonetheless, this is the command we would use to “remove” a parameter setting from the SPFILE, allowing it to default. So, for example, if we wanted to remove the SORT_AREA_SIZE, to allow it to assume the default value we specified previously, we could do so as follows: sys@ORA10G> alter system reset sort_area_size scope=spfile sid='*'; System altered. The SORT_AREA_SIZE is removed from the SPFILE, a fact you can verify by issuing the following: sys@ORA10G> create pfile='/tmp/pfile.tst' from spfile; File created. You can then review the contents of /tmp/pfile.tst, which will be generated on the database server. You will find the SORT_AREA_SIZE parameter does not exist in the parameter files anymore. Creating PFILEs from SPFILEs The CREATE PFILE...FROM SPFILE command from the previous section is the opposite of CREATE SPFILE. It takes the binary SPFILE and creates a plain text file from it—one that can be edited in any text editor and subsequently used to start up the database. You might use this command for at least two things on a regular basis: • To create a “one-time” parameter file used to start up the database for maintenance, with some special settings. So, you would issue CREATE PFILE...FROM SPFILE and edit the resulting text PFILE, modifying the required settings. You would then start up the database, using the PFILE= option to specify use of your PFILE instead of the SPFILE. After you are finished, you would just start up normally, and the database
- Page 70 and 71: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 72 and 73: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 74 and 75: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 76 and 77: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 78 and 79: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 80 and 81: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 82 and 83: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 84 and 85: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 86 and 87: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 88 and 89: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 90 and 91: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 92: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 95 and 96: 50 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 97 and 98: 52 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 99 and 100: 54 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 101 and 102: 56 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 103 and 104: 58 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 105 and 106: 60 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 107 and 108: 62 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 110 and 111: CHAPTER 3 ■ ■ ■ Files In this
- Page 112 and 113: CHAPTER 3 ■ FILES 67 Without a pa
- Page 114 and 115: CHAPTER 3 ■ FILES 69 and even dat
- Page 116 and 117: CHAPTER 3 ■ FILES 71 all operatio
- Page 118 and 119: CHAPTER 3 ■ FILES 73 *.cluster_da
- Page 122 and 123: CHAPTER 3 ■ FILES 77 • To maint
- Page 124 and 125: CHAPTER 3 ■ FILES 79 • Resource
- Page 126 and 127: CHAPTER 3 ■ FILES 81 3 l_dummy nu
- Page 128 and 129: CHAPTER 3 ■ FILES 83 Trace Files
- Page 130 and 131: CHAPTER 3 ■ FILES 85 _qerixAlloca
- Page 132 and 133: CHAPTER 3 ■ FILES 87 6 ( 7 TYPE O
- Page 134 and 135: CHAPTER 3 ■ FILES 89 A Brief Revi
- Page 136 and 137: CHAPTER 3 ■ FILES 91 Redundant Ar
- Page 138 and 139: CHAPTER 3 ■ FILES 93 (data from m
- Page 140 and 141: CHAPTER 3 ■ FILES 95 dictionary t
- Page 142 and 143: CHAPTER 3 ■ FILES 97 ■Note df i
- Page 144 and 145: CHAPTER 3 ■ FILES 99 “accidenta
- Page 146 and 147: CHAPTER 3 ■ FILES 101 So, at the
- Page 148 and 149: CHAPTER 3 ■ FILES 103 Password Fi
- Page 150 and 151: CHAPTER 3 ■ FILES 105 USER is "SY
- Page 152 and 153: CHAPTER 3 ■ FILES 107 Flashback L
- Page 154 and 155: CHAPTER 3 ■ FILES 109 of the requ
- Page 156 and 157: CHAPTER 3 ■ FILES 111 IMPDP, howe
- Page 158 and 159: CHAPTER 3 ■ FILES 113 tkyte@ORA10
- Page 160 and 161: CHAPTER 4 ■ ■ ■ Memory Struct
- Page 162 and 163: CHAPTER 4 ■ MEMORY STRUCTURES 117
- Page 164 and 165: CHAPTER 4 ■ MEMORY STRUCTURES 119
- Page 166 and 167: CHAPTER 4 ■ MEMORY STRUCTURES 121
- Page 168 and 169: CHAPTER 4 ■ MEMORY STRUCTURES 123
76<br />
CHAPTER 3 ■ FILES<br />
Unsetting Values in SPFILEs<br />
The next question that arises is, “OK, so we set a value, but we would now like to ‘unset’ it—in<br />
other words, we don’t want that parameter setting in our SPFILE at all, <strong>and</strong> we would like it<br />
removed. Since we cannot edit the file using a text editor, how do we accomplish that?” This,<br />
too, is done via the ALTER SYSTEM comm<strong>and</strong>, but using the RESET clause:<br />
Alter system reset parameter sid='sid|*'<br />
Here the SCOPE/SID settings have the same meaning as before, but the SID= component is<br />
not optional. The documentation in the <strong>Oracle</strong> SQL Reference manual is a bit misleading on<br />
this particular comm<strong>and</strong>, as it seems to indicate that it is only valid for RAC (clustered) databases.<br />
In fact, it states the following:<br />
The alter_system_reset_clause is for use in a Real Application Clusters environment.<br />
Later, it does go on to state<br />
In a non-RAC environment, you can specify SID='*' for this clause.<br />
But this is a bit confusing. Nonetheless, this is the comm<strong>and</strong> we would use to “remove” a<br />
parameter setting from the SPFILE, allowing it to default. So, for example, if we wanted to<br />
remove the SORT_AREA_SIZE, to allow it to assume the default value we specified previously,<br />
we could do so as follows:<br />
sys@ORA10G> alter system reset sort_area_size scope=spfile sid='*';<br />
System altered.<br />
The SORT_AREA_SIZE is removed from the SPFILE, a fact you can verify by issuing the<br />
following:<br />
sys@ORA10G> create pfile='/tmp/pfile.tst' from spfile;<br />
File created.<br />
You can then review the contents of /tmp/pfile.tst, which will be generated on the database<br />
server. You will find the SORT_AREA_SIZE parameter does not exist in the parameter files<br />
anymore.<br />
Creating PFILEs from SPFILEs<br />
The CREATE PFILE...FROM SPFILE comm<strong>and</strong> from the previous section is the opposite of<br />
CREATE SPFILE. It takes the binary SPFILE <strong>and</strong> creates a plain text file from it—one that can be<br />
edited in any text editor <strong>and</strong> subsequently used to start up the database. You might use this<br />
comm<strong>and</strong> for at least two things on a regular basis:<br />
• To create a “one-time” parameter file used to start up the database for maintenance, with<br />
some special settings. So, you would issue CREATE PFILE...FROM SPFILE <strong>and</strong> edit the<br />
resulting text PFILE, modifying the required settings. You would then start up the database,<br />
using the PFILE= option to specify use of your PFILE instead of the<br />
SPFILE. After you are finished, you would just start up normally, <strong>and</strong> the database