Wireshark is a great tool, and it's likely your best option for actually viewing the traces on your system.
However, you would need to use another tool to actually collect the trace if you are not running on Windows. Packet tracers vary by platform, with tcpdump being by far the most common (and easiest to find information about how to use it online), but you may also need to use iptrace or snoop, which are similar, but have their own quirks.
Yes, you can compact and truncate the database, though depending on your version, those utilities may not be safe to use. The most recent alert on that is here. If you're on a version older than that, you can run GBLOCKCOPY to clear up space, though that requires downtime.
These messages generally mean that a process is trying to run a routine as it is re-compiled, and the kernel realizes that the routine has changed out from under it. They don't necessarily indicate a problem, hence the informational 'level-0' message.
I suspect that the database has 2 KB block size. It would be mountable in 2008, but not in 2014. If you still have access to the 2008 system, you can run GBLOCKCOPY to convert the database to 8 KB blocks.
I don't see anything recently suggesting a similar problem or any changes in the product (though I may have missed something). I suggest filing a WRC issue for this for a more detailed investigation, but I'll give you my best guess here:
I suspect you typically start/stop the instance as a user that is not an Administrator. When you did the upgrade, you did so as an Administrator, and that left the instance running, started by an Administrator. The difference in which user started the instance likely caused the problem shutting down as another user. Given that, I'd expect that subsequent startups as a non-Admin user would allow for shutdowns also as a non-Admin user.
If this isn't the case, please provide the cconsole.log and the Caché SYSLOG ('do ^SYSLOG' from the %SYS namespace) to the WRC, and we'll be happy to help.
You can assign a custom resource to the Message Viewer, per this documentation. See screenshot below (the assign button). You'd just need to make sure users that actually need to be able to use the message viewer have access to whatever custom resource you assign. There's also more information about the Ensemble Management Portal security in general in this documentation, which might help.
From what I've gathered from Oracle, CDC is just a way to replicate data onto another system. If that's what you're looking for, Caché mirroring is the answer you're looking for. Take a look at:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KE…
That's the general mirroring information for how it works. Contained in that chapter is information about reporting asyncs, which is what it sounds like Oracle's CDC is for:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KE…
Though, it looks like Oracle replicates data to a different database on the same system, which mirroring will not allow. If you want to do replication to a different database on the same instance (though I can't think of a use case for that), you could use shadowing instead:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KE…
There are a few good suggestions here, and I just want to add another one. You could write custom code as a wrapper to call API's for whatever you're changing (whether adding users, tasks, etc.). Then, on all mirror members, you could configure a REST service that would accept requests to do the same (aka call your wrappers based on the request payload). Then, when you call a wrapper to, for instance, add a user, your code would call the REST service on the other mirror members, which would trigger adding that user on those members, and call the Security.Users Create method to add the user on the local instance.
There are no built-in REST APIs to call the API's, but you could easily write one.
All the methods to retrieve the list and add/remove databases from the list are documented in the Backup.General class here. As John mentioned, there is no way to freeze or thaw individual databases; it is a system-wide operation.
I'll tackle question 2:
For deciding which backups to take in an ECP environment, it really depends on your setup. In a somewhat typical setup, you'd have the data on the database server, and code on the application servers. In that case, you would definitely want to back up the database server (since that's where the data is), but you may not need to back up the application servers if you have some other repository (such as source control) for your code base.
I am not quite sure what you mean by having multiple data servers with the same instance name and database name. Can you elaborate? It is certainly possible to mirror your database server in an ECP environment.
Finally, I just want to note that you are talking about sharding, but tagged this as a Caché post. Only InterSystems IRIS supports sharding, not Caché. You probably want to tag this post with IRIS instead of Caché (or both, as your 2 questions really are quite separate).
You probably want to check out this Global Summit presentation from this year. The entire presentation is useful, but you might want to skip ahead to slide 70 for your purposes.
The best place to start would be our learning portal. There is an InterSystems IRIS learning track, and it has videos and courses that include sandboxes.
First, when you say you "loaded" 2017.2 onto your machine, did you do an install or something else?
It sounds like you have a corrupt Windows registry. If you didn't do a full installation and just copied files onto the machine, that would certainly have caused this.
If you did do an installation, I'd suggest contacting the WRC, as this should never happen, and we'd like to get to the bottom of it. We'll definitely want to look at the cconsole.log and the installation log (in C:\Windows\).
You wouldn't share CACHETEMP, but you could easily create a database that is non-journaled that you can share across ECP application servers.
The short answer is that you cannot restore a CBK from AIX (a big-endian system) onto Windows (a little-endian system). You would need to restore the CBK on another location on AIX (or another big-endian system), and copy the CACHE.DAT to the Windows system, where you can run the cvendian utility to convert the endianness. Note that this comes directly from that page of documentation:
Note:
This utility does not work for backup and journal files. You must restore databases on a platform of the same endian, move the restored databases to the different endian platform, and then use the cvendian utility to convert the databases.
I'd suggest taking a look at this documentation. It should be exactly what you need.
As far as I know, there is no built-in solution for this, but maybe someone else on here has built something.
If you want to build your own solution, the journal files are accessible via API's (See the %SYS.Journal.Record class, as well as %SYS.Journal.File). The Management Portal has a page with a journal 'Profile' that uses some of the methods in the Record class. It is viewable at <IP>:<port>/csp/sys/op/UtilSysJournals.csp -> Profile. That page simply prints the total number of updates to each global within one journal file, but you could easily do much more with the API's and the files (say, loop through all the journals for a specific date and keep track of the final values of each global throughout the day, and write that into a human-readable CSV or text file).
It might be best to open a WRC issue for this, but this is a fairly common error message that actually has nothing to do with SSL. This is generally a sign of 1 of 2 problems, depending on your platform:
Unix: Incorrect permissions on the cuxagent binary on the PRIMARY mirror member. The permissions on that file should look like:
[root@RH7-64-001 bin]# ls -l /intersystems/CACHE/bin/cuxagent
-r-sr-x--- 1 root iscagent 27468 Sep 13 13:40 /intersystems/CACHE/bin/cuxagent
Windows: Generally a problem with the ISCAgent being unable to actually find the instance or access the cache.cpf file. If you look in C:\Windows\system32\iscagent.log, you should see the reason for the problem.
If this doesn't point you to the solution, I definitely suggest contacting support.
The real question is why is that a problem? There are quite a few things involved in shadowing:
1) Processes retrieving/writing journal files
2) Dejournal reader process which reads those files and queues up records for sets/kills into database
3) Dejournal worker process which actually does those sets/kills
4) Dejournal prefetchers which fetch blocks from disk so 3) doesn't need to do disk reads itself
Most likely, you have 16+ dejournal prefetchers, optimizing the performance of shadowing keeping up with your source system.
There are 2 scenarios that cause a journal sync that you missed:
Hansel,
A common problem for users setting up mirroring for the first time is to add the IP intended to be used for the Virtual IP directly to the machine before creating the mirror. That IP address needs to be free (unassigned) when you create the mirror, so that mirroring itself can assign the IP to the interface.
For what it's worth, @Aaron Wassall and I gave a presentation at a previous Global Summit about common pitfalls when using mirroring (this problem included). It is available here: https://learning.intersystems.com/course/view.php?id=1025
you shouldn't need to give the ISCAgent root permissions to get it to work. you should contact the WRC, so we can take a look at this system to avoid this workaround.
The method you are trying to use is not documented - if you look in the class reference, it is not there. This data is internal. As @Alexander Koblov suggested, you should use the SYS.ECP class. If you want the byte transferred information, that is available in mgstat. If there's a particular piece of information you need that isn't available with a supported method (or you can't find it), contact the WRC.
All you need to do is shutdown the instance on the primary. This is documented here:
If your Veeam backup is short enough (on the order of a few seconds), there's really no need to do this, but if it's on the order of minutes, not seconds, that may be a good plan.
Your real problem here is the memory usage on the system. It may or may not be Caché using up all the memory, and that's where your investigation should focus, but I wanted to give a technical explanation here for why the write daemon specifically is getting killed.
Most of the memory used by Caché is allocated at instance startup, and is a 'shared memory segment', which you can see with 'ipcs'. Other (Caché and non-Caché) processes allocate memory for individual processing, but the vast majority of memory used by Caché on a running system is this shared memory segment. The largest chunk of that shared memory segment is almost always global buffers (where database blocks are stored for access by Caché processes). Anytime a database block is updated, it is updated in global buffers, and the write daemon will need to access that block in memory and write it to disk. Therefore, the write daemon ends up touching a huge amount of memory on a system, although almost all of that memory is shared. The Linux out of memory killer doesn't prioritize processes using individual memory vs. accessing shared memory segments, so the write daemon is almost always its first target (as it has accessed the most memory), even though killing that process doesn't actually free up much memory for the system (since that shared memory segment doesn't get freed until all other Caché processes detach from it).
This is what reporting async members are for. You can run an archiving task on the async to move the data to another database (or different globals in the same database, however you want to do it), then purge the data on the primary. As long as the reporting process knows where to look for the data, you're all set.