SNAP table

Hi All,
We are facing large number no of dumps in our ECC6.0.
So I want to know some information for SNAP table which stores dump data.
1 ) How to check how many entries can be store in SNAP table or what is the size of this table to proactive take step if it is going to full.
2 ) what can happen if SNAP table get full, Will only we not be able to store further dump data or it is possible that system get hang.
3 ) how can we delete table entries.
Please suggest.
Regards,
Shivam

Hi Rahul,
it may helpful...
As per SAP Note 11838 - Deleting short dumps from the SNAP table:
There are different ways of deleting short dumps from the SNAP table. However, before you delete them, you must analyze the cause of the short dump (using transaction ST22).
1.) Dump analysis: Reorganization
Go to 'ABAP/4 dump analysis' (in transaction ST22). Choose 'Reorganization'. You can now select all short dumps older than n days (default 7) for deletion.
CAUTION: If a large amount of records are deleted simultaneously during the reorganization, ORACLE error ora1562 'failed to extend rollback segment ...' may occur. In this case, refer to error Note 6328.
2.) Drop and recreate the SNAP table
With the database utility (transaction SE14), you can drop and recreate the SNAP table.
CAUTION: When you do this, ALL short dumps are deleted.
3.) Reorganization program RSSNAPDL
To avoid database problems, this program deletes old short dumps gradually from the SNAP table unless they are selected for retention. With standard setting all short dumps that are older than 7 days (28 days as of Release 7.00) and that are not flagged are deleted. Since this program occupies the database when large datasets are processed, it should be scheduled to run overnight. Use program RSNAPJOB to set a standard scheduling: the program RSSNAPDL is started every day at 1:00 o'clock in the morning.
These reorganization programs are available at the latest as of Release 2.1G/2.2A.
4.) The SNAP is also automatically reorganized. With each short dump that occurs in the dialog box (the dump is displayed as soon as it occurs), a maximum of 20 short dumps are deleted from the SNAP that are older than 7 days. In normal production operation this reorganization should be sufficient.
Mark it as correct if helpful.
Thanks
Kishore Cherukumalla

Similar Messages

SNAP BEG

What seems to be the problem/s with this error?
SQL error occurred when accessing table "SNAP_BEG"

Im my expirience SNAP ans SNAP_BEG are the tables that holds all the dumps, usually SNAP tables go to error when they are full or inconsistent...
Hope this help!
Juan
PS: Please reward with points if helpful

MLOGS not purge after a fast refresh (Materialized view) ...

Hi,
I have a database on my own site (Quebec) that has 36 materialized views refresh by a master table site that is physically at Montreal. The MVIEWs are refreshed every day of the week (monday to friday) at 7h00 until 19h00. We use the "fast refresh" technic to refresh the materialized views.
Last weekend, I transfered this database on a new server. So, I created a new SID (I rename the old SID "ORCL" by "ATQP") and I created this instance with a DB_BLOCK_SIZE of 16k rather than 8k. It's the only difference between the two instances (the old one and the new one). I also created the owner schema "ATQP" and I made an Export on the old server followed by an Import of the schema that owned the Materialized views (not a Full import) on the new server. The export was made many hours (saturday morning) after the last refresh of the week (friday, at 19h00) on the old server.
After the successul import on my new server, I'm looking for the information about the creation of the MVIEW. Everything seems OK. I can see that the last refresh date indicated "2008-02-22 19:00" (date / time of the last refresh of the week). I made a quick test on a small MVIEW (a fast refresh) and it worked, no error.
Yesterday morning, the DBA of the master table site mentionned us that the DELETE on the MLOGS didn't work on the master site. The refresh was made successfully but the MLOGS continue to grow up, again and again ... On my database, I'm looking in the SYS.SNAP$ table and I saw that the SNAPTIME date is '1950-01-01 12:00' rather than '2008-02-25 19:00'. In the SYS.SNAP_REFTIME, the SNAPTIME is OK but the LOADERTIME column contains the same strange date '1950-01-01 12:00'.
I made a quick check on my old server and the SYS.SNAP$ table is empty !!! I think it's normal because the last refresh on this node was made last friday night and I made the transfert last saturday (I shutdown the old database after).
I know how to solve the problem, by recreate the MVIEW, but it causes a big problem for us. We are in PRODUCTION and we don't want to refresh many millions of records. I think it will take a couple of days to refresh all the materialized views of my schema. And it doesn't sound good by the master table site management team ...
The master table site "rush" us to solve the problem before the weekend. They don't want that we overcharge the network link between them and us by refreshing those MVIEWS.
So, is it possible to make something simple to resynchronized the SNAPTIME date without refreshing completely all the materialized views ?
If the master site table recreate the MLOG (purge manually), is it possible that it will solve our problem ?
Is it also possible to recreate the MVIEW without refreshing the data (specify to Oracle to recreate the MVIEW but indicate that the table associated already exist) ?
All of my materialized view are up to date concerning the data. I don't want to refresh all of it.
Thank's in advance ...

