go to post Alexey Maslov · Apr 4, 2022 If you are interested in global moving without downtime there is (live-global-mover) Thank you, already not as new deployments of our HIS use separate document storage from the very beginning. Your solution is beautiful as it allows placing the ECP enabled "moved data" server to some less expensive disk storage. In our case that I've briefly described ECP & Mirror were already in use, so we couldn't place document DB on a separated data server as having several independent data servers would be a bad decision for many reasons.
go to post Alexey Maslov · Apr 4, 2022 To reduce the backup time, it could be interesting to move these data to a database dedicated to the archive and make a backup of this database only after an archive process ... Copy data older than 30 days to the ARCHIVE database Hi Lorenzo,We had the similar problem with our largest customer's site which summary database size overgrew 2 TB those days (now the have more than 5 TB). Our solution was more complex than yours as the data move process lasted several days, so we can't stop users for such a long time. We placed a reference to the new storage of (already moved) document data instead the document itself. After the data move was finished, namespace mapping was changed. References were left in the original DB because they took much less space than the original documents. This rather sophisticated approach allowed us to move the document data without stopping the users' activity. And what was the total win? Should the document data be backup'd? Yes. Should it be journalled / mirrored? Definitely yes. The only advantage achieved with this data separation was no more or less than the ability to deploy testing and/or learning environments without the document database. That's all.
go to post Alexey Maslov · Feb 14, 2022 And to launch IRIS do... Thanks, Evgeny. Can't notice a difference between the lines: 1 and 3, 4 and 6. Just a typo?
go to post Alexey Maslov · Feb 14, 2022 you should perform the one-liner as an argument of Xecute command Bonus: you can New other variables if you want, e.g. x "new $namespace,P set $namespace=""%SYS"",P(""Globals"")=""%DEFAULTDB"",sc=##class(Config.Namespaces).Create(""%All"",.P)"
go to post Alexey Maslov · Feb 14, 2022 Or add n $namespace before the call. Once you go up in the stack the namespace will be switched to your current namespace automatically. It would not unless you exit the current stack level. To achieve it, you should perform the one-liner as an argument of Xecute command, making it less pleasant, e.g. x "new $namespace set $namespace=""%SYS"",P(""Globals"")=""%DEFAULTDB"",sc=##class(Config.Namespaces).Create(""%All"",.P)"
go to post Alexey Maslov · Feb 11, 2022 I've succeeded with the code: %SYS>s P("Globals")="%DEFAULTDB" %SYS>s P("Library")="IRISLIB" %SYS>s P("Routines")="%DEFAULTDB" %SYS>s P("SysGlobals")="IRISSYS" %SYS>s P("SysRoutines")="IRISSYS" %SYS>s P("TempGlobals")="IRISTEMP" %SYS>Set tSC=##class(Config.Namespaces).Create("%All",.P) zw tSC tSC=1 %SYS>w $zv IRIS for UNIX (Ubuntu Server LTS for x86-64) 2021.1 (Build 215) Wed Jun 9 2021 09:48:30 EDT
go to post Alexey Maslov · Feb 8, 2022 ...make sure all integrations should work fine Hi, That's very important note. As to our experience of moving to IRIS our company's main development server, the most of the problems occurred outside IRIS: a "forgotten" Gitlab runner, or Ansible script, or other integration stuff. Those problems were mostly faced after the new server had been "lifted and shifted", as the correspondent pieces of software were the parts of our development cycle and could run on working environment only. In contrast, we had virtually no problems inside IRIS as our COS code had been preliminary converted and partially rewritten to achieve IRIS compatibility; the developers' local instances had been converted to IRIS beforehand as well.
go to post Alexey Maslov · Feb 7, 2022 ...to brand new server with iris2020.1 It's up to you, but why not install brand new IRIS on your brand new server? As you may notice, InterSystems is actively develop IRIS and usually doesn't release minor updated versions as it was in the case of Cache (e.g. IRIS 2020.1.1 vs Cache 2018.1.5). Choosing 2020.1, you are going to install the version which is near the end of its support cycle, see Minimum Supported Version Rules.
go to post Alexey Maslov · Feb 3, 2022 48! while all applauds are still to Vitaly. ClassMethod Solve(o As %String) As %Integer { a s c=$p(o,",",$i(i)) q:'$lf($lfs(o),-c) c g a }
go to post Alexey Maslov · Feb 3, 2022 Even if correct the syntax error occurred due to COS Syntax highlight: s res=0 f i=1:1:$l(o,",") s res=$p(o,",",i)+res q res it fails on Ed's samples #3, 4, 5 as it summarizes unpaired numbers: 1,-1,2,-2,3,3 returns 6 vs 3-110,110,-38,-38,-62,62,-38,-38,-38 returns -190 vs -38-9,-105,-9,-9,-9,-9,105 returns -45 vs -9
go to post Alexey Maslov · Feb 2, 2022 Straightforward one of 85 characters: ClassMethod Solve(o As %String) As %Integer { f i=1:1:$l(o,","){s x=$p(o,",",i) i $d(y(-x)){k y(-x)}else{s y(x)=1}} q $o(y("")) }
go to post Alexey Maslov · Feb 1, 2022 If you can't access Portal, you can edit cache.cpf with some text editor. SystemStart parameter is to be changed.
go to post Alexey Maslov · Nov 24, 2021 @Tony Alexander,your method is ~30% faster then "ready made" on the directory tree populated with ~ 200 files.Keep re-inventing wheels!
go to post Alexey Maslov · Nov 23, 2021 This (getFiles) method is marked as internal in Cache, and yes, it's typical internal as it's usage is relied on the strong internals knowledge :). Besides, it's hidden in IRIS, and its caller should be rewritten to achieve DBMS independence: ClassMethod ListDir2(path = "", wildchar = "*", recursive As %String(VALUELIST=",y,n") = "y", ByRef dirlist) { s pExtension=1 s pExtension(1)=wildchar #if $zversion["IRIS" s temp=$name(^IRIS.Temp) #else s temp=$name(^CacheTemp) #endif s pTempNode=$i(@temp) k @temp@(pTempNode) d ##class(%SQL.Util.Import).getFiles(path,.pExtension,pTempNode,recursive="y") m dirlist=@temp@(pTempNode) k @temp@(pTempNode) ;zw dirlist }
go to post Alexey Maslov · Oct 20, 2021 Hi Yuri, What do you mean by IoC?1) Indicator of Compromise, IoCor2) Inversion of Control
go to post Alexey Maslov · Oct 12, 2021 That approach works only for *.INT routines. Don't you use *.MAC and *.INC as well?
go to post Alexey Maslov · Sep 28, 2021 Bharathsimha, your initial question should be reformulated as "how to find global's [main] database" because all namespaces have "equal rights" for any global which is visible from (= mapped to) them. Julias is quite correct in his answering, but you should take into account that it concerns the global's main database only. If global subscript mapping is used, the full solution to get the list of all databases where the global is partially mapped is a more tricky task. If somebody is interested, I can write about how I solved it once.
go to post Alexey Maslov · Sep 14, 2021 Almost 15 minutes !!! What about the second pass with the same ObjectScript code w/o restarting IRIS? 1.7GB is not too much to be stored in the file system cache, so it should be ~5 times quicker. Besides, it's well-known that Cache (IRIS) as a record reader is not so good as a block reader. Everybody knows that %GIF is 5-10 times quicker than %GI. I have the same experience with my own developments: processing files at the block level (read block#$$$BLOCKSIZE) with records parsing at the COS level is quicker than read it record by record. `5*5=25` is close to the time difference between your ObjectScript and Python code runs. I've written this just to emphasize that we should love Python mostly for the power of its ecosystem, as Nigel wrote. As to speed, it would be better if you InterSystems guys do something to improve file i/o record level operations in IRIS engine...