go to post Chad Severtson · Jun 21 I urge folks to avoid ^%GSIZE with show details = yes unless there is an urgent need for recent size info. If you're going to read the whole database, I'd suggest an Integrity Check instead. It provides the same information but also verifies integrity.
go to post Chad Severtson · Jun 14 I use the following to get the full query. SELECT Location, RuntimeLocation, Statement->Statement FROM INFORMATION_SCHEMA.STATEMENT_LOCATIONS WHERE Location = ? OR RunTimeLocation = ?
go to post Chad Severtson · May 29 "You cannot create namespace-specific mappings to resources that are mapped in the %ALL namespace, as %ALL mappings override any namespace-specific mappings to the same resource." - Docs
go to post Chad Severtson · Apr 16 @Stefano Cairoli reminded me of my vow to update this with the release of the stochastic estimator. @Sarah Matthews did a fantastic job building it!
go to post Chad Severtson · Jan 25 I thought about it a bit. There are additional possible explanations depending on deployment topology and journal purge settings: Mirror member is offline Backup failed %SYS.Task.PurgeJournal is suspended/disabled/deleted
go to post Chad Severtson · Jan 25 Great article! I like the code snippet for more advanced automation of managing transactions. I often suggest this query to find transactions that are open longer than is suitable for operational stability. SELECT * FROM %SYS_Journal.Transaction_List() WHERE DATEDIFF('s', StartTime, NOW()) > 60
go to post Chad Severtson · Oct 30, 2023 A few thoughts: I consider <FILEFULL> or <DSKFUL> errors to be risks for data integrity -- the system is unable to write everything attempted. This is less of a risk with IRISTEMP, especially if the entire instance fails. However, if other databases are affected, you may have some physical or logical data integrity issues to resolve. Check your SQL query plans. I suspect you're generating some large temp tables if your IRISTEMP is the database that is filling up your disk. IRISTEMP is special -- it tries to keep the blocks in memory as much as possible before writing them out to the disk. If you're exhausting your disk space because IRISTEMP grew too large, then Alexander is correct: some additional global buffers could help. However, if your load exceeds your capacity, the bag will eventually burst. Setting a Maximum Size for IRISTEMP will not completely resolve the issue. However, it may make the situation more readily recoverable. If your IRISTEMP is on the same filesystem as your OS, it can be more difficult to recover without a restart. Consider setting MaxIRISTempSizeAtStart to be be able to recover more readily by automatically reducing the size of IRISTEMP
go to post Chad Severtson · Oct 20, 2023 I'd love to know more about your specific use case for using 32KB blocks for the database. In my experience, 8KB blocks are generally more adaptable unless you're exclusively working with atomic data elements that are that size or larger. IMHO, it's an instance wide consideration rather than only a database level consideration because allocating buffers of 32KB reserves a portion of the memory for blocks of that size.
go to post Chad Severtson · Sep 6, 2023 I expect transactions rolled back would be missing a TCOMMIT in the journal file. Walking the journal files and counting the TSTARTS vs TCOMMITS should give you a rough number. It could be off by the number of transactions that happened to be open at the start of the period. That error margin will vary significantly based on activity.
go to post Chad Severtson · Aug 23, 2023 Two thoughts: It looks like the Daemon in question is within the WebGateway -- not on the IRIS side. It looks like RELOAD = null is hardcoded immediately after it is checked (and is equal to one). One question: Can your change/source control fail review is RELOAD=1 is not present?
go to post Chad Severtson · Aug 22, 2023 Elijah has a great answer for this inquiry! However, I would urge caution with this approach for production systems -- especially with large volumes of MessageHeaders + MessageBodies. Reading the entire corpus of messages into memory to find a particular value could have a significant impact on overall performance.
go to post Chad Severtson · Aug 21, 2023 %request.Get("Top") will return the value which is stored in %request.Data("Top", 1). If you want to iterate through all the values, I'd use @Ashok Kumar 's solution or $ORDER on %request.Data.
go to post Chad Severtson · Aug 3, 2023 I'm late to the party, but it looks like several had similar approaches. 60 ClassMethod IsValid(s As %String) As %Boolean { f{s x="()",s=$CHANGE($TR(s,$TR(s,x)),x,"") q:s'[x} q s="" }
go to post Chad Severtson · Jul 11, 2023 Great solution! I compared the performance against querying %SYS.Journal.Records:List and found that using the objects is >10 times faster. Oddly, I couldn't execute the query via %SQL.Statement. TestJournalFileNext 0.777671s TestJournalResultSet: 10.972615s
go to post Chad Severtson · Jul 11, 2023 +1 for %ResultSet being deprecated. I'd suggest using %SQL.Statement instead. For your immediate question, it's a good practice to always check status codes. set status = rs.Execute() if ('status) { write $SYSTEM.Status.GetErrorText(status) } You also might find some information in Auditing if there is a security issue.
go to post Chad Severtson · Jul 10, 2023 You should definitely avoid putting strange journal files in your local journal directory! As Dmitry suggested, the Journal APIs will let you read the contents of a journal file. You can also use the existing Journal Profile utility for a general sense of which globals are most active in the file. set path = ##class(%SYS.Journal.System).GetLastFileName() //example, use any journal file do ##class(%CSP.UI.System.OpenJournalPane).ComputeJournalProfile(path) zw:$ZV["Cach" ^CacheTemp.JournalProfile(path) zw:$ZV["IRIS" ^IRIS.Temp.JournalProfile(path)
go to post Chad Severtson · Jun 30, 2023 Thanks for the feedback. We made sure that the product teams heard your perspective. There is a button somewhere in the new rules editor for switching back to the old one. System wide, you can also disable the web application for the new rules editor. We expect that the old ZEN based rules editor will be deprecated eventually. However, there are plenty of enhancements to the new in the pipeline based on valuable feedback like this.