Hi Justin,
The DBA of the master table site sent me a email about the fact he unregistered the MVIEW. He told me that the script for the unregistered worked well. He tried to purge the MLOG and he got the error ORA-23424 but I think it's normal (It's what you said yesterday about the fact that the UNREGISTER command also purge the MLOGS).
So, it seems that the MLOGS are still not purged (that's what the DBA of the master table site said). I ran the following query:
SQL> select * from [email protected];
LOG_OWNER MASTER LOG_TABLE LOG_TRIGGER ROW PRI OBJ FIL SEQ INC
ATQ ALIAS_ANILOTS MLOG$_ALIAS_ANILOTS NO YES NO YES NO YES
ATQ ALIAS_INTERVENANTS MLOG$_ALIAS_INTERVENANTS NO YES NO YES NO YES
ATQ ANILOTS MLOG$_ANILOTS NO YES NO YES NO YES
ATQ CATEGORIES MLOG$_CATEGORIES NO YES NO YES NO YES
ATQ CODES_POSTAUX MLOG$_CODES_POSTAUX NO YES NO YES NO YES
ATQ COMMANDES MLOG$_COMMANDES NO YES NO YES NO YES
ATQ COMMUNICATIONS MLOG$_COMMUNICATIONS NO YES NO YES NO YES
ATQ DEPLACEMENTS MLOG$_DEPLACEMENTS NO YES NO YES NO YES
ATQ DETAILS_STATUTS_COMMANDES MLOG$_DETAILS_STATUTS_COMM NO YES NO YES NO YES
ATQ DOMAINES MLOG$_DOMAINES NO YES NO YES NO YES
ATQ ENREGISTREMENT_LOGS MLOG$_ENREGISTREMENT_LOGS NO YES NO YES NO YES
ATQ ENREGISTREMENT_NOTES MLOG$_ENREGISTREMENT_NOTES NO YES NO YES NO YES
ATQ ESPECES MLOG$_ESPECES NO YES NO YES NO YES
ATQ EVENEMENTS MLOG$_EVENEMENTS NO YES NO YES NO YES
ATQ EVENE_DIFFERES MLOG$_EVENE_DIFFERES NO YES NO YES NO YES
ATQ IDENTIFIANTS MLOG$_IDENTIFIANTS NO YES NO YES NO YES
ATQ INTERVENANTS MLOG$_INTERVENANTS NO YES NO YES NO YES
ATQ INTERVENANTS_CLIENTS MLOG$_INTERVENANTS_CLIENTS NO YES NO YES NO YES
ATQ INTERVENANTS_SITES MLOG$_INTERVENANTS_SITES NO YES NO YES NO YES
ATQ MAX_EVENE_DIFFERES MLOG$_MAX_EVENE_DIFFERES NO YES NO YES NO YES
ATQ MESSAGES MLOG$_MESSAGES NO YES NO YES NO YES
ATQ MUNICIPALITES MLOG$_MUNICIPALITES NO YES NO YES NO YES
ATQ NEW_ANILOTS MLOG$_NEW_ANILOTS NO YES NO YES NO YES
ATQ NEW_EVENEMENTS MLOG$_NEW_EVENEMENTS NO YES NO YES NO YES
ATQ NEW_IDENTIFIANTS MLOG$_NEW_IDENTIFIANTS NO YES NO YES NO YES
ATQ NEW_SITES MLOG$_NEW_SITES NO YES NO YES NO YES
ATQ PAYS MLOG$_PAYS NO YES NO YES NO YES
ATQ PRODUCTIONS MLOG$_PRODUCTIONS NO YES NO YES NO YES
ATQ PROPRIETES_ANILOTS MLOG$_PROPRIETES_ANILOTS NO YES NO YES NO YES
ATQ PROVINCES MLOG$_PROVINCES NO YES NO YES NO YES
ATQ SITES_EXPLOITATIONS MLOG$_SITES_EXPLOITATIONS NO YES NO YES NO YES
ATQ TYPES_IDENTIFIANTS MLOG$_TYPES_IDENTIFIANTS NO YES NO YES NO YES
ATQ UTILISATEURS MLOG$_UTILISATEURS NO YES NO YES NO YES
ATQ VALEURS MLOG$_VALEURS NO YES NO YES NO YES
ATQ VALEURS_DETAILS MLOG$_VALEURS_DETAILS NO YES NO YES NO YES
ATQ VEHICULES MLOG$_VEHICULES NO YES NO YES NO YES
36 ligne(s) sélectionnée(s).
SQL>
I supposed that is the result of the MLOG of the MVIEW associated with my new server. How can I be sure that the MLOG associated with the old one are really deleted ?
Thank you

Problem using Function Module IDOC_INBOUND_ASYNCHRONOUS

Hi friends,
I have a critical problem load idoc ARTMAS05. I development a program for load the data with idoc but my program call the function module IDOC_INBOUND_ASYNCHRONOUS close my session of the SAP GUI and lose the load. This problem begining today because yesterday was work well. This morning when I'm load the idoc gave to me a short dump with this message "SNAP_NO_NEW_ENTRY" I have find some notes and obtained this note 17537.
Note Solution
Solution
When the SNAP Table is full: Reorganize the table e.g. via Transaction ST22->Go to->Reorganize. Please also refer to Note 16083. This may lead to other errors of this kind since not all dumps e.g. from SM21 can be displayed.
In case of database problems, the errors should no longer occur with new short dumps after correcting the database error. Here, other errors of this kind may occur in SM21 as well.
After apply the correction begin the error that I close me the Session of SapGui and lose all my data proccessing. Please need your help.
Thank and regards..

Hi Sir,
I am also facing the same issue...i need to update dependents Information Date Of Birth n Perid(Which is stored in IT0106)...in IT 0021..
Kindly correct my code....
I am using the following code for this...
data: w_return type bapireturn1.
data: p0021_struc TYPE p0021,
      p0106_struc TYPE p0106,
      p_pskey   TYPE pskey.
start-of-selection.
get pernr.
p0021_struc = p0021.
p0021_struc-favor = 'Gaurav'.
p0021_struc-fgbdt = '05/10/1955'.
Move p0021_struc-favor to p0021-favor.
p0106_struc = p0106.
p0106_struc-stras = '2235 BOmbay Road'.
p0106_struc-perid = '123456789'.
MOVE p0106_struc-stras to p0106-stras.
Enqueue personnel number
call function 'BAPI_EMPLOYEE_ENQUEUE'
    exporting
      number = pernr-pernr
    importing
      return = w_return.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
    EXPORTING
      infty            = p_pskey-infty
      number           = p_pskey-pernr
      subtype          = p_pskey-subty
      objectid         = p_pskey-objps
      lockindicator    = p_pskey-sprps
      validityend      = p0021-endda         " '99991231'
      validitybegin    = p0021-begda
      record           = p0021_struc
      operation        = 'mod'
      tclas            = 'A'
      dialog_mode      = '2'
     nocommit         = p_test
      VIEW_IDENTIFIER = '07'              "p0003-viekn
      secondary_record = p0106_struc
    IMPORTING
      return           = w_return
     key              = familykey
    EXCEPTIONS
      OTHERS           = 0.
Enqueue personnel number
call function 'BAPI_EMPLOYEE_DEQUEUE'
    exporting
      number = pernr-pernr
    importing
      return = w_return.

All Qualifications date is Maintained as 01.01.1900

Hi Friends,
In Infotype 24 it is displaying as " Change profile period from 01.01.1800" and the qualifications are created from 01.01.1900. I could not understand how to change this.
In the relationships there are different dates, qualifictions are assigned to employees on the date of their birth.
Pls let me know how to change this. Even i cannot delete this relationships
Pls let me know if any one has faced similar problem
Thanks
HRuser

Hi Dilek,
Thanks for the OSS note, we have cleared SNAP table now it is showing error in PAD31
is there some thing i am missing in relationships. ??
Runtime Error DBIF_RSQL_SQL_ERROR
Exception        CX_SY_OPEN_SQL_DB
Occurred on     10.09.2008 at   10:48:39
An SQL error occurred when accessing a table.
What happened?
What can you do?
Make a note of the actions and input which caused the error.
To resolve the problem, contact your SAP system administrator.
You can use transaction ST22 (ABAP Dump Analysis) to view and administer
termination messages, especially those beyond their normal deletion
date.
Error analysis
An exception occurred. This exception is dealt with in more detail below
. The exception, which is assigned to the class 'CX_SY_OPEN_SQL_DB', wasneither
caught nor passed along using a RAISING clause, in the procedure"ADATA_DB" "FORM)"
Since the caller of the procedure could not have expected this exception to occcur, the running program was terminated.
The reason for the exception is:
How to correct the error
The exception must either be prevented, caught within the procedure "ADATA_DB"
"(FORM)", or declared in the procedure's RAISING clause.
To prevent the exception, note the following:
Database error text........: "ORA-01653: unable to extend table SAPR3.HRPAD31
by 80 in tablespace PSAPSTABD"
Internal call code.........: "[RSQL/INSR/HRPAD31 ]"
Please check the entries in the system log (Transaction SM21).
You may able to find an interim solution to the problem
in the SAP note system. If you have access to the note system yourself, use the following search Criteria:
"DBIF_RSQL_SQL_ERROR" CX_SY_OPEN_SQL_DBC
"SAPLRHAP" or "LRHAPF1K"
"ADATA_DB"
System environment
SAP Release.............. "620"
Application server....... "Development"
Network address.......... "200.200.200.10"
Operating system......... "Windows NT"
Release.................. "5.2"
Hardware type............ "2x IA64 Level 3"
Character length......... 8 Bits
Pointer length........... 64 Bits
Work process number...... 1
Short dump setting....... "full"
Database server.......... "Development"
Database type............ "ORACLE"
Database name............ "VC3"
Database owner........... "SAPR3"
Character set............ "English_United State"
SAP kernel............... "640"
Created on............... "Aug 16 2007 23:23:39"
Created in............... "NT 5.0 2195 Service Pack 4 x86 MS VC++ 13.10"
Database version......... "OCI_920_SHARE "
Patch level.............. "196"
Patch text............... " "
Supported environment....
Database................. "ORACLE 9.2.0.., ORACLE 10.1.0.., ORACLE
User, transaction...
Client.............. 600
User................ "HUSER"
Language key........ "E"
Transaction......... "PP01 "
Program............. "SAPLRHAP"
Screen.............. "MP100100 6000"
Screen line......... 16
Information on where terminated
The termination occurred in the ABAP program "SAPLRHAP" in "ADATA_DB".
The main program was "MP100100 ".
The termination occurred in line 57 of the source code of the (Include) program LRHAPF1K"
of the source code of program "LRHAPF1K" (when calling the editor 570).
Processing was terminated because the exception "CX_SY_OPEN_SQL_DB" occurred in
the procedure "ADATA_DB" "(FORM)" but was not handled locally, not declared in the RAISING clause of the procedure.
The procedure is in the program "SAPLRHAP ". Its source code starts in line 8 of the (Include) program "LRHAPF1K ".
Source code extract
Dilek is there some thing i am missing some relationship with 031
Pls advise

ABAP runtime errors SNAP_NO_NEW_ENTRY

The following errors occured just after login, can anyone tell me how to handle it?
ABAP runtime errors SNAP_NO_NEW_ENTRY
Occurred on 0000.00.00 at 13:47:44
Runtime error: Unable to write short dump.
What happened?
The current ABAP/4 program " " had to be terminated because
one of the statements could not be executed.
This is probably due to an error in the ABAP/4 program.
Unfortunately, the original cause of the error cannot be determined
because there is no suitable short dump in the table SNAP (which
records information about the point of termination).
termination).
What can you do?
Note the actions and input that caused the error.
Inform your SAP system administrator.
You can print out this message by choosing "Print". Transaction ST22
allows you to display and manage termination messages, including keeping
them beyond their normal deletion date.
Error analysis
Error analysis
Unfortunately, the original cause of the error cannot be
determined, since there is no suitable short dump in table SNAP.
The table SNAP probably already contains a number of short dumps
and cannot accept any more. Please check the situation using the
system log.
The table SNAP contains all the short dumps for the last 7 days.
How to correct the error
Check the system log for each cause of error.
More space probably needs to be provided for table SNAP
using database means.
If the error occurred in a non-modified SAP program, you may be
able to find a solution in the SAP note system.
If you have access to the note system yourself, use the following
search criteria:

