Temp tablespace filling up

Hi,
The temp tablespace on our DB has suddenly started filling up.
There is 4gb ram on the server, roughly 1.3G is used by the OS,
, 1.7 bg the sga and 700mb by PGA target parameter.
We are using ASM, so the sort_area_size parameter does not come into play.
All the ratios are fine, but once the temp tablespace is nearly full, things grind to a halt.
Has anyone got any hints about best way forward.
I have set statspack to run on the hour.
I appreciate ram is low, but I am confused as to why this has suddenly started to happen.
Thanks for reading.

cleme1a wrote:
Hi,
The temp tablespace on our DB has suddenly started filling up.
There is 4gb ram on the server, roughly 1.3G is used by the OS,
, 1.7 bg the sga and 700mb by PGA target parameter.
We are using ASM, so the sort_area_size parameter does not come into play.
All the ratios are fine, but once the temp tablespace is nearly full, things grind to a halt.Ratios are mythical indicators of performance.
do as below so we can know complete Oracle version & OS name.
Post via COPY & PASTE complete results of the following:
sqlplus <username>/<password>
SELECT * from v$version;
exit

Similar Messages

TEMP tablespace fills up quickly

Hi All,
I know this is a very classic question.
In my client, we run annual reports during 1-2 days a year and the TEMP tablespace gets filled up very quickly.
What is the best practice of managing the TEMP tablespace size in a very busy database. (Oracle Applications is running)
Thanks,
Sinan Topuz

A temporary tablespace contains transient data that persists only for the duration of the session. Temporary tablespaces can improve the concurrency of multiple sort operations, reduce their overhead, and avoid Oracle Database space management operations. A temporary tablespace can be assigned to users with the CREATE USER or ALTER USER statement and can be shared by multiple users.
Within a temporary tablespace, all sort operations for a given instance and tablespace share a single sort segment. Sort segments exist for every instance that performs sort operations within a given tablespace. The sort segment is created by the first statement that uses a temporary tablespace for sorting, after startup, and is released only at shutdown. An extent cannot be shared by multiple transactions.
You can view the allocation and deallocation of space in a temporary tablespace sort segment using the V$SORT_SEGMENT view. The V$TEMPSEG_USAGE view identifies the current sort users in those segments.
You cannot explicitly create objects in a temporary tablespace.
Please note all this point.

One Temp Tablespace vs 2 Temp Tablespaces in a Group

I run a massive group by that generally takes up about 325GB of temp and on the system that it works on I have 1 tablespace this size that it works on, but I'm building a new system that has my Temp tablespaces on much faster disks, but I was trying to utilize 2 temporary tablespaces to get some parallelism accomplished, so I have 2 196GB tablespaces, but one of them fills up before the other one does...is their anyway to regulate what temp tablespace is used..should these 2 equally distribute the load when one fills up? My query just keeps blowing up when it runs out of the one temp tablespace. Any help is appreciated.

I run a massive group by that generally takes up about 325GB of temp and on the system that it works on I have 1 tablespace this size that it works on, but I'm building a new system that has my Temp tablespaces on much faster disks, but I was trying to utilize 2 temporary tablespaces to get some parallelism accomplished, so I have 2 196GB tablespaces, but one of them fills up before the other one does...is their anyway to regulate what temp tablespace is used..should these 2 equally distribute the load when one fills up? My query just keeps blowing up when it runs out of the one temp tablespace. Any help is appreciated.

ORA-01652 in TEMP Tablespace

Hi,
We have the following errors:
RMAN> crosscheck archivelog all;
starting full resync of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 01/07/2009 14:26:10
RMAN-03014: implicit resync of recovery catalog failed
RMAN-03009: failure of full resync command on default channel at 01/07/2009 14:26:10
ORA-01652: unable to extend temp segment by in tablespace
RMAN>
We have tried to increase the size of the TEMP tablespace, but this operation keeps using up the entire temp tablespace. It's the temp tablespace in the target database that is filling up.
We cannot keep increasing the size of the TEMP ts to fill the disk.
We have also tried to create a new repository but this had the same outcome.
I reckon there is something in the database tables, as one of our backups used the target control file as its repository. Should I remove the entries from these tables in the target tablespace to make the repository think there is no re-synching to be done?
Regards,
Tim.

