When preparing to install Oracle APEX on a db instance version 19c, I came accross the following instruction on document https://docs.oracle.com/en/database/oracle/application-express/21.1/htmig/apex-installation-requirements.html
Oracle Application Express requires the system global area (SGA) and
program global area (PGA) to be at least 300 MB.
I checked parameter and found the following value
SQL> SHOW PARAMETER MEMORY_TARGET
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
memory_target big integer 0
on step 4, the documentation states
If the value is 0, your database is using manual memory management.
Consult the Oracle Database Administrator’s Guide to learn how to
configure an equivalent memory size using manual memory management,
instead of continuing with the steps that follow.
I consulted Oracle Database Administrator's Guide, but I did not understand how to check that requirement when value of memory_target is 0.
How to determine if database instance configuration is in accordance with this requirement if memory_target is set to 0?
current instance configuration
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target big integer 1536M
pga_aggregate_limit big integer 3G
sga_target big integer 6G
sga_max_size big integer 6G
Related
I have downloaded Oracle Database Sample Schemas from GitHub and I'm following the official guide about how to import the HR schema manually.
Oracle SQL Developer prompt me with this banner: Enter value for 2:
Which is caused by the lines:
PROMPT specify default tablespeace for HR as parameter 2:
DEFINE tbs = &2
Now.
Being an official guide for newbies I expect at least an explication about the value I need to enter.
Especially because Oracle is providing the data so they must know if the default value should be 2, 200, 2000, etc..
What should I enter there?
A number or a string?
Are these Kb or Mb?
You need to supply the name of a TABLESPACE; this is specified in the instructions in the README.md file in the Github repository:
Use your current SYSTEM and SYS passwords, and also your actual default and temporary tablespace names. The passwords for the new HR, OE, PM, IX, SH and BI users will be set to the values you specify.
If you have not got an existing TABLESPACE that you want to use then you need to create one using the CREATE TABLESPACE command.
I.e. one example is:
CREATE TABLESPACE tbs_01 DATAFILE 'tbs_f2.dat' SIZE 40M ONLINE;
Then, if you didn't have an existing tablespace you wanted to use and had used the above command, the value you would need to provide is: tbs_01
I know that basically while creating a database, the model system DB is copied so based on the pictures below:
Why the initial size is 3MB for PRIMARY file and 1MB for LOG If the documentation clearly says that It should be 8MB for versions above 2016 and 1MB for anything lower (I'm on this category as I'm using 2014)
I understand that a log file could grow to 2TB maximum but why the Model database says unlimited and the STACK database says limited to 2TB?
Assuming that the actual default size is indeed 3MB and 1MB, why on the disk, I see 2240 KB and 560 KB?
Although the documentation for 2016 and later versions do say that the initial size is 8MB, I can't find references to the 1MB initial size in the 2005, 2008, 2008 R2, 2012 and 2014 versions. I don't have a 2014 version at hand but in 2008 R2 the initial size of model is also 3MB, so it seems to be the default initial value (maybe you confused initial size with the default autogrow value of 1MB).
In this point the documentation doesn't seem to be 100% accurate, because in all versions prior to 2016 they list the default autogrow of the primary data file as 10% when the real value is 1MB. Also, for the model log file the maximum size is Unrestricted/Unlimited (if you do select * from model..sysfiles the value of the size column in log row is -1) but when you create a new database the maximum size of the log file is indeed 2TB, I think that this is explained by this paragraph of the 2014 documentation:
If you modify the model database, all databases created afterward will inherit those changes. For example, you could set permissions or database options, or add objects such as tables, functions, or stored procedures. File properties of the model database are an exception, and are ignored except the initial size of the data file.
So I think that the documentation just coalesce the two facts, meaning that the maximum value of the log file for new databases is 2TB.
Because that column of SSMS don't shows decimal values, so the real value has to be rounded to an integer. Instead of using ROUND() probably they use CEILING() just to be in safe side (at least for low values, if not a size of e.g. 490KB would be reported as 0MB).
I've created a new page of type List from wizard to show all the fields License Permission (2000000043) system table in NAV 2015.
This field is populated only in the records where Object Type is LimitedUsageTableData and it's an option with the following
Option Strings = , Included, Excluded, Optional
I haven't found an official documentation that explain the meaning of the different values and how to change them (The License Permission table is read-only).
I think this might be related to the limits a user with Limited User license can have.
Just for an example, the table Service Order Allocation 5950 has Limited Usage Permission = Optional. What does it mean?
Limited users licensing is explained in detail in the document named "Microsoft Dynamics NAV Licensing Guide". You can download the latest version from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54248
In short, limited users are allowed to read any table and write to any 3 tables only. You do not need to specify which 3 tables would that be, NAV just counts database writes until there will be an attempt to write to 4th table.
In addition to this rule, there are granted tables which are not counted when you write to them, and there are restricted tables you can never write to.
Limited Usage Permission = Included - means that table is granted and does not count towards maximum of 3.
Limited Usage Permission = Excluded - means that table is restricted to write (e.g. G/L Entry)
Limited Usage Permission = Optional - means all the rest
You are not able to change these values as they are changed by Microsoft only and are part of a license. But partners are able to elect some of the tables in their ranges to be "Included" (which has to be approved by Microsoft).
I'm not very familiar with MS Access, but a user would like us to create a link to a SQL Server database for him to connect to via MS Access for reporting needs. I tried on my machine, using MS Access 2013, to connect to the database. I tried both options i'm provided with when connecting to an external datasource (ODBC Database). Import the source data as well as link the data source via a linked table.
Both options import the table I want, via a Readonly account our DBA setup, but when I look at the table I noticed that the Primary Key (column name = Id) is missing when viewing in MS Access. Also a bit field we have, which is populated in the SQL Server DB with 0 or 1, in MS Access has rows with -1 instead.
I tried to connect to the database using Sql Server Management Studio, using the Read only account and i'm able to see the primary key as well as the bit field fine.
Any ideas what I might be doing wrong, to be able to see the Primary Key and the bit field properly in MS Access.
The second question you asked about why TRUE is represented as -1 has been asked before. It's the same convention as used in BASIC. TRUE is equal to NOT FALSE. If FALSE is represented with a zero in 16 bits, and if NOT is the bitwise complement, then TRUE is represented by 16 bits set to one.
16 bits set to one, in twos complement notation, is equal to minus one.
What is the datatype of the ID column if it is an Int (Integer) then it should work fine but if not it may be incompatible with Microsoft Access.
The bit column can be set to use a Check Box if you go into the table design Select field and click Lookup Tab in the bottom pane. This setting will not persist if you relink the table however.
Today I did a test using AnyDAC (firedac) to fetch all data available in my remote SQL Server 2012.
My table that I fetch data from has these simple columns:
1. date - (size 3 byte)
2. time - (max 5 byte)
3. int - (4 byte)
4. bit - (1 byte)
5. int - (4 byte)
6. float - (4 byte)
7. float - (4 byte)
8. int - (4 byte)
9. int - (4 byte)
Total row size should be max 33 bytes.
Well, after fetching all rows available in my table (more than 2.14 million rows), I checked the received tcp traffic by FireDAC and observed that it is around 280MB which means each row needs around 130 byte while my expected value something close to 33 bytes.
Another measurement that I did by using a stored procedure defined on server side which have an insert sql to the same table above and I called the stored procedure using Array DML feature of AnyDAC. Array size was 300K and totally I have added 18.8 million records using it. Traffic used for it realized as 2.85 GB. (so 150 bytes per row)
Is there any configuration on FireDAC or SQL Server side to reduce traffic? Obviously, there is something wrong here. Any suggestions?
Thanks.
Info output:
================================
Connection definition parameters
================================
User_Name=*****
Password=*******
SERVER=sql.***.gen
ApplicationName=Bist
Workstation=NB
DATABASE=BIST
MARS=yes
DriverID=MSSQL
================================
FireDAC info
================================
Tool = D18 Architect
FireDAC = 8.0.1 (Build 3279)
Platform = Windows 32 bit
Defines = AnyDAC_Unicode;AnyDAC_DBX;AnyDAC_NOLOCALE_META;
AnyDAC_MONITOR
================================
Client info
================================
Loading driver MSSQL ...
Loading odbc32.dll driver manager
Creating ODBC environment handle
Searching for ODBC driver ...
Checking for ODBC driver [SQL SERVER NATIVE CLIENT 11.0] ...
Found [SQL Server Native Client 11.0]
Driver Manager version = 03.80.7601.0000
================================
Session info
================================
Current catalog =
Current schema = dbo
Driver name = sqlncli11.dll
Driver version = 11.00.2100
Driver conformance = 3
DBMS name = Microsoft SQL Server
DBMS version = 11.00.2100
Your network traffic to the SQL database server includes MUCH more than just the data you're looking to transmit (as you have observed by seeing much more traffic received than just row data)
Before I start, let me disclaim a few things: I am in no way an expert on network traffic and protocols, but have spent a fair amount of time playing around with them to understand enough. I also do not know much about what protocol the particular DAC software, query combination, etc. would employ to bring you your requested data back. That being said, I cannot give an exact example. but the concepts should still apply.
Communication with SQL server occurs through various protocols, however we will focus on just 1 for the sake of argument: TDS (Tabular Data Stream) protocol. (You can read more about SQL Server Protocols at: You can read more on SQL Server Protocols at: http://msdn.microsoft.com/en-us/library/ff420673(v=sql.105).aspx). TDS uses the TCP protocol, thus a TDS packet is nothing more than a specification wrapped in a TCP packet).
With TCP, communications are basically with a Request / Response type of exchange involving many request / response / acknowledge packets. Again, I am by no means an expert on this, but you can read more at http://en.wikipedia.org/wiki/Transmission_Control_Protocol
The "acknowledge" (or confirmation) aspect of the communication alone accounts for a fair amount of overhead beyond just the row sizes you referenced. You can see an example of this in the image below where communication is occurring between a client application and a SQL server:
Additionally, within the actual packet being sent pack to the application from the DB server, there is a lot of overhead within the TCP packet protocol itself along with overhead within the TDS packet.
Lets focus just on the TDS packet's overhead that adds to your overall data transfer payload. Below are all documented (http://msdn.microsoft.com/en-us/library/dd340794.aspx) of what can be found in a TDS packet:
ALTMETADATA
ALTROW
COLINFO
COLMETADATA
DONE
DONEINPROC
DONEPROC
ENVCHANGE
ERROR
FEATUREEXTACK
INFO
LOGINACK
NBCROW
OFFSET
ORDER
RETURNSTATUS
RETURNVALUE
ROW <- This is where your data is
SESSIONSTATE
SSPI
TABNAME
TVP ROW
And all the while, really your ACTUAL data (in the case you described above) is located within the ROW portion of the packet.
Below is a screenshot showing an ASCII version of 1 TDS packet. The highlighted portion of the packet frame (on the right) is the actual row data. All the rest is just overhead that makes the entire communication and ancillary things just work.
And this does not even include the overhead (albeit necessary) created by TCP itself.
In summary
You're transferring an extremely large amount of data and that data will always have overhead.
If the data is going to be summarized in the end, then summarize it on the DB server before shipping it.
If the data is going to be searched, offload that search to the DB server and just return what you need
If you need to list the data out (each row), then you're probably showing only a sub-set of results per page - only return those results you need through something like a SELECT TOP 50 .... WHERE ....
There are many other solutions depending upon your actual use of the data, but these are just some ideas.
Hope this helps!