Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Index usage

4 posts in General Discussion Last posting was on 2012-07-15 10:31:13.0Z
Raj Posted on 2012-07-12 11:34:03.0Z
Sender: 3c01.4ffeb471.1804289383@sybase.com
From: Raj
Newsgroups: sybase.public.ase.general
Subject: Index usage
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <4ffeb62b.3c4e.1681692777@sybase.com>
NNTP-Posting-Host: 172.20.134.41
X-Original-NNTP-Posting-Host: 172.20.134.41
Date: 12 Jul 2012 04:34:03 -0700
X-Trace: forums-1-dub 1342092843 172.20.134.41 (12 Jul 2012 04:34:03 -0700)
X-Original-Trace: 12 Jul 2012 04:34:03 -0700, 172.20.134.41
Lines: 44
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31244
Article PK: 74132

Hi,

We have a job, which runs in 3-5 minutes, But during
sometime in the day it runs very slowly. Was comparing the
query plan. Found this job uses table scan on a table during
this time, What could be the reason ? How can I fix this ?
Please have a look the difference below. Also, it uses 16K
I/O size in this case.

Thanks in advance.


Slow run:
---------

Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


Fast run:
----------


Nested iteration.
Index : INDEX_NDX
Forward scan.
Positioning by key.
Keys are:
ABC ASC
REC ASC
Using I/O Size 4 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf
pages.
Using I/O Size 4 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.



Cheers,
Raj


Rob V Posted on 2012-07-12 11:50:14.0Z
From: Rob V <rob@sypron.nl>
Reply-To: rob@sypron.nl
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: Index usage
References: <4ffeb62b.3c4e.1681692777@sybase.com>
In-Reply-To: <4ffeb62b.3c4e.1681692777@sybase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4ffeb9f6@forums-1-dub>
Date: 12 Jul 2012 04:50:14 -0700
X-Trace: forums-1-dub 1342093814 172.20.134.152 (12 Jul 2012 04:50:14 -0700)
X-Original-Trace: 12 Jul 2012 04:50:14 -0700, vip152.sybase.com
Lines: 81
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31245
Article PK: 74134

You need to provide the actual query since the actual predicate make all
the difference. Without that, it is hard to give any sensible comments
other than to point you to the Performance & Tuning manual which
discusses these things in detail.

The first question to ask is: did you run 'update statistics' or 'update
index statistics' on the table(s) involved? If not, do that first.

You should also specify the exact ASE version you're using. The query
plan looks like it is either 12.5 or before, or you're using
compatibility mode in ASE 15.

HTH,

Rob V.
-----------------------------------------------------------------
Rob Verschoor

Certified Professional DBA for Sybase ASE, IQ, Replication Server

Author of Sybase books (order online at www.sypron.nl/shop):
"Tips, Tricks & Recipes for Sybase ASE"
"The Complete Sybase IQ Quick Reference Guide"
"The Complete Sybase ASE Quick Reference Guide"
"The Complete Sybase Replication Server Quick Reference Guide"

rob@NO.SPAM.sypron.nl | www.sypron.nl | Twitter: @rob_verschoor
Sypron B.V., The Netherlands | Chamber of Commerce 27138666
-----------------------------------------------------------------

On 12-Jul-2012 13:34, Raj wrote:
> Hi,
>
> We have a job, which runs in 3-5 minutes, But during
> sometime in the day it runs very slowly. Was comparing the
> query plan. Found this job uses table scan on a table during
> this time, What could be the reason ? How can I fix this ?
> Please have a look the difference below. Also, it uses 16K
> I/O size in this case.
>
> Thanks in advance.
>
>
> Slow run:
> ---------
>
> Nested iteration.
> Table Scan.
> Forward scan.
> Positioning at start of table.
> Using I/O Size 16 Kbytes for data pages.
> With LRU Buffer Replacement Strategy for data pages.
>
>
> Fast run:
> ----------
>
>
> Nested iteration.
> Index : INDEX_NDX
> Forward scan.
> Positioning by key.
> Keys are:
> ABC ASC
> REC ASC
> Using I/O Size 4 Kbytes for index leaf pages.
> With LRU Buffer Replacement Strategy for index leaf
> pages.
> Using I/O Size 4 Kbytes for data pages.
> With LRU Buffer Replacement Strategy for data pages.
>
>
>
> Cheers,
> Raj
>


