Backup of specific Table

[Former Member]

Hi,

Is there any way i can backup a specific table?

Can anybody give some advise? Its very urgent

Regards,

Mofizur

[markus_doehr2]

SAP tables usually have dependent tables, so backing up "one table" will not help you in most cases because you will need to backup the dependent table too.

Since you didn´t mention which table (customer, standard) you are trying to "backup", it´s impossible to give an advise.

You could e.g . write an ABAP that copies the data from one table to another one.

--

Markus

[Former Member]

Hi Markus,

Thanks alot for ur response.

The tables are:

INOB,KSSK and AUSP.

Waiting for ur reply.

Regards,

Mofizur

[markus_doehr2]

Check with SE11 - Utilities - Graphics, there you will see the relation to other tables.

Short answer: You can´t backup those tables on their own, dependent tables must be saved too.

--

Markus

[Former Member]

you cannot backup those tables stand-alone. forget about it. you'll need all the depending tables including the number-ranges those tables were last working with, also the overall object tables. the tables you name are classification, so without the relations to the objects classified with data from those tables they are of no use to you!

cheers,

fish

Message was edited by:

Mylene Euridice Dorias

[Former Member]

Hi,

But how will I be able to know which are the <b>"all depending tables including the number-ranges those tables were last working with",</b>

Will the whole tablespace backup will be a better idea?

Regards,

Mofizur

[Former Member]

won't work. classification might include dependencies to (i don't know the english term, in german it is 'Beziehungswissen') which can include procedures (tx. SE37) or data concerning variant configuration - i doubt, you'll find all of those in only one table-space. why not backup the whole database and get it over with?

cheers,

fish

[lbreddemann]

Hi Mofizur,

there is a reason why there is no single-table-backup functionality in any serious database.

The reason is what is called the "single version of truth"-concept that basically says:

any specific state of the database as a whole has to be consistent and represents "the reality" for the application based on this database.

Due to information de-composition and normalization it's often impossible to take one table from a database and back it up in a way that allows a restore so that after the restore the database is consistent again.

Even if you would find an option (e.g. exp/expdb, r3load, loader etc.) to copy the table data to another location - how would you ensure the logical consistency of the data on restore time?

Perhabs its better you tell us, what exactly you want to accomplish - most often it's easier to find a special solution than a general one.

KR Lars

[Former Member]

Hi,

We have raise an OSS due to some problem.

Last reply from SAP was:

-

---

the problem is caues by a database inconsistency.

The following entry in table INOB is wrong and should be deleted.

• ***** ******

I ran report RCCLZUOB in display mode that found several more

inconsistencies.

Please run this report in display mode and check the result.

From my point of view the report has to be run in deletion mode after

that to remove the wrong database entries.

<b>It might be usefull to have a backup of tables INOB KSSK and AUSP</b>.

-

---

Thats why my development team is beating my head to take a backup and if required we have to restore it.

Regards,

Mofizur

[Former Member]

nevertheless. backing up those single tables will not be consistent if you try to reload them - see Lars' and my answers. As for RCCLZUOB: this report is 'mostly harmless' - i used it often to remove incosistencies in classification which occur after release strategies in MM-PUR were deleted (and as you might know, those classifcations cannot be transported properly, only ALE- distributed). make sure you have all the latest corrections to that report and then run it in update - mode.

[lbreddemann]

Hi Mofizur,

Ok, basically the best way to respond to such a 'recommendation' is to specifically ask the Support consultant that gave it to you.

In this special case I would <b>assume</b> that it would be sufficient to create a copy (not a backup) of the table via

CREATE TABLE INOB_COPY AS SELECT * FROM INOB;

After that you can run the report to fix the inconsistency.

With such a copied table the application developers should then be able to reensure the consistency of the database as a whole - just in case there happen some failure while the fixing-report runs.

Nevertheless: ask the support consultant what he thinks he recommended there to you and why. Ask him how he would "restore" the saved data in a consistent manner.

KR Lars

[former_member230861]

To create without entries

create column table bkp_tablename as (select * from tablename WHERE 1 = 2)
or
CREATE TABLE BKP_TABLENAME LIKE TABLENAME WITH NO DATA;



With entries
CREATE TABLE BKP_TABLENAME LIKE TABLENAME WITH DATA;