topic Re: Which BLK, AUX, BND table belongs to which Raster in Geodatabase Questions

Which BLK, AUX, BND table belongs to which Raster

DiegoLlamas — Wed, 01 Mar 2017 19:05:43 GMT

Hello,

I was having a problem with one of my rasters and i deleted several tables from SQL Server and now I do not see the raster in ArcCatalog or ArcMap after this but the space in the database wasn't released.

I notice I have two BLK, AUX, RAS and BND tables and I read that the BLK table store the space in the database so I need to delete it but I do not know how I can identify which BLK is for my second Raster and which for the one I already delete.

How Can I know which BLK, AUX BND, RAS tables belongs to my actual raster?

If I identify this, the other blk file is from the one i delete so I can delete this table.

Does anyone knows how can I identify this?

thanks,

Diego Llamas

Re: Which BLK, AUX, BND table belongs to which Raster

George_Thompson — Wed, 01 Mar 2017 19:19:48 GMT

Technically all the above are part of the raster. You should be able to track down the references to the correct raster via these tables: Raster datasets and raster catalogs in a geodatabase in SQL Server—Help | ArcGIS Desktop (I just searched for SQL Server)

Did the client not delete all of the associated files?

Re: Which BLK, AUX, BND table belongs to which Raster

DiegoLlamas — Wed, 01 Mar 2017 19:28:21 GMT

Hello George,

No it seems that he just delete the reference system tables from the raster in SDE.layers and other tables. He just deleted every row where the name of the raster appear. Now I am not able to identify which blk belong to the one he deleted so I can delete all this files and release the space that raster is taking.

Re: Which BLK, AUX, BND table belongs to which Raster

George_Thompson — Wed, 01 Mar 2017 19:44:58 GMT

If you have another raster that "works" then you could find all the information for that one and delete the other one. Otherwise it may be very risky to delete other files.

You mention that you only have 2 rasters in the GDB.

Re: Which BLK, AUX, BND table belongs to which Raster

DiegoLlamas — Wed, 01 Mar 2017 20:06:51 GMT

Yes, Thats what im going to do. I will follow the relation of the tables and delete the other one.

thanks for your help George.

Re: Which BLK, AUX, BND table belongs to which Raster

NeilAyres — Thu, 02 Mar 2017 07:32:49 GMT

It sounds like you are going in "via the back door" to delete database content.

Can be pretty dangerous. Why not use the normal ArcCatalog interface to do this sort of maintenance.

Re: Which BLK, AUX, BND table belongs to which Raster

DiegoLlamas — Thu, 02 Mar 2017 12:13:27 GMT

Hello Neil,

It seems that my raster somehow got corrupted because every time i tried to deleted from ArcCatalog, ArcMap or using SDE Command lines to do so, ArcMap or ArcCatalog Crushed that's way I needed to do from SQL manager.

Re: Which BLK, AUX, BND table belongs to which Raster

DiegoLlamas — Thu, 02 Mar 2017 18:30:00 GMT

So, this is what I found, did and worked fine.

since I have only one raster present, I looked for the layer_id of my actual raster from SDE_RATSER_Columns table (this raster had id 33) and then find out the BLK,AUX,RAS and BND of the specific layer id and delete the one wasn't number 33

Previously I looked into following system tables to find the entries of the corrupted raster (PR_Photo_2010).
-SDE_Table_registryTable_registry
-SDE_Geometry_columns
-SDE_Layers
-SDE_Column_registry
-SDE_GDB_items
-SDE_raster_columns

Right click and select Edit top 200 Rows for all these system tables.

.
Select the name of my raster and then right click and delete it.

Re: Which BLK, AUX, BND table belongs to which Raster

George_Thompson — Thu, 02 Mar 2017 18:45:42 GMT

I have done the manual deletion before in a database, but I had a verified backup and tested the process many times.

It is a very SPECIFIC per database workflow. I would not think that it may be the same in all cases like this.

Re: Which BLK, AUX, BND table belongs to which Raster

DiegoLlamas — Thu, 02 Mar 2017 19:10:24 GMT

That is correct George, I perform this workflow for a SQL Server 2008 R2 Database.So, this worked for this specific database and version.