Raj Posted on 2012-07-14 23:28:33.0Z
Sender: 35df.5001fd65.1804289383@sybase.com
From: Raj
Newsgroups: sybase.public.ase.general
Subject: Re: Index usage
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <500200a1.3653.1681692777@sybase.com>
References: <4ffeb9f6@forums-1-dub>
NNTP-Posting-Host: 172.20.134.41
X-Original-NNTP-Posting-Host: 172.20.134.41
Date: 14 Jul 2012 16:28:33 -0700
X-Trace: forums-1-dub 1342308513 172.20.134.41 (14 Jul 2012 16:28:33 -0700)
X-Original-Trace: 14 Jul 2012 16:28:33 -0700, 172.20.134.41
Lines: 226
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31253
Article PK: 74142

Hi Rob,

Here is the query. Statistics are updated. ASE version is
12.5.4 ESD #3 on AIX 6.1. Also, Have forced index to be used
on that table, Surprisingly it still used table scan(i mean
index has not been used) when this job run as part of EOD
batch. If we run same job in different time in the day, It
uses index and runs faster. Also If we kill and rerun the
job sametime, it works fine.I wonder what could be the
reason ? Why has the index not been used even it's forced?
Do predecessor jobs influence the query plan ? If yes, why
does it runs fast when we kill and rerun the job
immediately.

Thanks,
Raj

select
CODE="###",
NUROWS=count(*),
TOTAL_NOMINAL=convert( numeric( 19, 2), round( sum(
w.TP_NOMINAL ), 2 ) )
from
View1 w



create view View1 (
NB ,
H_BONDTYPE,
H_CISKEY,
F_AMOUNT ,
F_CCFRMCD1 ,
TP_NOMINAL ,
TP_PFOLIO ,
H_BREAK1,
RNG_RATE_LO,
RNG_RATE_HI,
RNG_INDEX,
RATE_CONV,
PRIME_BROK,
CRED_MIT,
CRED_APPR,
SWAPSWIRE,
SW_CONFIRM,
SW_CTP,
SW_PB_DEAL,
CL_BROK,
CL_EBROK,
CL_HOUS,
CL_ID,
CL_SENT,
TP_RTAMO,
CUSTOM,
TP_RTXCHF,
TP_RTXCHI,
CTRP_TYPE,
ICE_ID,
TP_VALSTAT,
RATE_1,
RATE_2
)
as
select
NB=w.NB,
H_CISKEY=rtrim(c.RXKEY),
F_AMOUNT=w.F_AMOUNT ,
F_CCFRMCD1=convert( char(10), w.F_CCFRMCD1 , 103 ),
TP_NOMINAL=case when w.TRN_GRP='RP' then convert( numeric(
19, 2 ), abs( w.TP_NOMINAL * w.TP_IQTYS ) ) else convert(
numeric( 19, 2), w.TP_NOMINAL ) end,
TP_PFOLIO=rtrim( w.TP_PFOLIO ),
H_BREAK1=case when w.H_BREAK1 like '%****%' then
'01/01/1980' else rtrim( convert( char(10), w.H_BREAK1, 103
)) end,

