Flashback Query ORA-01555

Gurus,
I'm receiving an ora-01555 error when attempting to run a flashback query. How can I get this resolve as I need to recover records that were deleted!
SQL> show parameter undo
NAME TYPE
VALUE
undo_management string
AUTO
undo_retention integer
604800
undo_tablespace string
UNDOTBS1
Undo Tablespace is 6GB!
select count(*) from bld as of timestamp (sysdate-5);
ORA-01555: snapshot too old: rollback segment number 19 with name "_SYSSMU19_1281712960$" too small
01555. 00000 - "snapshot too old: rollback segment number %s with name \"%s\" too small"
*Cause: rollback records needed by a reader for consistent read are
overwritten by other writers
*Action: If in Automatic Undo Management mode, increase undo_retention
setting. Otherwise, use larger rollback segments
All help is greatly appreciated.

Based on what you have posted you are toast. The data you are trying to read is no longer in the undo tablespace and therefore is unavailable to you.
Why you might ask? I suspect you would find great value in reading the most current issue of Oracle magazine: Especially Tom Kyte's article where he specifically addresses this issue.
SQL> select 604800/86400 from dual;
604800/86400
7Your undo retention exceeds 5 days ... thus all you have accomplished is to waste disk space.

Similar Messages

ORA-01555 in flashback

Hello to all
My database has bigfile undo tablespace that is autoextended and is retention guarantee
and my disk has enough space
undo_retention is equal 1800 when I execute
select *
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss');
I recieve ora-30052 error when i increase undo_retention to 172800 the query
executes fine
but while undo_retention=172800 I execute
select count(*)
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss');
I recieve ORA-01555 error, even I set undo_retention=2147483648 I recieve that error too
I expect since the undo tablespace is autoextended and retention quarantee, it increased and I don't
recieve ORA-01555 but it don't happened
do you know what is problem?
thanks
Edited by: ARKH on Nov 9, 2008 3:12 AM

Hi
response to Aman
Undo_retention is equal 172800 it's 48 hour my table has just 350163 record and that query is simple
I expect that query complete in very short time
don't oracle adjust Undo_retention when undo tablespace is autoextended
and in alert i found it :
Sun Nov 9 14:16:47 2008
ORA-01555 caused by SQL statement below (SQL ID: b2gr2cx5acptt, Query Duration=0 sec, SCN: 0x0000.0e3e3068):
Sun Nov 9 14:16:47 2008
select count(*)
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss')
Sun Nov 9 14:17:52 2008
ALTER SYSTEM SET undo_retention=8388608 SCOPE=BOTH;
Sun Nov 9 14:18:18 2008
Thread 1 advanced to log sequence 406
Current log# 3 seq# 406 mem# 0: /u01/app/oracle/oradata/tehrep/redo03.log
Sun Nov 9 14:21:31 2008
ALTER SYSTEM SET undo_retention=2147483647 SCOPE=BOTH;
Sun Nov 9 14:21:38 2008
ORA-01555 caused by SQL statement below (SQL ID: b2gr2cx5acptt, Query Duration=2 sec, SCN: 0x0000.0e3e3068):
Sun Nov 9 14:21:38 2008
select count(*)
from mdb.trde VERSIONS BETWEEN TIMESTAMP
to_timestamp('08/11/2008 22:01:00','dd/mm/yyyy hh24:mi:ss') and
to_timestamp('08/11/2008 22:02:00','dd/mm/yyyy hh24:mi:ss')
Sun Nov 9 14:27:43 2008
ORA-01555 caused by SQL statement below (SQL ID: 56fdpt2h9nn33, Query Duration=0 sec, SCN: 0x0000.0e3dc5d9):
Sun Nov 9 14:27:43 2008
select count(*)
from mdb.trde AS OF TIMESTAMP to_timestamp('08/11/2008 21:00:00','dd/mm/yyyy hh24:mi:ss')
Sun Nov 9 14:37:49 2008
Read of flashback database logfile 152, block 1958 found corrupted data.
See trace file for more information.
Reread of flashback database logfile 152, block 1958 found valid data.
Sun Nov 9 14:49:42 2008
Starting background process EMN0
EMN0 started with pid=22, OS id=7975
Sun Nov 9 14:49:46 2008
Shutting down instance: further logons disabled
Sun Nov 9 14:49:50 2008
Stopping background process QMNC
Sun Nov 9 14:49:50 2008
Stopping background process CJQ0
Sun Nov 9 14:49:52 2008
Stopping background process MMNL
Sun Nov 9 14:49:53 2008

