ALTER SYSTEM SET SGA_TARGET = 0 scope=spfile; not working

SQL> ALTER SYSTEM SET SGA_TARGET = 0 scope=spfile;
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.
Total System Global Area 2121256960 bytes
Fixed Size 2243280 bytes
Variable Size 1140852016 bytes
Database Buffers 973078528 bytes
Redo Buffers 5083136 bytes
Database mounted.
Database opened.
SQL> show parameters sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 2032M
sga_target big integer 0
SQL> create pfile=#/home/oracle/per03pfile' from spfile;
pfile has
*.sga_max_size=0
*.sga_target=0
and
instance1.__sga_target=2130706432
instance2.__sga_target=2130706432
tried ALTER SYSTEM SET SGA_TARGET = 0 scope=spfile sid='*'; aswell ...
oracle v11.2.0.2
GI 11.2.0.2
linux 64 bit

Chinar wrote:
user9198889 wrote:
SQL> ALTER SYSTEM SET SGA_TARGET = 0 scope=spfile;
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.
Total System Global Area 2121256960 bytes
Fixed Size 2243280 bytes
Variable Size 1140852016 bytes
Database Buffers 973078528 bytes
Redo Buffers 5083136 bytes
Database mounted.
Database opened.
SQL> show parameters sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 2032M
sga_target big integer 0
SQL> create pfile=#/home/oracle/per03pfile' from spfile;
pfile has
*.sga_max_size=0
*.sga_target=0
and
instance1.__sga_target=2130706432
instance2.__sga_target=2130706432
tried ALTER SYSTEM SET SGA_TARGET = 0 scope=spfile sid='*'; aswell ...
oracle v11.2.0.2
GI 11.2.0.2
linux 64 bitWhile SGA_MA_SIZE <> 0 then it seems SHARED MEMORY constructed according this setting.So it is not recommended to avoid automatic shared memory management.But if you decide this then you have to identify SHARED_PLOOL_SIZE,DB_CACHE_SIZE(in additionally LOG_BUFFER and LARGE_POOL) parameter manually and
ALTER SYSTEM SET SGA_TARGET=o scope=spfile and ALTER SYSTEM SET SGA_MAX_SIZE=o scope=spfile and restart database again.SQL> alter system set sga_max_size=0 scope=spfile sid='instance1';
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.
SQL> show parameters sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 2032M
sga_target big integer 0
SQL>
has it got todo with AMM being enabbled?

Similar Messages

ALTER SYSTEM SET SGA_TARGET

Hi,
in 10g R2 should I stop/start database when I change sGA_TARGET :
ALTER SYSTEM SET SGA_TARGET=value [SCOPE={SPFILE|MEMORY|BOTH}]
Thank you.

user522961 wrote:
OK.
When I query V$PARAMETER I have the OLD value for SGA_TARGET. It is normal because the value in V$PARAMETER comes from starting and spfile. How can I be sur that now oRACLE uses the new value for SGA_TARGET effectively ?
Thanks again.Not sure I understand your question. If you set SGA_TARGET with SCOPE=MEMORY or BOTH, it should be in effect immediately.
SQL> alter system set sga_target=253M scope=both;
System altered.
SQL> select value bytes, value/1048576 MB from v$parameter where name = 'sga_target';
BYTES              MB
268435456         256
SQL> show parameter sga
NAME                                 TYPE        VALUE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 512M
sga_target                           big integer 256M
SQL> alter system set sga_target=257M scope=both;
System altered.
SQL> select value bytes, value/1048576 MB from v$parameter where name = 'sga_target';
BYTES              MB
272629760         260
SQL> show parameter sga
NAME                                 TYPE        VALUE
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 512M
sga_target                           big integer 260M
SQL>

ALTER SYSTEM SET _awr_flush_threshold_metrics=TRUE SCOPE=MEMORY;

Hi,
our DB in 10g R2 on Win 2003 server has suddenly restarted with this message in alertlog :
ALTER SYSTEM SET awrflush_threshold_metrics=TRUE SCOPE=MEMORY;
I looked for this parameter in oracle documentation, I did not find.
1-what is this parameter for ?
2-How can I see which user connection has altered this parameter ?
Thanks.

user522961 wrote:
Hi,
our DB in 10g R2 on Win 2003 server has suddenly restarted with this message in alertlog :
ALTER SYSTEM SET awrflush_threshold_metrics=TRUE SCOPE=MEMORY;
I looked for this parameter in oracle documentation, I did not find.
1-what is this parameter for ?
2-How can I see which user connection has altered this parameter ?
Thanks.I don't think that you should be worried about it as its an undocumented parameter.
http://www.orafaq.com/parms/parm113.htm
Without Auditing, its not possible who changed it(if he really did)?
HTH
Aman....