RNG_RATE_LO=rg.RNG_RATE0,
RNG_RATE_HI=rg.RNG_RATE1,
RNG_INDEX=rg.RNG_INDEX,
RATE_CONV=idx.RATE_CONV,
PRIME_BROK=c.PRIME_BROK,
CRED_MIT=case when w.TRN_GRP='IRD' then ird.CR_MIT else
crd.CR_MIT end,
CRED_APPR=case when w.TRN_GRP='IRD' then ird.CR_APP else
crd.CR_APP end,
SWAPSWIRE=case when w.TRN_FMLY='IRD' then ird.SWAPSWIRE
else crd.SWAPSWIRE end,
SW_CONFIRM=case when w.TRN_FMLY='IRD' then ird.SW_CONFIRM
else crd.SW_CONFIRM end,
SW_CTP=case when w.TRN_FMLY='IRD' then ird.SW_CTP else
crd.SW_CTP end,
SW_PB_DEAL=case when w.TRN_FMLY='IRD' then ird.SW_PB_DEAL
else crd.SW_PB_DEAL end,
CL_BROK=case when w.TRN_FMLY='IRD' then ird.CL_BROK else
crd.CL_BROK end,
CL_EBROK=case when w.TRN_FMLY='IRD' then ird.CL_EBROK else
crd.CL_EBROK end,
CL_HOUS=case when w.TRN_FMLY='IRD' then ird.CL_HOUS else
crd.CL_HOUS end,
CL_ID=case when w.TRN_FMLY='IRD' then ird.CL_ID else
crd.CL_ID end,
CL_SENT=case when w.TRN_FMLY='IRD' then ird.CL_SENT else
crd.CL_SENT end,
TP_RTAMO=case when w.TP_RTAMO='None' or w.TP_RTAMO=' ' then
'N' else 'Y' end,
CUSTOM=case when ln2.CUSTOM=1 then 'Customised' else ' '
end,
TP_RTXCHF=w.TP_RTXCHF,
TP_RTXCHI=w.TP_RTXCHI,
CTRP_TYPE=c.TYPE,
ICE_ID=case when w.TRN_FMLY='IRD' then '' else crd.ICE_ID
end,
TP_VALSTAT=w.TP_VALSTAT,
RATE_1=0,
RATE_2=0
from
Table1 w,
Table1 c,
Table2 rg,
Table3 idx,
Table4 ird,
Table5 crd,
Table6 ln2 (index Table6_NDX)

where

w.TP_CNTRP *= c.LABEL and
and w.HDR_APPL LIKE 'SYD%'
and w.NB *= rg.RNG_NB
and w.F_PHASE *= rg.RNG_PHASE
and w.F_LEG *= rg.RNG_LEG
and rg.RNG_INDEX *= idx.INDEX
and w.NB *= ird.NB
and w.NB *= crd.NB
and (w.NB *= ln2.NB and w.F_PHASE *= ln2.SYS@RECORD)
go

> You need to provide the actual query since the actual
> predicate make all the difference. Without that, it is
> hard to give any sensible comments other than to point
> you to the Performance & Tuning manual which discusses
> these things in detail.
>
> The first question to ask is: did you run 'update
> statistics' or 'update index statistics' on the table(s)
> involved? If not, do that first.
>
> You should also specify the exact ASE version you're
> using. The query plan looks like it is either 12.5 or
> before, or you're using compatibility mode in ASE 15.
>
> HTH,
>
> Rob V.
> ----------------------------------------------------------
> ------- Rob Verschoor
>
> Certified Professional DBA for Sybase ASE, IQ, Replication
> Server
>
> Author of Sybase books (order online at
> www.sypron.nl/shop): "Tips, Tricks & Recipes for Sybase
> ASE" "The Complete Sybase IQ Quick Reference Guide"
> "The Complete Sybase ASE Quick Reference Guide"
> "The Complete Sybase Replication Server Quick Reference
> Guide"
>
> rob@NO.SPAM.sypron.nl | www.sypron.nl | Twitter:
> @rob_verschoor Sypron B.V., The Netherlands | Chamber of
> Commerce 27138666
> ----------------------------------------------------------
> -------
>
>
>
> On 12-Jul-2012 13:34, Raj wrote:
> > Hi,
> >
> > We have a job, which runs in 3-5 minutes, But during
> > sometime in the day it runs very slowly. Was comparing
> > the query plan. Found this job uses table scan on a
> > table during this time, What could be the reason ? How
> > can I fix this ? Please have a look the difference
> > below. Also, it uses 16K I/O size in this case.
> >
> > Thanks in advance.
> >
> >
> > Slow run:
> > ---------
> >
> > Nested iteration.
> > Table Scan.
> > Forward scan.
> > Positioning at start of table.
> > Using I/O Size 16 Kbytes for data pages.
> > With LRU Buffer Replacement Strategy for data
> pages. >
> >
> > Fast run:
> > ----------
> >
> >
> > Nested iteration.
> > Index : INDEX_NDX
> > Forward scan.
> > Positioning by key.
> > Keys are:
> > ABC ASC
> > REC ASC
> > Using I/O Size 4 Kbytes for index leaf pages.
> > With LRU Buffer Replacement Strategy for index
> > leaf pages.
> > Using I/O Size 4 Kbytes for data pages.
> > With LRU Buffer Replacement Strategy for data
> pages. >
> >
> >
> > Cheers,
> > Raj
> >
>
>
>


