I've noticed recently that my distribution db is massive, and while searching for solutions, I keep coming across articles mentioning that these 2 jobs should be running:
"Agent History Clean Up: Distribution" and
"Distribution Clean Up: Distribution"
Other users have reported that these seem to be disabled by default, but, I do not see them at all(under SQL Server Agent > Jobs). To ensure that it wasn't something to do with my specific instance of replication, I created a dummy instance and the jobs were still not created.
How do I ensure that these are properly created?
I ended up having to completely disable distribution on the server, and re-configure it, from scratch (I used the GUI).
Related
This question is related to I need help upgrading OroCommerce to 4.1.1.
I'm getting several errors related to extended entities... I believe there must be something wrong with cache building but I can't find the root cause (nor a solution :( ).
I checked the db structure in my production server against the VM where everything is working just fine and I can't see any significant difference (meaning the new fields such as digitalAsset_id for oro_attachment_file table or wysiwyg for oro_fallback_localization_val are there).
I just run an extra php bin/console oro:migration:load --force -e prod it didn't make a difference...
Edit:
Just checked the differences in the var/cache directory of both installations and in fact I see that the VM version has the methods that are missing from the prod one.
I uploaded the working code into the production server and re run the platform upgrade but I'm still running into issues.
In case oro:migration:load command (or oro:platform:update that actually triggers migration load) failed for the first time, you have to:
fix errors,
restore from the database dump
and run the command again.
Otherwise, there could be migrations that end up with errors,
but on the second run, they are not executed again, which could lead to the mess with the database schema, entity metadata, or entity config.
Also oro:migration:load command is not self-sufficient. There could be a need to warm up some entity configuration after the schema change. Please, try to run oro:platform:update, even if all the migrations are already executed, it would try to warm up all the caches and could fix an error.
I am using SIFLess to install Sitecore 9.1 Update 1 on my local machine in order to get started with development with my team. However, the install is not creating certain databases on my system that are needed to get up and running, most notably the Reporting database. This of course causes problems when I deploy code from my team's repo to my local instance as it references these databases. I see that the SIFLess-generated PowerShell script has calls to a 'RemoveDatabase' function that references these databases in the uninstall method, but no code to create them in the first place during an install. The missing databases are:
MarketingAutomation
Messaging
Processing.Pools
ProcessingEngineStorage
ProcessingEngineTasks
ReferenceData
Reporting
Xdb.Collection.Shard0 and 1
Xdb.Collection.ShardMapManager
These are what I have gleaned from the uninstall logic in the PowerShell script generated by SIFLess. Again, no logic exists to create them in the first place in the install section. My team members all have these databases on their systems. What am I doing wrong? I am a Sitecore novice here.
Please make sure you are using the good package. You have to download the XP package, not XM. (Just to be sure here). Afterwards, the Database installation are done with DacPac found within the Sitecore Web Deploy Package ( *.scwdp).
Please, also make sure that within this scdwp you can see (can double click or extract) the database missing :
MarketingAutomation
Messaging
Processing.Pools
ProcessingEngineStorage
ProcessingEngineTasks
ReferenceData
And do the same with the xConnect SCWDP, and make sure you see the databse missing there :
Xdb.Collection.Shard0
Xdb.Collection.Shard1
Reporting
Sometimes, if you have tried the installation script more than once, you can have some undesired behavior. You are possibly trying to go forward with the wrong certificates. Also, some services were actually created on previous installation attempts.
Here is what I think should help you get through.
Clean your workspace
Remove your databases that are related to the installation if exists.
Remove your certificates (using certlm -> you can type in your windows search bar "cert" and then you should be able to pick "Manage computer Certificate".
On the left sidebar, Click on Personal > Certificates.
Remove your installation-related certificates
nameOfYourInstallation.identityserver
nameOfYourInstallation.sc
nameOfYourInstallation.xconnect
Open your Windows Services Manager (you can type in your windows search bar "services" and select the services app)
You should be able to see those services :
Sitecore Marketing Automation Engine - nameOfYourInstallation(might be one of your previous install)
Sitecore Processing Engine - nameOfYourInstallation
Sitecore XConnect Search Indexer - nameOfYourInstallation.
Write those down. Keep your service app open.
Using NSSM (probably installed already from some of your previous installed, if not, can use chocolatey ( https://chocolatey.org/packages/NSSM ) remove those services.
in a cmd : nssm remove serviceName
Note that you can remove them by right clicking etc. I just prefer the nssm way.
When its done, restart your computer (some services and in a state of removal, that needs a restart to be completely removed)
Try to install again.
Hope it helps, cheers !
Is it possible to delete old builds in Gitlab CI?
I tested a few things and have now about 20 builds that are useless (most are failed anyway).
It also shows stages that I don't have anymore which kinda clutters the Pipelines page and some of the uploaded artifacts are a bit big.
I wasn't able to find any documentation on this, only that disabling CI in the settings doesn't remove the builds.
Using Gitlab 8.10 Community (hosted by Gitlab.com)
There is currently no option in the GUI to completely get rid of a build other than expunge related data from the build. (The erase option in the build)
If you would have a local installation you could modify the database directly but I would advise caution. (I'll put the guide here for completeness sake)
Login to the GitLab database. If you use the default PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
Check if there is a table ci_builds. For pSQL: \dt
Delete the builds with normal SQL. For example: DELETE FROM ci_builds WHERE id = 2
(Optional) If you want to cleanup a list of commits which triggered a build you need to midify the table ci_commits.
Exception Message: Unable to create the workspace '9_20_NAME' due to a mapping conflict. You may need to manually delete an old workspace. You can get a list of workspaces on a computer with the command 'tf workspaces /computer:%COMPUTERNAME%'.
Details: The path D:\Builds\NAME is already mapped in workspace 9_22_NAME. (type MappingConflictException)
Exception Stack Trace: at Microsoft.TeamFoundation.Build.Workflow.Activities.TfCreateWorkspace.Execute(CodeActivityContext context)
at System.Activities.CodeActivity`1.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
So the above has been plaguing me for just over a week now and on the surface it seems like a simple issue, delete or rename the workspaces and move on. However this issue won't shift that easily.
In short I have tried the following:
Cleared Workspaces
Created new build definitions
Moved the build folder location (e.g. D:\builds\name to D:\builds\name-2)
Build machine restart
Uninstalled / Reinstalled TFS (2013 update 3)
Rebuild the build machine and restored the TFS database
I've pretty much narrowed down the issue to something within TFS itself, but for all the good will I cannot find out what.
It's worth noting that when I delete the workspaces (using TFS sidekicks) the builds will run upto a handful of times. I've not narrowed down exactly what causes change from success to failure, however I can delete all the workspaces then run the builds a couple of times without issue and then suddenly this will come back (around 2-3 builds before constant recurring failure).
My solution was to edit my build definitions > Source Settings > Build Agent Folder and change this from a hard coded value to $(SourceDir).
A team member pointed me to this answer but I'm none the wiser as to why this setting would cause this behavior.
You will need to go to the build machine, search for the old workspace that use the same build definition name, delete that one so the build can create new workspace with the same name again. Check this blog: https://mohamedradwan.wordpress.com/2015/08/25/unable-to-create-the-workspace-due-to-a-mapping-conflict/
Also, try to rename your build definition to something unique to see whether this will fix the issue. http://blog.casavian.eu/2014/04/02/build-workspace-issue/
I have one jenkins job.
My first configuration stores the last 60 builds.
After 32 builds I get following message:
Build execution is suspended due to the following reason(s):
Your total DEV#Cloud disk usage is over your subscription's quota. Your subscription Free allows 2 GB, but you are using 2052 MB across all services (Forge and Jenkins). To fix this, you can either upgrade your subscription or delete some data in your Forge repositories, Jenkins workspaces or build artifacts.
Ok, the build artefacts are to big.
Now I configured the jenkins job to store 60builds and only 3 artefacts.
Where can I find the (old) build artefacts?
Where can I delete them?
You can manually delete build artifacts by deleting builds. This can be achieved by selecting a build from build history and then deleting it with the "delete this build" link. This is quite cumbersome, so a better solution is to go to build config and do the following: check the "discard old builds" checkbox, click "Advanced" button, put a suitable value to either the "days to keep artifacts" or "max # of builds to keep with artifacts".
You could also install the disk usage plugin, which gives you information on how much space your jobs are taking.
Here's a wiki article about managing disk usage on DEV#cloud.