cancel
Showing results for 
Search instead for 
Did you mean: 

Unexpected sharing violation during I/O to file...

Former Member
0 Kudos

Dear all,

short intro of myself. I've been working with the SSM database since the beginning of the 90s, primarily as BI developer. The more recent activities with SAP, NW etc are more or less new to me though, although i also worked with the scorecard and the PIP back then, so i have a "fair" clue of that as well.

What i want to ask now, is how i should handle the following scenario. I have one SSM model where i am developing, i.e. creating NKPIs, KPIs, dimensions etc. The customer has a few test users, that are using a different model on the same server, where they are getting to know the SSM application and administration and above all,  are evaluating the data.

I try to create a dumpfile from my development model at the end of the day, and when it is appropriate, i want to load it into the evaluation model. I use the following steps:

sup kill conn to SV

sup chan data SV maxacc update

use SV

load ...

When i issue the final "use" command, i get the error message :"

System> use sv

DB-142:

Unexpected Sharing Violation during I/O to File SV.

Check your Disk Drive or Network."

I have tried stopping the SAPSSAM Listener before these commands also, but no difference. Issuing a "sup sho log" shows that i am the only logged on user. The file is locked in the Windows system as well, if i try to rename it for example, i get a message that it is in use by SAP(!).

The file is obviously locked by another process. I have tried waiting over night, i have tried re-starting the whole "SAP systems" in SAPmmc. The only thing that fixed it was a re-boot of the server.

What am i missing? Is there anything else i should stop, before trying to use the file exclusively?

The system is a stand-alone Windows 2008 Server R2, with SSM 10.

BR,

Hans

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

I'm going to suggest another option here. If you still have problems in the Windows system access it may not be a PAS / SSM issue.

Windows 2008 has a nasty trick. If you install an application and are not administrator, it will create a hidden shadow directory under your user. When you are logged on it maps this to the real directory and acts as if the install was successful. For other users the files "vanish" and cause errors. There is a short section in the install guide telling you which directories need to be openned for access prior to installing.

Perhaps something lke this is happening to you.

Former Member
0 Kudos

Thanks, this sounds worth investigating further. We've had more "sharing violations". What i did then was to kill the lsstcp processes through TASKKILL in DOS (but that's more or less only because i am not allowed to run the Performance Monitor on the server).

This solved the lock on the database file. However, then i had problems with SSM admin not reflecting the changes in KPI names in the database. (Old ones were still there, probably because there were some connections made in the SSM admin between database measures and SSM KPIs), and new ones were displayed with short names. Then i tried to restart Java in the admin interface, but it wouldn't restart at all, the window just went blank and then timed out. So there's definitely something weird going on with the background SW!

I didn't do the installation myself, but i was sitting behind someone. I believe we followed the install guide exactly, but i also re-call some issues with users and access rights. I will check this!

What scares me now, is the only solution to re-install, or can we change directory permissons and so on afterwards?

Former Member
0 Kudos

You can repair. There are a few tricks I'd need to guide you through and for that I'll need to find my notes. First estalish whether this is the problem.

Log on as a different Windows user and got to the PAS HOME directory. See whether the physical database is missing. If it is missing then we have identified the problem and we can focus on the fix. If it is not missing then my suggestion is not the problem.

Former Member
0 Kudos

