Shulou(Shulou.com)06/01 Report--

Phenomenon description

Dameng also has its own logical backup tools (dexp, dimp) similar to Oracle. For more information, please refer to the official manual dexp&dimp.pdf.

However, we sometimes encounter the problem of string truncation when doing dimp.

How can we solve this kind of problem?

Limited we must be very clear, string truncation of this error, it must be a lack of accuracy, here only for two possible situations, describe the problem.

There are only two issues to consider:

Whether the table structure is inconsistent, that is, the table of dexp is varchar (500), and the table we imported is only varchar (400).

This is rare because sometimes we often create new imports for full users, and the table structure is also brought in from the source.

Whether the character set of the database instance on the source side of the 0.Dexp is the same as that of the database instance on the destination side of dimp.

This is a problem that we may not pay attention to.

Treatment method

Processing method 1: check whether the table structure is consistent

Whether the table structure is inconsistent, that is, the dexp table is varchar (500), and the table we import is only varchar (400).

This problem is easy to understand, that is, literally, we just need to change the accuracy of the destination table to be consistent with the source, re-empty the table, and then import it.

Method 2: check the character set of database instance

When we encounter this problem, we actually encounter this problem when we dexp the database from the database instance of UTF-8 and dimp it to the database instance of GB18030.

By default, the precision of the varchar field of the Dameng database instance is bytes, while for Chinese characters, the byte occupation under UTF-8 coding is larger than that under GB18030 coding.

So on the other hand, the table structure moved by dexp&dimp is the same, for example: all varchar (400), the number of men who can be stored is not the same.

Note:

-for database instances within the same project and instances that may need to transfer data to each other, be sure to plan and set the underlying database parameters (including character sets) to be consistent!

-for database instances in the same project, be sure to maintain consistency. Data transmission is required in different projects, but the correlation does not exist and the character set cannot be consistent. You can manually enlarge the precision of the varchar field on the destination database instance. Why it can be treated in this way has been explained in method 2.

This is a script that doubles the precision of all the varchar fields in the target table in the database instance (executed as SQL): you can check the table by controlling the cursor.

Declare

Begin

For rs in (

Select sch.name sch,tab.name tab,col.name col,COl.length$ len from sysobjects sch,sysobjects tab, syscolumns col

Where sch.id=tab.schid and sch.name | |'. | | tab.name in (

'USER.TABUTKMONITOR'

'USER.TABUTHORIZATIONRISKLOG'

'USER.TABUSTOMER'

'USER.TABARD'

'USER.TABOSSREPORT'

'USER.TABUDGETENTITYCARDS'

'USER.TABRANSACTIONLOG'

'USER.TABCCOUNT'

'USER.TABSTOMERINFO'

'USER.TABRANSACTIONLOG'

'USER.TABUTHORIZATIONRISKLOG'

)

And tab.id=col.id and col.TYPE$ in ('VARCHAR','VARCHAR2')) loop

Declare

Begin

Execute immediate 'alter table "' | | rs.sch | |'. | | rs.tab | |'" modify'| | rs.col | | 'varchar (' | | rs.len*2 | |');'

Exception when others then

Print (sqlerrm)

End

End loop

End

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.