补充两句：
1. SNAP表的Reorganization应该在后台通过定期的（每天）job执行，参看Note 16083。
2. 如果登录系统即发生Dump，怀疑是否SNAP的table space是导致这个Dump的原因，考虑可能有其它致命错误。如果登录后还可以执行transaction，尝试执行SM21，DB02检查。

Short dump in Production system !!!

Hi Experts,
We have getting a short dump for all actions in Production system. Suppose if we use se38 and tried to press display it shows a short dump error. Despite when we tried to use tcodes or using LSMW or try to execute a program or like this all type of actions its throws a short dump error. Dont know what is the reason behind that since the short dump is not the defined the reason for the dumb. Have any of you experts got this type of experience?. Pls give your ideas. Thanks in advance.

Hello Kavi,
Contact your basis team. SNAP is a table which holds all ABAP dump. It looks like SNAP table is full and cannot accomodate new entries.
In any production enviornment, the SNAP entires will be deleted regularly and only dumps for the last 8 days will be available
Check if any job(SM36 or table tbtcp) is running for this program RSSNAPDL in your production system.
Thanks

ABAP runtime error: snap_no_new_entry

Hi All,
We got the above error.
We tried ST22 --> Go to --> Till here I can go only.....I am not able to Reorganize.
As well as I tried Reorganize again its Throw the DUMP.
Plz Suggest Other Answer.
Regards,
Rableen