So, finally we have tested. (since the company in question has out-sourced the IT to an external company, it wasn't easy to get hold of other Windows IDs...)

Unfortunately, the two different users we tried could all see the datbase files (and everything else that i deem essential). So it looks like a dead-end.

Apart from the locked files, we have also experienced that the SSM application doesn't reflect KPI-name changes (Now i am referring to the PAS names or labels). The drop-down boxes have displayed the short names insetaed of the labels, some old changed measures are being displayed. It is like there is a process that should be checking these things, either from within SSM or NW, which occasionally goes haywire... If there's such a thing, maybe this rougue process also causes the locks?

Former Member
0 Kudos

Concerning the display of old names. I'm sort of guessing here but SSM must be getting these names from somewhere. If you're certain they're no longer in your database, then there are three possibilities I can think of;

It could be a caching problem with your web browser or web server.

Alternatively it might indicate SSM is pointing at some other (older) PAS cube. Do you have an older version of the PAS cube? In this case the model connections would be the source of the problem.

Finally, despite the evidence to the contrary, it could still be the Windows 2008 issue. Once Windows creates a ghost copy, even if you later create a database in the real home directory, Windows will continue to use the ghost copy in preference to the real one. Try deleting a PAS KPI and see whether SSM can still see the old deleted one.Try adding anew member to a dimension and see whether SSM still sees the old dimension.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Hans,

Try to restart JPIP (using tools page).

Best Regards,

Miguel

Former Member
0 Kudos

Miguel,

thanks, but this doesn't solve the problem. I can't even re-start JPIP from in there, once i have this share violation (can't even bring up the version window.)

Like i wrote, re-starting NW or even the whole "SAP Systems" in the SAPMMC won't help. Only solution is to re-boot the server. Functional, but not so practical...

BR,

Hans

Former Member
0 Kudos

Hi,

Another thing you can try is to put the option EXITCLEAR=YES on LSSERVER.INI to see, after the re-boot, if it never happens again.

Best Regards,

Miguel

Former Member
0 Kudos

Hi Hans,

How goes it?

I've hit this a few times myself so I wrote up some procedures on various steps to fix it.  I'll paste it below.  The bottom line is that you need to kill the rogue lsstcp.exe process on the server that's causing the hang.

Take care,

Tom

Recovering from a PAS Sharing Violation

Sometimes you can encounter a sharing violation in PAS when
attempting to get exclusive access to a cube.
Exclusive access is required to do any write operations to the cube
itself.   A sharing access violation can
be triggered when PAS connections are killed while users are actively using the
cube.

The below log was generated from one of the BAR Cubes
procedures to rebuild the cube.  The log
will exist in the home directory (currently e:\program files(x86)\sap
businessobjects\strategy management\applicationserver\home) and  the file begins with TRACE_ and the file type
is .trc.

LSS>       job CONTROL_VAR COBPWD LIBCOBPWD

LSS>       sup kill con COBPWD

GUEST(1): Process
5480 Killed

GUEST(8): Process
7272 Killed

GUEST(18): Process
9652 Killed

GUEST(21): Process
3952 Killed

GUEST(22):

LSS>       use COBPWD ret exc

DB-142:

Unexpected Sharing
Violation during I/O to File COBPWD.

Check your Disk
Drive or Network

You can see above that a DB-142: error occurred.  When this happens, the correct solution is to
remove the rogue lsstcp.exe process on the server that is triggering the
sharing violation.  The easy way to do
this is to reboot the server, but that is often not viable.  A less drastic way to fix this is to manually
remove all rogue lsstcp.exe processes on the server. 

The below procedure is a conservative approach to fixing
this problem.  Sometimes you can skip the
recycling of NetWeaver CE and/or the stopping of the SAP SM Listener, but I
like to be cautious.  If you follow this
process, you can recover in about 10 minutes.
The system will not be available during that time, however.

The first step is to restart JPIP.  This is necessary to close down all the valid
lsstcp.exe processes.  Run the tools menu
and select “JPIP Session Monitor”.

select “Restart JPIP” .

Next, stop NetWeaver CE.
See below.  Right-click on the PRD
server and select restart

You should always do a soft restart

Next, while NetWeaver CE is recycling itself stop the SAP SM
Listener service to prevent any new lsstcp.exe sessions from starting up.

Next, start the task manager on the server and go to the
processes tab, sort alphabetically.  You
will probably see one or more lsstcp.exe sessions there.  You should see at least one or more.

For each of the processes, select one at a time and hit the
delete key and confirm that you want to stop the process.  When all the lsstcp.exe processes are
stopped, restart the SAP SM Listener.  By
that time, NetWeaver will probably be recycled and you should be back in
business.

If you try to use the cube exclusively and it gives you the below error, then reboot the server.

ENV035:

Database COBPWD
is not available because it is in use by GUEST

for READ
access.  Contact the Database
Administrator for more

Be sure to issue the command “Exit Clear” from the
Application Server Administrator so that the cube is available for normal use.

Former Member
0 Kudos

Thanks Tom!

good to see some familiar names still around .

Unfortunately the Adminsistrators are not allowed to view the TaskManager at the server. (The customer has out-sourced the IT Operations externally...) I ended up with a re-boot, but in the future I guess i can shut down the processes through DOS-command. What worries me is once the customer will run the updates themselves, through E&A, that they will experience similar problems. It wouldn't be too hard to incorporate a batch-file proc in the E&A and/or restart of the JPIP, doing this for the customers, or?

BR,

Hans

Former Member
0 Kudos

Hi,

How often this problem happens to you? regularly?
If is regular, have you considered the possibility of this being a windows 2008 server problem and not a PAS problem?

Best Regards,

Miguel

Former Member
0 Kudos

Hi Hans,

Yes,it IS good to see familiar names around.  Yes, you can stop the processes via dos commands. The process that I have set up at the City of Boston to minimize the chance of hitting this is to go into the Tools menu and restart any connections associated with the cube(s) you are dealing with.

We had hit this problem 2 times in about a 6 month period, which is when we started using the above process and since then (about 5 months) we have not hit it again.  The actual issue happens when user "a" is writing to the cube, and then user "b" (aka you) issues the sup kill conn to command.  I've tried all sorts of things to get around issuing the sup kill conn to command, but unless you're in java you can't stop it any other way.  If you're in java, then you're able to (I forget the specific calls, but they're there and I can get them to you if you want them).

When customers do update models via E&A (Load PAS Model), the java calls that I'm referring to are used, and they're 100% safe - work all the time.  Test it and see.  If you are using the cube in the pas admin, E&A will give you a message that it can't load.

Take care,

Tom

Former Member
0 Kudos

Hi Thomas,

If you try to use the cube exclusively and it gives you the below error, then reboot the server.

ENV035: Database COBPWD is not available because it is in use by GUEST  for READ access.  Contact the Database Administrator for more

Be sure to issue the command “Exit Clear” from the
Application Server Administrator so that the cube is available for normal use.

Any other solution to the above issue, apart from Re-booting server , restarting JPIP , Killing connection in PAS. I am stilling getting the error while updating BW Query in Import Schema

Regards

Former Member
0 Kudos

Thanks a lot for the procedure.

But i want to know if this always is gonna happen, if more than one person is accesing to the application server of SSM?.

Thanks in advance for the response.

Best Regards,

Franco Jordan.

Former Member
0 Kudos

Hi Jordan,

You run the risk of this happening if you have a custom application that issues the "SUP KILL CONN TO <cubename>" command AND another user has the cube in exclusive mode (for writing) and that user has written to the cube or is in the process of writing to the cube.

It's very likely even in the above scenario that the problem will still not occur.  There's usually a very small window of time between when a user writes to a cube and when a checkpoint update occurs to that cube (confirming the write).  This writing typically occurs during the "LOAD CUBE" functionality in Entry & Approval.  My guess is that if the SUP KILL CONN TO command is issued during that small window of time, this error has a greater likelihood of occurring. 

I haven't done enough unit testing to verify this, but I'm basing it on my observations and past history using PAS.

If you don't have a custom application that issues the SUP KILL CONN TO command, you should never get this error.  If you have a custom app that uses SUP KILL CONN TO, you can take other precautions (as described in the procedure) to minimize the risk of this happening.  This error hasn't occurred in probably 2 years at my clients site where the procedure has been followed.

Tom

Former Member
0 Kudos

Tom,

Thanks a lot for the response and explication.

Best Regards,

Franco Jordan