SQL Server merge replication error "The schema script 'xxx.sch' could not be propagated to the subscriber" - sql-server-2005

I recently made some changes to a working publication under Merge replication which seem to have broken synchronization for the subscriber.
The error message I'm getting is:
The schema script 'ftdb_arcmessagefac64b65_76.sch' could not be propagated
to the subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001)
Get help: http://help/MSSQL_REPL-2147201001
The process could not read file 'D:\Program Files\Microsoft SQL
Server\MSSQL.1\MSSQL\ReplData\unc\xxx\20120701000581\xxxx.sch' due to OS error 3. (Source: MSSQL_REPL, Error number: MSSQL_REPL0)
Get help: http://help/MSSQL_REPL0
I've looked in the unc directory, and there's no directory 20120701000581, but there's a directory 20120706110881 from when the snapshot of the publication was updated.
I've tried reinitializing the subscription and recreating the snapshot, but the process still fails expecting the 20120701000581.
I haven't tried deleting and recreating the subscription yet, as I would rather get to the bottom of the issue before trying this. Can someone explain what may be happening and how to fix this?

this happen because subscriber cant locate snaps so you can share snaps folder in your network using UNC
http://msdn.microsoft.com/en-us/library/ms151151.aspx

After some further investigation, it appeared that I was able to make some changes to the article properties in the subscription and once the snapshot was rebuilt the subscription resynchronization ran successfully.

View snapshot agent status-> Monitor-> Right Click on Error Subscription and choose Reinitialize.
Good luck

Related

SQLServer 2012 Installed copy showing problems:

My problem is like this: I had a copy of SqlServer 2012 installed on my machine. It's been there for over 3 years without any glitches at all. Just 4-5 days ago, a problem sprouted up. When I started Management Studio it told me that
msdb got corrupted so it cannot be opened.
The complete message is something like this:
Cannot display policy health state at the server level, becuase the user doesn't have permission. Permission to the database msdb is required for this feature to work correctly.
So what could be wrong here? What sudden changes/anomalies could have crept in that has made this unstable? Someone told me it could be due to a wide range of possibilities. The reason could be anything. Even some nuget packages affect the database. Initially I though this could have been an issue with login, permissions etc. So I tried to run as administrator also. No, it did not cure this problem. If you try to create a new database it simply tells me, that I can't do it. The message is something like this:
An exception occurred while executing a T-SQL statement or batch.[Microsoft.SqlServer.ConnectionInfo]. Database msdb cannot be opened. It has been marked as SUSPECT by recovery. [Microsoft Sql Server, Error:926]
How do I recover from this? Can you provide me some guidance? Or a clue where precisely to look for the hints of problem? All my work is stalled. Any kind of assistance in recovering my ailing sqlserver installation will be humbly received.
So, I'm requesting you all to show me the way.
Thanks in anticipation.
I fixed mine with Solution C from the following website. my MSDB was corrupt and not loading so I stopped the services and replaced it with the files from the template in the SQL Server directory.
https://www.mssqltips.com/sqlservertip/3191/how-to-recover-a-suspect-msdb-database-in-sql-server/
"The templates are saved in "C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn\Templates" (the path varies by version and install choices, this is the default for SQL Server 2012). By shutting down the instance and replacing the bad MSDB data (msdbdata.mdf) and transaction log (msdblog.ldf) files with the template files I was able to restart the instance without error!" (just incase the website link doesn't work I have quoted it here).
Fissh
If your MSDB is corrupted, restore from your most recent backup. That's the safest thing to do and that's why we have backups to begin with.
If you do not have a backup of MSDB, you have a couple of options.
Recreate it. Detailed instructions here: https://msdn.microsoft.com/en-us/library/dd207003(v=sql.110).aspx#CreateMSDB. This is the best way to ensure you get a clean, functional MSDB and is the fastest way to get up and running again. IMPORTANT: Doing this means you lose all jobs, backup history, etc... that is stored in MSDB. Remember to recreate all maintenance jobs after you're done else you're just waiting for the next thing to fall over (e.g. transaction log backups no longer run, tlogs grow till you run out of disk space - now you can't run any queries that will commit transactions).
DBCC CHECKDB WITH Repair_allow_data_loss is another option which you'll probably find if you google/bing the issue. This might work but it is not recommended. The problem is you don't really know what will be lost. It works by deleting what it can't read then fix the links to get the database physically functional again. Once that's done, you'll have to go back and figure out what remains and is still functional. That is tedious and error prone. Besides, if you're gonna do this very thorough manual check to ensure all your jobs are intact, you're better off just re-creating them on a new, clean MSDB.

Oracle Shutdown error ORA-01033

I had installed Oracle 11g on windows 07,everything was working fine.But today it is giving me an error saaying ORA-01033: ORACLE initialization or shutdown in progress . I followed the steps mentioned in the different communities but unable to solve the error. After connecting as sqlplus sys/sys as sysdba. and executing below statement,i got following error. How to solve this error?
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 9: 'C:\APP\MKHATAL\ORADATA\ORCL\VELODBDATA.DBF'
ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
ORA-01110: data file 9: 'C:\APP\MKHATAL\ORADATA\ORCL\VELODBDATA.DBF'
Thanks in advance!!
First, check your ALERT.LOG file typically located in D:\app\oracle\diag\rdbms\DBNAME\SID\trace\.
The latest entries in your ALERT.LOG should give you an indication on what is going on. Is the database starting? Shutting down?
Should the database be stuck in the shutdown process, you can try to kill the oracle.exe process and then restart the database via Windows Service.
Often, when the database seems to hang on startup, it is actually applying REDO to get a consistent state, so pay close attention on what the ALERT.LOG tells you.
There's more info needed to be able to solve similar issues. Questions like these are interesting to get answered:
To what level can you start the database ? None, nomount, mount or
open (exclude the last one in this case)
What does the ALERT.LOG file show ? This from the moment the first
issue is suspected to be around
An obvious question is just : what happened ? What action were you
doing when you saw the first error message ?
Can you shutdown the database ? If yes, which methods : normal,
immediate or abort only ? Know that stopping the database with ABORT
option may make problems bigger as they are already.
Did you try rebooting the server ? This is particularly an issue on
Windows, which is your case.
Depending on how you stopped the database, do you have a cold backup
?
Depending on RMAN still working : can you take a backup ? The RECOVERY you were trying is not bad, but it could be interesting to know what is happening on OS level with that file; Is it there ? If yes, is it locked or not ? Does the OS think it's a valid file ?

How to troubleshoot TFS error TF237086 "The work item cannot be saved..."

I am getting the following error in a TFS 2010 build:
The work item '59' could not be updated: 'TF237086: The work item cannot be saved because at least one field contains a value that is not allowed.'
Work item 59 is a basic task I created to associate with my changeset on check-in. I have done no customization to the "task" work item. I get no errors when opening the task up and changing values manually. There is nothing in the build log that gives any clues as to what field is causing the problem.
How can I troubleshoot this issue?
Something I would do in this case:
Check the build service account, there's a high chance that when the work item is associated, its ChangedBy field is updated with this account and the value is not valid. Somebody in MSDN forum suggested checking the list of valid TFS users for a work item (you can open a bug and try typing the name in the AssignedTo field) and see if this account is in that list.
Try a checkin by yourself with the same associated task and see what fields are updated (you should be able to see this in the History tab), from there you can figure out the possible fields, and hopefully can guess the one that is in trouble.
If none of this works, I can get some more details and try to repro it on my machine. We'll need to improve error message to specify which fields that are invalid.
Hope this helps.
[Update]
The cause was indeed that the build service account (NT AUTHORITY\SYSTEM) did not have permissions to modify work items. All my attempts to fix this by editing group memberships failed, but I did get the build working without errors by using an unused project contributor's account as the build service account. Changing build service account may require the old build workspaces to be renamed or reassigned.
I had the same issue, after restarting VS 2015 IDE and entering credentials to my account on the TFS I was able to get rid of the errror.
After changing the build service account, I got a new error
The working folder xxxx is already in use by the workspace
1_1_SSSSSSSS;NT AUTHORITY\SYSTEM on computer SSSSSSSSS.
The solution to that issue is to use the TF utility to delete the workspace(s) associated with the SYSTEM build account. I had to copy the TF utility from my Laptop over to our server to run it.
See TFS Build Service Account change causes Build Failures - “Working Folder in use” Failures
Got the error on a long running build system where the user accounts had not changed.
found the WORKSPACE ID in the build log ran
tf.exe workspaces /owner:*
to confirm the workspace was on the build server and then ran
tf.exe workspace /delete 9_1_BUILDSERVER;OURDOMAIN\TFSBuild
to delete it, queued another build and no further problem.
If you changed process type, can throw this exception. Please correct your process type. My problem solved with the action.

"File Not Found" in MSBuild Community Tasks -- Which File?

I'm trying to use the VssGet task of the MSBuild Community Tasks, and the error message "File or project not found" is beating me with a stick. I can't figure out what in particular the error message is referring to. Here's the task:
<LocalFilePath Include="C:\Documents and Settings\michaelc\My Documents\Visual Studio 2005\Projects\Astronom\Astronom.sln" />
<VssGet DatabasePath="\\ofmapoly003\Individual\michaelc\VSS\Astronom_VSS\srcsafe.ini"
Path="$/Astronom_VSS"
LocalPath="#(LocalFilePath)"
UserName="build" Password="build"
Recursive="True" />
If I write a Streamreader to read to either the database path or the local path, it succeeds fine. So the path to everything appears to be accessible. Any ideas?
Two thoughts. One, sometimes a type load exception manifests as a FNF - let's hope that's not it. But if the code is actually being honest, you can track the problem using Procmon or Filemon. Start one of those utilities and then run your task again. You should be able to track down a record of a file that couldn't be located.
#famoushamsandwich that's a great response -- I had not previously heard of procmon or filemon. Tried procmon on the problem, but even after sifting through the relevant output (my gosh the machine does a lot more stuff behind the screen than I was aware of) I couldn't find where a file I'm referencing wasn't being found.
Procmon and Filemon are good suggestions - just make sure you filter the results to only show errors. Otherwise the success messages will bury the problem entries. Also, you can filter out processes that are not at fault (either through the filter dialog or by right-clicking the entry and choosing "Exclude Process".)
A couple other thoughts:
In the LocalFilePath, you are specifying a single file as opposed to a folder. The task, on the other hand, specifies to get files recursively. Perhaps you need to remove "\Astronom.sln" from the LocalFilePath?
Is the build task being run under your account or another? It's possible you have a permissions issue
Do you already have a copy of the code pulled down in the same location? Perhaps there is a failure to overwrite an existing file/folder?

Bewildered student vs. ORA-00257 Error--can I fix this? How?

Of course my boss is out the day something goes wrong. It's just me, an inexperienced little student here, trying to get our website back up and running. All alone.
The oracle database our site pulls data from won't let me connect (throwing the error on our site), giving me the error: ORA-00257. In full:
ORA-00257: archiver error. Connect internal only, until freed.
Cause: The archiver process received an error while trying to archive a redo log. If the problem is not resolved soon, the database will stop executing transactions. The most likely cause of this message is the destination device is out of space to store the redo log file.
Action: Check archiver trace file for a detailed description of the problem. Also verify that the device specified in the initialization parameter ARCHIVE_LOG_DEST is set up properly for archiving.
All I have is the username and password into the database. And of course the Oracle SQL Developer client.
My question is: am I equipped to fix this problem? If so, how? If it's fixable (by me), and someone can explain it, can they explain it very, very slowly and painstakingly?
If anyone can help, even if it's just to say, "You're doomed!" ...thank you in advance.
You've probably used up all of the space on the disk/partition where the archive logs are being written. Your DBA or DBA-standin should be involved at this point, because losing these logs will affect your ability to recover the database - Oracle is helping you by refusing transactions to make sure the database can be recovered if that is necessary.