Rob V Posted on 2012-07-15 10:31:13.0Z
From: Rob V <rob@sypron.nl>
Reply-To: rob@sypron.nl
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: Index usage
References: <4ffeb9f6@forums-1-dub> <500200a1.3653.1681692777@sybase.com>
In-Reply-To: <500200a1.3653.1681692777@sybase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <50029bf1@forums-1-dub>
Date: 15 Jul 2012 03:31:13 -0700
X-Trace: forums-1-dub 1342348273 172.20.134.152 (15 Jul 2012 03:31:13 -0700)
X-Original-Trace: 15 Jul 2012 03:31:13 -0700, vip152.sybase.com
Lines: 268
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31254
Article PK: 74148

The index used in the query plan is not the same index as forced in the
query you posted.
Anyway, the query plan shown is only a small part of the query you
posted. With such a complex view involved, there are likley no easy
answers to questions why a query plan works out one way or another.
In cases like this, especially with multiple tables and outer joins
involved, table scan could easily occur as indexes are just no usable.
Having said that, if you force an index it should typically be used no
matter how inefficient it is (except when for example isolation level
zero is active). When you force an index that doesn't exist, you get an
error message in the initial showplan, and the forcing is ignored.

Without index forcing, changing data contents in the table(s) is a
common reason why different query plans are chosen at different executions.
For queries like these, you have a more complex case of optimizer
debugging. Traceflag 302 would be the direction to udnerstand why
different choices are made at different times; you'd need to study the
Performance & Tuning manual first though: there is no quick or easy way
to learn or explain how to dig into these things.

HTH,

Rob V.
-----------------------------------------------------------------
Rob Verschoor

Certified Professional DBA for Sybase ASE, IQ, Replication Server

Author of Sybase books (order online at www.sypron.nl/shop):
"Tips, Tricks & Recipes for Sybase ASE"
"The Complete Sybase IQ Quick Reference Guide"
"The Complete Sybase ASE Quick Reference Guide"
"The Complete Sybase Replication Server Quick Reference Guide"

rob@NO.SPAM.sypron.nl | www.sypron.nl | Twitter: @rob_verschoor
Sypron B.V., The Netherlands | Chamber of Commerce 27138666
-----------------------------------------------------------------

