Although possible - I wouldn't recommend this approach. Doing this - you have no control over the batch or commit sizes and could end up bloating the transaction log to the point it fills the drive. This will cause the insert to rollback - and that could end up taking a very long time.
Using SSIS you can control the batch and commit sizes on the OLEDB Destination. Also, using SSIS you can connect directly to Oracle with a destination directly to SQL Server and avoid the whole XML/Excel file extract and load. You still have to worry about data type conversions - but you still have those issues with files.
If you cannot utilize direct database connections - and must rely on a file - then please don't use XML or Excel. A simple CSV file will be much better and you won't be limited in the number of rows (Excel has a limit) - or be processing huge files (XML has a very large overhead).
The only way to insure you have the right data types - is to make sure you identify the appropriate data types for each column. If the source system (Oracle) is using decimal - then map to decimal in SQL Server with the same precision. If the source system is using varchar2 - make sure you map to the varchar in SQL Server with the same length.
To manage performance - SSIS will help because you can control the batch and commit sizes. Using a reasonable batch and commit size will help. If you import 1,000,000 rows all at once - then SQL Server has to commit all of those rows and that will take much longer than committing 5 batches of 200,000 rows each.