この度、11月22日(米国時間)にSAS 9.4 M4(16w48)が出荷開始となりましたのでお知らせ致します。
メールくれないよりはマシだけどさ。
英語サイトの方では先週にだいぶ対応されているんだけど、何故日本は遅れるのか意味が分からない。
AMOの自動更新機能で気付くようになってるので、もう少し努力しましょうというか本国とちゃんと連携しないと厳しいよホント。
しかももうそのHotfixが出てる状況なんで。
この度、11月22日(米国時間)にSAS 9.4 M4(16w48)が出荷開始となりましたのでお知らせ致します。
メールくれないよりはマシだけどさ。
英語サイトの方では先週にだいぶ対応されているんだけど、何故日本は遅れるのか意味が分からない。
AMOの自動更新機能で気付くようになってるので、もう少し努力しましょうというか本国とちゃんと連携しないと厳しいよホント。
しかももうそのHotfixが出てる状況なんで。
COMPRESSを有効にして保存してみる事をお勧めします。
特に文字データが多い場合には有効です。固定長文字列を採用している事もあって、SASデータセットは文字データを含んでいると無駄な容量食ってる事が多いです。
暇なら、固定長文字列の長さの妥当性もチェックしてみるのをオススメします。
作業中のデータセットを無駄に永続化していないか確認しましょう。
SASでのデータ加工は、作業中のデータセットを何個も作りつつ実施する事が多いです。まあプログラムの作り上、インタプリタ言語という特性もあって、ありがちなのですが。
特に、過去の資産の中にその手のゴミを放置しておくと、いつまで経っても放置されっぱなしになるので、整理する際に消してしまうのも手です。
SASのビューを使ってみるのも一つの手です。
データセットの設計を見直し、正規化標準化マスタ利用等考えて下さい。
しばしば、特に必要のない項目をそのままなんとなく保存しているケースを見る事があります。
見るための帳票とデータセットが分離せず、ビューをそのまんまデータとしているようなデータセットは、容量の無駄が相当あります。
まあ、ここら辺になってくると、スキルとかの問題が発生するんですが・・・・・・しばしば他言語での開発でも、「Webの見た目そのまんまのデータを作ってしまう」パターン。
ただ、そう言いつつ今までその手の人を排除出来た試しがなく、スキルでは見抜きづらいところもあります。テストとかで「やる能力がある」のは確認出来ても、「そういう行為を自然と行えるか」という事とは違うんですよね。ついつい、「短時間で物が作れるか」を判定しがちです。パフォーマンスの観点も入れるとちょっとは変わるんですが、大きな課題のパフォーマンスの観点は、ナカナカ短時間のハック見てても分からないです。
SDTMも無駄多いんすよねえ・・・・・・
48410 - Attempts to enable .NET Framework 3.5 in Windows 8 Pro, Windows 8 Enterprise, and Windows Server 2012 fail
として、対応手順も記載されているのだけど、どうもこれだけでは不具合が解消しない事がある。
あ、 IT logというのは、
この対応手順は、Windowsコンポーネントを追加でインストールする場合の挙動を変更している訳だけど。
よくWSUS環境だとこの辺りについては対応されていないが為に色々面倒な事になるのだが、この変更を行うと、そこはMicrosoftUpdateから取ってきてくれるようになる。っぽい。
んだが、その後、PowerShellだかCmd.exeだかの権限絞り込みで、どうもSAS Deployment Wizardから再実行しても実行出来ないっぽい。
よく分からんし精査していないが、というのも、まあ、ここまで来たら、手で.net framework 3.5の機能を突っ込んだ方が早えよと。
しかし、これ、ネットワークが外に繋げられる場合ならいいんだけど、そうでない場合には、追加インストール用のフォルダを作っておくかメディアがないと無理。
他のコンポーネントは同梱されているのだが、これは出来ないんだろうか。まあ、サーバのコア機能だから無理なのかな。
SAS Deployment Wizardを使うと、%userprofile%\AppData\Local\SAS\SASDeploymentWizard の中にいろいろSDWの実行ログができるんだが、その中には、画面からの選択を記憶しておいてくれるResponseファイルというのがあるんだが。
これを使って記録していた情報を再生すると、途中で文字化けが起こります。
SASサーバの再構築がこれでできるかと思ったのに・・・・・・
面倒臭いなあ・・・・・・
記録側のResponseファイルがS-JISで保存されているので、それをUTF-8(BOMはいらんと思うが多分あっても問題はない)で保存すればOK。
というのをSAS9.4TS1M3で確認。生温かいバグですが、テクサポにいつ報告しようかね・・・・・・
頭を悩ませて来た問題ではあるんだけど。
混ざって来てたから一緒の問題だと思い込んでたけど、違うわ・・・・・・
HRESULT 800ac472 from set operations in Excel
Yes, you are getting the VBA_E_IGNORE error that Excel will return when you try to invoke the object model when the property browser is suspended.
:
HRESULT Codes in Excel interop in C# - Stack Overflow
HRESULT codes that start with 0x800A are internal errors in the application that you are interoperating with. The last 4 digits are the hex code of the internal error. So in your case that's 0xC472 == "Excel error 50290". That gives your user a hundred thousand Google hits. "The file used has this or that problem" gives your user no Google hits, Microsoft does not maintain a mapping of internal error codes to error descriptions and Google doesn't maintain a list of your error descriptions. Use Marshal.GetHRForException() – Hans Passant Jun 5 '14 at 21:04
へえ。
https://support.microsoft.com/ja-jp/kb/820595
オートメーション サーバーとなっている Excel 2002 は、オートメーションのメソッドやプロパティの設定を実行しようとすると、ユーザーの入力処理など Excel が他の処理を行っているかどうか確認するようになりました。ActiveX コントロールなどの外部コンポーネントとの通信の間でイベントを発生させるプログラムの場合、一時的に Excel の準備ができていない状態になることがあり、このときにオートメーションの通信を行うと、Excel は実行時エラーを返します。
Ready プロパティを使用し、アプリケーションの準備ができている場合にだけ処理を実行します。Ready プロパティは Excel 2002 で新しく追加されたプロパティです。
これらの情報は古いが、内部でおそらく同様の状況になってそうだ。
ともかく。
SASのAMOでこの手の問題が発生していて、
Excel2010で確認してみたが、プロパティはある。
ただ、まあ、これに対応しているかどうかは、VSTOアドインの中身をリバースでもせんと分からんから無理だなあ。対応していても、さてReadyに対応してりゃこのエラー吐かなくなるかは分からないし。
HRESULT 800ac472
"ExcelのExceptionなので対応が無理"という訳ではなかろうちうのは普通に思う所ではあるが、
ここらへんの情報を煮詰めて問い詰めないと、多分対応しないんだろうなあ。はあ。
うんまあ、一応言っておくと、SASのせいとは言わない。
言わないんだが、もう少しどうにかしてくれてもいい感じはある。
ウチのProxyはPACファイル仕様である。そもそも、Windows謹製のFTPがProxyに対応していないのだが。
PuTTYとか使うのがめんどい。
二通り考えられる。
上記方法で何にせよ落ちるんだけど、SAS Software Depotの場合、複数OSパターン落ちてくるんで、Hotfixとして適用出来ないものが混じっている。その場合にはやっぱりダメとか言われるので、何にせよSASHFADDを用いた方が楽。
楽、なんだけどさ・・・・・・
別にSつかないFTPでもいいんだが、なんでかよく分からんが上手く乗り越えられる気がしなかった。毎度ながらFTPは会社のFW内では通しにくい。Windowsでは。
Windowsの接続はやっぱり鬼門だなあと思う。Linuxとか大抵http_proxyとかに仕込めば乗り越えられるんだがなあ・・・・・・
でもとりあえずダウンロードまでは出来る事は確認した。
その場合には、SAS94_HFADD_data.xmlとDeploymentRegistry.txtだけが必要。DeploymentRegistry.txtは作成出来るはずだし、SAS94_HFADD_data.xmlはブラウザ経由で落とせるだろう(FFでは出来た)。
ftpは通らないが、ANALYSIS_SASHFADD_~フォルダは作成され、中のHTMLから、まとめてダウンロードする事も可能。そう、FFならね。
流石に分割ダウンロードまでやると問題あるとは思うけど、まあ出来る方法が沢山あるに越した事はない。
英語翻訳の仕事をしている訳ではないんで、ホント「日本語の情報だせ」とか要望されるのは勘弁。
Knowledge Baseには、おおよそ日本語モノより十倍以上のノウハウがあります。
support.sas.com
というかまあ、日本語ソースがあまりにも貧弱なのですが。
オススメはFocus Areaです。
support.sas.com
日本のSASコミュニティは、SAS Foundation周りのノウハウに情報が固まってますが、その情報も正直、Focus Areaに書かれていたりする情報が多いです。
ただ。
この辺り、Sitemapがちゃんと整備されておらず、ナカナカ目的の情報に到達するのは難しいかも知れません。
Googleでサルベージする方が早いかも。
色々とプロジェクトに関わってきていての経験知です。
イラッと来る事は多々有りますが、海外製品の場合、「直るまで仕様だと言い張る」事がありまして、それはまあそうだなあ(うっかり認めると賠償の問題がありますので)とは思うんですが、流石に、Usage NoteがHotfix出てProblem Noteに昇格した時に、「その取扱はどうなんだ」と思ったりはしました。
ただまあ、その手の隙間でヤクザみたいに押し寄せて来る連中ってのはグローバル企業なら当たり前のような所があり、多分日本のSIerがグローバル化出来ないのもそこら辺緩いからなあと思ったりします。
ともかくも、法曹関係は抜きにして、サッサと先に進みたいんだがなと思う今日このごろ。
こういう事のやり取りをしていると、心が死んでく感じがします。
会社としての責任を問うとか、会社としての責任回避とか、もうどうでもいいんだけどどうにかならないのかなあ。そのせいで、「何が分かって何が分からん」のかという話が茫洋とするのがホントやってらんねえ。
他に代わって質問する事も多々あります。・・・・・・出来れば、「SASテクニカルサポートにお願い出来ない事をこちらに聞かないでほしい」とか思うんだけど。だいぶ病んでます。
あそこは、製品のサポートです。
SASは売る時にはカスタマイズ「出来る」と言うんですが、カスタマイズした設定が正しいとか間違ってるとかは、「マニュアル読んで」としか言いません。
障害を見つけてしまうと、・・・・・・Caryの本社に問い合わせが流れていくんですよね・・・・・・
SASテクニカルサポートでも、誰に当たるかで回答の方向性が異なる事は多々有ります。
「MSのエラーコードをAMOが拾っているのであって、MSのサポートに確認して下さい」みたいな人と、
「本国に調査を依頼します」みたいな人がいます。
実は両者同じような対応だという事だったりしますが。前者の方が冷たいようですが、実は結構踏み込んで答えてもらっている所でもあります。まずこのパターン、解決不能あるいはパッチが出るパターンです。障害かどうかと言われると、MSの製品のせいもあるかもですしSASの場合もなくはないです。
プログラム開発や保守をしている訳ではないので、SAS Japanで何か解決用のパッチを出せる訳でもない。
回避策を、という場合でも、業務側が考えて回避する事が一番ラクなので、あんまりサポートで対応すべきとも思えないんですよね。
開発のメインルートだと、流石にSASも検証してます。あまり綺麗でない使い方、あるいは、Excelだとマクロ記録してカスタマイズ、みたいなやり方でしている使い方、なんかは、システム開発屋からは見えづらいので、いつまでもバグが残ったりします。
ちょっと綺麗に書くだけでバグってる部分回避出来たりするんだけどー、という所を、頑張っても互いに不幸になるだけだ、とは思います。
あと、SASのソリューション製品の環境を妙にカスタマイズすることは、全くオススメしません。
インストールのオプションの範疇ならわりと分かりやすいですし出来るんですが、アレ、WebServerだとかWebAppServerだとかWebDAVだとかで出来る膨大なパラメータのうち、比較的カンタンに理解されやすい部分だけを抽出しているだけです。
JVMのサイズだとかCacheサイズだとかもぜーんぶ一から設定する事は不可能とは言いませんが、SASがその設定のマニュアルを持っていません(OEMのマニュアルはあるんですがそれもApacheベースとかだとかそういう感じ)し、まるっと売ってるのはそこら辺を自力で構築すると大変面倒だからです。
本来、「/Config/Lev1」とかの下は触るものではない、という風には言われています。
で、このあたりを深掘りして完全なサポートするのは、正直どこの世界に言っても無理じゃないでしょうか。
事前に何が起こるのかとかを設定変更した場合に予測は不可能なんで、故にドライランとか別環境とか持っているものなんですよねえ。
はあ。
「if 0 then set 」って昔調べた時には情報ホント無かったんだけど、今SASプログラマの人がボチボチネットに書いてますね。
で、見てた時に、そういや某所でやってた時に、ここら辺で面倒臭い話あったなと思い出して調べてみた所、やっぱりこのコードは特定条件下でバグになります。まあ普通はならんのですけど。
参考までに、関係しそうな所に対してリンク貼っときます。TB打てないんだよなはてなブログ。
データステップ100万回 SAS新手一生: 【訂正追補】SASデータセットのオブザベーション数をマクロ変数に格納する方法_call symput
SAS忘備録: データステップ内で、色々なデータセットのオブザベーション数を取得する
SAS忘備録: 行削除の落とし穴
プログラムは↓
data _NULL_ ;
if 0 then set SASHELP.CLASS nobs=_SYS_OBS ;
put 'トータルの物理オブザベーション数->' _SYS_OBS ;
stop ;
run ;
で、ログが↓
66 data _NULL_ ;
67 if 0 then set SASHELP.CLASS nobs=_SYS_OBS ;
68 put 'トータルの物理オブザベーション数->' _SYS_OBS ;
69 stop ;
70 run ;
トータルの物理オブザベーション数->19
NOTE: DATAステートメント処理(合計処理時間):
処理時間 0.00 秒
CPU時間 0.00 秒
簡単に説明すると、最初、定義とかは取りに行くんですが、実行部分で「if 0 then」となっているので、レコード自体は読み込まれません。
この場合に、通常はdataステップはオブザベーション数分実行されるんですが、1行も読み込まない設定の場合には、1回だけ実行されます。
データの定義部に、オブザベーション数が書き込まれてるんですね。
で、「トータルの」と但し書きを入れたのは、例えば「set SASHELP.CLASS SASHELP.CLASS」とかにすると、この合算のオブザベーション数(38)が書き込まれます。
本題にも関わってくるのですが、このデータの定義部に書かれているオブザベーション数は、「物理オブザベーション数」であり、「論理オブザベーション数」ではないという事を頭に入れておいて下さい。
プログラムは以下です。
proc sql ;
create table CLASSDEL as select * from SASHELP.CLASS ;
delete * from CLASSDEL where AGE=15 ;
quit ;
data _NULL_ ;
if 0 then set CLASSDEL nobs=_SYS_OBS ;
put 'トータルの物理オブザベーション数->' _SYS_OBS ;
stop ;
run ;
SASHELP.CLASSを複写したCLASSDELというデータセットを作成します。
そして、「SQLプロシージャで」DELETE文を発行しています。この場合、AGE=15(4オブザベーション)を削除します(ホントどうでもいい事ですが、CLASSデータセットは日本語版、UTF-8や英語版などでNAMEやSEXの中の値が変わるためAGEにしてます)
その結果は?
71 proc sql ;
72 create table CLASSDEL as select * from SASHELP.CLASS ;
NOTE: テーブルWORK.CLASSDEL(行数19、列数5)が作成されました。
73 delete * from CLASSDEL where AGE=15 ;
NOTE: 4行がWORK.CLASSDELから削除されました。
74 quit ;
NOTE: PROCEDURE SQL処理(合計処理時間):
処理時間 0.01 秒
CPU時間 0.01 秒
75
76 data _NULL_ ;
77 if 0 then set CLASSDEL nobs=_SYS_OBS ;
78 put 'トータルの物理オブザベーション数->' _SYS_OBS ;
79 stop ;
80 run ;
トータルの物理オブザベーション数->19
NOTE: DATAステートメント処理(合計処理時間):
処理時間 0.01 秒
CPU時間 0.00 秒
さてと。
「このデータの定義部に書かれているオブザベーション数は、「物理オブザベーション数」であり、「論理オブザベーション数」ではない」と言っていた事に繋がるのですが、SQLプロシージャでDELETE文を発行した場合、オブザベーションがまるっと消されるのではなく、単にDELフラグが立つだけです。
そしてこの際定義部は書き換えられないです。
その為、こうなります。
同様の操作をdataステップで実行する事は可能です。但し、MODIFYなんて、まあ滅多に使わないと思いますが。
data CLASSDEL ;
set SASHELP.CLASS ;
run ;
data CLASSDEL ;
modify CLASSDEL ;
if AGE=15 then remove ;
run ;
data _NULL_ ;
if 0 then set CLASSDEL nobs=_SYS_OBS ;
put 'トータルの物理オブザベーション数->' _SYS_OBS ;
stop ;
run ;
308 data CLASSDEL ;
309 set SASHELP.CLASS ;
310 run ;
NOTE: データセットSASHELP.CLASSから19オブザベーションを読み込みました。
NOTE: データセットWORK.CLASSDELは19オブザベーション、5変数です。
NOTE: DATAステートメント処理(合計処理時間):
処理時間 0.01 秒
CPU時間 0.01 秒
311 data CLASSDEL ;
312 modify CLASSDEL ;
313 if AGE=15 then remove ;
314 run ;
NOTE: データセットWORK.CLASSDELから19オブザベーションを読み込みました。
NOTE: データセットWORK.CLASSDELを更新しました。
オブザベーションの再書き込み0、追加0、削除4
NOTE: DATAステートメント処理(合計処理時間):
処理時間 0.00 秒
CPU時間 0.01 秒
315 data _NULL_ ;
316 if 0 then set CLASSDEL nobs=_SYS_OBS ;
317 put 'トータルの物理オブザベーション数->' _SYS_OBS ;
318 stop ;
319 run ;
トータルの物理オブザベーション数->19
NOTE: DATAステートメント処理(合計処理時間):
処理時間 0.00 秒
CPU時間 0.00 秒
現在、「SQLプロシージャでDELETEステートメントを発行する」「DATAステップでREMOVEステートメントを発行する(MODYFYステートメントでデータセットを取り込む場合)」場合に、「物理オブザベーション数が論理オブザベーション数から乖離する」事がわかっています。
他に、オブザベーション数を取得する方法は、ざっと考えて二つあります。
CONTENTSプロシージャを利用する方法と、SQLプロシージャでSASHELP.VTABLE(あるいはDICTIONARY.TABLES)を利用する方法です。
proc sql ;
create table CLASSDEL as select * from SASHELP.CLASS ;
delete * from CLASSDEL where AGE=15 ;
quit ;
data _NULL_ ;
if 0 then set CLASSDEL nobs=_SYS_OBS ;
put 'トータルの物理オブザベーション数->' _SYS_OBS ;
stop ;
run ;
proc contents data=CLASSDEL out=INFODEL noprint ;
quit ;
proc print data=INFODEL ;
var MEMNAME NOBS DELOBS ;
quit ;
proc sql ;
create table INFODEL2 as
select MEMNAME,NOBS,DELOBS,NLOBS from SASHELP.VTABLE
where LIBNAME='WORK' and MEMNAME='CLASSDEL' ;
quit ;
proc print data=INFODEL2 ;
var MEMNAME NOBS DELOBS NLOBS ;
quit ;
今度は、アウトプット(LISTINGで出力)を。
OBS MEMNAME NOBS DELOBS 1 CLASSDEL 15 4 2 CLASSDEL 15 4 3 CLASSDEL 15 4 4 CLASSDEL 15 4 5 CLASSDEL 15 4
OBS memname nobs delobs nlobs 1 CLASSDEL 19 4 15
CONTENTSプロシージャの出力には変数の情報も入ってくる為その分オブザベーションが増えてしまっているのですが、NOBSは想定のものに「書き換えられている」イメージです。
SQLプロシージャで、SASHELP.VTABLEを利用すると(これは裏でせっせと情報集めに行っているので注意が必要です--対象になるテーブルだけ参照しに行きますが、WHEREの書き方やハンドリング次第ではかなり時間がかかります)、書き換わっていない「NOBS」が表示されます。
DELOBSという変数を表示させていますが、こちらが「削除された(が物理的には残っている)オブザベーション数」になります。
NLOBSはVTABLEにしかありませんが、こちら「論理オブザベーション数」です。
削除されたオブザベーションは、内部的にはデータを保持していますのでバイナリエディタとかで確認出来たりします。
あと、当然ながらパフォーマンス劣化につながります(以前SASサーバのレポジトリ肥大とかあったのはそのせいだろうなあ。今のバージョンでは確認してませんが)。
その場合には、
data <dataset> ; set <dataset> ; run ;
とか書ければ良いのですが。
あと、普段のSAS使いの人はあまり影響ないとは思いますが、Data Integration Studioで、SQLのDELETE文はわりと発行しているので注意です。
ただ、この削除方法等はRDBMSでは見かけるものです。その目的は、マルチアクセスという事にあるわけで、そういや、SAS/SHARE辺りは特に考えてなかったなあ・・・・・・面倒臭い。
SDTMの1ファイルが1GB制限であるというのは、OSや各種ファイルシステム、アプリの要件であり、この規制は無意味ではなく通信の物理制約も含めて「担保出来る範囲」という事です。
現在はだいぶ通信も安定している環境が多いのであんまり気にならないのかと思いますが、1GBではなく2GBではファイルシステムやアプリで制限が出て来ます。
例えば、ZIPの元の規約では、1ファイルのサイズが2GBを超えられず、圧縮ファイル全体のファイルサイズも2GBを超えられません。
ファイルというものが、そもそもサイズ制限が「必ず」存在し、そこを超えられないという事を認識した方が良いです。
で、これらを解決する方法は、当たり前に「ファイルの分割しかない」んです。
圧縮などのアルゴリズムも、送り手と受け手側に同じ認識がないとダメですし。これをXMLフォーマットにした所で、「物理的ファイルのサイズは制限された方がいい」のは普通です。
例えばインターネットを介したファイルの転送では、社内だとネットワークドライブとか、「仮想的にローカルディスクっぽくして扱う」のが当たり前になっているでしょうが、本来「転送はしばしば失敗し、分割して送信されているパケットは順不同になったりもする」ものです。
1ファイル辺りのサイズが大きくなればなるほど、転送に失敗する確率も増えていきます。まあ、レジューム機能つきでの転送とかもない訳じゃないですが、あまりに長い時間転送しようとすると、その通路上でのトラブルが増えます。FWでのヘッダの改造が原因だったり、長時間のダウンロードの強制停止であったり、原因は様々ですが。
てか、まず、「分割するのが基本」と思った方が良いです。
ただ、この話、「SDTMのガイドラインとして考えるべきか」というと、それとは違うレイヤなんですけどね。
ODMとかそこら辺の話です。SDTMに付随する情報として扱うべきで、本来、ファイル名+ナンバリングで逃げるのは厳しい所なんですがね。
ただ、CDISCの各種規約、骨組みはともかくとして実装が進んでいるのがSDTMな為、歪な発展するのは仕方ないですけどね。まあ結局SDTMが越境してくるような形で各標準書き換えるんだとは思いますが。
よく忘れるので。
Start Order | Server or Service | Tier | Dependencies |
---|---|---|---|
1 | SAS Metadata Server*1*2 | Server tier | |
2 | SAS Web Infrastructure Platform Data Server | Server tier | |
3 | SAS OLAP Server | Server tier | SAS Metadata Server |
4 | SAS object spawner | Server tier | SAS Metadata Server |
5 | SAS/SHARE server | Server tier | SAS Metadata Server |
6 | SAS/CONNECT spawner | Server tier | SAS Metadata Server |
7 | SAS Deployment Tester server | Server tier | SAS Metadata Server |
8 | SAS Distributed In-Process Scheduler Job Runner | Server tier | SAS Metadata Server |
9 | JMS Broker | Middle tier | |
10 | Cache Locator | Middle tier | |
11 | SAS Web Server*3 | Middle tier | |
12 | SAS Web Application Server | Middle tier | Cache Locator |
13 | SAS Environment Manager server | Middle tier | SAS Web Infrastructure Platform Data Server SAS Web Application Server*4 |
14 | SAS Environment Manager Agent | Server and middle tier | |
15 | SAS Deployment Agent | Server and middle tier |
明確な依存関係は意外なほど薄いのであるが。
薄いのであるが。
しかし、サービスのスタートアップで、レスポンスタイムアウトとか結構あるっぽいんだよなー。
ちなみに、確認用にするつもりで、サービス登録でなくシェル起動で設定しようとすると、インストールでコケるのでとりあえずサービスで突っ込んだ後にサービスを手動構成にするという荒業を行っている。自己責任でどうぞ。
あと、最小構成でも8GB程度のメモリだと起動後で既にほぼメモリを使い切ってるような状況になる(実際には6GBくらいなんだが・・・・・・)。
厄介なのはMiddle Tier(Webサービスとかが起動してる所)なので、こっち側は必要な時に上げ下げするつもりで良いのかも知れん。
各サービスの機能については、また別エントリで。
余談。
手動のサービスを上げ下げするには、管理者実行の必要がある。「net start~」もあるが、個人的には最近は「sc start~」を使っている。
*1:In clustered configurations, make sure that all metadata server nodes are running before you start dependent components.
*2:In the third maintenance release for SAS 9.4, the documentation was changed to recommend starting the SAS Metadata Server first, followed by the SAS Web Infrastructure Platform Data Server (instead of the reverse). This order is easier and more logical for deployments in which the metadata server is installed on a separate machine from the other server-tier components.
*3:In the first maintenance release for SAS 9.4, the documentation was changed to recommend that the SAS Web Server be started before the SAS Web Application Server. This start-up order helps ensure optimum performance when web applications are initialized. The sas.servers script has also been changed to incorporate the new order.
*4:The SAS Environment Manager server can start without these components. However, the SAS Environment Manager application requires them in order to provide full functionality.