ORA-01555 Snapshot too old, rollback segment too small after flashback tab

Hello
Further to an update on a table in database, I realize that I have done an error and I want to come back in the state of table before this operation.
For this I use 'Flashback table' as this command :
flashback table 'table_name' to timestamp to_timestamp('2010-11-08 08:00:00 AM','YYYY-MM-DD HH:MI:SS PM')
and I get this error :
ORA-01555 :Snapshot Too Old rollback segment N° x , "_SYSSMU9$", too small
What I can do to not have this problem ? can I avoid it ?
Please helps .
Regards
Edited by: 794982 on 12 nov. 2010 05:05
Edited by: 794982 on 12 nov. 2010 05:05
Edited by: 794982 on 12 nov. 2010 05:06

To set the undo retention period:
Do one of the following:
• Set UNDO_RETENTION in the initialization parameter file.
UNDO_RETENTION = 1800
• Change UNDO_RETENTION at any time using the ALTER SYSTEM statement:
ALTER SYSTEM SET UNDO_RETENTION = 2400;
The effect of an UNDO_RETENTION parameter change is immediate, but it can only be honored if the current undo tablespace has enough space.
For more reference.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm

Select query giving ora-01555. Need help with tuning

Hi,
Following query of mine fails with ORA-01555:
select xx from a where a.xx NOT IN (select xx from b where status=0)
Tables a & b have million rows approx. How can I tune the query (to remove "NOT IN").
The explain plan is:
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=705828732 Card=55061 Bytes=3468843)
1 0 FILTER
2 1 TABLE ACCESS (FULL) OF 'A' (Cost=1773 Card=55061 Bytes=3468843)
3 1 PARTITION RANGE (ITERATOR)
4 3 PARTITION LIST (ALL)
5 4 TABLE ACCESS (FULL) OF 'B' (Cost=12819 Card=45553 Bytes=2596521)
Thanks,
Prachi

You could try:
select xx from a
minus
select xx from b
where status = 0;But it's not likely to be any better and it won't solve your ora-1555.
The problem is not your select statement but some other process that is updating the rows you need and overwriting rollback segments.
Do you have a large update process that is committing in a cursor for loop?

[9.2.0.4.0] ORA-01555, how to get full text query?

Hi all,
my db version is 9.2.0.4.0.
In alert log i found somehing like:
ORA-01555 caused by SQL statement below (Query Duration=3429 sec, SCN: 0x0657.4e6b7e0c):
Wed Jan 16 17:33:43 2008
SELECT
      T1.CONFLICT_ID,
      T1.LAST_UPD,
      T1.CREATED,How can I get the full query?
thanks a lot
aldo

If you can get the sql_id then use below query to find full text.
SELECT
SUBSTR(SQL_TEXT, 1 + (i - 1) * 80, 80) SQL_TEXT
FROM
DBA_HIST_SQLTEXT HST,
(SELECT ROWNUM I FROM DBA_HIST_SQLTEXT WHERE ROWNUM <=
60)
WHERE
HST.SQL_ID = '&SQL_ID'
Rergards
Jafar

Help to produce an ora-01555 error.

