BW: handling Link errors

The process chain reported an error last night. The problem was very strange.

This is a GL model. infopackage says error occurred in the data selection every time it is executed. st22 and sm21 have been checked in BW, and there is no exception.

After thinking about it, people all said that the problem lies in the extraction, so we should check it with R3.

So environment --> job overview --> Source System

Sure enough, it was canceled. That is to say, this is not the current error, but because of the past.

PS: I have encountered a very disgusting problem once because the backend process of R3 occupies extractor resources and keeps yellow light and zero data records.

In addition, you cannot underestimate the step-by-step analysis of monitor. Sometimes it is very useful, but it is best to use en to log on and there will be problems with translation. Here we will also tell you that the problem lies in the source system.

Well, since the problem lies in R3, what is the problem.

Sm59. Test the RFC connection. No problem.

Sm51, look at the server, active, very normal

Sm50

Let's see what is running in the background. After clicking the CPU button, I found that a process has been executed for about 19 hours. My account is actually mine... hey, it's not from work yesterday.

Turning back to sm21, I saw an error.

If you don't want to talk about it, simply kill the process and then extract it. Everything is OK.

In fact, it is quite simple to sum up, either it is a problem with BW, maybe it is activation, routines, data, or the uploading sequence of abnormal fi data sources, sometimes, due to session and process, or RFC problems, logs are full, table spaces are full, and nodes are full, which may affect data extraction. However, it is relatively easy to find. After all, there is a basis.

At R3, it is relatively troublesome and the problem is very complicated. Especially for enhanced data sources, I have encountered a method that can directly run the dead but run the sm50 process once and for all, but pay attention to security.

In addition, Mr. Chen has a blog, which is quite good, but he hasn't used such a complicated one. Transfer

 

 

 

How to deal with the problem of no response for a long time when a large amount of data is pumped?

During the launch of a project, due to the huge data volume of some models, the pumping speed is very slow and the traffic is in the yellow light for a long time. The message of monitor is: Missing messages.

 

After several similar issues, I have summarized some experiences:

 

 

First, check whether some of the system's parameter settings are correct. The parameters related to the number of pumping include:

1. Check whether the system connection is normal: sm59

2. Configure transmission settings for sbiw:

IDOC frequency: How many IDOC messages are returned, and then an IDOC message is returned. (In monitor, you must receive the IDOC message to confirm that the data transmission is complete. Otherwise, wait until the missing messages error is reported ). When the IDOC data packet is large, it is recommended to reduce the frequency so that problems can be detected in a timely manner. Generally, the value range is 5-10, not greater than 20.

IDOC data packet: each data packet contains several records, usually between 5000 and ~ In the range of 20000. Generally, each loading process should have no more than 100 data packets. Therefore, it is best to set this value to a greater value when a large amount of business data is extracted. For example: 50000 (Oracle/SQL Server) or 10000 (Informix)

3. Estimate the maximum waiting time for infopackage execution based on the data volume, and set the timeout time.

4. Set the maximum number of trfc connections: sm58

 

Then, the problem is handled in a timely manner based on the information reported by the monitor:

1. If the XXXX from yyyy of the monitor remains changing, it indicates that the data is still being transmitted. Normally, it will continue until XXXX = yyyy, where yyyy is the source data volume.

2. If the XXXX from yyyy of the monitor does not move, there is a problem. Check the detail message. Missing messages usually occurs, because too many pumping threads cause SQL deadlocks. At this time, we should use sm50 to check whether the pumping process is at work. If the pumping process does not move, sm58 should be taken to observe the trfc situation, the trfc with the manual execution (F6) deadlock and the trfc with a long wait. At this time, the process in sm50 should continue to work.

3. Observe the monitor until all data is extracted to BW and processed. If all the data is exhausted (XXXX = yyyy), but it is still in the yellow or red light status of missing messages, you can manually set the red request, then manually update the data packet, and then manually set the green. Sometimes, you also need to roll up manually.

4. If the data volume is large, it is best to perform full update first and then perform initial without data.

5. If the data volume is large (more than 10 million), it is best to count the data by time period or credential number in full update.

This was written a long time ago and is not comprehensive enough. Let's put it up first and change it later. You are welcome to add...

Looking forward to an unknown journey with hope.

 

Pasted from