DataRecov er This call stack can be observ ed when the automatic log segment reclaim is activ e.

iv e. SA P Note 31 47 346 desc

y ::Directory L ribes a deadlock bug that can result in the CompletionThread[LOG] getting stuck permanently in this call s
ogSegmentFa tack. This issue is fix ed with SA P HA NA >= 2.00.062.
ctory ::release
UnusedSegme
nts
DataRecov er
y ::LogPartitio
n::checkFileS
y stemDiskUsa
geThreshold
DataRecov er
y ::LogSegmen
tFactory ::get
NewSegment
DataRecov er
y ::LogPartitio
n::startIO
DataRecov er
y ::LogPartitio
n::finishIO
DataRecov er
y ::LogSegmen
t::finishIOPar
t

Condi DPCommitT ptime::Group

These This callto
locks are linked stack is related
smart to distributed
data integration transaction
(SDI, processing
SAP Note (inv olv
2400022) anding the
sev eral serv ices
remote / hosts).
source Prepare
threads like
MulticastUtil: commit logging is grouped for one worker and flushed together with the max imum log sequence number.
tional ranPersiste :
:handleStrea Longer wait times ty pically indicate communication / av ailability issues or sev ere indiv idual issues like in
Var ntDistributo mRequest ternal deadlocks or hanging aborts and dangling transactions. Check the database activ ities and traces for
DPDistributor<remote_source_id>
Wait rQueueData Distribution:: further details.
DPReceiver<remote_source_id>
Condi AvailableCo GroupMultica
DPReceiverWriter<remote_source_id>
stStreamMan
tional nd
ager::handle
Varia DPPersisten Increased wait times can be linked to communication issues that slow down the accesses to the remote sources
ble W tTranDataCl . See SAP Note 2222200 for more information related to network in SAP HANA environments.
DataA ccess::L This call stack happens after the critical sav epoint phase in order to ensure that all open log buffers up to a
ait eanerDataA ogger::sy
With newer nc SAPspecific
HANAlog position are
Revisions flushed
these lockstoare
diskimplemented
(and if requiredvia
shipped to the secondary
semaphore waits andsythe
stemlock
replication
names site).
end w
vailableCon DataRecov er It should be v ery quick. Long runtimes or a sav epoint being permanently stuck is ty pically a consequence
ith "Semaphore" rather than "Cond".
d y ::LoggerImp of a sev ere underly ing issue.
l::sy nc
DPReceiver See SA P Note 2000000 ("How can the performance of commit operations be optimized?") and eliminate is
DataA ccess::P
InboundQue sues related to commits, e.g. slow / stuck I/O to the LOG file sy stem or slow sy stem replication log shippin
ersistenceMa
g.
ueEmptyCo nagerSPCallb
nd ack::spPostCr A lso check for other critical scenarios like an internal deadlock or hanging aborts and dangling transactio
iticalPhaseCal ns. Check the database activ ities and traces for further details.
lback
Condi DPPrefetch This
DataA lock indicates that data is read from a source system via dpserver / SDI (SAP Note 2400022) and / or is
ccess::S
tional ThreadStop av epointImpl
being processed by the indexserver. This can for example happen in case of expensive database requests that i
::enterPostCri
Var Condition nvolve both tables from the SDI source and target system.
ticalPhase
Wait DataA ccess::S
Condi av epointImpl
tional ::doSav epoint

Varia
ble W
ait

Condi DPStatsThr This state can be considered as inactive (SAP Note 2114710 -> "Are there situations where threads are errone
tional eadCond ously reported as being active?").
Var
Wait
Condi
tional
Varia
ble W
ait