On 15-Jul-2012 01:28, Raj wrote:
> Hi Rob,
>
> Here is the query. Statistics are updated. ASE version is
> 12.5.4 ESD #3 on AIX 6.1. Also, Have forced index to be used
> on that table, Surprisingly it still used table scan(i mean
> index has not been used) when this job run as part of EOD
> batch. If we run same job in different time in the day, It
> uses index and runs faster. Also If we kill and rerun the
> job sametime, it works fine.I wonder what could be the
> reason ? Why has the index not been used even it's forced?
> Do predecessor jobs influence the query plan ? If yes, why
> does it runs fast when we kill and rerun the job
> immediately.
>
> Thanks,
> Raj
>
> select
> CODE="###",
> NUROWS=count(*),
> TOTAL_NOMINAL=convert( numeric( 19, 2), round( sum(
> w.TP_NOMINAL ), 2 ) )
> from
> View1 w
>
>
>
> create view View1 (
> NB ,
> H_BONDTYPE,
> H_CISKEY,
> F_AMOUNT ,
> F_CCFRMCD1 ,
> TP_NOMINAL ,
> TP_PFOLIO ,
> H_BREAK1,
> RNG_RATE_LO,
> RNG_RATE_HI,
> RNG_INDEX,
> RATE_CONV,
> PRIME_BROK,
> CRED_MIT,
> CRED_APPR,
> SWAPSWIRE,
> SW_CONFIRM,
> SW_CTP,
> SW_PB_DEAL,
> CL_BROK,
> CL_EBROK,
> CL_HOUS,
> CL_ID,
> CL_SENT,
> TP_RTAMO,
> CUSTOM,
> TP_RTXCHF,
> TP_RTXCHI,
> CTRP_TYPE,
> ICE_ID,
> TP_VALSTAT,
> RATE_1,
> RATE_2
> )
> as
> select
> NB=w.NB,
> H_CISKEY=rtrim(c.RXKEY),
> F_AMOUNT=w.F_AMOUNT ,
> F_CCFRMCD1=convert( char(10), w.F_CCFRMCD1 , 103 ),
> TP_NOMINAL=case when w.TRN_GRP='RP' then convert( numeric(
> 19, 2 ), abs( w.TP_NOMINAL * w.TP_IQTYS ) ) else convert(
> numeric( 19, 2), w.TP_NOMINAL ) end,
> TP_PFOLIO=rtrim( w.TP_PFOLIO ),
> H_BREAK1=case when w.H_BREAK1 like '%****%' then
> '01/01/1980' else rtrim( convert( char(10), w.H_BREAK1, 103
> )) end,
>
> RNG_RATE_LO=rg.RNG_RATE0,
> RNG_RATE_HI=rg.RNG_RATE1,
> RNG_INDEX=rg.RNG_INDEX,
> RATE_CONV=idx.RATE_CONV,
> PRIME_BROK=c.PRIME_BROK,
> CRED_MIT=case when w.TRN_GRP='IRD' then ird.CR_MIT else
> crd.CR_MIT end,
> CRED_APPR=case when w.TRN_GRP='IRD' then ird.CR_APP else
> crd.CR_APP end,
> SWAPSWIRE=case when w.TRN_FMLY='IRD' then ird.SWAPSWIRE
> else crd.SWAPSWIRE end,
> SW_CONFIRM=case when w.TRN_FMLY='IRD' then ird.SW_CONFIRM
> else crd.SW_CONFIRM end,
> SW_CTP=case when w.TRN_FMLY='IRD' then ird.SW_CTP else
> crd.SW_CTP end,
> SW_PB_DEAL=case when w.TRN_FMLY='IRD' then ird.SW_PB_DEAL
> else crd.SW_PB_DEAL end,
> CL_BROK=case when w.TRN_FMLY='IRD' then ird.CL_BROK else
> crd.CL_BROK end,
> CL_EBROK=case when w.TRN_FMLY='IRD' then ird.CL_EBROK else
> crd.CL_EBROK end,
> CL_HOUS=case when w.TRN_FMLY='IRD' then ird.CL_HOUS else
> crd.CL_HOUS end,
> CL_ID=case when w.TRN_FMLY='IRD' then ird.CL_ID else
> crd.CL_ID end,
> CL_SENT=case when w.TRN_FMLY='IRD' then ird.CL_SENT else
> crd.CL_SENT end,
> TP_RTAMO=case when w.TP_RTAMO='None' or w.TP_RTAMO=' ' then
> 'N' else 'Y' end,
> CUSTOM=case when ln2.CUSTOM=1 then 'Customised' else ' '
> end,
> TP_RTXCHF=w.TP_RTXCHF,
> TP_RTXCHI=w.TP_RTXCHI,
> CTRP_TYPE=c.TYPE,
> ICE_ID=case when w.TRN_FMLY='IRD' then '' else crd.ICE_ID
> end,
> TP_VALSTAT=w.TP_VALSTAT,
> RATE_1=0,
> RATE_2=0
> from
> Table1 w,
> Table1 c,
> Table2 rg,
> Table3 idx,
> Table4 ird,
> Table5 crd,
> Table6 ln2 (index Table6_NDX)
>
> where
>
> w.TP_CNTRP *= c.LABEL and
> and w.HDR_APPL LIKE 'SYD%'
> and w.NB *= rg.RNG_NB
> and w.F_PHASE *= rg.RNG_PHASE
> and w.F_LEG *= rg.RNG_LEG
> and rg.RNG_INDEX *= idx.INDEX
> and w.NB *= ird.NB
> and w.NB *= crd.NB
> and (w.NB *= ln2.NB and w.F_PHASE *= ln2.SYS@RECORD)
> go
>
>
>
>> You need to provide the actual query since the actual
>> predicate make all the difference. Without that, it is
>> hard to give any sensible comments other than to point
>> you to the Performance & Tuning manual which discusses
>> these things in detail.
>>
>> The first question to ask is: did you run 'update
>> statistics' or 'update index statistics' on the table(s)
>> involved? If not, do that first.
>>
>> You should also specify the exact ASE version you're
>> using. The query plan looks like it is either 12.5 or
>> before, or you're using compatibility mode in ASE 15.
>>
>> HTH,
>>
>> Rob V.
>> ----------------------------------------------------------
>> ------- Rob Verschoor
>>
>> Certified Professional DBA for Sybase ASE, IQ, Replication
>> Server
>>
>> Author of Sybase books (order online at
>> www.sypron.nl/shop): "Tips, Tricks & Recipes for Sybase
>> ASE" "The Complete Sybase IQ Quick Reference Guide"
>> "The Complete Sybase ASE Quick Reference Guide"
>> "The Complete Sybase Replication Server Quick Reference
>> Guide"
>>
>> rob@NO.SPAM.sypron.nl | www.sypron.nl | Twitter:
>> @rob_verschoor Sypron B.V., The Netherlands | Chamber of
>> Commerce 27138666
>> ----------------------------------------------------------
>> -------
>>
>>
>>
>> On 12-Jul-2012 13:34, Raj wrote:
>>> Hi,
>>>
>>> We have a job, which runs in 3-5 minutes, But during
>>> sometime in the day it runs very slowly. Was comparing
>>> the query plan. Found this job uses table scan on a
>>> table during this time, What could be the reason ? How
>>> can I fix this ? Please have a look the difference
>>> below. Also, it uses 16K I/O size in this case.
>>>
>>> Thanks in advance.
>>>
>>>
>>> Slow run:
>>> ---------
>>>
>>> Nested iteration.
>>> Table Scan.
>>> Forward scan.
>>> Positioning at start of table.
>>> Using I/O Size 16 Kbytes for data pages.
>>> With LRU Buffer Replacement Strategy for data
>> pages. >
>>>
>>> Fast run:
>>> ----------
>>>
>>>
>>> Nested iteration.
>>> Index : INDEX_NDX
>>> Forward scan.
>>> Positioning by key.
>>> Keys are:
>>> ABC ASC
>>> REC ASC
>>> Using I/O Size 4 Kbytes for index leaf pages.
>>> With LRU Buffer Replacement Strategy for index
>>> leaf pages.
>>> Using I/O Size 4 Kbytes for data pages.
>>> With LRU Buffer Replacement Strategy for data
>> pages. >
>>>
>>>
>>> Cheers,
>>> Raj
>>>
>>
>>
>>