BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
PhiSlogan
Obsidian | Level 7

I have an issue with a Repository that has no path. What probably happened is that someone eliminated the physical repository folder. The metadata for the deleted repository is still active and it is in an Admin STATE. I have accessed management console as an unrestricted user but cannot seem to repair, eliminate or unregistered the metadata object under metadata manager>>repository

I have attached screenshots to illustrate the errors.repo_error.JPGrepo_error_1.JPGrepo_error_2.JPG

1 ACCEPTED SOLUTION

Accepted Solutions
CarlosSpranger
Obsidian | Level 7

I managed to Remove the Corrupted Project Repo by use Of Proc Metaoperate of the SAS® 9.4 Open Metadata Interface.

CSB

View solution in original post

7 REPLIES 7
jklaverstijn
Rhodochrosite | Level 12

Here's my 2 cents worth. I have once ran into similar issues (with project repositories) and had to save the cake by using drastic measures. Drastic enough that I shouldissue warnings and dislaimers and tell you not to do this. And then you're on your own. So make backups! And then some more. And if the damage is such that metadata backups from management console don't work, make backups of your file systems while the server is stopped. Have a solid contingency plan. This is all assuming there is no chance of undoing the work of those (hopefully ex-)colleagues of yours that deleted the physical files of your repository.

 

Then use a datastep and the metadata_delobj() function on A0000001.A5C0JUSF (did I read that correctly?) to eliminate the occurrence of that wrecked repos. Then restart your server and see what's left.

 

There are other ways like creating a new repository, backing up the files (they are SAS datasets). Then remove the repos again and dive into those tables. Find the references to the now deleted repos and edit them into references to the lost repos. Now stick those datasets in the location that was deleted in the first place. Now you may be able to start the server and get rid of this repos once and for all. I recommend to not ever to use it.

 

I expect some flame from fellow admins and rightfully so. But desperate times call for desperate measures. And if someone has a way of getting things back on track without this then so much the better.

 

Good luck!

 

Regards,

-- Jan.

PhiSlogan
Obsidian | Level 7

@jklaverstijn  I am currently heading towards the same path undesirable but now i will have to wait for our infrastructure teams decision.. I am following this issue to try recover from an earlier physical server backup...

 

jklaverstijn
Rhodochrosite | Level 12

Good luck with finding your data back; it's always your best bet.

 

I just figured out another way I couldn't possibly recommend:

 

Shut down your metadata server, make a backup of the repository manager data in <SASConfig>/Lev1/SASMeta/MetadataServer/rposmgr. Then use a SAS Base session to edit the table RPOSCTRL table in that location. Delete the record that refers to the lost repository. Restart the metadata server and hope for the best. A Metadata Analyse&Repair would be in order as a first step when (if) your server comes back to live.

 

Regards,

-- Jan.

PhiSlogan
Obsidian | Level 7

Hi @jklaverstijn  and others following this thread.

 

I have tried what @jklaverstijn suggested - editing the repoctrl  table - with the following observed results:

  1. I made a backup of the repository manager directory - /opt/sas/Lev1/SASMeta/MetadataServer/rposmgr - and proceeded to pause the MetadataServer.
  2. Then i downloaded the physical table rposctrl.sas7dabat
  3. I then loaded and edited the table rposctrl.sas7dabat using SAS Enterprise Guide - below is a code example 
    1. *nota: the objective is to delete the registered damaged repository - by the way we load the table to an existing library so as to run the program that deletes the row:
    2. Proc SQL;
      Delete from LibEx.rposctrl
      where ID=A0000001.A5C0JUSF;
      run;
  4. I uploaded the newly edited rposctrl.sas7dabat table to repository manager directory - /opt/sas/Lev1/SASMeta/MetadataServer/rposmg - and resumed the MetadataServer 

 

RESULT - unsuccessful
We Logged into SAS Management Console and found the registered damaged repository still present under the list of repositories. We have forwarded the issue to SAS Technical Support....

 

Regards, 

--PhiS

jklaverstijn
Rhodochrosite | Level 12

I first felt disappointment but then saw some hope. You say you paused and resumed the server. I'd rather stop and start instead. Just to make absolutely sure the underlying tables are released.

 

Anyways it is always a good idea to involve SAS tech support.

 

Hope this helps,

-- Jan.

CarlosSpranger
Obsidian | Level 7

I managed to Remove the Corrupted Project Repo by use Of Proc Metaoperate of the SAS® 9.4 Open Metadata Interface.

CSB
PhiSlogan
Obsidian | Level 7

@CarlosSpranger thanks!! We were struggling for days!!
I looked up the syntax for Proc Metaoperate and it solved our issue!!

Here's the reference link: https://documentation.sas.com/?docsetId=lrmeta&docsetTarget=n1jgbwzbr4219bn19szcvulhi4h6.htm&docsetV...

Here's the code i ran:

proc metaoperate
   action=delete
   repository="A0000001.A5C0JUSF"
   noautopause;
run;

 

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 7 replies
  • 2376 views
  • 3 likes
  • 3 in conversation