Hi Rableen,
ABAP runtime error: snap_no_new_entry.
The error implies SNAP table is full in the SAP system and it cannot write new entries. Since you tried to perform reorganize using ST22 and it failed, I would request you to do the following
1) Check whether Transaction log is full. If yes, then either take backup of transaction log or shrink the same.
2) Restart SAP and database.
3) Repeat the ST22 dump Re-organization process.
Hope this helps.
Regards,
Deepak Kori

Need help with database error

hi i get this error when trying to create a program -
> Could not allocate space for object 'SNAP' in database 'D01' because the 'PRIMARY' filegroup is full.
can someone tell me how to fix this problem.
thanks in advance

Yes,
Wat version of SQL are you using?
For SQL 2000 logon to Enterprise Manager, from the console window navigate to the database and check the name of the database that you have provided. right click and go to properties and check the "datafiles" tab. At the bottom of the screen you will find file properties, check wat are the properties.
also you can delete the data from SNAP table by running some standard progam "RSSNAPDL". Refer SAP Notes 11838, 40918 and 126974 and then implement the program in your system so that the SNAP table doesnt get full.
Thank you
Abhijeet

ABAP/4 runtime error SNAP_NO_NEW_ENTRY

Hi All,
I am unable to login in to my SAP server, after entering user id and password, the below ABAP Dump is displayed
ABAP/4 runtime error SNAP_NO_NEW_ENTRY
I have checked the SAP notes, but no luck
Please advise
SAPXPT