If you are sure that it is on the target DB what you can do is enable a trace for the event to see what triggers this error
it doesnt have to be on temporary table because there are temp segments on normal tables used for index creation type operations as well so you need to find the problem before assuming it is temp tablespace error
alter system set events '1652 trace name errorstack level 1';
to turn off
alter system set events '1652 trace name context off';
If you cant find anything from trace then you can send the trace output here maybe somebody can catch something.
Coskan Gundogar
http://coskan.wordpress.com
Edited by: coskan on Mar 30, 2009 4:28 PM

TEMP Tablespace Groups

In Datawarehouse environment, Database verion 10gR2:
Created two temp tablespaces TEMP1 and TEMP2 with 10GB each in a temp tablespace group(TEMP_GROUP) and assigned the TEMP_GROUP as default temporary tablespace to user "BATCH", expecting the batch user can use 20GB of temp tablespace.
When a process needs a temp tablespace of more than 10GB, the process fails with an error unable to extend temp tablespace. It is not utilizing the other 10GB TEMP tablespace.
When I assign a dedicated TEMP tablespace TEMP3 with 15GB as the default temp tablespace, the process succeeds.
It looks like when a session starts it assigns one TEMP tablespace(from group), if that fills up it is not taking advantage of the other TEMP tablespace in the group, which makes me think that Groups are not helping here.
Is there an other way around to utilize multiple temp tablespaces for a single user.
Can we expect an improvement of this feature in the future releases or is that not a possible scenario?

-- Using a tablespace group, rather than a single temporary tablespace, can alleviate problems caused where one tablespace is inadequate to hold the results of a sort, particularly on a table that has many partitions. A tablespace group enables parallel execution servers in a single parallel operation to use multiple temporary tablespaces.
CREATE TEMPORARY TABLESPACE TEMP2 TEMPFILE '/u10/oracle/oradata/dbt1/datafile/temp02.dbf'
SIZE 20M
TABLESPACE GROUP tempgroup1;
CREATE TEMPORARY TABLESPACE TEMP3 TEMPFILE '/u10/oracle/oradata/dbt1/datafile/temp03.dbf'
SIZE 20M
TABLESPACE GROUP tempgroup2;
ALTER TABLESPACE temp TABLESPACE GROUP tempgroup1;
select * from v$tempfile ;
select * from dba_tablespace_groups ;
alter user ABCD temporary tablespace tempgroup1 ;
-- Verify that temp group is assigned to user
select * from dba_users where username='ABCD' ;
After you assign the group to the user abcd then retry your operation as abcd user.
This time it will use both the temporary tablespaces for sort operations.
Thanks
GC

Temp Tablespace space needed to create an index of 52GB - preventing 01652

Hi,
I've seen quiet a few threads on the subject, but could not find a clear (to me) answer on the subject.
We have a huge table made by 30/40 partitions of roughly 20M records each (each record being about 1k of size), overall 800GB.
The index we already have shows:
1* select sum(bytes/1024/1024) from dba_segments where segment_name like 'CALL_LOG_I0'
SQL> /
SUM(BYTES/1024/1024)
52088
so that I assume it's 52GB in size. Since we have to create another very similar one I would assume the size would be similar.
Command would be:
create index call_log_i0_new on call_log (msisdn, generation_timestamp, cdr_reference_number, Multiple_AMA_Sequence_Number) NOLOGGING online;
Tried the NOSORT option but it's not compatible with the online option.
After a while the TEMP tablespace got filled up (we have about 20GB space in there).
My question is if I need to have a temp tablespace at least as big as the index size (52GB) to let the index be built online.
Thanks in advance !
Cheers,
Mike

Thanks to all, found useful information in Metalink following your suggestions:
You need to add more space to the tablespace where the index is created.
A possible option to reduce sort space usage is to use the NOSORT option.
Your table contains 66 million rows. The average row length is
50-60 bytes and you are indexing 4 of 5 columns in the table.
Example space calculation:
66 million rows * 50 (avg row length) = 3.3 gig of data
Rule of thumb:
upper bound for sort (not guaranteed) is 3 times data_
= about 10 gig of sort space needed
These numbers are scaring since assume that I may need much more space than the index size (about 3x) which is something we cannot afford. Will go with the NOSORT option once the system is brought down and we could skip the online option.
Thanks to all !
Mike