Question on alter system set cluster_database = true

11.2.0.2.0 windows 2008
doing a restore to a development RAC I noticed the following. I took the database out of cluster mode on one instance
alter system set cluster_database=false scope=spfile sid='PRD1';
shutdown, start up, do the restore, all good, I go to set cluster_Database=true but had issue instance would only start on one node, I reviewed my notes and found problem was when I set cluster_Database back to true I had typed
alter system set cluster_database=true scope=spfile sid='*';
instead of
alter system set cluster_database=true scope=spfile sid='PRD1';
So issue fixed.
I retested and confirmed '*' wont take. Ive seen many examples of '*' working online and I am sure I have used '*' many times so had just typed it off my head. Anyone explain? probably quotes or something.

Any chance there are multiple lines for cluster_database in the spfile ?I had thought maybe this, but confirmed no, it was a fresh build anyway that I was restoring to.
>
- Dump the spfile to a pfile ... edit ... recreate the spfile on all nodes.
>
Im not sure what this will achieve? the spfile is shared on the ASM.
>
As the cluster_database=true is a parameter to enable the RAC configuration. As you typed sid='*' it will try to enable the cluster_database parameter in all the instances(nodes) as it is RAC.
In your case as you did on a single node by specifiying the sid name it will work as it will look only for that sid and enable that particular node.
>
I find this hard to read but I think this misinterprets as well.
Thanks for the contribution. I think Ive found the solution
the asterisk doesnt apparently mean actually "all instances", from here
http://www.comp.dit.ie/btierney/oracle11gdoc/rac.111/b28254/admin.htm#BCEFICEE
and
"Setting SPFILE Parameter Values for Oracle Real Application Clusters"
-- this is a good example of what happened to me
>
*.OPEN_CURSORS=500
prod1.OPEN_CURSORS=1000
Note:
The value before the dot in an SPFILE entry identifies the instance to which the particular parameter value belongs. When an asterisk precedes the dot, the value is applied to all instances that do not have a subsequent, individual value listed in the SPFILE.
For the instance with the Oracle system identifier (SID) prod1, the OPEN_CURSORS parameter is set to 1000 even though it has a database-wide setting of 500. Parameter file entries that have the asterisk (*) wildcard character only affect the instances without an instance-specific entry. This gives you control over parameter settings for instance prod1. These two types of settings can appear in any order in the parameter file.
If another DBA runs the following statement, then Oracle updates the setting on all instances except the instance with SID prod1:
ALTER SYSTEM SET OPEN_CURSORS=1500 sid='*' SCOPE=MEMORY;
>
so when I was on node 1 and ran it for *, I was setting it for all the nodes except the node I was on which holds true from what Ive seen. I'll remember that one.

Alter system set nls_length_semantics

Hi all,
my question concerns the scope in the change of NLS_LENGTH_SEMANTICS can be performed.
The 10gR2 documentation only the
"Modifiable ALTER SESSION"
But what about altering the system and making your own setting to default for all sessions? With which scope?
I tried
alter system set nls_length_semantics='CHAR';
alter system set nls_length_semantics='CHAR' scope=spfile;
alter system set nls_length_semantics='CHAR' scope=both;
None had really any effect. Do I have to bounce the database?

Hello,
Do I have to bounce the database?Yes, you have to shutdown and startup the database.
Else the NLS_LENGTH_SEMANTICS change won't be effective.
You may have more details on the following thread:
nls_database_parameters->nls_length_semantics Help!
There's also an interesting Note from MOS:
Examples and limits of BYTE and CHAR semantics usage (NLS_LENGTH_SEMANTICS) [ID 144808.1]They give many information about NLS_LENGTH_SEMANTICS and the following Bug:
Bug 1488174
Problem: ALTER SYSTEM does not change the setting of NLS_LENGTH_SEMANTICS for the current and new (!) sessions.
Workaround: Don't use ALTER SYSTEM SET NLS_LENGTH_SEMANTICS scope=both; but set NLS_LENGTH_SEMANTICS as a init.ora parameter or issue ALTER SYSTEM SET NLS_LENGTH_SEMANTICS=CHAR scope=spfile; and bounce the database.Hope this help.
Best regards,
Jean-Valentin
Edited by: Lubiez Jean-Valentin on May 27, 2010 2:06 PM

ALTER SYSTEM SET processes=1000 generates ORA-00064: object is too large to