Hello,
SAP note 17537 describes the following :
The error may be caused by the following:
- Table SNAP is full,
- short dump was not written due to database problems,
- short dump has already been solved by reorganization.
So check if the SNAP table is full or if there is a general database problem.
Probably it is the last one, maybe a connection problem to the DB, archiver stuck, ...
Can you still connect to the database with the command : R3trans -d
Merry Christmas,
Wim Van den Wyngaert

Short dumps

hI
Can any one explain me the key feautres in analyzing short dumps if we get for any ABAP program.
Thanks.
Venkat.

ABAP Dump Analysis (ST22)
All the data saved in SNAP table. & text messages saved in SNAPT.
ABAP Dumps is the default workspace for the Logs and ABAP Dumps navigator group. The ABAP Dumps workspace provides status information for each mySAP ABAP dump generated for the mySAP managed system that you are monitoring. ABAP Dumps is a predefined workspace that contains the following specific information for each dump:
u2022     Program associated with the dump
u2022     Host computer where the dump originated
u2022     User who created the dump
u2022     Date and time the dump was created
u2022     Names of the instances associated with ABAP dumps
u2022     Summary count of dumps by program
u2022     Summary count of dumps by user
You can use the data for specific dumps for the following purposes:
u2022     Identify the number of ABAP dumps generated for a specific mySAP instance
u2022     Identify runtime problems that are occurring on your system
The workspace table view has predefined launch definitions. You can use the launch definitions to run the following transactions on the mySAP system:
Some common dumps : -
1) COMPUTE_INT_TIMES_OVERFLOW
Whole number overflows on multiplication & addition operation.
Always Declare Result field Larger.
per =    ( act / budget ) * 100.
bal =    it_out1-balance + bal .
pr =     it_out1-t_wtext_pr + pr
2) COMPUTE_BCD_OVERFLOW
A value does not fit in a calculation field.
You may need to define the result field to be larger.
1.     Showu2019s error on internal table. (multiplication & addition)
3) Time out
Reason for error:-
After a certain time, the program terminates to free the work process
for other users who are waiting.
2.     The current setting is 1800 seconds.
3.     Primary Index not Used & Sequencing not proper.
4.     Avoid Nested Loops.
5.     Avoid to use select single in loops
6.     Avoid using INTO CORRESPONDING TO
7.     Avoid using SELECT in loops.
8.     SORT the internal table always and use BINARY SEARCH.
9.     for all entries that time check SY-TFILL.
4)     DBIF_RSQL_INVALID_RSQL
The data read during a SELECT access could not be inserted into the
target field.
Check the Sequence of the select Query field & internal table fields.
5)     DBIF_DSQL2_OBJ_UNKNOWN
Because of Database is not properly connected to Level 2 server.
1)     when ur using set Connection command to connect Level 2 server
That time check the value of Sy-subrc = 0 .
6)     SAPSQL_ARRAY_INSERT_DUPREC
Its show the Error when you are going to insert duplicates record in database using
Insert command.
There are three ways to solve this problem.
1     Delete adjacent duplicate.
ii.     Insert ACCEPTING DUPLICATE KEYS
iii.     modify command
7.     CONVT_NO_NUMBER
Solution:-The program attempted to interpret the value "RTGS " as a number, but
since the value contravenes the rules for correct number formats,
this was not possible.
1.     put Input Validation using If Query
2.     when programmer try to pass the Char value to num field
3.     or trying to perform Pack or unpack operation on Char. Fields.
8.      CALL_TRANSACTION_NOT_FOUND
Transaction " " is not listed in the table of transaction codes
The current ABAP/4 program uses CALL TRANSACTION to call the Transaction
& Leave to Transaction
Table TSTC (Transactions) contains no entry for the Transaction " ". This could be due to a program error (incorrect transaction code specified).
Ensure that upper/lower case is correct.
1.     Use capital Values because itu2019s case sensitive.
9)     Table_invalid_index.
When you are going to perform Read Insert, update, Delete operation Using index Value & index value = 0. That time it shows this error.
Check the index value is less then or equal to zero.
10)     DATASET_CANT_OPEN
OPEN DATASET / TRANSFER / CLOSE DATASET
Check Sy-subrc = 0.
11     LIST_TOO_MANY_LPROS
At present, the maximum permitted number of nested screen levels is
restricted to 50.
Set by BASIS.
Use leave to transaction u2018Tcodeu2019 to close all Screens at the end of the program.
12     . DBIF_DSQL2_SQL_ERROR
Because of Database is not properly connected to Level 2 server.
1 when ur using set Connection command to connect Level 2 server
That time check the value of Sy-subrc = 0 .