Oracle DB : UNDO tablespace filled 99%

Hi,
That's not a problem (I hope) but just a question on Livecycle ES DataBase.
The Undo tablespace set to 4Gb, always filled 99%.
Is it normal ? is there preconized size for it ? Does we have to maintain it ...
The LiveCycle configuration is :
ES (1) version 8.2.1 SP3, Jboss
Oracle 10g
The server is running on Windows Server 2003 Ent OS.
Thank you for your response !

It very much depends on the tool used to determine the usage of the UNDO tablespace. Many tools do not take into account that the UNDO tablespace and the TEMP tablespace may seem to be full (have correctly formatted blocks) while still having a lot of functional space available inside of those blocks.
In other words, if the tool calculates the usage in the same way as data tablespaces, it will be reporting the wrong value. Ideally, the UNDO tablespace will always be close to 100% full using traditional calculation.
Assuming the tool is doing it's calculation correctly, the second thing to note is that UNDO is the core to Oracle Consistent Read mechanism. (Which is, in turn, the core to many of the Flashback techniques.) The UNDO data, which is created at transaction time, must be available after the transaction has committed if a consistent read or flashback is invoked. The more UNDO, the further back in 'time' you can flash back.
So the correct way to tune the UNDO is to specify the amount of time you require UNDO to exist. And you verify that using the DBA_UNDO_EXTENTS view and the STATUS column. Totally free space in the undo occurs when the STATUS is EXPIRED. If you have no EXPIRED extents, they can not be reused (except in a pinch) and the system will allocate more space to the UNDO tablespace if possible.
A great reference is the thread at http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6894817116500
I am curious - is 4GB UNDO really an issue?

TEMP TS Filling Up

Hi,
The TEMP tablespace is already enormous - 120GB, but it still fills up too quickly...
Can anyone suggest what to do to prevent this from happening?
Thanks,
P.S. 10.2.3, RH Linux.

You should use V$SORT_USAGE, but either way, if it doesn't report anything, it means there are no curent sessions performing sorting operations.
USERNAME, USER, SESSION_ADDR, SESSION_NUM are the columns used to identify the sorting session.
You can use V$SORT_SEGMENT to identify the sort segment currently allocated at your temporary tablespace, but it is not that important at this time, it only states that your temporary tablespace hosts a temporary segment, which is not currently in use, as you can see from the previous query.
Temporary tablespaces will keep on growing and they look like they are filled at nearly 100%, it looks like it will never release the space, but it is a normal behavior, temporary tablespaces simply don't release space once they allocate it assuming the same space will be required to be re-allocated in the future, it is just a performance issue, it'll be easier for the temporary space to have preallocated the space instead of reallocating it.
It is important to verify the temporary space usage, as I previously stated in my first post in the thread. If you just want to manually release the space, just drop/create the temporary tablespace to a size that fits your requirements, but bear in mind that if the tablespace grew that high, it will probably do it again in the future if sorting space is required to meet the sorting requirements.
~ Madrid

Cleaning up temp tablespace with out restarting Oracle instance.

Hi,
I've a scenario where my temp tablespace gets filled up and i rarely restart my Oracle instance.
My temp tablespace is not auto-incremental and the Oracle version i have is 9.2.4
Appreciate if any one can provide the answers/suggestions?
Thanks.

Thanks for the reply...
I gone through the thread on Jeff Hunter where he is altering by making the temp table space to auto increment.
But my tablespace an i can't change my tablespace to autoincrement since it is in continous use 24x7 and 365 days.
Any ideas please?
Thanks

Creating a Global Temporary Table on non-default TEMP tablespace.