Hello all,
I've been gotten wind of about UNDO management, but I'm not able to reproduce an ora-01555. I tried one way that I found in some metalink notes but I didn't succeed. I know that using some PL/SQL statements I get there, but how can I achieve it?
I appreciate your help.
Thanks in advance,
Regards,
Emerson

Easy to reproduce. Just use flashback query to an SCN that has aged out of undo.
E.g
SQL> select object_id from test as of scn 5936742 where object_id = 20;
select object_id from test as of scn 5936742 where object_id = 20
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 6 with name
"_SYSSMU6_2443381498$" too smallAnother option is to reduce undo retention, shrink the undo tablespace and turn off autoextend. Then in one session run a long select, and in another session run a loop with an update and a commit.
E.g
begin
for i in 1..10000 loop
update test set object_id = object_id where object_id = 20;
commit;
end loop;
end;
/

Error in Flashback Query

while trying to execute flashback query i am getting an error
CREATE TABLE flashback_query_test (
id NUMBER(10)
desc flashback_query_test
SELECT current_scn, TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') FROM v$database;
INSERT INTO flashback_query_test (id) VALUES (1)
COMMIT;
SELECT COUNT(*) FROM flashback_query_test
SQL> SELECT COUNT(*)
2 FROM
3 flashback_query_test
4 AS OF
5 TIMESTAMP TO_TIMESTAMP('2010-02-01 16:58:43', 'YYYY-MM-DD HH24:MI:SS');
flashback_query_test
ERROR at line 3:
ORA-01466: unable to read data - table definition has changed
pls help me out!................

The SCN to TIMESTAMP conversion only has a granularity of approximately 3 seconds if I remember correctly. So my guess is that you are getting this error because you are trying to flashback to the same time that the table was created putting you in that 3 second window of SCN to TIMESTAMP ambiguity.
You can see this ambiguity by using the SCN_TO_TIMESTAMP or TIMESTAMP_TO_SCN functions as shown below:
SQL> COLUMN TSTAMP NEW_VALUE T;
SQL> SELECT CURRENT_SCN, TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD HH24:MI:SS') AS TSTAMP FROM V$DATABASE;
         CURRENT_SCN TSTAMP
       9080346377361 2010-02-01 07:13:12
SQL> SELECT TIMESTAMP_TO_SCN(TO_TIMESTAMP('&T','YYYY-MM-DD HH24:MI:SS')) FROM DUAL;
old   1: SELECT TIMESTAMP_TO_SCN(TO_TIMESTAMP('&T','YYYY-MM-DD HH24:MI:SS')) FROM DUAL
new   1: SELECT TIMESTAMP_TO_SCN(TO_TIMESTAMP('2010-02-01 07:13:12','YYYY-MM-DD HH24:MI:SS')) FROM DUAL
TIMESTAMP_TO_SCN(TO_TIMESTAMP('2010-02-0107:13:12','YYYY-MM-DDHH24:MI:SS'))
                                                              9080346377360See how the SCNs are different?
Now if you allow some time to pass between table creation and INSERT, you should be able to get the results as shown:
SQL> CREATE TABLE FLASHBACK_QUERY_TEST(id NUMBER(10));
Table created.
SQL> EXEC DBMS_LOCK.SLEEP(3);
PL/SQL procedure successfully completed.
SQL> COLUMN TSTAMP NEW_VALUE T;
SQL> SELECT CURRENT_SCN, TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD HH24:MI:SS') AS TSTAMP FROM V$DATABASE;
         CURRENT_SCN TSTAMP
       9080346377430 2010-02-01 07:15:30
SQL> INSERT INTO FLASHBACK_QUERY_TEST(ID) VALUES(1);
1 row created.
SQL> COMMIT;
Commit complete.
SQL> SELECT COUNT(*) FROM FLASHBACK_QUERY_TEST;
            COUNT(*)
                   1
SQL> SELECT COUNT(*) FROM FLASHBACK_QUERY_TEST AS OF TIMESTAMP TO_TIMESTAMP('&T','YYYY-MM-DD HH24:MI:SS');
old   1: SELECT COUNT(*) FROM FLASHBACK_QUERY_TEST AS OF TIMESTAMP TO_TIMESTAMP('&T','YYYY-MM-DD HH24:MI:SS')
new   1: SELECT COUNT(*) FROM FLASHBACK_QUERY_TEST AS OF TIMESTAMP TO_TIMESTAMP('2010-02-01 07:15:30','YYYY-MM-DD HH24:MI:SS')
            COUNT(*)
                   0HTH!

ORA-01555 while gathering table statistics

Hello All,
While running a job to gather table statics it failed and I saw in my alert logs ORA-01555, below is the job:
DBMS_STATS.GATHER_TABLE_STATS (SCHEMA_NAME, TABLE_NAME, PARTITION_NAME, ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE, METHOD_OPT=> 'FOR ALL COLUMNS SIZE AUTO');What is the reason behind the ORA-01555 ?
How can I prevent it in the future ?
Regards,

There are two queries,
Below query for optimal undo size based on your undo retention
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
(to_number(e.value) * to_number(f.value) * g.undo_block_per_sec) /
(1024 * 1024) "NEEDED UNDO SIZE (MEGS)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     NEEDED UNDO SIZE (MEGS)
       20860                     900          955.6171875
Another query is based how much undo retention you have to configure as per the undo size
select d.undo_size / (1024 * 1024) "ACTUAL UNDO SIZE (MEGS)",
substr(e.value, 1, 25) "UNDO RETENTION (Secs)",
round((d.undo_size / (to_number(f.value) * g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION (Secs)"
from (select sum(a.bytes) undo_size
from v$datafile a, v$tablespace b, dba_tablespaces c
where c.contents = 'UNDO'
and c.status = 'ONLINE'
and b.name = c.tablespace_name
and a.ts# = b.ts#) d,
v$parameter e,
v$parameter f,
(select max(undoblks / ((end_time - begin_time) * 3600 * 24)) undo_block_per_sec
from v$undostat) g
where e.name = 'undo_retention'
and f.name = 'db_block_size';
Below is the result from my database;
        ACTUAL UNDO SIZE (MEGS)     UNDO RETENTION (Secs)     OPTIMAL UNDO RETENTION (Secs)
     20860                           900                         19646
BTW, have you tried again by executing the same ?Yes with no problem, it only happened once
In the link you mention I read the below
"The ORA-1555 happens when people try to save space typically. They'll have small
rollback segments that could grow if they needed (and will shrink using OPTIMAL). So,
they'll start with say 10 or so 1meg rollback segments. These rollback segments COULD
grow to 100meg each if we let them (in this example) however, they will NEVER grow unless
you get a big transaction.
If your database does lots of little transactions, the RBS will never grow on their own.
They will stay small.
Now, someone needs to run a query that will take 5 minutes. On your system however the
rollback wraps every 2 minutes due to lots of little transactions going on. In this
system, ORA-1555's will happen frequently. What you need to do here is size rollback so
that it wraps less frequently (less frequently then your long running queries). Here if
I sized the rollback so that I had 10, 10meg segments (not so they could GROW to 10meg
but that they are starting at 10meg) we would wrap maybe every 20minutes now. that'll
give that 5minute query plenty of time to complete without reusing rollback it needs.
I Think this is exactly my case, how can I resize my redo segments ? and how can I check its current size?

Flashback query works, but not flashback versions query

This is a test database (Oracle10g 10.1.0.5), not in archivelog mode. I deleted one row 2 hours ago. I can still use flashback query:
select * from tm_instances as of timestamp to_timestamp('STARTTIME_HERE') to view this row. But I can't use the following flashback versions query:
SELECT versions_startscn, versions_starttime,
versions_endscn, versions_endtime,
versions_xid, versions_operation from tm_instances VERSIONS BETWEEN TIMESTAMP to_timestamp('STARTTIME_HERE') and MAXVALUE
It gave the following error:
ORA-30052: invalid lower limit snapshot expression
So I guess flashback query works better than flashback versions query?
undo_retention is set to 900 by default here.
Thanks,
Hai

currently function returns all mydate rows, i just want mydesired date rowsCheck if there is a column in the table with the same name as the function parameter. It's the most probable reason of such DML operations behaviour in PL/SQL procedures and function.
Rgds.

ORA-01555 error ?

I found one ora-01555 error in alert log at 14:37PM.But when i run the following query
select ssolderrcnt from v$undostat where to_char(begin_time,'hh:mi:ss')='14:00:00' and to_char(end_time,'hh:mi:ss')='15:00:00'
no rows selected is getting
It has to show 1 as ora-01555 occured at 14:37pm.
Whats wrong.?

g, the reference material really does not apply to the question of this thread which is finding the v$undostat information for the time period when an ORA-015555 error occurred.
Try this:
select * from v$undostat
where ssolderrcnt <> 0
or nospaceerrcnt <> 0
This should find all v$undostat periods where a 1555 occurred along with periods where you ran short of undo tablespace.
Also v$undostat is only populated where undo management is in effect. There should be 404 rows in this view if undo management is in effect otherwise this view is not useable for this purpose.
HTH -- Mark D Powell --

Receiving error ORA-01555: snapshot too old:

Need some info...
Currently seeing ORA-01555: snapshot too old: rollback segment number 18 with name "_SYSSMU18$" too small.
Info:
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 4200
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS_1
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
35792
SQL>
run this based on threads in here:
SQL> select (35792/60)/60 query,(4200/60)/60 retention from dual;
QUERY RETENTION
9.94222222 1.16666667
I need some help figuring out what to set my undo_retention to? Should it be 36000?
Any help is appreciated.
Thanks

Jamie CC wrote:
The query that was in the alert log was running against a table with 779 rows. The query uses the index (not worried if it wouldn't for that small a table) and came back in one second... This makes no sense. Is it possible that there was a sub-query running and the wrong query was put into the alert log?More likely the query in the alert log was one that died, but the cause was a different query. Remember, the meaning of an ORA-1555 is that the query needed to go back to undo in order to gather a view of the data to a certain SCN, and the data had already been aged out. So the alert log gets the one that died, but the cause is another one. Feel lucky at that, in older versions it was considered an app error IIRC.
Search for the error on asktom.oracle.com for a number of scenarios, and you might want to review the part of the concepts manual about read consistency to make sense of it all. You might also find Tom's book explanation about it with a google search.
Also, depending on your version, there may be things to set like retention guarantee.
I've found on the ERP/MRP systems I work on these errors will appear weekly from people leaving sessions connected after they go home, so I kill 'em off at night. And that's with an undo nearly as big as the db data, that's normally almost empty.

The nature of "ORA-01555: snapshot too old..." error

Hi all,
Please help me to understand the nature of this error:
ORA-01555: snapshot too old: rollback segment number 23 with name "_SYSSMU23_755263746$" too small
One of reports returns this error. Yes, I googled it, but honestly I can't understand deeply what causes it. Usually I resolve it by performing sql request on yesterday's copy of production database. Is it correct to say that this error happens when I try to perform request on tables that are changed in the same moment? What is correct solution to resolve it other than using yesterday's copy of production database?

marco wrote:
Antonio,
The problem is generally small segments of undo, you need to add more space or put guaranty the tablespaces.
How do I describe it for our DBA (how much extra space do I need and what is the name of tablespace)?
Before you go to your DBA, you should figure out how much space your largest query/update uses. That is, your biggest transaction, how much space does it need? 10M? 100M? 1G? From there, your DBA can then size your UNDO properly (or at least "more better" ). Yes he "name of the tablespace" is just called "UNDO").
As mentioned before, the solution might not even be to increase your UNDO size, but rather to identify the "problem job", and fix it. That's not easy, however, talk to your DBA, he may be able to help with that as well.
Things to look for:
1) a job that issues a lot of commits. (suspicious - try to reduce # of commits).
2) a job that runs for a long time and updates along the way (suspicious - try to reduce run time).
3) a job that runs for a long time and has no updates (try to reduce run time - in this case, if this job starts running, and then takes a long time, a lot of other jobs may be reasonably doing updates, and this long run query needs to reference a row that was updated - it might lose it in the UNDO, though).
4) long running queries running at same time as updates on same table. (not always possible, but think about it: a "long running query" is often a "report" of some sort (not always, but often). Try to schedule the reports when less update activity is expected. Or, if the updates are part of the same batch, try to schedule them after each other so they don't overlap. (if the updates are online users, there isn't much you can do except try to decrease runtime of the long running query).
You DBA can help find candidates for those cases.

UNdo error (ora-01555) - Snapshot too old error

Hi,
If undo get filled and if we get a snapshot too old error then what is the solution for this error, plz give step by step solution for this.

You prevent ORA-01555 errors by
1) Setting UNDO_RETENTION equal to or greater than the length of the longest running query/ serializable transaction in the system
2) Ensuring the UNDO tablespace is large enough to accomodate the amount of UNDO generated over that period of time.
You would need to determine things like the length of your longest running query, the amount of UNDO getting generated, etc. and adjust your UNDO_RETENTION and UNDO tablespace accordingly.
Justin