Error SNAP_NO_NEW_ENTRY or DBIF_RSQL_SQL_ERROR

Hi,
I get Error SNAP_NO_NEW_ENTRY or DBIF_RSQL_SQL_ERROR.
Need help
Points willl be rewarded.
Thanks
Vinayak

Hi
I would guess that your transaction log is full.
SNAP table is used to store shortdumps and this error means the table cannot be written to.
N.P.C

Snap_no_new_entry error in sap

Hi All,
we are facing snap_no_new_entry ump for all SAP transaction in one of the SAP system.
can some please suggest what was the cause and how to resolve this issue.
OS ; Linux
DB is Sybase
Thank you.
Siva

Hi Kiran,
If you get a dump at logon you should be able to call SE38 and run RSSNAPDL which will delete the old entries from the SNAP table.
Try it, Also make sure that all the housekeeping jobs are scheduled so this doesn't happen again.
Regards,
Deva

Snap_no_new_entry ABAP dump coming while ST22 is reorganized regularily

Dear Friends,
snap_no_new_entry ABAP dump comes and hamper all activities while ST22 is reorganized daily. After restarting the server, It is working fine for a day only. Can you suggest in this regard to fix this problem permanently?
System Environment : SAP ECC 6.0, AIX, DB2
Table spaces :
Tablespace
Name
TS Type
KB Total
Percent Used
KB Free
Page Size (KB)
High-Water Mark
(KB)
No. Containers
Contents
TS State
AUTORESIZE
PSAPTEMP16
SMS
64
100.00
0
16
0
4
Temporary objects
Normal
NO
SYSTOOLSTMPSPACE
SMS
64
100.00
0
16
0
4
Temporary objects
Normal
NO
ECP#BTABD
DMS
6422528
99.94
3680
16
6418720
4
Large objects
Normal
YES
ECP#ES702DX
DMS
35586048
99.94
21888
16
35564032
4
Large objects
Normal
YES
ECP#EL702DX
DMS
18972672
99.93
13632
16
18958912
4
Large objects
Normal
YES
SYSCATSPACE
DMS
2785280
99.67
9216
16
2775936
4
Regular data
Normal
YES
ECP#ES702IX
DMS
7471104
99.58
31456
16
7439520
4
Large objects
Normal
YES
ECP#STABD
DMS
3637248
99.58
15424
16
3621696
4
Large objects
Normal
YES
ECP#POOLD
DMS
6258688
99.54
28832
16
6252608
4
Large objects
Normal
YES
ECP#POOLI
DMS
3637248
99.47
19200
16
3617920
4
Large objects
Normal
YES
SAPTOOLS
DMS
3053056
99.14
25120
16
3027808
4
Large objects
Normal
YES
ECP#PROTD
DMS
851968
98.94
9056
16
842784
4
Large objects
Normal
YES
ECP#BTABI
DMS
2457600
98.81
29344
16
2428128
4
Large objects
Normal
YES
ECP#CLUD
DMS
491520
98.75
6144
16
485248
4
Large objects
Normal
YES
ECP#STABI
DMS
2424832
96.81
77280
16
2400160
4
Large objects
Normal
YES
ECP#SOURCED
DMS
458752
95.02
22848
16
435776
4
Large objects
Normal
YES
ECP#SOURCEI
DMS
458752
93.34
30528
16
428096
4
Large objects
Normal
YES
SYSTOOLSPACE
DMS
229376
92.70
16736
16
212512
4
Large objects
Normal
YES
ECP#EL702IX
DMS
98304
84.29
15424
16
82752
4
Large objects
Normal
YES
ECP#LOADD
DMS
131072
79.86
26368
16
104576
4
Large objects
Normal
YES
ECP#PROTI
DMS
131072
77.57
29376
16
101568
4
Large objects
Normal
YES
ECP#CLUI
DMS
65536
63.31
24000
16
41408
4
Large objects
Normal
YES
ECP#DDICI
DMS
1015808
63.13
374464
16
986816
4
Large objects
Normal
YES
ECP#DDICD
DMS
5439488
61.23
2108736
16
5436512
4
Large objects
Normal
YES
ECP#DOCUD
DMS
65536
51.91
31456
16
53024
4
Large objects
Normal
YES
ECP#LOADI
DMS
32768
48.53
16800
16
15840
4
Large objects
Normal
YES
ECP#DOCUI
DMS
65536
36.25
41696
16
35744
4
Large objects
Normal
YES
ECP#USER1D
DMS
32768
30.69
22624
16
10016
4
Large objects
Normal
YES
ECP#USER1I
DMS
32768
30.00
22848
16
9792
4
Large objects
Normal
YES
SAPEVENTMON
DMS
51200
28.38
36576
16
14496
4
Large objects
Normal
YES
ECP#DIMD
DMS
32768
25.29
24384
16
8256
4
Large objects
Normal
YES
ECP#DIMI
DMS
32768
25.29
24384
16
8256
4
Large objects
Normal
YES
ECP#EL702I
DMS
32768
25.29
24384
16
8256
4
Large objects
Normal
YES
ECP#FACTD
DMS
32768
25.29
24384
16
8256
4
Large objects
Normal
YES
ECP#FACTI
DMS
32768
25.29
24384
16
8256
4
Large objects
Normal
YES
ECP#ODSD
DMS
32768
25.29
24384
16
8256
4
Large objects
Normal
YES
ECP#ODSI
DMS
32768
25.29
24384
16
8256
4
Large objects
Normal
YES
ECP#ES702I
DMS
6651904
0.12
6643520
16
8256
4
Large objects
Normal
YES
ECP#EL702D
DMS
17334272
0.05
17325888
16
8256
4
Large objects
Normal
YES
ECP#ES702D
DMS
31391744
0.03
31383360
16
8256
4
Large objects
Normal
YES