Hi All
I'm using Oracle Release 10.2.0.1.0.
When performing:
=============
ALTER SYSTEM SET processes=10000 SCOPE=SPFILE;
We can't start the 10g DB: ORA-00064: object is too large to allocate on this O/S (1,5282400)
When reducing the size to 150 there is no problem starting the db. I can not start it. ORA-00064: object is too large to allocate on this O/S (1,5282400)
I refered to ORA-00064: object is too large to allocate on this O/S :::Plz Help Me
But I can not resolve this problem.
Please help me.
thiensu

Not sure, because i haven't got ORA-00064 yet.
ORA-00064: object is too large to allocate on this O/S num, num
Cause: The initialization parameter DB_BLOCK_SIZE is set to a value that calls for more contiguous space than can be allocated on the operating system being used.
Action: Reduce the value of DB_BLOCK_SIZE so that the requested contiguous space is within the capacity of the operating system.
http://www.pitt.edu/~hoffman/oradoc/server.804/a58312/newch2a1.htm
Regards
Girish Sharma

Alter system scope=spfile not taking

This should have been brain-dead simple but something is happening I've never seen and don't understand.
Oracle SE 10.2.0.4 on Windows Serve 2003
I do an ALTER SYSTEM ... SCOPE=SPFILE, but when the database is restarted, values have reverted back.
SQL> show parameter spfile
NAME                                 TYPE        VALUE
spfile                               string      E:\ORACLE\PRODUCT\10.2.0\ROY\D
                                                 ATABASE\SPFILEROYDEV.ORA
SQL> show parameter control
NAME                                 TYPE        VALUE
control_file_record_keep_time        integer     7
control_files                        string      +SAN/roydev/controlfile/curren
                                                 t.261.686792331, +SAN/roydev/c
                                                 ontrolfile/current.260.6867923
                                                 31
SQL> --
SQL> alter system set control_files='x:\oradata\roydev\controlfile\control01.ctl','y:\oradata\roydev\controlfile\control02.ctl' scope=spfile;
System altered.
SQL> --
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 612368384 bytes
Fixed Size                  1298192 bytes
Variable Size             167772400 bytes
Database Buffers          440401920 bytes
Redo Buffers                2895872 bytes
Database mounted.
Database opened.
SQL> show parameter spfile
NAME                                 TYPE        VALUE
spfile                               string      E:\ORACLE\PRODUCT\10.2.0\ROY\D
                                                 ATABASE\SPFILEROYDEV.ORA
SQL> show parameter control
NAME                                 TYPE        VALUE
control_file_record_keep_time        integer     7
control_files                        string      +SAN/roydev/controlfile/curren
                                                 t.261.686792331, +SAN/roydev/c
                                                 ontrolfile/current.260.6867923
                                                 31
SQL> spool off