Snapshot too old ORA-01555 from select statement (discoverer)??

Hi All
Am I loosing the plot .. but we have a select statement run from discoverer which is causing the famous snapshot too old error.
My understanding is that undo is generated from select/insert/update.
So why is the following discoverer Select statement causing the error?
from alert
ORA-01555 caused by SQL statement below (SQL ID: gk0wxgqmx66sh, Query Duration=3866 sec, SCN: 0x001e.089cf3f9):
SELECT ( ROUND(( TO_DATE(SYSDATE)-o101038.HIRE_DATE )/365,2) ) as
" bla bla
ORDER BY o101020.SUB_ORGANIZATION_NAME ASC
Thanks in Advance

simon.9999 wrote:
Hi All
Am I loosing the plot .. but we have a select statement run from discoverer which is causing the famous snapshot too old error.
My understanding is that undo is generated from select/insert/update.
So why is the following discoverer Select statement causing the error?
from alert
ORA-01555 caused by SQL statement below (SQL ID: gk0wxgqmx66sh, Query Duration=3866 sec, SCN: 0x001e.089cf3f9):
SELECT ( ROUND(( TO_DATE(SYSDATE)-o101038.HIRE_DATE )/365,2) ) as
" bla bla
ORDER BY o101020.SUB_ORGANIZATION_NAME ASC
Thanks in Advance
The SELECT statement is the victim.
Some session is doing DML against the same table against which the SELECT occurs & is likely doing COMMIT inside a LOOP.

ORA-01555 in Oracle 9.2.0.5

we running Baan IV on a Oracle 9.2.0.5 database.
Sometimes we got an error in the alert log file like:
ORA-01555 caused by SQL statement below (Query Duration=60440 sec, SCN: 0x0001.a452e41c)
Now, i want to know which user with which sql-statement (if possible) get this error.
So this error is mostly at night, i try to write a trigger to get this information.
But i don't know how to do this.
Can somebody help me ?
T.Kindermann

Now, i want to know which user with which sql-statement (if possible) get this error.If you see the alert log file, you will also have the sql that caused ora-1555 errors along with time stamp.
If you are using AUM (automatic Undo management), tune your undo parameters and tablespace using v$undostat. If you are using MUM (manual rollback segment), create a big rollback segment and assign to this transaction.
Jaffar

Flashback Query ORA-01555

Similar Messages

Maybe you are looking for