Hi Dharmendra,
The error implies SNAP table is full in the SAP system and it cannot write new entries. Since you tried to perform reorganize using ST22 , I would request you to do the following
1) Check whether Transaction log is full. If yes, then either take backup of transaction log or shrink the same, you can check db2diag.log for more details.
Note : As per log if any process making the log to fill , kindly terminate it
2) Restart SAP and database.
3) Repeat the ST22 dump Re-organization process.
Hope it helps
BR Vaibhav

RABAX: level LEV_RX_WRITE_SNAP failed

Hello,
I am performing some tests in our SAP system on HP UX, Oracle. One of this test includes cancelling a wp with core so it generates an ABAP dump. The WP gets cancelled, but No dump information is being written. In the WP trace file, I see this information. Something to do with RABAX and LEV_RX_WRITE_SNAP failed. I also deleted some entries from SNAP table using standard background job, but that did not help either.
PLEASE help!
======================
M PfStatDisconnect: disconnect statistics
M Entering TH_CALLHOOKS
M ThCallHooks: call hook >SAP-Trace buffer write< for event BEFORE_DUMP
M TrThHookFunc: called for WP dump
M ThCallHooks: call hook >ThrSaveSPAFields< for event BEFORE_DUMP
M ThrSaveSPAFields: save spa fields
M Entering ThSetStatError
M ThIErrHandle: don't try rollback again
M ThIErrHandle: call ThrCoreInfo
A RABAX in unkown environment: task_type=0, run level=8, rabax state=80000000 ztta_task_type=0
( 0) 0x40000000017503ec   CTrcStack2 + 0x2bc [dw.sapRP1_DVEBMGS10]
( 1) 0x4000000001750120   CTrcStack + 0x18 [dw.sapRP1_DVEBMGS10]
( 2) 0x4000000001db5c78   rabax_CStackSave__Fv + 0x100 [dw.sapRP1_DVEBMGS10]
( 3) 0x4000000001dc22bc   ab_rabax + 0x1e1c [dw.sapRP1_DVEBMGS10]
( 4) 0x4000000001db5734   ab_CoreInfo + 0xd4 [dw.sapRP1_DVEBMGS10]
( 5) 0x4000000000e90e34   ThrCoreInfo + 0x14 [dw.sapRP1_DVEBMGS10]
( 6) 0x4000000001041818   ThIErrHandle + 0x15e8 [dw.sapRP1_DVEBMGS10]
( 7) 0x400000000104021c   ThErrHandle + 0x24 [dw.sapRP1_DVEBMGS10]
( 8) 0x400000000112a3e4   ThSigHandler + 0xa4 [dw.sapRP1_DVEBMGS10]
( 9) 0x4000000000b3d790   SigIGenAction + 0x668 [dw.sapRP1_DVEBMGS10]
(10) 0xc0000000002f9398   sigreturn [/usr/lib/pa2064/libc.2]
(11) 0xc0000000002ff2ec   semopsys + 0x2c [/usr/lib/pa20_64/libc.2]
(12) 0xc000000000306ecc   semop + 0xcc [/usr/lib/pa2064/libc.2]
(13) 0x4000000000ee5348   WtRstOsEvt + 0x68 [dw.sapRP1_DVEBMGS10]
(14) 0x4000000000ee5c4c   EvtWtRst + 0xcc [dw.sapRP1_DVEBMGS10]
(15) 0x4000000001054eb8   ThRqWaitFor + 0x3a0 [dw.sapRP1_DVEBMGS10]
(16) 0x40000000010305dc   ThRqAccept + 0x200c [dw.sapRP1_DVEBMGS10]
(17) 0x400000000103421c   ThReceive + 0x57c [dw.sapRP1_DVEBMGS10]
(18) 0x4000000001028fdc   TskhLoop + 0x13dc [dw.sapRP1_DVEBMGS10]
(19) 0x4000000001021ba8   tskhstart + 0x1e0 [dw.sapRP1_DVEBMGS10]
(20) 0x4000000000dccfe4   DpMain + 0x484 [dw.sapRP1_DVEBMGS10]
(21) 0x4000000002276bfc   nlsui_main + 0x14 [dw.sapRP1_DVEBMGS10]
(22) 0x4000000000a38154   main + 0x14 [dw.sapRP1_DVEBMGS10]
(23) 0xc00000000000a770   $START$ + 0xa0 [/usr/lib/pa20_64/dld.sl]
A TH VERBOSE LEVEL FULL
M SigIRegisterRoutine: handler for signal 11 installed (ab_catch_dumperror)
M SigIRegisterRoutine: handler for signal 10 installed (ab_catch_dumperror)
A ** RABAX: level LEV_RX_WRITE_SYSLOG entered.
A ** RABAX: level LEV_RX_WRITE_SYSLOG completed.
A ** RABAX: level LEV_RX_WRITE_SNAP entered.
M SigIRegisterRoutine: handler for signal 10 installed (ab_catch_dumperror)
A ** RABAX: level LEV_RX_WRITE_SNAP failed.
============================================

Hello,
No one has come across this error?
It is only that the SYSTEM_CORE_DUMPED error does not get registered, other Dumps are visible. What is the core dump doing different that the others?
Please help with this error
Thanks

SNAP table

Similar Messages

Maybe you are looking for