EdStevens wrote:
Girish Sharma wrote:
EdStevens wrote:
Ok, here's what I figured out (and I don't have any experience with Oracle Managed files either)...
The db was using the default spfile, to a point. When I did my ALTER SYSTEM, the timestamp on the default spfile was changing, and that was part of what threw me off. I finally created a pfile from the spfile, and that pfile reflected my changes, but also included a parameter -- spfile=+ASM/... yada, yada. Looking at the contents of the actual spfile (yes, I know it's a binary, but the parms themselves are clear text, so you can see what's going on .. just don't try to edit it). I saw exactly what was in the created pfile.
Next I renamed my newly created pfile, then did another CREATE PFILE FROM SPFILE, only this time specified the spfile name, pointing to the ASM based file. Sure enough, none of my changes were reflected in that file; further evidence that it was overriding. I did a sanity check on the two pfiles, merging a few things from the first into the one created from the ASM file, the created a new default spfile from that. After that life was good.
This was a first for me. Of course I've been at this long enough to have used pfiles before there were spfiles. I've seen pfiles that had a single line, 'SPFILE= ..' to point to some non-standard spfile. But I've never seen an spfile itself refer to yet another spfile.
Oh well. All's well that ends well, and I learned something new.Sorry Ed, but I am still not able to understand your solution because I am bit confused of below text specially :
only this time specified the spfile namewhat you specified here other than first one's pfile spfile=+ASM/...folder1/folder2 ?
Sure enough, none of my changes were reflected in that file; further evidence that it was overriding.completely failed to understand this line, what happened 2nd time that you did't got changes reflected; while you got in the first one pfile.
The more cause of my confusion may be poor and bad in English, but I know, I don't have poor wish of oracle learning, so I am asking for removing doubts please.
Regards
Girish SharmaOk, let me see if I can clarify.
When first approaching the database, I checked to see if it was using a pfile or spfile. A 'show parameter spfile' indicated it was using an spfile, and it was the default name in the default location (%ORACLE_HOME\database\spfile%ORACLE_SID%.ora).
Next I did a couple of ALTER SYSTEM SET .... SCOPE=SPFILE commands.
Next I bounced the database and rechecked the parameters I had set, and they were back to their original values.
After a couple of more iterations to make sure I wasn't doing something really stupid (after all, this should have been dead simple) I opened this thread, then continued to poke at it. So,
Next I created a default pfile from the default spfile - CREATE PFILE FROM SPFILE. This created %ORACLE_HOME%\database\init%ORACLE_SID%.ora.
On examining the resulting pfile, I saw my changes reflected in it, but also was surprised to see the parameter *.SPFILE=+ASM/...., so was including an addition spfile that was under ASM. (BTW, the entire purpose of this exercise was to migrate the database off of ASM.) At this point, as a sanity check I opened the default spfile - the one pointed to by the SHOW PARAMTER SPFILE command, the one in ORACLE_HOME\database. It did - as it should have - matched perfectly with the newly created pfile. So it was apparent that my ALTER SYSTEM changes were going to this default spfile but - unbeknownst to me at the outset - were being over-ridden by that second, ASM-based spfile.
At this point, I renamed the just-created pfile to something like initORCL.sav. Then created a new pfile from the ASM-based spfile - CREATE PFILE FROM SPFILE='+ASM\spfile.ora'. This new pfile was much more extensive than the first, and there were the parameters that were overriding the ones I was trying to change. I hand-modified this pfile, including some other things I found in the first, then created a new default spfile from it. So at this point I had the default spfile without it pulling in a second one that would override what I did.
Does that clarify?Yes, now its 100% clear to me.
Thank you.
Regards
Girish Sharma

Query on ALTER SYSTEM SET

Hi,
I was under impression that
"PFILE has the limitation to change the initialization parameters dynamically.If any init parameter is to be changed,we can edit the pfile and the parameter changes will come into effect with the next reboot of the system.
To overcome this limitation,Oracle has come up with the concept of SPFILE ,where in the initialization parameters can be changed dynamically using ALTER SYSTEM SET statement."
But,today I started my test database using PFILE and executed the following command to change the memory_target parameter from 300M to 290M.
ALTER SYSTEM SET memory_target=290M;
And to my surprise,this statement executed fine without any errors and memory_target parameter has been set to the new value(of course,in memory).
Isn't it changing the init parameters dynamically using PFILE itself??
Please clarify my doubt and correct my understanding.
Regards,
Bharath

bharathDBA wrote:
Hi,
I was under impression that
"PFILE has the limitation to change the initialization parameters dynamically.If any init parameter is to be changed,we can edit the pfile and the parameter changes will come into effect with the next reboot of the system.
To overcome this limitation,Oracle has come up with the concept of SPFILE ,where in the initialization parameters can be changed dynamically using ALTER SYSTEM SET statement."
But,today I started my test database using PFILE and executed the following command to change the memory_target parameter from 300M to 290M.
ALTER SYSTEM SET memory_target=290M;
And to my surprise,this statement executed fine without any errors and memory_target parameter has been set to the new value(of course,in memory).
Isn't it changing the init parameters dynamically using PFILE itself??
Please clarify my doubt and correct my understanding.
Regards,
Bharath
You have a wrong interpenetration about the genesis of the SPFILE. Yes it is a binary file and all that but remember, its not the SPFILE that makes a parameter dynamic or a PFILE that makes it static but it's the very nature of the parameter itself that makes it happen. Yes, the difference in the PFILE and SPFILE parameter would be evident when you would change a dynamic parameter and would give a bounce to the db. Since teh PFILE wasn't updated (its a text file so has to be updated manually) , with the next restart, the parameter would take the same value as it has in the PFILE. But with the SPFILE, depending on what you have set in the SCOPE, the parameter would behave accordingly.
HTH
Aman....

Alter system set control_files

when we use this command to multiplex the control files
should we list all the current controls files as well the copied once If yes ,should i performe alter database backup controlfile to trace command ?
Thanks in Advance

If you are working in Oracle8i you can not apply that exact command. That exact command is applicable from Oracle9i. I clarify: The comand ALTER SYSTEM SET ... exists prior to 9i but in 8i that parameter is not dinamic. In order to modify that parameter you have to do so:
1.- Realize what controlfiles you have
2.- Apply the command with the controlfiles that you have additioning the new controlfiles to duplicate. You have to apply this command with SCOPE=SPFILE;
3.- Shutdown the database
4.- Copy the controlfiles with OS
5.- Start the database
Joel Pérez
http://otn.oracle.com/experts

"ALTER SYSTEM SET"

Hi
When a parameter is changed using "ALTER SYSTEM SET parameter=X" without the clause SCOPE, where will that parameter be changed? In memory or in spfile?
Thanks

In the memory and once you bounc the database, the value which you sent is gone. If you need to keep permanently, use scope=spfile.
SJH
OCP DBA

Alter system set events Question

Version 10202 on AIX
sql> alter system set events '4030 trace name heapdump level 536870917; name errorstack level 3';
Questions about this statement..
what this command is doing, i guess creating tracefile for event 4030...& the location of trace file would be the current direcotry?
& how to setup same kind of event trace for other events, any tips....& what to check in tracefile for problem?

The values for level I have record are 1, 2, 3, 8, and 32 so I am guessing the number shown is the address of a specific heap to be dumped. The address of a heap would potentially change with a change in the shared pool storage parameters. Where did you get the address value?
The dump should go to the user background dump destination and not the current directory.
PS - if you have metalink look at document: #218105.1 Introduction to ORACLE Diagnostic EVENTS
HTH -- Mark D Powell --
Message was edited by: MDP add PS to Metalink Doc
mpowel01

"Alter system set command" in a RAC database!!

Hi, all.
The database is (10.2.0.2.0) 2- node RAC database on 32-bit windows 2003
EE SP1.
I issued the following command on Node 1 database.
--> Alter system set db_block_buffers= xxx sid='rac1';
I was able to see "PE enqueue" in top 5 wait event section from an AWR report.
In addition, I was able to find "PZ99","PZ98" process dump file in BDUMP.
Soon later, I could find CKPT and DBWR hung.
Is there anyone who experienced this issue?
Thanks and Regards.
Message was edited by:
user507290

10.2.0.2 has some bug which is fixed 10.2.0.3
You check sequence cache. If it has less value, increase it to 10000.
select CACHE_SIZE from dba_sequences where SEQUENCE_OWNER='SYS' and SEQUENCE_NAME='AUDSES$';
SQL> alter sequence sys.audses$ cache 10000;
Ashok

Alter system set shared_pool_size extremely slow.

I am trying to increase my shared_pool_size from 60m to 200m by simply typing alter system set shared_pool_size=200m;
I did alter system flush shared_pool; before to clear out the current shared_pool.
I'm on 9i and my SGA_MAX_SIZE is 3g and I have plenty room to grow.
show sga
Total System Global Area 3222769016 bytes
Fixed Size 744824 bytes
Variable Size 2382364672 bytes
Database Buffers 838860800 bytes
Redo Buffers 798720 bytes
My event in v$session_wait is background parameter adjustment.
Any help would be appreciated. I know that I can bounce the server and let it read it from the init.ora. However, I'm trying to fix some current 4031s in my shared pool. The flush did fix them temporarily.

Are you sure your instance was in the state you thought it was ? This is what you reported from show sga:
Total System Global Area 3222769016 bytes
Fixed Size                    744824 bytes
Variable Size             2382364672 bytes
Database Buffers           838860800 bytes
Redo Buffers                  798720 bytesYou say your shared_pool_size is 60M and you want to grow it to 200M, but the Variable Size in the output above suggests that your shared pool had already grown to about 2.3 GB, so your command would have been trying to shrink it quite dramatically. (And 9i isn't very good at shrinking the shared pool because of the problems of pinned and "KEEP"ed objects in the library cache.
Things to check (from another session):
v$sga_current_resize_ops to see if your resize operation is still running, and what it's trying to do.
v$sga_resize_ops to see i f your resize operation completed some time ago - leaving your session stuck somewhere else. (There's a convenient query I wrote against this view published here: http://jonathanlewis.wordpress.com/2007/04/16/sga-resizing/ )
v$session_wait (for the resize session) to see if the session is waiting or working
v$sesstat (for the resize session) to see if it gives you any clues about current activity
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Alter system set db_2k_cache_size=10m

Hi All,
I am using 11gR2 and try to create db_2k_cache_size when the execute the below command throwing error like..
alter system set db_2k_cache_size=10m
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00384: Insufficient memory to grow cache
Could you please let me know what is the cause of the issue?
Regards
Narender B

Can anyone help on this...
Regards
Narender B

Alter system set events '1460 trace name errorstack off';

Hi,
if I issue :
alter system set events '1460 trace name errorstack off';
Is there any query that can make me sur and help me to see the value of events '1460' ?
Thank you.

Is there any query that can make me sur and help me to see the value of events '1460' ?No one, because you turned off the trace level.
Nicolas.

ALTER SYSTEM SET SGA_TARGET = 0 scope=spfile; not working

Similar Messages

Maybe you are looking for