Could not load data from the data source.If you can correct the problem, press the re

5538
9
06-01-2011 05:07 AM
Highlighted
Occasional Contributor III
Hi,

After upgrading to ArcSDE 10 SP2 , i am currently facing an issue whenever i am trying to do editing using ArcMap on the layers. Everytime, i choose to edit, then trying to view (open) the table i face with the below error:


Could not load data from the data source.If you can correct the problem, press the refresh button to reload data.Possible problems can include bad network connection, invalid field,etc.

underlying DBMS error[ORA-01536:space quota exceeded for tablespace 'TS_SDE_LOG_DATA_01'



can you please help?

plz check attached erro image.

thanks,
Reply
0 Kudos
9 Replies
Highlighted
Esri Esteemed Contributor
You need to speak with your database adminstrator about storage allocation in the database.
It's quite possible that this doesn't have anything to do with SP2 application.

- V
Reply
0 Kudos
Highlighted
Occasional Contributor III
Thank You Vince for your feedback. I will contact my DBA.

However, i am now facing with another type of error whenever i am trying to edit a table:


Underlying DBMS error [Error executing stored procedure <schema>.logfile_util.logfile_pool_get_id::ORA-01403: no data found]


please note that these errors are taking place when i upgraded from ArcSDE 9.3.1 SP2 to ArcSDE 10 SP2.

please check the attached image.

regards,
Reply
0 Kudos
Highlighted
Occasional Contributor III
Hi,

the below errors while trying to edit layers:

Could not load data from the data source.If you can correct the problem, press the refresh button to reload data.Possible problems can include bad network connection, invalid field,etc.
Underlying DBMS error [Error executing stored procedure <schema>.logfile_util.logfile_pool_get_id::ORA-01403: no data found]


underlying DBMS error[ORA-01536:space quota exceeded for tablespace 'TS_SDE_LOG_DATA_01'

have been fixed by changing the parameter "maxblobsize" under "SERVER_CONFIG" table in SDE schema.

The command to use:

sdeconfig -o alter -u sde -v maxblobsize=5000000 -i XXXX -s XX

XXXX: sde port number
XX: your server name (hosting your SDE)
Reply
0 Kudos
Highlighted
New Contributor II
mousaem is onto something... we have been editing in 10 and 10 SP1 with no problems for a few months.... after applying SP 2 two weeks ago, we started to get this error. 
I will use alter statement and see if it works for me too. Which file can I put this in so SDE starts everytime with this setting?
I see MAXBLOBSIZE in giomgr.defs... mine is set to "SE_UNLIMITED_BLOBSIZE"    sounds unlimited to me, why the need for setting to 5000000?
Reply
0 Kudos
Highlighted
Esri Esteemed Contributor
ArcSDE has been using the SDE.SERVER_CONFIG table to store initial connection paramaters
since 9.0. The 'sdeconfig' utility updates this table; changing the giomgr.defs file only matters
if you then use 'sdeconfig -o import' to post the changes to the server.

I believe the code for unlimited size is '-1' (you can query the table directly with SQL*Plus to
confirm this).

I have no idea why changing the MAXBLOBSIZE would impact session-based logfile creation;
if it works, this a great question to ask Tech Support.

- V
Reply
0 Kudos
Highlighted
New Contributor II
Hello All,

We are getting a similar error "AutomationException: Underlying DBMS error [Error executing stored procedure <schema>.logfile_util.logfile_pool_get_id::ORA-01403: no data found]" when trying to publish a version to DEFAULT.

However, I have checked our SERVER_CONFIG table and it's already set to -1.

Is the issue more likely to be related to using session-based logfiles?

Thanks
Andy
Reply
0 Kudos
Highlighted
New Contributor II
Hello,

I've managed to narrow down the cause of this to be the actual reconcile method on IVersionEdit4. The scenario that causes this is as follows:

1. Create new version V1.
2. Add a new feature to version V1.
3. Create new version V2.
4. Add a new feature to version V2.
5. Publish version V2.
6. Publish version V1.

Essentially I think it's because a reconcile has been done on V2 between creating V1 and then publishing it. For example the following does work:

1. Create new version V1.
2. Add a new feature to version V1.
3. Publish version V1.
4. Create new version V2.
5. Add a new feature to version V2.
6. Publish version V2.

Please can anyone help?

Thanks
Andy
Reply
0 Kudos
Highlighted
New Contributor II
I think I have inadvertently fixed this issue. I had another user that had an unrelated exception being thrown when trying to do selections e.g.

AutomationException: Unable to create logfile system tables. User perhaps lacks
permissions or resources to create tables [ORA-01031: insufficient privileges

I fixed this AutomationException with the following ArcSDE command

sdeconfig -o alter �??v LOGFILEPOOLSIZE=10

Therefore, it appears that by creating the following within the SDE schema it has also resolved my DBMS error e.g. [Error executing stored procedure <schema>.logfile_util.logfile_pool_get_id::ORA-01403: no data found] issue:

SDE_LOGPOOL_1
SDE_LOGPOOL_2
SDE_LOGPOOL_3
SDE_LOGPOOL_4
SDE_LOGPOOL_5
SDE_LOGPOOL_6
SDE_LOGPOOL_7
SDE_LOGPOOL_8
SDE_LOGPOOL_9
SDE_LOGPOOL_10

My question would be: Why would a reconcile operation on IVersionEdit4.reconcile have any relationship to logfiles stored in the SDE schema when the owner of the version is an user called GISEDITOR?

Is there something else that needs setting in my dbtune file?
Reply
0 Kudos
Highlighted
Occasional Contributor III
I found a similar problem when editing.  According to the help:

" Records are written to log file tables for later use by the application  whenever a selection of a specific size is made, a reconciliation or  post on a versioned database is performed, or a disconnected editing  checkout is done in a client application."

My sdeconfig settings for log files were:
  MAXSTANDALONELOGS   0
  ALLOWSESSIONLOGFILE TRUE
  LOGFILEPOOLSIZE     100
  HOLDLOGPOOLTABLES   TRUE
 
When I changed them to:
MAXSTANDALONELOGS   0
  ALLOWSESSIONLOGFILE FALSE
  LOGFILEPOOLSIZE     0
  HOLDLOGPOOLTABLES   TRUE
 
the problem went away.
Reply
0 Kudos