Hello ,
I am using Oracle 11g.
I have a procedure which create global temporary tables for its functionality. As the data which is going in the global temporary table , mean the data which is going in the default TEMP tablesapce is too huge ..... billions of rows..
So what i want to do is , I want to create the global temporary table in another TEMP2 tablespace ( which is not the default one) so the load of billions of rows of data will be shifted to TEMP2. The default TEMP tablespace will not be affected and it can be used for other transactions.
Is this possible. Can i shift the global temporary table from TEMP( Default temp tablespace) to TEMP2 ( the non-default temp tablespace) ????
Please guide me with proper solutions and examples ....
Thanks in advance ..

DBA4 wrote:
Hello ,
I am using Oracle 11g.
I have a procedure which create global temporary tables for its functionality. As the data which is going in the global temporary table , mean the data which is going in the default TEMP tablesapce is too huge ..... billions of rows..
So what i want to do is , I want to create the global temporary table in another TEMP2 tablespace ( which is not the default one) so the load of billions of rows of data will be shifted to TEMP2. The default TEMP tablespace will not be affected and it can be used for other transactions.
Is this possible. Can i shift the global temporary table from TEMP( Default temp tablespace) to TEMP2 ( the non-default temp tablespace) ????
Global temporary tables are instantiated in the temporary tablespace of the schema that inserts the data - not into "the default" temporary tablespace.
Assume Schema1 creates a GTT and grants all on that table to schema2
Assume schema1 also creates a procedure (authid owner, the default) to insert data into the GTT and grants execute on the procedure to schema2
If schema2 executes: insert into schema1.gtt, the data will appear in the temporary tablespace of schema2
If schema2 executes: execute schema1.procedure, the data will appear in the temporary tablespace of schema1
So if you want to protect the "normal" temporary tablespace, you could just create a special temporary tablespace for the owner of the procedure.
Regards
Jonathan Lewis

TEMP tablespace getting full while inserting a CLOB in Trigger

We have a Oracle 10g (10.2.0.4.0) DB on a Solaris 9 box which also runs our J2EE web-service application on Weblogic 8sp6 server.
We get around 220K web-service requests from upstream callers daily to insert data in the main table, say TABLE1, which has daily partitions on a date column. This table has around 21 columns out of which 1 is a CLOB column.
Now this table has an AFTER INSERT trigger which calls a package procedure to insert the same record into another table, say TABLE2.
From Java application insert statement in executed in below format using a weblogic jdbc connection pool :
INSERT INTO TABLE1(COLUMN1, COLUMN2, ........., CLOB_COLUMN,........, COLUMN21) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20);
Clob object is prepared in application using ojdbc14.jar.
We are observing a strange issue here. The TEMP tablespace utilization keeps on growing as more and more inserts are executed by application and after ~125K inserts the TEMP tablespace gets full and we start getting ORA-01652 error.
On further analysis we could see that there are only 7-10 session being maintained but as more and more inserts happen TEMP tablespace utilization goes on increasing for each of these sessions.
When we tried with inserting just few records and then watching the session details in v$session_wait then we could see that it is in INACTIVE state and waiting for the event ‘SQL*Net message from client’. This does not seem correct as the session has successfully inserted the data and committed the transaction and we can see the data in the tables as well.
The confusing thing here is when we modify the trigger to pass blank string('' ) instead of the CLOB column to TABLE2 then this issue does not occur. All 200K records are inserted properly and TEMP tablespace utilization also keep always below 1%.
Can you please help us in solving this issue. Is this related to any oracle issue?
Inside the package we have tried using DBMS_COPY statement to copy the CLOB column after insert but still same result.
Code for reference:
Trigger:
=====================================
CREATE OR REPLACE TRIGGER trg
AFTER INSERT OR UPDATE
ON TABLE1
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF (:NEW.date_col > SYSDATE - 2)
THEN
IF (:NEW.cat IN (1001, 1002))
THEN
pkg.process_change
     (:NEW.COLUMN1,
          :NEW.COLUMN2,
          :NEW.CLOB_COLUMN,
FLAG
END IF;
END IF;
END;
=====================================
Package:
=====================================
procedure PKG.Process_change(
p_COLUMN1 number,
p_COLUMN2 varchar2,
p_CLOB_COLUMN clob,
flag boolean
) is
v_watermark pls_integer;
v_type varchar2(1);
begin
if (flag) then
v_type := 'U';
else
v_type := 'I';
end if;
select t_seq.nextval into v_watermark from dual;
insert into TABLE2(
COLUMN1 number,
COLUMN2 varchar2,
CLOB_COLUMN clob,
watermark,
dml_type
)values (
p_COLUMN1 number,
p_COLUMN2 varchar2,
p_CLOB_COLUMN clob,
v_watermark,
v_dml_type
end;
=====================================

My first thought on reading your post is that not only are you using a database version that is now so old it is in extended support and even then not even the most recent patchset for it.
The first thing I would do is move to 11gR2 and if you can't do that at least get to 10.2.0.5 and apply CLOB relevant patches as well.
Same goes for your operating system. Solaris 9 is ancient: So move to 10 which has vastly improved memory management.
To help you further it would be really valuable to know the table layout. For example is this a heap table or an IOT? Is it partitioned? Is this RAC? What size are the CLOBs? Are they stored in-line? Chunk size? etc.
This page should start you down the right road:
http://docs.oracle.com/cd/B19306_01/appdev.102/b14249/adlob_tables.htm#sthref204
But I am also wondering why you would use a trigger to, as you say, "insert the same record into another table." This description is a poster child for "bad design."

How to create temp files in temp tablespace

Dear all,
Due to outage of our SAN, we our out of production for the
last 3 days. By the grace of Almighty we have restored production by
database recovery from our standby backup. Since temp tablespace and
temp data files do not taken as backup for standby, now after recovery
we are getting abap dumps asking for temp_1 and temp_2 datafiles.
Please guide us how to create temp files. v$tablespace is showing tablespace PSAPTEMP but datafile are not there
Abap dumps are giving these errors as mentioned below
====================================================
The exception must either be prevented, caught within the procedure
"DATA_SELECTION"
"(FORM)", or declared in the procedure's RAISING clause.
To prevent the exception, note the following:
Database error text........: "ORA-01157: cannot identify/lock data file 256 -
see DBWR trace file#ORA-01110: data file 256:
'/oracle/SD1/sapdata4/temp_2/temp.data2'"
Internal call code.........: "[RSQL/FTCH/MARA ]"
===================================================
another one asking for
'/oracle/SD1/sapdata3/temp_1/temp.data1'"
Best Regards
Waqas

if you want to add a new tempfile to your TEMP Tablespace,you can do like that.
ALTER TABLESPACE <name of TEMP Tablespace> ADD TEMPFILE <pfad to the file_and_file name> SIZE <size>;
You can use also the options REUSE autoextend off or on .
e.g:
alter tablespace PSAPTEMP add tempfile '/oracle/SD1/sapdata4/temp_2/temp.data2' SIZE 1000K REUSE;
The directory temp_2 should exist.
Or you can use the BR*Tools to create a new datafile. Enter brtools and follow the instructions or menu.
More to TEMP Tablespaces see please following SAP notes:
659946 - FAQ: Temporary tablespaces
600513 - ORA-25153 after recovery due to missing tempfiles
and the Oracle Note:
160426.1: TEMPORARY Tablespaces : Tempfiles or Datafiles ?
I hope it helps.

Should I increase TEMP tablespace size here ?

Version: 10.2.0.4
Platform : RHEL 5.8
Currently we are running a batch job in a schema. The default temporary tablespace for that schema is TEMP.
But I see that the tablespace is full.
SQL> select file_name, bytes/1024/1024/1024 gb from dba_temp_files where tablespace_name = 'TEMP';
FILE_NAME                                                                 GB
/prd/fdms/oradata_db18/fdmsc1sdb/oradata/ts_temp/temp01.dbf               10
SQL> SELECT     TABLESPACE_NAME, FILE_ID,
        BYTES_USED/1024/1024,
        bytes_free/1024/1024
FROM V$TEMP_SPACE_HEADER where tablespace_name = 'TEMP' 2    3    4 ;
TABLESPACE_NAME                             FILE_ID BYTES_USED/1024/1024 BYTES_FREE/1024/1024
TEMP                                              1                10240
So, far the application users have not complained and I didn't see any 'unable to extend' error in the alert log yet, but the above scenario is dangerous. Right? I mean SQL statements with sorting can error out. Right ? Unlike UNDO, with temp tablespace, temp segments cannot be reused. Right ?

Hello,
As said previously, the Sort Segments can be reused, the Views V$SORT_SEGMENT and V$TEMPSEG_USAGE are relevant to monitore the usage of the Temporary Tablespace.
You'll find in the Note below a way to control over time the Temporary Tablespace:
How Can Temporary Segment Usage Be Monitored Over Time? [ID 364417.1]
More over, you may also check for any ORA-01652 in the Alert Log.
But don't worry to much to get a Full Temporary Tablespace, here "Full" doesn't mean "unreusable".
Hope this help.
Best Regards,
Jean-Valentin Lubiez

Restored coldbackup and having trouble with TEMP tablespace

Hi, i succesfully restored from a coldbackup on solaris.(oracle 9.2)
i can log on to database using toad, query the database, but when i try to take an export or something i got the error
EXP-00056: ORACLE error 1157 encountered
ORA-01157: cannot identify/lock data file 203 - see DBWR trace file
ORA-01110: data file 203: '/sun2int1/oracle92/app/oracle/product/9.2.1/oradata/TPRS/temp03.dbf'
ORA-06512: at "SYS.DBMS_LOB", line 424
ORA-06512: at "SYS.DBMS_METADATA", line 1140
ORA-06512: at line 1
EXP-00000: Export terminated unsuccessfully
when i did the restore, i simply renamed the datafiles and redo logs.
But i didnt rename the TEMP datafile, as you can not rename it with a "alter database rename file ..." command
so thats the problem!
i planned to create a new default temp. tablespace, and simply make it default and drop the other one. but it does not work!
i tried to execute:
CREATE TEMPORARY TABLESPACE temp4 TEMPFILE '/oracleAS/TPRS/oradata/TPRS/temp4.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1M MAXSIZE unlimited
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
create temporary tablespace temp01 tempfile '/oracleAS/TPRS/oradata/TPRS/temp01.dbf' size 100M;
but they all hang! i wait, but nothing happens! (and alert log does not log anything too)
and finally i tried to drop the default tablespace, and i couldnt drop it as i thought. (ORA-12906: cannot drop default temporary tablespace
So, im stuck and i beleive i have to RENAME the datafile for temporary tablespace. how can i do this?
Edited by: merope on Jun 9, 2009 11:32 AM

SQL> col file_name for a50
col status for a15
col tablespace_name for a15
col PROPERTY_VALUE for a20
select file_name,tablespace_name,bytes/1024/1024 as "SIZE_IN_MB",status,autoextensible from dba_temp_files;
SELECT PROPERTY_NAME,PROPERTY_VALUE FROM DATABASE_PROPERTIES where PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE';
SQL> SQL> SQL> SQL> SQL> SQL> ERROR:
ORA-01157: cannot identify/lock data file 202 - see DBWR trace file
ORA-01110: data file 202: '/izmir1/oradbTPRS/temp1.db'
no rows selected
SQL>
PROPERTY_NAME PROPERTY_VALUE
DEFAULT_TEMP_TABLESPACE TEMP3
This is not the actual directory: /izmir1/oradbTPRS/temp1.db
it is the old location, but in the restored db, the temp1.db file is in some other directory
how can i rename this?
Edited by: merope on Jun 9, 2009 11:50 AM

9i on Linux. Problems with Temp tablespace cleanup

I am currently running Oracle 9i Enterprise on SUSE Linux 7.2.
I am executing queries against the new XMLType datatype and every query adds to the Temp tablespace, which doesn't get cleaned up. Eventually, the tablespace will run out of space and Oracle will issue and error:
ORA-01652: unable to extend temp segment by 128 in tablespace <name>
The only way to clean up the Temp tablespace seems to be by restarting the server.
Is that happening on other platforms as well? I would appreciate any help.

Hi
You can connect to the database as DBA (Sys or System) and make a bigger temporal tablespace. Or create a new bigger temporary tablespace and assign it to the user.
A10!
PS: Temporary tablespace is used when no memory available for the session, for example when a big ORDER BY is done. Try to increase the memory assigned, just look at initXXX.ora (sort_size)

Temp tablespace filling up

Similar Messages

Maybe you are looking for